Patch: RFA: solib URLs

[Tom Tromey]

>>>>> "Mark" == Mark Wielaard <mark@klomp.org> writes:

Mark> I was thinking the same thing, but I would suggest just using
Mark> the "jar:" protocol and then make the jar protocol handler
Mark> detect if something is a .jar/.zip or a .so file.

To be honest I didn't consider this approach too carefully.  I just
assumed we couldn't do it, since it is incompatible.

There would be some nice benefits of reusing file: (which
URLClassLoader will magically change into jar: as appropriate).  For
instance, you could put a .so file on the default class path.

Both you and Andrew suggested this, though, so it has to be a good
idea.  Perhaps compatibility with the various "won't happen" cases
isn't important.  What do you think about that?

Mark> You could then even go so far as making JarFile and
Mark> JarInputStream also able to transparently read entries from a
Mark> .so file. I believe the java.util.jar API is abstract enough to
Mark> make this possible.

I'm not so sure.  I haven't looked at JarFile (et al) very much.  But
as far as URLClassLoader goes, there are differences.  With a .so
file, there is no way to find the .class file as a resource -- the
class always shows up in the helper as a side effect of opening the
.so.  So parts of URLClassLoader, at least, will still need to know
the difference.  At least we need to change findClass and the
URLLoader (as is done in the current patch).

I took a quick look at JarFile.  I don't see how we could go this
route.  We'd have to add an API to let URLClassLoader find the class
as a class, not as a resource.  We could have a subclass of JarFile
that works differently -- but then we don't seem to be gaining much.

Reusing jar: would be nice, too, since it would let even more code
work without modification.  For instance, some code will get a class'
CodeSource and pick apart the URL for other purposes.  On the other
hand, reusing jar: means incompatibility in some areas, like the
class-is-not-a-resource thing.

I've thought briefly about faking that, too, by returning a 0-length
resource in response to a request for a class that really does exist.
But that would seem to be a mistake.  At some point the applications
just have to be changed :-(

Mark> But I have to admit that I haven't looked to much into this idea
Mark> yet (or actually read your patch that carefully...)

I don't think you need to read the patch to have an opinion on how the
feature ought to be presented, so no worries there.

I think the fundamental idea is that a .so file should be just like a
.jar file.  That's a simple message we can put out, and that's what
the resource compilation patch and this patch were intended to
implement.  One thing we don't do, that we could do, is also compile a
.jar file's manifest into the resulting .so (current gcj explicitly
skips this section).  I haven't read about manifests (sigh...) so I'm
not yet sure how useful that will be.

Tom