lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF subversion and git services (JIRA)" <>
Subject [jira] [Commented] (LUCENE-7292) Change build system to use "-release 8" instead of "-source/-target" when invoking javac
Date Fri, 20 May 2016 20:27:13 GMT


ASF subversion and git services commented on LUCENE-7292:

Commit 7bd6d94952cb0710415c73b038963bf92275d2fb in lucene-solr's branch refs/heads/branch_6x
from [~thetaphi]
[;h=7bd6d94 ]

LUCENE-7292: Use '-release' instead of '-source/-target' during compilation on Java 9+ to
ensure real cross-compilation

> Change build system to use "-release 8" instead of "-source/-target" when invoking javac
> ----------------------------------------------------------------------------------------
>                 Key: LUCENE-7292
>                 URL:
>             Project: Lucene - Core
>          Issue Type: Improvement
>          Components: general/build
>    Affects Versions: 6.0
>            Reporter: Uwe Schindler
>            Assignee: Uwe Schindler
>              Labels: Java9
>             Fix For: 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 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 {{}} 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

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message