[
https://issues.apache.org/jira/browse/LUCENE-7292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Schindler updated LUCENE-7292:
----------------------------------
Description:
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}}.
was:
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.releaseargs}} that is dynamically evaluated:
On Java 9 it contains {{-release $\{javac.release\}}}, for java 8 it contains
{{-source $\{javac.release\} -target $\{javac.release\}}}
- 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}}.
> 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
> Fix For: 6.x, master (7.0)
>
> Attachments: 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: [email protected]
For additional commands, e-mail: [email protected]
