libgcj has some j2ee classes but not all

[Bryce McKinlay]

On Thursday, Aug 7, 2003, at 17:55 Pacific/Auckland, Per Bothner wrote:

> Bryce McKinlay wrote:
>
>> It currently isn't possible to have two instances of a class with the 
>> same name, so you'll have to remove the offending classes from either 
>> your application or from libgcj. This is due to the way GCJ's ABI 
>> works.  Work is underway on a new ABI that will support this, but it 
>> probably won't be ready for a while.
>
> We should probably move J2EE-only classes into a separate .jar
> and .so.  I'd like us to continue searching those by default,
> but it should possible to not get the j2ee-classes by changing
> the classpath, so that can point to some other j2ee implementation.

Do we have any J2EE-only classes in libgcj? A lot of the stuff you'd 
associate with J2EE (javax.transaction, javax.naming, ...) also appears 
in the J2SE. That isn't to say that splitting them out into another .so 
wouldn't be a bad idea, but how do we make it easy for the user?

One idea would be to have a "libgcj extensions" directory which is 
searched for .jars by default by the compiler. If a class is found in 
one of these .jars, gcj would automatically link against a 
corresponding .so.

So for example, when it finds javax.foo.Bar in j2ee.jar, it will know 
to add -lj2ee to the link options.

Bryce.