[gcj-eclipse-merge-branch] MinGW ecj: Cross-built ecjx?! (was Re: ecj branch)

Wed Dec 6 00:46:00 GMT 2006

On Wed, 6 Dec 2006, Marco Trudel wrote:
> If you're talking about the language features and, as you have said you're 
> using another bytecode compiler than gcj anyway, there's no need to wait for 
> the new release. Just compile your .java to .class files with a bytecode 
> compiler that understands these language features. They will be disappeared 
> in the .class files (backwards compatibility issues, I guess). I'm doing that 
> for a long time now and these language features all work:
> - generics
> - autoboxing/unboxing
> - extended for loops
> - static imports
> - varargs
> - enumerations

That's what I've been doing for a long time too. The drawback with this 
approach is that it requires two java environments to be installed where my 
target audience (PyLucene is Python) normally requires None if one does not 
count the libgcj.so runtime (and even so, when static builds work, all runtime 
requirements are linked into PyLucene.so extension).
To build PyLucene from sources one should only need the gcj environment. I've 
been able to make that possible by shipping a PyLucene 'source tarball' that
includes Java Lucene .jar files but that appears broken as described in my 
previous message.
The reason I'm excited about ecj is that it may solve this problem too. If so, 
people should then be able to compile PyLucene from python/c++/java sources 
with only one package, the gcc/gcj compiler suite.
Andi..