GNU Jaxp patch

Per Bothner per@bothner.com
Tue Feb 15 17:38:00 GMT 2005


Tom Tromey wrote:
> For instance, we could split libgcj into several smaller libraries ...
> The latter users would have to start adding "-l-java-awt", etc, to
> their link lines (which is worse than it sounds since first of all it
> introduces a version dependency and second it means we have trouble
> renaming things in the future).
> 
> Per had a plan to solve all this, way back, but as I recall it
> involved linker hacking.

I don't believe so, but I don't know the capabilities of modern
linkers.

My idea is: The compiler has a searchpath of .jar it searches, at
compile time.  If it emits a reference to a symbol (class, method,
or static) in foo.jar, it will emit a "requirement" for "-lfoo".
I'm guessing this can done without any linker or assembler hacking,
at least on systems that use ELF and the GNU tool-chain, but I
don't actually know enough about ELF and GNU ld to say for sure.

With the new ABI and classloader mechanism you probably don't even
need that, if class name resolution is deferred to class load time.
Just add something to the start-up code: If class A references
foo.jar you can just treat it as if the code contained:
   static {
     gnu.gcj.ClassLoader.addLibraryToSearch("foo.jar", "-foo");
   }
or even:
   static {
      gnu.gcj.ClassLoader.findClassInLibrary("A", "foo.jar", "-foo");
   }
Of course this has to be a bit more "magic" than that, since the
addLibraryToSearch has to be executed before the class is loaded.

Note that the findClassInLibrary also provides a hint for which
libraries to search for which classes, which could be a nice
speed-up, atleast for the "bootclasspath".

The requirement for this model is that you have consistent naming
conventions and search paths for jars and shared libraries.
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/



More information about the Java-patches mailing list