[commit-cp] [bugs #9466] java.net.URL.getURLStreamHandler uses wrong classloader

[Steven Augart]

This is an automated notification sent by Savannah.
It relates to:
                bugs #9466, project classpath

==============================================================================
 LATEST MODIFICATIONS of bugs #9466:
==============================================================================

               Posted by: Steven Augart <saugart>
               Posted on: 2005-01-15 22:54 (EST5EDT)
    _______________________________________________________

Follow-up Comment:
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.

==============================================================================
 OVERVIEW of bugs #9466:
==============================================================================

URL:
  <http://savannah.gnu.org/bugs/?func=detailitem&item_id=9466>

                 Summary: java.net.URL.getURLStreamHandler uses wrong
classloader
                 Project: classpath
            Submitted by: davidholmes
            Submitted on: Sat 06/26/2004 at 14:51
                Category: None
                Severity: 5 - Average
                  Status: None
                 Privacy: Public
             Assigned to: mark
             Open/Closed: Open
        Platform Version: None

    _______________________________________________________


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.

    _______________________________________________________

Follow-up Comments:


-------------------------------------------------------
Date: Sat 01/15/2005 at 22:54       By: Steven Augart <saugart>
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.

-------------------------------------------------------
Date: Sun 07/04/2004 at 19:20       By: David Holmes <davidholmes>
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).

-------------------------------------------------------
Date: Sun 07/04/2004 at 19:19       By: David Holmes <davidholmes>
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).

-------------------------------------------------------
Date: Thu 07/01/2004 at 18:52       By: Mark Wielaard <mark>
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





    _______________________________________________________

Carbon-Copy List:

CC Address                          | Comment
------------------------------------+-----------------------------
saugart                             | 




==============================================================================

This item URL is:
  <http://savannah.gnu.org/bugs/?func=detailitem&item_id=9466>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/