vajda at osafoundation
May 27, 2006, 12:43 PM
Post #18 of 82
On Sat, 27 May 2006, Chris Hostetter wrote:
> : As long as gcj is not implementing the new language features in 1.5, I'm stuck
> : with 1.4. If the Lucene core started using 1.5-only features, I'd have to
> : create more and more patches for PyLucene to still build and stay current with
> : Java Lucene.
> As I understand it (based on nothing more then what google tells me for
> "GCJ 1.5") some 1.5 features are already supported by GCJ, and work is in
> progress to get the full list ... which makes me thing that as long as all
> lucene 2.0.* releases are java1.4 compatible, it may not be the end of the
> world for lucene 2.1.* releases to contain java1.5 code, if we assume that
> lucene 2.1.0 probably won't happen for a while anyway if it's going to
> include significant API changes.
There are two aspects to this:
- the new language features such as generics:
they are in the works, quoting from http://lwn.net/Articles/171139/
"Tom Tromey is the main developer of GCJX, the GCJ frontend successor that
supports the new 1.5 language features. He surprised everybody  soon
after the GPLv3 draft was released by proposing to look into replacing
the Java source-to-bytecode part of the GCJ compiler with the Eclipse
compiler (ECJ) instead of using his own GCJX effort. The GPLv3 isn't
final yet (and won't be for a year), and there are lots of technical
issues to discuss. But sharing code and resources between projects seems
like a very attractive feature."
as you can see, the future looks bright, but my guess is that this is at
least one year off.
- the new runtime library features: the GNU Classpath project  that is
implementing the gcj java runtime. Although a lot of progress is being
made there, the GNU classpath library has never been 100% complete when
compared to the current Sun JRE. For example, regex support wasn't there
in gcj 3.x. The holes are usually easy to plug because, via gcj's CNI
interface , I can implement these in C++ or hook them into the python
In other words, filling in missing runtime features is easy with CNI but
working around missing new language features can only be done by recoding
the pieces not supported by gcj.
To unsubscribe, e-mail: java-dev-unsubscribe [at] lucene
For additional commands, e-mail: java-dev-help [at] lucene