[
https://issues.apache.org/jira/browse/LUCENE-718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12744901#action_12744901
]
Hoss Man commented on LUCENE-718:
---------------------------------
you realize we're going to have this same problem with 1.6 right?
> 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: [email protected]
For additional commands, e-mail: [email protected]
