Bug#895619: plexus-compiler: use --release instead of -source/-target for jdk9+ when setting defaults

[Emmanuel Bourg]

Le 03/07/2018 à 20:01, Thorsten Glaser a écrit :

> I’m not sure… building (and then running) most of tarent’s
> software products, which unfortunately are often not publicly
> available due to them containing customer-relevant information
> (some is OSS though).

I'm only referring to issues with Maven and its dependencies, like the
one you reported in #901881. I can't do much about not packaged
applications.

Bug#895619: plexus-compiler: use --release instead of -source/-target for jdk9+ when setting defaults

[Thorsten Glaser]

On Tue, 3 Jul 2018, Emmanuel Bourg wrote:

> Please report any incompatibility spotted when running Maven with Java 8
> and I'll see if it can be fixed. What is the scope of the ecosystem you
> envision?

I’m not sure… building (and then running) most of tarent’s
software products, which unfortunately are often not publicly
available due to them containing customer-relevant information
(some is OSS though).

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

Bug#895619: plexus-compiler: use --release instead of -source/-target for jdk9+ when setting defaults

[Emmanuel Bourg]

Le 03/07/2018 à 16:53, Thorsten Glaser a écrit :

> This will break all kinds of things here, we’ll need Maven and
> the whole ecosystem around it.

Please report any incompatibility spotted when running Maven with Java 8
and I'll see if it can be fixed. What is the scope of the ecosystem you
envision?

Bug#895619: plexus-compiler: use --release instead of -source/-target for jdk9+ when setting defaults

[Thorsten Glaser]

On Tue, 3 Jul 2018, Emmanuel Bourg wrote:

> The Java 8 compatibility can be preserved on a case by case basis by
> setting the release parameter manually. For Maven based packages it's as
> simple as specifying the maven.compiler.release property in
> debian/maven.properties [1]. For Ant based packages the build.xml file
> has to be patched, and the 'release' attribute added to the  tasks.
> 
> I'll ensure that Tomcat and Jetty can still be run with Java 8 in Buster.

This will break all kinds of things here, we’ll need Maven and
the whole ecosystem around it.

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

Bug#895619: plexus-compiler: use --release instead of -source/-target for jdk9+ when setting defaults

[Thorsten Glaser]

On Tue, 3 Jul 2018, Emmanuel Bourg wrote:

> Le 02/07/2018 à 17:59, Thorsten Glaser a écrit :
> 
> > Revert default-jdk to 8 until these all are fixed.
> > (Since the internal APIs are, well, internal, they
> > all ought to be fixed by their respective upstreams
> > *anyway* AIUI.)
> 
> Reverting to OpenJDK 8 won't help, because most of the private APIs
> don't have a public replacement yet.

It will help in that, when building with OpenJDK 8, plexus-compiler
will not need to add a --release, and as such, they’ll “still” be
available in legacy mode.

The goal here is:

Build all packages so that they run with Java 8. If we can achieve
that with Java 9, 10, 11, so be it. If not, the package is slightly
buggy (see below), and we’ll have to build it with Java 8 until that
is fixed.

The assumption here is:

Use of these internal APIs is a bug in the package, to be fixed
anyway, and the workaround will not live for a long time.


I think that Java 8 builds already warn (please correct me if wrong)
if those APIs are used; this could lead to an easy MBF and workaround
upload from scanning old build logs.

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

Bug#895619: plexus-compiler: use --release instead of -source/-target for jdk9+ when setting defaults

[Emmanuel Bourg]

Le 02/07/2018 à 17:26, Emmanuel Bourg a écrit :

> Someone has a better idea?

I've reverted the --release parameter in ant/1.10.4-2 and
plexus-compiler/2.8.4-2 for Maven.

The Java 8 compatibility can be preserved on a case by case basis by
setting the release parameter manually. For Maven based packages it's as
simple as specifying the maven.compiler.release property in
debian/maven.properties [1]. For Ant based packages the build.xml file
has to be patched, and the 'release' attribute added to the  tasks.

I'll ensure that Tomcat and Jetty can still be run with Java 8 in Buster.

Emmanuel Bourg

[1] https://salsa.debian.org/java-team/jetty9/commit/fd1829d8

Bug#895619: plexus-compiler: use --release instead of -source/-target for jdk9+ when setting defaults

[Emmanuel Bourg]

Le 02/07/2018 à 17:59, Thorsten Glaser a écrit :

> Revert default-jdk to 8 until these all are fixed.
> (Since the internal APIs are, well, internal, they
> all ought to be fixed by their respective upstreams
> *anyway* AIUI.)

Reverting to OpenJDK 8 won't help, because most of the private APIs
don't have a public replacement yet. The commonly used sun.misc.Unsafe
class got java.lang.invoke.VahHandle [1] as a replacement, but other
internal classes like sun.misc.SignalHandler have no substitute. We can
only move forward and gradually replace the internal APIs with the
public equivalent when they become available.

[1]
https://docs.oracle.com/javase/10/docs/api/java/lang/invoke/VarHandle.html

Bug#895619: plexus-compiler: use --release instead of -source/-target for jdk9+ when setting defaults

[Emmanuel Bourg]

Le 02/07/2018 à 17:52, Thorsten Glaser a écrit :

> How do I reproduce this with Java 8, anyway?

You can't, the --release option appeared in Java 9.

Bug#895619: plexus-compiler: use --release instead of -source/-target for jdk9+ when setting defaults

[Thorsten Glaser]

On Mon, 2 Jul 2018, Emmanuel Bourg wrote:

> Someone has a better idea?

OK, since the last one was impracticable:

Revert default-jdk to 8 until these all are fixed.
(Since the internal APIs are, well, internal, they
all ought to be fixed by their respective upstreams
*anyway* AIUI.)

Or, perhaps better: Use --release, and for those
packages that fail with it, use an explicit B-D
on openjdk-8-jdk instead of default-jdk until that
individual package is fixed. But keep the default
at newer JDK plus --release to ensure the amount
of to-be-fixed packages does not grow in the meantime.

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

Bug#895619: plexus-compiler: use --release instead of -source/-target for jdk9+ when setting defaults

[Thorsten Glaser]

On Mon, 2 Jul 2018, Emmanuel Bourg wrote:

> Base64 is easy, but sun.misc.Unsafe is another story. It's widely used

OIC. I haven’t run into that one yet.

How do I reproduce this with Java 8, anyway?

tglase@tglase:~ $ javac --release 1.8
javac: invalid flag: --release
Usage: javac  
use -help for a list of possible options

Despite http://openjdk.java.net/jeps/247 indicating
it should be supported.

(If for nothing else, then to see whether there are
any Sun-internal class uses left by breaking the build.)

Thanks,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

Bug#895619: plexus-compiler: use --release instead of -source/-target for jdk9+ when setting defaults

[Emmanuel Bourg]

Le 02/07/2018 à 17:32, Thorsten Glaser a écrit :

> Patch code that uses those internal APIs. This is what we do here™
> as well, ever since we could require Java 8 at the customers’ sites.
> It’s been easy so far as most of the time it was just base64.

Base64 is easy, but sun.misc.Unsafe is another story. It's widely used
and its replacement (VarHandle [1]) requires Java 9+. So even if it
builds with OpenJDK 10, it still won't work with Java 8.

[1] http://openjdk.java.net/jeps/193

Bug#895619: plexus-compiler: use --release instead of -source/-target for jdk9+ when setting defaults

[Thorsten Glaser]

On Mon, 2 Jul 2018, Emmanuel Bourg wrote:

> revert the use of the --release option in Ant/Maven. That would mean the
> packages built with OpenJDK 10/11 are unlikely to run with OpenJDK 8
> (the binary incompatibility in the ByteBuffer class affects quite a lot
> of code).

Ouch, that would hurt. (Especially considering that 8 is still
a candidate for default-jdk in buster.)

> Someone has a better idea?

Patch code that uses those internal APIs. This is what we do here™
as well, ever since we could require Java 8 at the customers’ sites.
It’s been easy so far as most of the time it was just base64.

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

Bug#895619: plexus-compiler: use --release instead of -source/-target for jdk9+ when setting defaults

[Emmanuel Bourg]

Le 13/04/2018 à 17:14, Tiago Stürmer Daitx a écrit :

> plexus-compiler currently will default -source and/or -target to 1.7
> whenever the following occours:
> 1) whenever either has not being set
> 2) whenever either has been set to 1.6 or earlier
> 
> This patch modifies the detection logic in order to be able to set the
> '--release' flag when (and only when):
> - the '--release' is *not* set
> - AND both -source and -target are being set to a default value
> - AND the running jvm is jdk9 or newer
> 
> This prevents errors such as the infamous "Method
> flip()Ljava/nio/ByteBuffer; does not exist in class java.nio.ByteBuffer"
> that is caused by building with openjdk-9 with -source set without
> setting the proper bootclasspath [1,2]. JEP-247 [3] has provided the
> --release to prevent such issues and should be used instead of -source
> whenever the javac being used is jdk9 or higher.

Setting the --release option automatically is now implemented in Maven
(since plexus-compiler/2.8.4-1) and Ant (since ant/1.10.3-2), and it
triggers a new issue unfortunately. When the --release option is set the
internal JDK APIs (com.sun.*, sun.misc.*) are no longer available, and
this breaks several packages (axis for example, see #902861). The same
code compiles fine with '-source  -target ' though.

I'm not sure we can fix all the errors reported and we may have to
revert the use of the --release option in Ant/Maven. That would mean the
packages built with OpenJDK 10/11 are unlikely to run with OpenJDK 8
(the binary incompatibility in the ByteBuffer class affects quite a lot
of code).

Someone has a better idea?

Emmanuel Bourg

Bug#895619: plexus-compiler: use --release instead of -source/-target for jdk9+ when setting defaults

[Emmanuel Bourg]

Le 01/05/2018 à 17:44, Tiago Daitx a écrit :

> Do we have packages that are currently setting the fork option? I
> would like to take a look at a few examples to get on overview of what
> else is being set (and maybe why) before committing any changes to the
> way the patch deals with a fork.

I've found at least 3 packages forking to compile:

https://sources.debian.org/src/guacamole-client/0.9.9+dfsg-1/guacamole/pom.xml/#L56
https://sources.debian.org/src/jline2/2.14.6-1/pom.xml/#L306
https://sources.debian.org/src/jruby/9.1.13.0-1/debian/patches/0004-Add-missing-maven-artifacts-pom-files.patch/?hl=1077#L1071

There might be more, it looks like the sources.debian.org search engine
missed some occurrences.

Bug#895619: plexus-compiler: use --release instead of -source/-target for jdk9+ when setting defaults

[Tiago Daitx]

On Mon, Apr 30, 2018 at 9:02 AM, Emmanuel Bourg  wrote:
> Thank you fo the update. I'm attaching the revised patch since it wasn't
> sent to the bug log.

Thanks!

> I suggest also setting the -release parameter when the VM is forked.
> Since the plexus-compiler package is only used to build Debian packages
> with the default JDK there is no risk of calling a JDK that doesn't
> support the new parameter.

Right, I was not sure if that was the case - that is:
1) used only by debian builds and
2) that the default-jdk would be used for a fork.

In particular, when setting "fork" the user also has the option to set
a few other properties, such as "executable", "compilerArgs",
"compilerVersion", etc which can change the behavior quite a lot.


Do we have packages that are currently setting the fork option? I
would like to take a look at a few examples to get on overview of what
else is being set (and maybe why) before committing any changes to the
way the patch deals with a fork.

> Also no need to print the deprecation message for the source/target
> parameters, this is Debian specific and we aren't going to reconfigure
> all upstream projects ourself anyway.

Ack.


Thanks for the help and for the review.


-- 
Tiago Stürmer Daitx
Software Engineer
tiago.da...@canonical.com

PGP Key: 4096R/F5B213BE (hkp://keyserver.ubuntu.com)
Fingerprint = 45D0 FE5A 8109 1E91 866E  8CA4 1931 8D5E F5B2 13BE

Bug#895619: plexus-compiler: use --release instead of -source/-target for jdk9+ when setting defaults

[Emmanuel Bourg]

Hi Tiago,

Le 14/04/2018 à 03:11, Tiago Daitx a écrit :

> Please review the new debdiff attached in this email.

Thank you fo the update. I'm attaching the revised patch since it wasn't
sent to the bug log.

I suggest also setting the -release parameter when the VM is forked.
Since the plexus-compiler package is only used to build Debian packages
with the default JDK there is no risk of calling a JDK that doesn't
support the new parameter.

Also no need to print the deprecation message for the source/target
parameters, this is Debian specific and we aren't going to reconfigure
all upstream projects ourself anyway.

Emmanuel Bourg
diff -Nru plexus-compiler-2.8.2/debian/changelog 
plexus-compiler-2.8.2/debian/changelog
--- plexus-compiler-2.8.2/debian/changelog  2017-09-18 10:31:35.0 
-0300
+++ plexus-compiler-2.8.2/debian/changelog  2018-04-12 11:35:44.0 
-0300
@@ -1,3 +1,10 @@
+plexus-compiler (2.8.2-6) UNRELEASED; urgency=medium
+
+  * Use a default --release instead of defaults -source/-target in order to
+have the right bootclasspath set as per JEP 247. (Closes: #895619)
+
+ -- Tiago Stürmer Daitx   Thu, 12 Apr 2018 14:35:44 
+
+
 plexus-compiler (2.8.2-5) unstable; urgency=medium
 
   * Team upload.
diff -Nru plexus-compiler-2.8.2/debian/patches/auto-adjust-language-level.patch 
plexus-compiler-2.8.2/debian/patches/auto-adjust-language-level.patch
--- plexus-compiler-2.8.2/debian/patches/auto-adjust-language-level.patch   
2017-07-04 03:58:08.0 -0300
+++ plexus-compiler-2.8.2/debian/patches/auto-adjust-language-level.patch   
2018-04-12 11:35:44.0 -0300
@@ -3,40 +3,114 @@
 Forwarded: not-needed
 --- 
a/plexus-compilers/plexus-compiler-javac/src/main/java/org/codehaus/plexus/compiler/javac/JavacCompiler.java
 +++ 
b/plexus-compilers/plexus-compiler-javac/src/main/java/org/codehaus/plexus/compiler/javac/JavacCompiler.java
-@@ -339,12 +339,20 @@
+@@ -100,6 +100,16 @@ public class JavacCompiler
+ 
+ private static final String JAVAC_CLASSNAME = "com.sun.tools.javac.Main";
+ 
++private static final String JAVA_CLASS_VERSION = System.getProperty( 
"java.class.version", "0" );
++
++private static final java.util.List unsupportedLanguageLevels = 
java.util.Collections.unmodifiableList(java.util.Arrays.asList(new 
String[]{"1.1", "1.2", "1.3", "1.4", "1.5", "5"}));
++
++private static final String DEFAULT_SOURCE_VERSION = "1.7";
++
++private static final String DEFAULT_TARGET_VERSION = "1.7";
++
++private static final String DEFAULT_RELEASE_VERSION = "7";
++
+ private static volatile Class JAVAC_CLASS;
+ 
+ private List javaccClasses = new 
CopyOnWriteArrayList();
+@@ -195,6 +205,23 @@ public class JavacCompiler
+ }
+ }
+ 
++protected static boolean supportsReleaseFlag()
++{
++return getCurrentJvmClassVersion() >= 53;
++}
++
++protected static int getCurrentJvmClassVersion()
++{
++try
++{
++return Float.valueOf( JAVA_CLASS_VERSION ).intValue();
++}
++catch (Exception e)
++{
++return 0;
++}
++}
++
+ public String[] createCommandLine( CompilerConfiguration config )
+ throws CompilerException
+ {
+@@ -339,30 +366,55 @@ public class JavacCompiler
  }
  else
  {
-+List unsupportedLanguageLevels = 
java.util.Arrays.asList(new String[]{"1.1", "1.2", "1.3", "1.4", "1.5", "5"});
++boolean useDefaultSource = true;
++boolean useDefaultTarget = true;
 +
  // TODO: this could be much improved
- if ( StringUtils.isEmpty( config.getTargetVersion() ) )
+-if ( StringUtils.isEmpty( config.getTargetVersion() ) )
+-{
+-// Required, or it defaults to the target of your JDK (eg 1.5)
+-args.add( "-target" );
+-args.add( "1.1" );
+-}
+-else
++if ( !StringUtils.isEmpty( config.getTargetVersion() ) && 
!unsupportedLanguageLevels.contains( config.getTargetVersion() ) )
  {
- // Required, or it defaults to the target of your JDK (eg 1.5)
++if ( supportsReleaseFlag() )
++{
++System.err.println( "Use of maven-compiler-plugin's 
'target' option is no longer recommended, consider using 'release' instead" );
++}
++useDefaultTarget = false;
  args.add( "-target" );
--args.add( "1.1" );
-+args.add( "1.7" );
-+}
-+else if ( unsupportedLanguageLevels.contains( 
config.getTargetVersion() ) )
-+{
-+System.err.println( "Use of target " + 
config.getTargetVersion() + " is no longer supported, switching to 1.7" );
-+args.add( "-target" );
-+args.add( "1.7" );
+  

Bug#895619: plexus-compiler: use --release instead of -source/-target for jdk9+ when setting defaults

[Emmanuel Bourg]

Thank you for the patch Tiago. "1.7" is repeated many time, that might
be nice to put it in a variable so we can update the patch easily in the
future.

Emmanuel

Bug#895619: plexus-compiler: use --release instead of -source/-target for jdk9+ when setting defaults

[Tiago Daitx]

Please consider the attached debdiff for review.

On why it is important to use --release instead of the usual -source/-target:
any package that is not build with it can run into those
incompatibilities at runtime when run with an older (but targeted)
release. As a lot of libraries are being build with only
-source/-target set any package that depend on those won't run on
older (but targeted) jdk. It can also affect builds in case the
compiled tool is run during build time with the same old targeted jdk
- see bug #895234 where it was impossible to build
libcommons-lang3-java with openjdk-8 because bnd would fail. In fact,
for the affected packages (ie. use of flip()Ljava/nio/ByteBuffer),
since the build works but runtime fails the current scenario is the
same as setting -target 1.9.

This is already happening with the transition from openjdk-8 to 9 and,
although there's no such indication, it could also affect the
transition from 9/10 to 11 if they do similar changes to the JDK.

Another alternative to using --release is fixing the code that uses
the incompatible API, such as was done for gradle [1], but that does
not scale as well and it is reactive since errors are only detected
during runtime.

Regards,
Tiago

References:
[1] 
https://sources.debian.org/src/gradle/3.4.1-7/debian/patches/java8-compatibility.patch

On Fri, Apr 13, 2018 at 12:14 PM, Tiago Stürmer Daitx
 wrote:
> Source: plexus-compiler
> Version: 2.8.2-5
> Severity: normal
>
> Dear Maintainer,
>
> plexus-compiler currently will default -source and/or -target to 1.7
> whenever the following occours:
> 1) whenever either has not being set
> 2) whenever either has been set to 1.6 or earlier
>
> This patch modifies the detection logic in order to be able to set the
> '--release' flag when (and only when):
> - the '--release' is *not* set
> - AND both -source and -target are being set to a default value
> - AND the running jvm is jdk9 or newer
>
> This prevents errors such as the infamous "Method
> flip()Ljava/nio/ByteBuffer; does not exist in class java.nio.ByteBuffer"
> that is caused by building with openjdk-9 with -source set without
> setting the proper bootclasspath [1,2]. JEP-247 [3] has provided the
> --release to prevent such issues and should be used instead of -source
> whenever the javac being used is jdk9 or higher.
>
>
> I have tested and I can confirm it works fine, but I would like some
> review to make sure it is sane and get opinions on other (better?) ways
> to do this - specially concerning the detection of the jvm being run.
>
> Also, fork and an alternative javac compiler might be set, thus I would
> like to discuss as to what behavior it should default it in that case.
>
> Regards,
> Tiago Daitx
>
> References:
> [1] https://bugs.launchpad.net/ubuntu/+source/gradle/+bug/1760359
> [2] https://github.com/plasma-umass/doppio/issues/497
> [3] http://openjdk.java.net/jeps/247
>
>
> -- System Information:
> Debian Release: buster/sid
>   APT prefers bionic
>   APT policy: (500, 'bionic'), (400, 'bionic-proposed')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.15.0-13-generic (SMP w/8 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_US (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled



-- 
Tiago Stürmer Daitx
Software Engineer
tiago.da...@canonical.com

PGP Key: 4096R/F5B213BE (hkp://keyserver.ubuntu.com)
Fingerprint = 45D0 FE5A 8109 1E91 866E  8CA4 1931 8D5E F5B2 13BE
diff -Nru plexus-compiler-2.8.2/debian/changelog plexus-compiler-2.8.2/debian/changelog
--- plexus-compiler-2.8.2/debian/changelog	2017-09-18 10:31:35.0 -0300
+++ plexus-compiler-2.8.2/debian/changelog	2018-04-12 11:35:44.0 -0300
@@ -1,3 +1,10 @@
+plexus-compiler (2.8.2-6~01) UNRELEASED; urgency=medium
+
+  * Use a default --release instead of defaults -source/-target in order to
+have the right bootclasspath set as per JEP 247. (Closes: #895619)
+
+ -- Tiago Stürmer Daitx   Thu, 12 Apr 2018 14:35:44 +
+
 plexus-compiler (2.8.2-5) unstable; urgency=medium
 
   * Team upload.
diff -Nru plexus-compiler-2.8.2/debian/patches/auto-adjust-language-level.patch plexus-compiler-2.8.2/debian/patches/auto-adjust-language-level.patch
--- plexus-compiler-2.8.2/debian/patches/auto-adjust-language-level.patch	2017-07-04 03:58:08.0 -0300
+++ plexus-compiler-2.8.2/debian/patches/auto-adjust-language-level.patch	2018-04-12 11:35:44.0 -0300
@@ -3,40 +3,81 @@
 Forwarded: not-needed
 --- a/plexus-compilers/plexus-compiler-javac/src/main/java/org/codehaus/plexus/compiler/javac/JavacCompiler.java
 +++ b/plexus-compilers/plexus-compiler-javac/src/main/java/org/codehaus/plexus/compiler/javac/JavacCompiler.java
-@@ -339,12 +339,20 @@
+@@ -339,30 +339,64 @@ public class JavacCompiler
  }
  else
  {
+-// TODO: this 

Bug#895619: plexus-compiler: use --release instead of -source/-target for jdk9+ when setting defaults

[Tiago Stürmer Daitx]

Source: plexus-compiler
Version: 2.8.2-5
Severity: normal

Dear Maintainer,

plexus-compiler currently will default -source and/or -target to 1.7
whenever the following occours:
1) whenever either has not being set
2) whenever either has been set to 1.6 or earlier

This patch modifies the detection logic in order to be able to set the
'--release' flag when (and only when):
- the '--release' is *not* set
- AND both -source and -target are being set to a default value
- AND the running jvm is jdk9 or newer

This prevents errors such as the infamous "Method
flip()Ljava/nio/ByteBuffer; does not exist in class java.nio.ByteBuffer"
that is caused by building with openjdk-9 with -source set without
setting the proper bootclasspath [1,2]. JEP-247 [3] has provided the
--release to prevent such issues and should be used instead of -source
whenever the javac being used is jdk9 or higher.


I have tested and I can confirm it works fine, but I would like some
review to make sure it is sane and get opinions on other (better?) ways
to do this - specially concerning the detection of the jvm being run.

Also, fork and an alternative javac compiler might be set, thus I would
like to discuss as to what behavior it should default it in that case.

Regards,
Tiago Daitx

References:
[1] https://bugs.launchpad.net/ubuntu/+source/gradle/+bug/1760359
[2] https://github.com/plasma-umass/doppio/issues/497
[3] http://openjdk.java.net/jeps/247


-- System Information:
Debian Release: buster/sid
  APT prefers bionic
  APT policy: (500, 'bionic'), (400, 'bionic-proposed')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.15.0-13-generic (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled