Java WebStart slow, requesting libraries from invalid folder

Question

Problem and question: Java webstarted app looking for its classes in base folder instead of ./lib.

As suggested in similar question at Java Web Start applications ask repeatedly for un-existing files I have turned off the jar signing, to rule out the security issue, and the problem persists.

Below find the clean example on what is going over the network for this simple java program:

public static void main(String[] args) {
 // TODO code application logic here
 System.out.println("Hello World! Initializing the class from the jar residing in lib/ folder. Expecting heavy network traffic...");
 //This class resides in lib/SampleJavaLibrary.jar
 //Initializing it just to excercise the class loader problem
 CDummyClass sDummy = new CDummyClass();
 System.out.println("Done");
}

On the network (by wireshark), one can observe repeated requests for jars in base folder, On some calls I counted up to 10 retries, replied by web server with 404. Ultimately, the loadClass is successful, but only after 10 or more requests for nonexisting jars. Multiply this with the number of classes being accessed in given program, and you end up with very slow initialization. In this simple case, there are "only" 2 retries for this simple class.

It all starts normal, the jars are loaded, all is good and nice:

6 0.020921 192.168.1.35 192.168.1.130 HTTP GET /mnt/vbox/workspace/WebStartSample/distC/launch.jnlp HTTP/1.1
8 0.028092 192.168.1.130 192.168.1.35 HTTP HTTP/1.1 200 OK (application/x-java-jnlp-file)
10 0.514038 192.168.1.35 192.168.1.130 HTTP GET /mnt/vbox/workspace/WebStartSample/distC/lib/SampleJavaLibrary.jar HTTP/1.1 
11 0.520688 192.168.1.130 192.168.1.35 HTTP HTTP/1.1 200 OK (application/java-archive)
12 0.618640 192.168.1.35 192.168.1.130 HTTP GET /mnt/vbox/workspace/WebStartSample/distC/WebStartSample.jar HTTP/1.1 
14 0.652541 192.168.1.130 192.168.1.35 HTTP HTTP/1.1 200 OK (application/java-archive)

This is where the trouble begins, at library class call:

16 0.943801 192.168.1.35 192.168.1.130 HTTP GET /mnt/vbox/workspace/WebStartSample/distC/SampleJavaLibrary.jar HTTP/1.1 
18 0.991748 192.168.1.130 192.168.1.35 HTTP HTTP/1.1 404 Not Found (text/html)
22 0.997281 192.168.1.35 192.168.1.130 HTTP GET /mnt/vbox/workspace/WebStartSample/distC/SampleJavaLibrary.jar HTTP/1.1 
24 1.004799 192.168.1.130 192.168.1.35 HTTP HTTP/1.1 404 Not Found (text/html)

Ultimately, after above retrying, the class is being found and initialized (!), most likely from the already existing jar, which was loaded at application startup.

Why is jnlp class loader looking into base folder, and why for so many retries, is beyond me. I did tried to run under debugger, but could not find the sources for class loaders and could not figure it myself.

FWIW here is my jnlp file, and yes, I did tried all variations of update tag, lazy, eager, no changes

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<jnlp codebase="http://mydebian.mydomain/mnt/vbox/workspace/WebStartSample/distC" href="launch.jnlp" spec="1.0+">
 <information>
 <title>WebStartSample</title>
 <vendor>user</vendor>
 <homepage href=""/>
 <description>WebStartSample</description>
 <description kind="short">WebStartSample</description>
 </information>
<update check="always"/>
 <resources>
<j2se version="1.5+"/>
<jar href="WebStartSample.jar" main="true"/>
 <jar href="lib/SampleJavaLibrary.jar"/>
</resources>
 <application-desc main-class="webstartsample.Main">
 </application-desc>
</jnlp>

I suspect there is something wrong with the JNLPClassLoader(), that is the particular loader used within the webstart.

Regards,

Robert

• Thorbjørn Ravn Andersen: Has this JNLP-application worked before or is this new functionality?
• Jarek Przygódzki: Which JVM are you using? Does it work wit Sun Java WebStart?

Answer 1

Recommendations:

1. Validate the JNLP using JaNeLA. It seems valid to my eye, but JaNeLA is the better judge.
2. Include the package element for each Jar. This element is mentioned in the Resources section of the JNLP File Syntax (also expanded in the table at the top of the page). Chase the link in the page to the (downloadable only) API Specification for further details of the package element. And as an aside, the API Spec. is the single best resource on JWS. I wish Oracle would make it web-browsable.
3. Index the Jar files.
4. Continue to ask such great (well thought out, well researched, well presented) questions. :)

• Thorbjørn Ravn Andersen: JaNeLA looks nice. Can it be used inside an ant script?
• Andrew Thompson: It is not currently designed to be. Having said that: a) It is open source (so anything is possible). b) The XSD can be extracted and used directly in the Ant based xmlvalidate task. The XSD is also available separately. If you find the inspiration to rework JaNeLA as something that can work as both an Ant task and a within GUI, I'd be happy to add the code into the source and add you to the list of contributors. ;)
• Thorbjørn Ravn Andersen: I was sort of hoping I could use it with a bit less work than what you hint at, as a step in our build and release process. I'll see when inspiration shows up, and come back to you then.

Answer 2

Thanks everyone for suggestions. It was Andrew hint to 'index the jars' which pointed me to the right direction...

Namely, the jars (produced my current IDE of choice, Netbeans) were indexed. However, the META-INF/INDEX.LIST within the main jar contained the references to other jars as if they were in current folder, next to the main jar.

JarIndex-Version: 1.0
WebStartSample.jar
webstartsample
SampleJavaLibrary.jar
newpackage

That resulted in jnlpClassLoader(), using the main index, and looking for jars in codebase url, while they actually resided under ./lib url subfolder.

This is how the correct index (recreated manually) looks:

JarIndex-Version: 1.0
WebStartSample.jar
webstartsample
lib/SampleJavaLibrary.jar
newpackage

To make the problem worst, such webstarted application would not fail, they would just look for classes/jars in wrong places first, and then eventually find them, presumably already loaded bu jnlp loader as described in original question.

Briefly, this IS related to Netbeans build and packaging procedure.

My immediate fix was disabling the jar indexing, and that resulted in correct and minimal network traffic, and greatly improved application initialization.

To do it in Netbeans, go to Tools->Options->Miscellaneous->Ant->Properties and add jar.index=false

Proper fix would be to make Netbeans index the jar correctly but that is the another question.

Again, thanks all for suggestions.

ps.

• janela util found no major faults in my jnlp
• package element including made no changes
• mydebian refers to my server, the client is win7 with all latest and greatest java runtimes and jdks, including netbeans 6.9 (also tested with 7.0, same problematic index produced)

• R. Simac: I have just found this is known Netbeans bug, already fixed. However, if your project was created with older netbeans IDE version, the bug will persist and there is manual procedure of disabling Java Webstart, removing the jnlp-impl.xml file, and reenabling Webstart. More at netbeans.org/bugzilla/show_bug.cgi?id=190929

Answer 3

The "mydebian.mydomain" hostname hints you are running on Debian, where OpenJDK is the default Java implementation.

The Sun Java WebStart implementation is not part of OpenJDK, so an alternative implementation is used. As Java WebStart does not have an official TCK there are subtle differences and even bugs in the OpenJDK implementation which needs to be found manually (as there is no official TCK).

I would suggest trying with a Sun JVM (e.g. on Windows) and see if the behaviour changes.