I tried looking for a solution to the below problem everywhere, but i did not find any.
I have a client which launches through jnlp. The client downloads one jar with JNLPClassLoader (the default jnlp mechanism). This particular jar then downloads all the other jar files through http and creates a URLClassLoader with all the downloaded jars. And the main application is then launched in a separate thread with the ContextClassLoader as the above created URLClassLoader.
The Client/Server communication is through RMI. RMI writes the whole clients classpath(by calling the getURLs() method of the URLClassLoader) as an annotation with every object that is sent over the wire (if the class is loaded by URLClassLoader, which is the case here).
Now the problem is, as the number of jars the client downloads increases, the length of the annotation written by RMI in every object increases. As a result of this the RMI calls get slower and slower.
In my case the client/server classpath is the same all the time. Since the client downloads all the jars from the server, the server already has all these jars. What this means is, i do not need the annotation to be written with every object, since the server can anyway find it in its own classpath. Hence i tried the below approach to solve this.
Override the getURLs() method in the URLClassLoader to return null. Then RMI does not write any annotation and the server loads it from the classpath. Though it did work for me, but this basically is a hack. Does anyone have the correct solution of this problem ?
Your help will be much appreciated.
You can get the actual URL of the source JAR file per object, via Class.getProtectionDomain().getCodeSource().getLocation(). So each object only needs its own single classpath URL in the annotation.
However the annotations are only written once per class per stream, not with every object. You may not save quite as much as you think.
It would make more sense not to download the JARs and to create the URLClassLoader using their original locations. Downloading will still take place but only on-demand as required. In fact unless the client is running an HTTP server surely this is exactly what is really happening?