P4
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 :)
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 :)