bug-classpath
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug classpath/22754] java.net.URL.getURLStreamHandler uses wrong classl


From: erik.brangs at gmx dot de
Subject: [Bug classpath/22754] java.net.URL.getURLStreamHandler uses wrong classloader
Date: Sun, 25 Jan 2015 12:55:58 +0000

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22754

Erik Brangs <erik.brangs at gmx dot de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |erik.brangs at gmx dot de

--- Comment #6 from Erik Brangs <erik.brangs at gmx dot de> ---
I'm not sure who filed this bug originally but it might still be worth
pursuing. There's a bug on the Jikes RVM bugtracker about missing support for
custom protocol handlers ( http://jira.codehaus.org/browse/RVM-853 ). I think
that it's related to this issue.

It's been a while since I looked at this problem, but according to my notes,
the issue for RVM-853 on the Jikes RMV side is that the URL class will be
loaded before the application class loader is ready. The URL class will thus
cache the bootstrap classloader which it will use later. The bootstrap
classloader, however, won't be able to find the custom protocol handler.

Therefore, I'd argue that no caching should take place and that the context
classloader should be used.

If it's necessary to cache a classloader, it would be an improvement if the VM
were able to change the cached value (e.g. through the GNU Classpath VM
interface when the VM starts). IMHO that's still worse than using the context
classloader but it should at least fix the protocol handler problem for Jikes
RVM.

The above is all based on my notes. I can take another look at the code and/or
do some testing if needed.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]