lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andi Vajda <>
Subject Re: Lucene and Java 1.5
Date Sat, 27 May 2006 19:43:04 GMT

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

     "Tom Tromey is the main developer of GCJX, the GCJ frontend successor that
      supports the new 1.5 language features. He surprised everybody [1] 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 [2] 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 [3], 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:
For additional commands, e-mail:

View raw message