truezip: The TrueZIP Homepage

TrueZIP is a Java based Virtual File System (VFS) which enables client applications to access ZIP, TAR and derivative archive types transparently as if they were just directories in a file’s path name. Following are TrueZIP’s primary features:

Easy to use:
TrueZIP features drop-in replacements for the java.io.File/FileInputStream/FileOutputStream classes. If you know how to deal with these classes, you can instantly use TrueZIP - though you should really, really read the manual to bypass some common pitfalls and power up your client applications with some advanced I/O tricks.
Thread-safe:
Multiple threads can access the same archive file at the same time. Where restrictions apply, TrueZIP enforces them to prevent client applications from corrupting archive files.
Unlimited nesting:
Client applications can create and access nested archives up to a virtually unlimited nesting level: outer.zip/inner.tar.gz/nuts.jar/META-INF/LICENSE.TXT is a perfectly valid path name.
Strong cryptography:
Forget WinZIP’s contended encryption, abstain from PKZIP’s patent bombed encryption! TrueZIP’s Random Access Encryption Specification (RAES) is open source and features continuous 256 bit encryption and authentication with SHA-256/AES-256/CTR. Furthermore, RAES can be applied to any data payload, not just ZIP files.
Easily extensible:
TrueZIP can support virtually any archive type via its pluggable archive driver architecture. TrueZIP ships with archive drivers for ZIP, TAR and all derivatives (JAR, TAR.GZ, TAR.BZ2, TZP, …).
Relentlessly robust:
TrueZIP ships with numerous assertions and comprehensive unit tests to ensure maximum reliability. Companies like JBoss, Vignette and many more rely on TrueZIP to deploy applications and content.
Fu*ing fast:
Despite the startup time of the JVM and despite the overhead required to implement a VFS, TrueZIP’s nzip utility main class unzips the sources for JDK1.5.0_09 even slightly faster than 7-Zip (details to follow in a future article on this web site).
100% open source:
Covered by the Apache Software License, Version 2.0.
100% pure Java:
No native code incorporated.

JIIC: Java ISO Image Creator

JIIC is a streaming-based Java implementation of ISO 9660 for creating CD-ROM filesystem images (”ISO images”) with the extensions El Torito, Joliet and Rock Ridge. It is based on the SABRE streaming API and provides an Ant task for easy integration into Java-based build processes.

Modify archives, Part 1 - Java World

Modify archives, Part 1
Supplement Java’s util.zip package to make it easy to write or modify existing archives

By Allen Holub, JavaWorld.com, 07/28/00
I started out this month intending to write an article about caching class loaders. I wanted to create a class loader that a client-side application could use to automatically update itself from a server-side version every time the application ran. The idea was for the class loader to maintain a jar archive of the class files that made up the application, and to update that archive as needed during the class-loading process. I still intend to write the class loader article at some point in the future. But when I started writing the code, I quickly bogged down in implementing the archive-related piece. It turned out that the java.util.zip APIs weren’t nearly as flexible or complete as I had thought, and I had to put a significant effort into a set of archive-maintenance classes before I could proceed with my class loader. Consequently, this article and Part 2 will present those classes; I’ll return to the class loader afterwards.

TEXTBOX:

TEXTBOX_HEAD: Modifying archives: Read the whole series!

* Part 1 — Supplement Java’s util.zip package to make it easy to write or modify existing archives

* Part 2 — The Archive class allows you to right or modify stored archive files

:END_TEXTBOX
Reading a jar from a URL

Java features a rich set of jar APIs. For example, you can read archives using a URL that takes the form jar:!. The following URL gets the source code for one of the classes in my threads package from an archive on my Website:

JavaFX Home

Start developing rich immersive user experiences with JavaFX, a rich client platform for all screens.

The JavaFX Preview SDK provides the essential set of technology, tools and resources required for web scripters and early adopters to create JavaFX applications.

The focus of this release is to empower users proficient in web scripting technologies (such as HTML, CSS, AJAX, JavaScript and ActionScript) to create connected applications that run in standard web browsers as well as on the desktop.

These applications can be optimized to run on mobile devices as JavaFX Mobile is made available in the Spring 2009 and on other devices in the future.

[Swing] Application Wide Hotkeys - Gregg Bolinger

I’m working on a Swing application and I need the ability to have application wide hotkeys. Basically that means no matter what I am currently doing in my app specific keystrokes always do the same thing. For example I am mimicking IDEA’s CTRL+N functionallity. When CTRL+N is pressed a dialog opens with a textfield that allows me to type in a search string. As I type a list below the textfield populates with what my app thinks I am looking for.

I found most of the GlobalHotkeyManager code somewhere on the web. I honestly can’t remember where right now. If it looks familiar to you then let me know and I’ll give props. Also, if anyone has alternative methods that might be a better approach please let me know.

public class GlobalHotkeyManager extends EventQueue {

private static final GlobalHotkeyManager instance = new GlobalHotkeyManager();
private final InputMap keyStrokes = new InputMap();
private final ActionMap actions = new ActionMap();

private final static String LOOKUPDIALOG_KEY = “LOOKUP_DIALOG”;
private final KeyStroke lookupDialogHotkey = KeyStroke.getKeyStroke(KeyEvent.VK_N, KeyEvent.CTRL_MASK, false);

static {
// here we register ourselves as a new link in the chain of
// responsibility
Toolkit.getDefaultToolkit().getSystemEventQueue().push(instance);
}

private GlobalHotkeyManager() {
getInputMap().put(lookupDialogHotkey, LOOKUPDIALOG_KEY);
getActionMap().put(LOOKUPDIALOG_KEY, new LookupDialogAction());

} // One is enough - singleton

public static GlobalHotkeyManager getInstance() {
return instance;
}

public InputMap getInputMap() {
return keyStrokes;
}

public ActionMap getActionMap() {
return actions;
}

protected void dispatchEvent(AWTEvent event) {
if (event instanceof KeyEvent) {
// KeyStroke.getKeyStrokeForEvent converts an ordinary KeyEvent
// to a keystroke, as stored in the InputMap. Keep in mind that
// Numpad keystrokes are different to ordinary keys, i.e. if you
// are listening to
KeyStroke ks = KeyStroke.getKeyStrokeForEvent((KeyEvent) event);
//if (DEBUG) System.out.println(”KeyStroke=” + ks);
String actionKey = (String) keyStrokes.get(ks);
if (actionKey != null) {
//if (DEBUG) System.out.println(”ActionKey=” + actionKey);
Action action = actions.get(actionKey);
if (action != null && action.isEnabled()) {
// I’m not sure about the parameters
action.actionPerformed(
new ActionEvent(event.getSource(), event.getID(),
actionKey, ((KeyEvent) event).getModifiers()));
return; // consume event
}
}
}
super.dispatchEvent(event); // let the next in chain handle event
}
}

I left the relevant comments in the code so that it should be fairly straight forward. GlobalHotkeyManager is a singleton because we only ever want one manager running per application instance. I have an Application class I use that acts as sort of Session object for the application. It has getter and setter methods for global components that I need access to and it saves me from having huge constructors where I might have to pass in 10 different objects just to display a particular screen. The GlobalHotkeyManager is created and then set in my Application class.

Application.getInstance().setHotkeyManager(GlobalHotkeyManager.getInstance());

The LookupDialogAction class is really simple.

public class LookupDialogAction extends AbstractAction {

public void actionPerformed(ActionEvent e) {
setEnabled(false);
new LookupDialog(Application.getInstance().getMainFrame(), true);
setEnabled(true);
}
}

I haven’t yet completed the LookupDialog code that actually does the work once the dialog is visible. I’m planning that for another article because I am going to use it to demonstrate a great API I found called GlazedLists.

Demystifying JFormattedTextField: A Step by Step tutorial » Java Swing

JFormattedTextField is a very useful Swing component, that let’s your users see data in a format suitable for them, while letting you read or write from it in a way that that suitable for your code. Let’s make sure that you clearly understand everything related to it.

Ok, let’s start. here’s the first thing you need to know about the JFormattedTextField:
What you see is not what’s inside:

Consider the TextField component. It has only one value associated with its model. The “text”. This is the same value that the user sees, and the value that you set or get using your code. This is OK for simple text fields, but what about cases where it’s convenient for you to manipulate the data in different way than what you need to show to the user. Not sure when such a case would arise? Consider this. Say you have a percentageTextField, in which the user can type his value in percentage like “30%” , “40%” etc. It’s very intuitive and readable for the user to see the string with “%” appeneded in the end (like “30%” instead of “30″), but wouldn’t you find it more easier to manipulate this value as integers 30 and 40, instead of Strings “30%” and “40%”?
To solve this problem, JFormattedTextField introduces the notion of “value” in addition to the concept of “text”. The “text” part is what is showed to the user and the “value” part is what is easy for the code to manipulate. Got it? If you did, it should be obvious that the “text” part can only be a string(as it’s the one that displayed to the user) and the “value” part can be any object
Easy So far? The rest should be even easier. read on.

Kirill Grouchnikov’s Blog: File viewer panel control for Swing applications

File viewer panel control for Swing applications
Posted by kirillcool on December 14, 2007 at 09:58 PM | Comments (5)

Flamingo component suite comes with a flexible and powerful component that hosts command buttons, providing support for button groups, single selection mode (for toggle command buttons), same icon state / dimension and automatic column layout. The official documentation for the base command button panel and file viewer panel have the detailed walkthroughs, and here i will give a short overview of some of the main features.

As i wrote on my other blog, one of Flamingo’s goals is to provide a small and cohesive set of powerful UI components that allow creating modern applications that provide visual functionality similar to or superseding that of Vista Explorer and Office 2007. The command button panel and its extension, file viewer panel, address the functionality commonly found in file explorer applications.

Here is a simple file explorer that uses the breadcrumb bar and file viewer panel with button state set to medium:

Elie Levy’s Blog: Java Dock (Launch Bar)

Java Dock (Launch Bar)
Posted by elevy on July 25, 2007 at 11:14 AM | Comments (15)

With the timing framework and the glass panel, you can create almost any UI component. Offering cool and complex behaviors.

In this blog I present a version of a launch bar (Dock).

Here is a screen shot of it in action:

Ajaxload - Ajax loading gif generator

java.net: Translucent and Shaped Swing Windows

Support for translucent and shaped windows has been a long-standing request for the AWT and Swing teams. Even though native applications have had access to this functionality on all major operating systems for quite a few years, it has not been accessible in core Java. This is changing in the upcoming “Consumer JRE,” a major update to Java SE 6 which provides an API to create shaped, globally translucent, and per-pixel translucent top-level windows.
History

Developers of native applications usually enjoy a greater level of flexibility in developing UI applications. While this comes at the price of restricting an application to a particular platform, in many cases it is outweighed by a richer UI experience and tighter integration with the desktop. Traditionally, cross-platform UI toolkits such as Swing, SWT, QT, and wxWidgets tend to suffer from a well-known dilemma: what to do when only some of the target platforms support a requested feature. In such a case, emulating missing functionality can only get you so far.

Shaped and translucent windows are perfect examples of the limitations of cross-platform UI toolkits. If a specific target platform does not support this functionality, there is not much you can do, and this can be used as a strong argument against adding this feature to the toolkit. However, the Swing developer community has long since argued that the major target platforms have provided these features for quite some time. In fact, Windows has supported shaped windows since Windows 95 (see the SetWindowRgn documentation on MSDN). The matching functionality in X11 has been available since 1989 (see the X Nonrectangular Window Shape Extension Library PDF document). In OS X, you can just set a non-opaque background color on a JFrame.

Up until now, there were three major alternatives available to Swing applications interested in cross-platform translucent and shaped windows:

* Use the java.awt.Robot to capture the desktop prior to showing the target window. This approach has been documented in chapter 41 of Swing Hacks by Joshua Marinacci and Chris Adamson.
* Use JNI to wrap the native APIs of the target platform(s).
* Use the JNA library developed by Timothy Wall. This library was made available in 2007, and Timothy has blogged about non-rectangular windows and alpha-mask transparency.

The main problem with the first approach is the very use of the Robot class. Even when you have screen capture permission, it must be done before you show your window. In addition, how do you keep the desktop background in sync? Suppose you have a YouTube video playing in the background. Unlike the window-generated events (resize, move), AWT doesn’t provide any way to register a listener on repaint of intersected windows. While Chris and Joshua provide a workaround by taking a snapshot at least every second, it is not enough for overlaying background video playback. Furthermore, your window needs to be hidden before every snapshot; this can result in visible flickers.

Using JNI and JNA results in significant visual fidelity improvements. Pure JNI comes with a steep price: you need to bind to the relevant APIs of each one of the target platforms and bundle the native libraries. JNA does the heavy lifting for you; it bundles the native libraries and provides a class loader that is capable of extracting and loading them at runtime. It supports Linux, OS X, Windows, Solaris, and FreeBSD.