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

[gcc-bugzilla at gcc dot gnu dot org]

The java.net.URL.getURLStreamHandler method tries to loan a potentially
application-defined class using Class.forName(clsName). This will fail unless
the specified class can be loaded by the bootstrap loader.

The correct behaviour would be to use the context class loader to load the
class. At a minimum the system/application class loader must be used.


------- Comment #1 from from-classpath at savannah dot gnu dot org  2004-07-01 
22:52 -------
Agreed that using the bootstrap classloader is probably not what you want. But
I could not find which class loader strategy is actually expected. There are
several options:
- Use the system/application ClassLoader
- Use the classloader of the first calling class that has a non-system
classloader, using SecurityManager.currentClassLoader().
- Use the Thread context class loader.

For now I just implemented using the application/system classloader always
since this class has been there since 1.0:

2004-07-01  Mark Wielaard  <address@hidden>

        * java/net/URL.java (systemClassLoader): New static field.
        (getURLStreamHandler): Always use system/application classloader
        for finding URLStreamhandler. Remove unecessary instanceof checks.

Could you check that this solves your problem?

An explicit testcase for Mauve is also highly appreciated.

Thanks,

Mark


------- Comment #2 from from-classpath at savannah dot gnu dot org  2004-07-04 
23:19 -------
In a well written aplication the second and third options should be equivalent:
the context class loader should be the first non-system class loader in the
call stack. I consider use of the context class loader to be the correct fix in
this situation. Use of the system/application class loader will fail in some
situations. To alleviate the potential for a mis-behaving custom class-loader,
or a badly set context class loader, the system/application class loader could
be used as a fall back.

I can't check the patch directly but we implemented the same limited patch
locally (we don't support custom class loaders as yet).


------- Comment #3 from from-classpath at savannah dot gnu dot org  2004-07-04 
23:20 -------
In a well written aplication the second and third options should be equivalent:
the context class loader should be the first non-system class loader in the
call stack. I consider use of the context class loader to be the correct fix in
this situation. Use of the system/application class loader will fail in some
situations. To alleviate the potential for a mis-behaving custom class-loader,
or a badly set context class loader, the system/application class loader could
be used as a fall back.

I can't check the patch directly but we implemented the same limited patch
locally (we don't support custom class loaders as yet).


------- Comment #4 from from-classpath at savannah dot gnu dot org  2005-01-16 
03:54 -------
I have a strong argument for why I think that David's argument (use the context
class loader) is correct.

What if someone is attempting to use the URL class in writing their Application
Class Loader (also known as the system class loader)?  We get a serious
recursion and bootstrap problem.  Jikes RVM (until yesterday) based its
Application Class Loader on Classpath's URLClassLoader, which in turn needs the
URL Class.  

When we're at the phase in the bootstrap process where we are generating the
application class loader, the current context loader is the bootstrap class
loader.  If URLClassLoader would use only the bootstrap class loader,
everything would be fine.  Instead, by it insisting on the system class loader
(application class loader), we get a circular dependency.  

ClassLoader.defaultSystemClassLoader also returns a
class loader based on the java.net.URLClassLoader, and
which requires a working URL class.


-- 


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