Apparently, there has been a subtle change in JDK 1.4.2. Either intentional
or accidental, but the URL:
file://path/jarfile.jar
does not appear to work under JDK 1.4.2, at least on Windows (the platform
where this was noticed and tested today). Instead, the following URL does
work:
jar:file:path/jarfile.jar!/
Which means that the code in o.a.j.transport.Loader would change:
- jarlist.add(new URL("file://" + baseDirectory + "/SAR-INF/lib/" +
flist[i] ));
+ jarlist.add(new URL("jar:file:" + baseDirectory + "/SAR-INF/lib/" +
flist[i] + "!/"));
This behavior is noted at
http://forum.java.sun.com/thread.jsp?forum=26&thread=408858&tstart=0&trange=
15. Does anyone have any additional information on this issue? I'm not
spotting anything in the docs, release notes or javadocs.
Two related questions. Does anyone have any thoughts on the use of
new URLClassLoader(URL[]) vs URLClassLoader.newInstance(URL[])
Most examples use the latter form. There are is a code difference related
to package security and exported packages. The current Java v1.4.2
documentation
(http://java.sun.com/j2se/1.4.2/docs/guide/extensions/spec.html) don't go
into it, but there is some information on exported packages in a cached copy
of some docs from an older beta
(http://kavosh.irost.net/books/jdk1.2beta3/docs/guide/extensions/spec.html).
This probably doesn't effect our use AT THE MOMENT, but I'm surprised to see
the the operations aren't synonyms.
Also, we've ran into some cases where:
classLoader.loadClass(className);
fails, whereas:
Class.forName(className, true, classLoader)
works. The best analysis I have found on the subject so far is Ted Neward's
paper at http://www.javageeks.com/Papers/ClassForName/index.html, but he
doesn't really go too far into the details of WHY the latter behaves
differently, other than acknowledging that it does.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
