In memory jar / class file execution

Question

I have a jar file (say app.jar) in a certain location available as a file/stream from an http server. The problem is that app.jar is itself a frequently updated jar file being

Answer 1

Further Edit:

I scanned the web and came across this excellent article which may also have a bearing on your question: http://www.szegedi.org/articles/remotejars.html

In which case most of what I wrote below is irrelevant, but I'll leave it anyway just in case.

Edit:

Ok, I think I'm getting a better picture of your requirements. Requirements are tricky though, so let me tell you what I think you're trying to do, and then I'll see what solutions that suggests. I probably will get this wrong, then we do it again.

Requirements:

A distributed caching mechanism for serving WebStart applications. The applications (.jars) change on a regular basis. They are self-contained. You want to have a local-cache able to serve the Webstart jar files obtained from a central server, keeping them in memory. I do not understand your requirements for Exit.

Solutions?

What you may be looking for is a web-server that can host a webapp that will read updated application jars into memory, then serve them to the webstart launcher. You will need to use a web-server such as Jetty/Tomcat, and write a simple webapp to run under it. The webapp will poll the central server for application updates, and will make the application jars available to webstart through URLs which it serves. Polling the central server probably makes more sense than having the central server push new applications to the local servers for reasons of firewall and scalability.

I don't know of any off-the-shelf webapps that do this, there may be one.

But like I said, I probably still don't get this. Requirements: got to love them.

---

I'm going to make some assumptions in this answer, based on your question. It sounds like you want to cache the "app.jar" from the remote machine, for the lifetime of the "load.jar" on the local machine, in order to allow isolate "load.jar" from changes to "app.jar" during its lifetime. This seems like a good idea: I would expect that if you use an URLClassLoader to bring "app.jar" into the "load.jar" space, then an update mid-way through execution could wreak havoc.

It also sounds like you don't want to have "load.jar" make a disk-based copy of the "app.jar" -- I think this is a reasonable goal: who wants to have old jar files scattered around on the machine? who wants permission issues relating to trying to write temporary files?

Given these goals, you need to find or implement a classloader that makes a snapshot of "app.jar" when "load.jar" first hits a class inside it. This isn't hard: I had to do something similar in my One-JAR JarClassLoader, which loads Jar files from inside Jar files. During startup it loads all found bytes into memory, then resolves classes on demand using that memory store. While possibly less efficient than lazy-loading, it's fast, and stable, and would solve your problem.

Unfortunately, One-JAR does not allow network (or file) resources to be cached in this manner. It uses delegation through a normal URL classloader, which would make it not cache your remote resources.

I suggest you take a look at the CVS repository: http://one-jar.cvs.sourceforge.net/viewvc/one-jar/one-jar/src/com/simontuffs/onejar/JarClassLoader.java?revision=1.58&view=markup

around line 678. Don't be daunted by the size of this class, its a bunch of special cases to handle, well, special cases.

If I had to create something from scratch, I would subclass URLClassLoader, override the loadClass, getResource, and findResource methods (see for example line 281 where One-JAR does this for its own class-loader inversion needs), put in bytecode caching by loading the entire "app.jar" into memory as a byte array hashmap indexed by class/resource name keys (this is One-JAR again), and then you'd be cached in memory.

I hope this helps.

--simon.