lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hoss Man (JIRA)" <>
Subject [jira] Updated: (LUCENE-718) possible build.xml addition to ensure 1.4 class compatibility
Date Mon, 20 Nov 2006 02:45:03 GMT
     [ ]

Hoss Man updated LUCENE-718:

    Attachment: check.bootclasspath.patch

patch with changes

> possible build.xml addition to ensure 1.4 class compatibility
> -------------------------------------------------------------
>                 Key: LUCENE-718
>                 URL:
>             Project: Lucene - Java
>          Issue Type: Improvement
>          Components: Other
>            Reporter: Hoss Man
>         Attachments: check.bootclasspath.patch
> As encountered recently, setting the "source" and "target" values for the java compiler
don't acctually test that the classes/methods are 1.4 compatible -- just that the language
syntax/features are...
> ...i've come up with one possible solution, that's really feels like a hack, but i wanted
to throw it out here for comment, in a nutshell:
>    1) we support a new optional javac.bootclasspath property indicating with path the

>        compiler should use.
>    2) people compiling with 1.4 can ignore that property
>    3) anyone who has a 1.5 compiler by default, can set this proprety to point at a 1.4
>         of the rt.jar -- which is not inlcuded (users would need to install it themselves)
>    4) as part of the "init" target the build file will attempt to compile a java class
that is
>        syntactically correct in java 1.4, but utilizes a method only available in 1.5
... if this 
>        class compiles cleanly, the task will fail.
>    5) java 1.5 users that aren't concerned about submitting compatible patches back to

>         the comunity and don't want to hassle with a 1.4 version of rt.jar, can set 
>         a"javac.trustbootclasspath" and go about their merry way.
> The main idea here being that if someone has both JVMs installed and accidently uses
the wrong one to test something before submitting a patch or committing, their build will
either fail with a helpful message, or compile against the correct set of core classes anyway
if they've done a small amount of setup.
> Caveats to commiting this:
>    a) it's a hack, so i don't wnat to commit unless multiple people like it
>    b) at the moment, all "successful" ant executions print a confusing compiler error
as right 
>        off the bat, it would be better if we could supress that somehow.
>    c) the BUILD.txt should be updated accordingly.

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:


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

View raw message