Binary compatibility and finding compiled classes

[Andrew Haley <aph at redhat dot com>]

Tom Tromey writes:
 > One thing we'd like to be able to do with the new binary compatibility
 > code is compile a .jar to a .so, drop it somewhere, and then have the
 > application pick it up without excessive configuration.
 > 
 > There have been a few different proposals, and implementations, of
 > this idea.  I think it would be useful to clear some of this up now,
 > before the next release, so we can at least be clear about what is
 > supported and what is experimental; maybe we can also remove anything
 > we know we don't want.
 > 
 > Current attempts:
 > 
 > Brainstorming:
 > 
 > 
 > I think we will need at least the hash map and CodeSource ideas.  I'm
 > also partial to the factory class approach, but I haven't tried to
 > write down what the interface might look like; there may be
 > undesirable consequences of this.
 > 
 > Some important considerations:
 > 
 > - Avoid excessive application changes.  We went down this road with
 >   Eclipse and, unless upstream is very friendly, it just isn't
 >   maintainable.
 > 
 > - Be invisible.  Real applications out there depend on all kinds of
 >   things, like CodeSource pointing where they expect it to point.
 > 
 > - Performance.  The point of this exercise is to make things perform
 >   well.

We want something that scales well: future applications will be huge,
and there will be a lot of them.  We must not designe a solution that
slows down as people add apps or classes.

I'm suggesting O(1) or O(log N) as the target for the lookup.

 > - Versioning.  We've been hurt a bit by early decisions that didn't
 >   take into account compatibility needs of the future (i.e., the
 >   class-to-soname loading idea causes crashes pretty regularly for
 >   me).  We need to be future-proof in some intelligent way.  This is
 >   at least partly taken care of by the BC code.
 > 
 >   Currently I think we're considering the 4.0 BC code a preview.
 >   We'll try to preserve binary compatibility with future releases
 >   (assuming one of us actually gets around to adding a version number
 >   to the BC output :-), but I don't think we're planning to promise
 >   it until some later release.
 > 
 > 
 > Anyone have other ideas, comments, or constraints?

Put the DSO in the jar.

Andrew.