United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6191612 JavaWebstart breaks backwards compatibility of System.loadLibrary()
JDK-6191612 : JavaWebstart breaks backwards compatibility of System.loadLibrary()

Details
Type:
Enhancement
Submit Date:
2004-11-05
Status:
Resolved
Updated Date:
2012-12-05
Project Name:
JDK
Resolved Date:
2012-12-05
Component:
deploy
OS:
generic,windows_xp
Sub-Component:
webstart
CPU:
x86,generic
Priority:
P4
Resolution:
Won't Fix
Affected Versions:
5.0,6
Fixed Versions:
8

Related Reports

Sub Tasks

Description
FULL PRODUCT VERSION :
java version "1.5.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-b64)
Java HotSpot(TM) Client VM (build 1.5.0-b64, mixed mode, sharing)

ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows XP [Version 5.1.2600]

A DESCRIPTION OF THE PROBLEM :
Java Webstart requires developers to invoke System.loadLibrary() in a specific order, from least-dependant to most-dependant libraries. That is, if library A depends on library B, we need to explicitly load library B followed by library A. Loading library A directly will result in a UnsatisfiedLinkError being thrown.

This is a major problem because it breaks backwards compatibility for normal libraries. That is, it is impossible to use normal libraries under JWS without adding extra code to guarantee loading order.

The proposed fix is for JWS to automatically detect library dependencies and load them in the appropriate order. This is technically doable and the only downside would be that lazy library loading in JNLP would require a slight syntax change.

I argue that maintaining backwards compatibility is more important at this point than allowing lazy library loading.

The proposed approach is as follows:

1) If System.loadLibrary() is invoked on a library and all its dependencies can be found, then load it normally.
2) If System.loadLibrary() is invoked on a library and any of its dependencies are missing, download and scan all other libraries specified by <nativelib> to look for the missing library.
3) In order to improve lazy library loading in the future, <nativelib> should allow the specification of the libraries contained therein (this is an optional attribute). In such a case, JWS would be smart enough not to download any libraries that cannot possibly contain the missing libraries. Lazy loading would continue to work.


REPRODUCIBILITY :
This bug can be reproduced always.
###@###.### 2004-11-05 19:45:45 GMT
More comment and concern from the submitter:

-----------------------------------
	I have recently begun working with VisualStudio 2005 to compile my 
code. 
It turns out that all newer builds now require a manifest file 
alongside the DLL 
that you build. I then recalled http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6191612 
which 
discusses the fact that Webstart does not extract DLLs from JAR files 
until loadLibrary() 
is explicitly invoked on them. The original bug 
report was complaining that if I loadLibrary(A) 
and A depends on B then 
A will fail to load because Webstart unpacked A.dll but not B.dll.

	Anyway, now with the introduction of manifest files we have a bigger 
problems. 
Not only must I somehow be able to tell Webstart that 
loadLibrary(A) also requires it to 
unpack B but I must also tell it to 
extract the manifest file too. Some workarounds come to 
mind (such as 
embedding the manifest file within the DLL) but I was wondering why 
Webstart 
does not unpack the entire JAR into a directory when any of its 
files are requested (as opposed 
to extracting them one by one). I don't necessarily agree with the evaluation of the bug that 
this will require 
a specification change but anyway maybe this is worth running by the 
engineers
 once again since the nature of the problem has changed (VS2005 
didn't exist last time I filed 
this issue). If we can just unpack the 
entire JAR into a directory then maybe this will be a 
quick fix and we 
kill two birds with one stone :)

                                    

Comments
EVALUATION

The proposed fix includes specification changes.
The basic idea of handling the dll loading ordering problem is a good one.  We could react to the UnsatisfiedLinkError thrown from the the call to System.LoadLibrary(), but onfortunately, it is not Java Web Start making the call.  We would need to put hook into System.LoadLibrary itself, or use the existing call that will be made into JNLPClassLoader.findLibrary.
###@###.### 2004-11-05 20:33:55 GMT
                                     
2004-11-05



Hardware and Software, Engineered to Work Together