Evan Summers's Blog

Sync and Destroy 1: The Cookie Jar

I had so much fun today with this, it shouldn't be legal...

Here is a demo which is a jar which hosts embedded demos which are loaded via URLClassLoader looped back to a builtin webserver, also hosting the article that explains it all... Total download size? 115k! (By the time you read this maybe more, but then it'll have more features :)

(executable java5 jar)

The code is on webservlet.dev.java.net.

The next step is to try a nice splash screen, or interactive startup page, and/or login panel, to keep the user distracted while loading a larger application in the background (using URLClassLoader).

Comments

• Why no JNLP/WebStart? (You will need URLClassLoader.newInstance.)

  Posted by: tackline on October 28, 2006 at 06:16 AM

• The article in the demo, which explains this, i'll publish here (and project will be living at cookiejar.dev.java.net by the way).

  The initial idea was to compare speed of direct executable jar download (clicking on a link to a jar), to webstart (clicking on link to JNLP file).

  Webstart offers updates (JREs and your jars) and caching and dependent jars and signing and all those great things. But for my dinky demos, this is not always needed and maybe not as important as fastest possible cold start, or at least illusion of one, eg. by way of an interactive "splash" startup screen.

  So i pack200 my demo jar ie. aptfoundation.jar, cos it gets squashed from 404k to 92k - but then i can't click 'n run it using the browser (cos it becomes a pack.gz file) - so the "cookie jar" (maybe "splash jar" would be better name) embeds the main aptfoundation.jar.pack.gz as a resource file, unpacks and runs it - and the cost of an extra 20k.

  An advantage this offers, besides guaranteed pack200, and also good browser/desktop integration (eg. the percentage progress can be seen in the firefox tab on the XP taskbar) -
  is flexibility - eg. one can build an interactive startup/splash screen, login, or whatever, before executing the embedded jar, and/or while fetching the main jar off the network in the background - in fact i'd like to be able to invoke WebStart in the background to resync and load the real app and all its dependencies!

  The other thing is that cookiejar has an embedded webserver, which it uses for URLClassLoader. Today i'm working more on this, eg. you can be reading an article out of this webserver (which runs locally) in a tab in your browser, and you click on a launch button in the article which has URL like http://localhost:8005/command/ProgressWorkerDemo - and the webserver (being local) can almost immediately popup this demo :) So i can have bunch of demos in my 150k cookie jar, including a big article with tons of "launch" buttons to demonstrate stuff - and those demos pop up literally instanteously :) Check back tomoro for that :)

  It would maybe be nice if WebStart JNLP supported something like that, ie. a single "splash jar" which you can specify in the JNLP to be run while it verifies/fetches the main jar in the background. I dunno if it would make sense, cos i haven't thought it through, but certainly from a user point of view, getting something relevant up in the screen almost immediately to get them not watching the hourglass for more than a few seconds, is important?

  Maybe JNLP could support an extension which is an embedded XML Swing layout that it renders straight-away. This could get the user going while the main jar loads. For example one could configure an about tab with some reading material, and a login tab, or whatever! When the main jar is loaded and running, it could be piped the content of the XML-defined screen, in an XML file, ie. the text of any fields, state of check boxes and what-not,
  eg. when the user hits a "Submit" button, which gets enabled when the jar is up and running ie. able to accept this data. What you think of that idea?
  

  Posted by: evanx on October 28, 2006 at 07:24 AM

• 
  update: i added a console for the webserver.

  I don't know if URLClassLoader supports pack.gz jars? I'll try that. That'd be handy for having a splashy jar, which can be 100k or less, to load in a few seconds, where that then uses webstart support classes if possible, or URLClassLoader, to start downloading pack.gz jar's to launch the app.

  ps. i decided i should have left the title of this entry like it was when i drafted it ie. Sync and Deploy. But "Seek and Deploy" would have been best. Cos "Sync and Destroy" doesn't sound like a very safe download ;)
  

  Posted by: evanx on October 29, 2006 at 03:28 PM

• 
  so i fixed a bug which was in the server (BServer's run() method), if it couldn't connect to the port, it was doing a "throw new RuntimeException" but now it's a "handleException(e)" which displays an exception dialog, eg. "Address already in use" eg. if you run it twice.

  and fixed another bug that the logger wasn't clearly showing the exception and trace in the console window.

  When it connects to the port, it fires an event "serverStarted" on CookieJar, which cause the frame to enable to Browser button and Run button.

  Posted by: evanx on November 06, 2006 at 09:34 AM

This work is licensed under a Creative Commons License.