java.endorsed.dirs plan

[Tom Tromey <tromey at redhat dot com>]

Work on getting jonas to work has shown that we need to properly
implement java.endorsed.dirs.  This feature lets the user install jars
into a special directory.  Classes from these jars are loaded by the
bootstrap class loader and can override certain parts of the core
class library (according to a given list; it includes the xml and sax
stuff, plus corba).

See:

    http://java.sun.com/j2se/1.4.2/docs/guide/standards/


Implementing this is somewhat trickier than it might seem.  One
problem is that some classes in javax.imageio depend on org.w3c.dom in
ways that can't easily be worked around using reflection tricks; e.g.,
IIOAttr extends org.w3c.dom.Attr.

Here is my working plan to implement this.  Let me know if I missed
something.

1. Move org.w3c.dom and org.xml.sax out of libgcj.so and into their
   own .sos.  Without this I don't see any good way we could override
   these.

2. Compile these two BC.  Perhaps the user will want to override
   parts of these libraries but not all of them; I don't think any
   guarantees are made here.

3. Keep javax.imageio in libgcj.so, but compile it BC.  This is needed
   as otherwise loading a different org.w3c.dom could break
   javax.imageio.  (Ugly Makefile hacking, here I come.)

4. Change the bootstrap class loader into a URLClassLoader that does
   no delegation.  At startup, populate it with the contents of
   java.endorsed.dirs.

5. Arrange for the bootstrap loader to know about the two new .so
   files.  There are various ways we can do this, but I think the most
   straightforward one is to simply add them to the loader with
   'gcjlib' URLs.  At least, I couldn't think of any drawbacks to this
   approach.

6. Handle duplicate class registration.  Suppose the user replaces
   half of org.xml.sax (and uses the .db approach so these are loaded
   from a .so); in this case we will see duplicate class
   registrations.  One fix would be to disable this error in the
   situation where the class is BC-compiled.  I was worried about
   symbol clashes causing problems for us, but I think we are
   relatively safe here.  In the future we can be more confident,
   since the plan as I understand it is to avoid public symbols
   altogether.


This is pretty messy, but it gets us where we need to be at the
moment.  In the future I suppose we'll compile more of libgcj BC, and
this will look less hacky.

Whenever we have CORBA, we will handle it similarly.


One other related note.  Right now, our bootstrap loader lies and
claims that classes it loads are actually loaded by the system class
loader.  We do this for historical reasons; some applications compiled
and linked with the C++ ABI died when they saw a 'null' result from
getClassLoader().

I think we're going to have to revert this and go back to not lying
about the class loader.


Losers (that I could think of) in the above scenario:

* Embedded users.  This drives libgcj even more toward the
  desktop/server world.  My impression -- and correct me if I'm
  wrong -- is that our embedded users often hack the build anyway, to
  drop packages they don't like.  I think we ought to support this
  more directly (but at the moment I don't plan to write it).

* CNI users who want to use XML stuff or javax.imageio.  CNI may work
  by accident with BC code today, but only if you aren't also using
  the endorsed directory overrides.  Furthermore, you will need to
  explicitly link against the new .so files if you use them.

* Defenders of sanity.  Sorry, guy.

Tom