You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Michael Busch (JIRA)" <ji...@apache.org> on 2009/08/19 07:33:15 UTC
[jira] Resolved: (LUCENE-718) possible build.xml addition to ensure
1.4 class compatibility
[ https://issues.apache.org/jira/browse/LUCENE-718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Michael Busch resolved LUCENE-718.
----------------------------------
Resolution: Won't Fix
Lucene 3.0 and JDK 1.5 are coming soon!
> possible build.xml addition to ensure 1.4 class compatibility
> -------------------------------------------------------------
>
> Key: LUCENE-718
> URL: https://issues.apache.org/jira/browse/LUCENE-718
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Other
> Reporter: Hoss Man
> Attachments: check.bootclasspath.patch, 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...
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6333296
> ...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 copy
> 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.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org