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
<tiago.daitx at canonical.com> 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.daitx at canonical.com

PGP Key: 4096R/F5B213BE (hkp://keyserver.ubuntu.com)
Fingerprint = 45D0 FE5A 8109 1E91 866E  8CA4 1931 8D5E F5B2 13BE
-------------- next part --------------
A non-text attachment was scrubbed...
Name: plexus-compiler_2.8.2-5_debdiff_2.8.2-6.patch
Type: text/x-patch
Size: 5943 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-java-maintainers/attachments/20180413/d80c2fe2/attachment.bin>