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
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
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
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
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
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
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
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.
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
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
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
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.
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
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.
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
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
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
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
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
19 matches
Mail list logo