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 [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
    runtime.

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.

Andi..

[1] http://www.peakpeak.com/~tromey/blog/2006/01/29/
[2] http://www.gnu.org/software/classpath/
[3] http://gcc.gnu.org/onlinedocs/gcj/About-CNI.html

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to