java.endorsed.dirs plan

Fri Mar 11 00:29:00 GMT 2005

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