On 23/08/12 18:50, Shirish Kuncolienkar wrote:
Could I get the change reviewed please
This behavior is seen on Windows.
Logic in URLClassPath.getLoader() does not take care of an URL which
looks like "jar:file:/C:/test/xyz.jar!/". The logic ends up choosing a
FileLoader instead of a JarLoader. JarLoader has provision for
closing file handles, so choosing a JarLoader will solve the problem.
Secondly the constructor of JarLoader blindly adds a prefix and suffix
to the provided URL to make it look like a jar URL. Changed the code
here to conditionally append/prepend
The change set can be found at
http://cr.openjdk.java.net/~shirishk/7183373/webrev.0/
-Shirish
Shirish,
I have a slight concern that this would modify the Loader class to be
used in some circumstances
completely independent of the requirements of URLClassLoader.close().
This is very sensitive code.
Would it be possible to fix this within the context of whatever loader
is currently being invoked?
- Michael
