JarPlug: Say Goodbye to File Explorer! White Paper

Related Resources:

JarPlug: Say Goodbye to File Explorer!

Five days later here it is: JarPlug, the Java ARchive PLUGin for Eclipse (sorry... :). And what days: going up the learning curve of Eclipse plugin internals and trying to figure out a workflow paradigm for editing Jar files that made sense inside the Eclipse IDE. More on that later.

Installation

Once installed you may have to restart Eclipse, but you should see a new JarPlug tabbed-pane next to the Outline view in all your perspectives. If not, go "Window|Show View|Other|Java|JarPlug" and it should show up. It might show up somewhere else, in which case just drag it to where it should go (see following screenshots for ideas).

Let's take a look

Fig.1: Duke's Bank under JBoss in Eclipse

Notice that I've expanded one of the JAR files commons-beanutils.jar in the package explorer, and selected the LICENSE.TXT into the editing window. It's here that the first limitation of the built-in Eclipse Jar support become apparent: you can't edit the file you selected. In this case that's probably a good thing, but sometimes this just gets in the way.

More problematic is the next situation: a Jar file which is not on the classpath of the project is selected in the package explorer:

Fig.2: A Jar File off the Classpath

This time there is no view into the internal structure of the file in the package explorer, and the results of double-clicking on the test.jar file are entertaining, but not useful. Now let's activate the JarPlug view:

Fig.3: The JarPlug View

The structure of the Jar is now revealed: 117 entries (not including directories), displayed in a tree-view format. So what can we do now? Let's edit one of the XML files at the top level. Double-click on the build.xml file in the JarPlug view and something very interesting happens. Or a number of things.

Fig.4: Extracting and Editing

1. JarPlug automatically extracts the file into the workspace. It puts it under a directory tree named $jarplug.work and further under a folder named test.jar.$work. Why? Because in Eclipse pretty much everything depends on resources having a real physical presence in the filesystem (see FAQ 285 in the Eclipse 3.0 FAQ Reference)
2. JarPlug opens the package explorer tree and selects the extracted file.
3. JarPlug automatically opens an editor for the extracted file.

Deleting things

Fig.5: Deleting

The selected nodes are actually placed into a pending-delete state; when the archive is finally updated they will be gone from it. So far, nothing has changed in the original archive. Nor will it: one of the principles behind the design of JarPlug is the principle of least surprise: you will be aware of what you are doing when you are doing it, or will be told about it. Onward... Why does the deletion mark next to build.xml appear grayed out? Because it has been marked for delete, but there is a copy of this file under the $jarplug.work directory tree, and this copy takes precendence (as you might think it should). Least surprise.

Putting it all back together again

Fig6. Updating

After the file has been updated, the Eclipse IDE looks like this:

Fig7. Updated

Notice that a new file has been created, with the same name as the original file, but in a different location under the $jarplug.work/... folder. It would be too surprising in many ways to overwrite the original file: if you wish to do that, you have to move the new file into the location of the original file.

As you would expect, this new file is missing the things we deleted, but it does contain the build.xml file which we edited, and which was marked for pending delete (but shown as being in a conflicted state)

Why such caution? Suppose you were editing one of the files on the project classpath. What would happen if you suddenly replaced it behind the scenes with an updated Jar? Probably not nice things, and most likely surprising things.

The conservative workflow of JarPlug should prove to be acceptable for most applications, it wouldn't be hard to put in a properties page to commit updates over the original files, and since Eclipse automatically keeps track of deleted resources for you, recovery would always be possible.

Off We Go!

Fig8. JarLaunch

A simple right-click against the Jar file you want to run, and it launches, with or without a debugger attached. The first time you launch a Jar for debug this way, the debugger will probably not be able to find the source code if you've set a breakpoint. You can remedy this in the usual manner, and this new source-path will be persisted for the next launch. Indeed, all JarLaunch does is fire up the normal Eclipse launcher, and you can fire up the normal Eclipse launch configuration manager using Configure Run or Configure Debug

What else?

• You can see the date and time of the archive files by selecting the Show/Hide Dates action
• Deleting a folder in the JarPlug view marks all children of that folder for deletion.
• You can undelete selected items, these will then pass through to the updated Jar file
• The popup-menu supports expand/collapse of all folders in the JarPlug view
• If you choose to edit a Jar file in the $jarplug.work tree, then this file will be overwritten by an update. You have been warned, so don't be surprised! :) But, you can always restore it from the Local History
• Doing a right-click extract on the top node in the tree will extract every entry in the jar file into the file-system. This might take while, and is probably not what you want, but it's there just in case you need it. That's not too surprising is it?

Summary

Or, if you're a major corporation with lots-o-money and can spare a bit, I'd be happy to make it jump though your hoops.

The most urgent task is a code refactoring and cleanup, as would be expected of a five-day rapid prototyping exercise using the test-driven-design approach it's not as pretty as it could be. Indeed, the complexity collapse which usually occurs in early-stage software development like this hasn't happened, and there are far to many special cases for my comfort level. These issues will be resolved given time. Meanwhile, I hope you find this a useful tool, and I look forward to getting your feedback.

Status