This is the mail archive of the java@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: libgcj has some j2ee classes but not all


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]