lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vic Bancroft <>
Subject Re: Java 1.5 (was ommented: (LUCENE-565) Supporting deleteDocuments in IndexWriter (Code and Performance Results Provided))
Date Tue, 11 Jul 2006 04:01:31 GMT
Andi Vajda wrote:

> On Mon, 10 Jul 2006, Doug Cutting wrote:
>> Andi Vajda wrote:
>>> On Sat, 8 Jul 2006, Doug Cutting wrote:
>>>> Since GCJ is effectively available on all platforms, we could say 
>>>> that we will start accepting 1.5 features when a GCJ release 
>>>> supports those features. Does that seem reasonable?
>>> +1
>> If we use this criteria, then we should probably officially support 
>> GCJ. Ideally we should run nightly unit tests with GCJ. Andi, would 
>> you be interested in helping to set this up?
This is interesting to me, is the nightly build environment difficult to 
replicate ?

> I'd be interested in doing this but what is it that we're after in 
> 'supporting gcj' actually ?

There is some advantage in using gcj as a measure of usability in the 
context of a "free (as in beer)" java, such that for a given target 
platform, one can deliver executables and shared libraries without 
requiring virtual machine runtimes. The second advantage is to give a 
simple method to nightly test contributions using new features. The 
third advantage seems to be a reduction in computational load on servers 
running native code.

> - running a fully compiled program linked against a ?
> if so, which platforms ? the gcj story is very different on each and 
> every
> platform, including different linuxes and gcj is not well supported on
> some platforms at all.

This seems to be the case, since on an updated fedora core 5 with gcj 
(GCC) 4.1.1 20060525 (Red Hat 4.1.1-1), the Makefile modifications 
required are trivial.

> - running java bytecode with the gcj VM (gij, I believe) ?
> if the .java code needs to be compiled with gcj then a number of patches
> still need to be applied against the Java lucene sources.
> PyLucene is built by compiling .java -> .jar using a regular JDK (Apple's
> or Blackdown) and using gcj to compile from .jar -> .so thereby working
> around all the gcj java front-end bugs
> Even when only compiling .jar -> .so with gcj, a number of patches still
> need to be applied:

The last time I checked for src/gcj/Makefile (revision 420696), all that 
was required was to fix the name of the lucene archive file to match 
what is actually generated, e.g., $(BUILD)/lucene-core-[0-9].*.jar and 
add the FieldCache* to the names to skip . . .

Not having contributed to lucene yet, is it required to generate a 
'patch' to add to jira, or is the following output from a simple `svn 
diff` sufficient for experimentation ?

    Index: src/gcj/Makefile
    --- src/gcj/Makefile (revision 420696)
    +++ src/gcj/Makefile (working copy)
    @@ -8,7 +8,7 @@

    -CORE_OBJ:=$(subst .jar,.a,$(wildcard $(BUILD)/lucene-[0-9]*.jar))
    +CORE_OBJ:=$(subst .jar,.a,$(wildcard $(BUILD)/lucene-core-[0-9]*.jar))
    CORE_JAVA:=$(shell find $(ROOT)/src/java -name '*.java')

    @@ -55,7 +55,7 @@
    # yet accept from .class files.
    # NOTE: Change when is fixed.
    $(CORE_OBJ) : $(CORE_JAVA)
    - $(GCJ) $(GCJFLAGS) -c -I $(CORE) -o $@ `find $(ROOT)/src/java
    -name '*.java' -not -name '*Sort*' -not -name 'Span*'` `find $(CORE)
    -name '*.class' -name '*Sort*' -or -name 'Span*'`
    + $(GCJ) $(GCJFLAGS) -c -I $(CORE) -o $@ `find $(ROOT)/src/java
    -name '*.java' -not -name '*Sort*' -not -name 'Span*' -not -name
    'FieldCache*'` `find $(CORE) -name '*.class' -name '*Sort*' -or
    -name 'Span*' -or -name 'FieldCache*'`

    # generate object code from jar files using gcj
    %.a : %.jar


"The future is here. It's just not evenly distributed yet."
 -- William Gibson, quoted by Whitfield Diffie

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message