Community
Participate
Working Groups
We have an RCP application that is about 40mb in size. When the Java Web Start cache is up to date the application takes 10 seconds to launch. When launching the same application natively it takes about 2 seconds (with an existing configuration cache). The issue comes from the fact that when launching an application Java Web Start reads every referenced jar from it's cache before launching the application. This is caused by WebStartMain looking up all resources of JarFile.MANIFEST_NAME and then loading the manifest for each. I don't have a publicly accessible example to show how to reproduce this. But you should be able to reproduce it by creating an RCP app, ensuring that the local cache is up to date, turn on JWS tracing[1], and then launching the app. The log file will show that every plug-in gets read from the cache at application startup rather than as needed. All bundles are not started from what I can tell; the jars are just read from disk. Also a utility like FileMon[1] helps to monitor the disk activity. If an example is needed let me know and I can try to work something up. If you think that I've misdiagnosed something let me know and I'll rerun my tests. Other miscellaneous information: * We're not using jar indexing yet but since every jar will have a manifest I don't think this will help. * I believe this also precludes the ability to use the lazy loading feature available in JWS >= 1.5. This isn't that important to me at this point in time but it might be to others and it might be to me in the future. * Specifying download="lazy" and a JNLP spec of 1.5 didn't have any effect on the loading of these jars. Java Web Start: v1.6.0 Eclipse RCP: v3.2.2 [1] http://java.sun.com/javase/6/docs/technotes/guides/deployment/deployment-guide/tracing_logging.html [2] http://www.microsoft.com/technet/sysinternals/FileAndDisk/Filemon.mspx
I just found out that our version of startup.jar is from Eclipse 3.3 in order to run with Java 6. So I need to do a little more digging before anyone looks into this.
Hi Brad, your analysis is right on. The reason why we need to do all this funny searching is to discover the jars that are constituting the application. If we don't do it, we have no way to detect changes (addition, removal, updates) because there is no jnlp api (at least that I know of) giving back the list of jars reachable from the jnlp file being run. Do you have any idea how we could avoid the lookup? Is there any system property or class library specific trick that we could use to know that no new jar has been downloaded? Lazy loading will not work. The problem is not caused by the lookup of the manifest, but by the fact that equinox uses its own classloader directly on the jar file therefore bypassing the lazy loading capability of jnlp which is implemented through URLConnections (see bug #170574). Note that a solution to this jnlp specific problem could be to write a special equinox framework adaptor that would take the URLConnections. Do you fell like trying this out?
(In reply to comment #2) > Do you have any idea how we could avoid the lookup? Is there any system > property or class library specific trick that we could use to know that no new > jar has been downloaded? Do you know much about DownloadServiceListener[1]? I haven't tried it but it sounds like it might give us notifications of downloads. It's just a guess. > Lazy loading will not work. The problem is not caused by the lookup of the > manifest, but by the fact that equinox uses its own classloader directly on the > jar file therefore bypassing the lazy loading capability of jnlp which is > implemented through URLConnections (see bug #170574). Note that a solution to > this jnlp specific problem could be to write a special equinox framework > adaptor that would take the URLConnections. Do you fell like trying this out? I would like to but I'm not sure when I'll find the time. I appreciate the pointer to the bug. If I find some free time I'll look into it. [1] http://java.sun.com/products/javawebstart/docs/javadoc/javax/jnlp/DownloadServiceListener.html
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
