[
https://issues.apache.org/jira/browse/LUCENE-7292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15504826#comment-15504826
]
ASF subversion and git services commented on LUCENE-7292:
---------------------------------------------------------
Commit b67a062f9db6372cf654a4366233e953c89f2722 in lucene-solr's branch
refs/heads/branch_6x from [~thetaphi]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=b67a062 ]
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
