[ 
https://issues.apache.org/jira/browse/LUCENE-7292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15504824#comment-15504824
 ] 

ASF subversion and git services commented on LUCENE-7292:
---------------------------------------------------------

Commit 3712bf58196cd0bd56fad213547dee12029e7cbf in lucene-solr's branch 
refs/heads/master from [~thetaphi]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=3712bf5 ]

LUCENE-7292: Fix build to use "--release 8" instead of "-release 8" on Java 9 
(this changed with recent EA build b135)


> Change build system to use "-release 8" instead of "-source/-target" when 
> invoking javac
> ----------------------------------------------------------------------------------------
>
>                 Key: LUCENE-7292
>                 URL: https://issues.apache.org/jira/browse/LUCENE-7292
>             Project: Lucene - Core
>          Issue Type: Improvement
>          Components: general/build
>    Affects Versions: 6.0
>            Reporter: Uwe Schindler
>            Assignee: Uwe Schindler
>              Labels: Java9
>             Fix For: 6.1, 6.x, master (7.0)
>
>         Attachments: LUCENE-7292.patch, LUCENE-7292.patch, LUCENE-7292.patch, 
> LUCENE-7292.patch
>
>
> Currently we pass {{-source 1.8 -target 1.8}} to javac and javadoc when 
> compiling our source code. We all know that this brings problems, because 
> cross-compiling does not really work. We create class files that are able to 
> run on Java 8, but when it is compiled with java 9, it is not sure that some 
> code may use Java 9 APIs that are not available in Java 8. Javac prints a 
> warning about this (it complains about the bootclasspath not pointing to JDK 
> 8 when used with source/target 1.8).
> Java 8 is the last version of Java that has this trap. From Java 9 on, 
> instead of passing source and target, the recommended way is to pass a single 
> {{-release 8}} parameter to javac (see http://openjdk.java.net/jeps/247). 
> This solves the bootsclasspath problem, because it has all the previous java 
> versions as "signatures" (like forbiddenapis), including deprecated APIs,... 
> everything included. You can find this in the {{$JAVA_HOME/lib/ct.sym}} file 
> (which is a ZIP file, so you can open it with a ZIP tool of your choice). In 
> Java 9+, this file also contains all old APIs from Java 6+.
> When invoking the compiler with {{-release 8}}, there is no risk of 
> accidentally using API from newer versions.
> The migration here is quite simple: As we require Java 8 already, there is 
> (theoretically) no need to pass source and target anymore. It is enough to 
> just pass {{-release 8}} if we detect Java 9 as compiling JVM. Nevertheless I 
> plan to do the following:
> - remove properties {{javac.source}} and {{javac.target}} from Ant build
> - add {{javac.release}} property and define it to be "8" (not "1.8", this is 
> new version styling that also works with Java 8+ already)
> - remove attributes in the {{<javac source="..." target="..."/>}} calls
> - add a new Ant property {{javac.release.args}} that is dynamically evaluated 
> inside our compile macro: On Java 9 it evaluates to {{-release 
> $\{javac.release\}}}, for java 8 it uses {{-source $\{javac.release\} -target 
> $\{javac.release\}}} for backwards compatibility
> - pass this new arg to javac as {{<arg line="..."/>}}
> By this we could theoretically remove the check from smoketester about the 
> compiling JDK (the MANIFEST check), because although compiled with Java 9, 
> the class files were actually compiled against the old Java API from ct.sym 
> file.
> I will also align the warnings to reenable {{-Xlint:options}}.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to