Hi all,
FYI Paul Sandoz forwarded us this email if you don't follow the
jdk9-dev ML
==
Hi,
In case you are not monitoring this alias.
This is likely relevant to not just to MRJARs but also to maven java
compiler support and the sniffer/conformance plugins etc.
Paul.
Begin forwarded message:
*From: *joe darcy <joe.da...@oracle.com>
*Subject: **New feature in JDK 9 builds: javac -release $VERSION*
*Date: *July 13, 2015 5:50:54 AM GMT+02:00
*To: *"jdk9-...@openjdk.java.net" <jdk9-...@openjdk.java.net>
Hello,
As of JDK 9 b72 [1], a feature recently pushed by Jan Lahoda is now
available: the javac -release command line option.
This feature was developed under JEP 247: Compile for Older Platform
Versions [2]. In brief, to use javac to cross-compile to an older
release
of the platform it is not sufficient to just set the -source and -target
options to the older value; the bootclasspath must also be set to
correspond to the older release too. [3] Setting the bootclass was often
forgotten and acquiring the needed information could be inconvenient.
The -release flag in javac addresses both of these shortcomings. Now
only a
single flag (-release) needs to be set to cross compile compared to
three
flags (-source, -target, -bootclasspath) and the needed information is
included in the JDK. The set of release values follows the same "one
plus
three back" policy now used for the -source and -target options. [4]
Therefore, in JDK 9, the accepted argument values for -release are 6,
7, 8,
and 9.
Feedback on the this feature can be sent to
compiler-...@openjdk.java.net.
Cheers,
-Joe
[1] https://jdk9.java.net/download/
[2] http://openjdk.java.net/jeps/247
[3] "How to cross-compile for older platform versions,"
https://blogs.oracle.com/darcy/entry/how_to_cross_compile_for
[4] JEP 182: Policy for Retiring javac -source and -target Options
http://openjdk.java.net/jeps/182
On Fri, Jul 10, 2015 at 8:47 AM, Hervé BOUTEMY <herve.bout...@free.fr>
wrote:
> Le jeudi 9 juillet 2015 09:48:13 Tibor Digana a écrit :
> > Nice project indeed.
> > Maybe only JRE has the benefit from multi-version JAR, but I cannot
>
> imaging
>
> > this feature in ordinal projects.
>
> +1
> currently, there are not so much projects that produce a different
> artifact for
> different JREs, but there are, even if not the majority
> see the JEP [1] "Motivation" section
>
> > Who has benefit from writing the code
> > three times if API of module matters. Maybe performance will be
> > different
> > only.
>
> notice that one of the motivation, apart from the use case you are
> thinking
> to, is that with JDK modularization, there are intends to deprecate
some
> APIs
> (internal or not): this MVjar will be useful to deal with such type
of JDK
> evolution (and stop with current problem that any new JDK adds APIs
but
> never
> ever removes anything)
> This is a long term goal: the feature has to be there, be successful
and
> prove
> being usable for the most specific libraries before expecting using it
> more to
> support JDK cleanup (in Java 10 or more)
>
>
> What I'm satisfied now with the working example is that whatever one
> thinks
> about the feature, Maven is not in the way: there is now a proved
recipe
> to
> create MVjars if the feature gets added into a JRE, and this base
recipe
> does
> not require any change in any tool (be it Maven or IDE integration)
>
> There is IMHO still one issue in the recipe: there is a trick
(written by
> Paul
> Sandoz, who gave me its initial work) to avoid installing intermediate
> artifacts (to limit the impact of multi-modules, since intermediate
> artifacts
> don't really have any meaning). I didn't try to deploy the current
demo,
> but I
> fear it currently would fail: I suppose that's my next test now the
the
> mvjar
> is great (thanks to Robert's help :) )
>
> Regards,
>
> Hervé
>
>
> [1] http://openjdk.java.net/jeps/238
>
> > On Thu, Jul 9, 2015 at 1:08 AM, Hervé BOUTEMY [via Maven] <
> >
> > ml-node+s40175n5839659...@n5.nabble.com> wrote:
> > > Hi,
> > >
> > > In april, we had a discussion about Multi-Version JAR Files.
> > >
> > > Since then, we worked to create a sample project built with
Maven, to
>
> see
>
> > > how
> > > Maven configuration would currently look like, before trying to
create
>
> new
>
> > > features to make more compact configuration and avoid
multi-modules
> > > creation.
> > >
> > > Here is the result:
> > > https://github.com/hboutemy/maven-jep238
> > >
> > > AFAIK, the result of this code is a valid MVJar, and this gives a
good
> > > overview of a basic Maven recipe to make MVJars.
> > >
> > > There is one limitation I have with assembly in the last module: I
>
> can't
>
> > > exclude /META-INF content from every versioned content (ie avoid
> > > /META-
> > > INF/versions/*/META-INF in final MVJar).
> > >
> > > Is it me or excludes don't work as expected in assembly plugin?
> > >
> > > Regards,
> > >
> > > Hervé
> > >
> > >
---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [hidden email]
> > > <http:///user/SendEmail.jtp?type=node&node=5839659&i=0>
> > > For additional commands, e-mail: [hidden email]
> > > <http:///user/SendEmail.jtp?type=node&node=5839659&i=1>
> > >
> > >
> > >
> > > ------------------------------
> > >
> > > If you reply to this email, your message will be added to the
>
> discussion
>
> > > below:
>
http://maven.40175.n5.nabble.com/DISCUSSION-JEP-238-Multi-Version-JAR-File
>
> > > s-tp5839659.html>
> > >
> > > To start a new topic under Maven Developers, email
> > >
> > > ml-node+s40175n142166...@n5.nabble.com
> > > To unsubscribe from Maven Developers, click here
> > > <
>
>
http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscri
>
>
be_by_code&node=142166&code=dGlib3JkaWdhbmFAYXBhY2hlLm9yZ3wxNDIxNjZ8LTI4OT
>
> > > Q5MjEwMg==> .
> > > NAML
> > > <
>
>
http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=macro_vie
>
>
wer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.Basi
>
>
cNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.templa
>
>
te.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-inst
>
>
ant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>
> > --
>
> > View this message in context:
>
http://maven.40175.n5.nabble.com/Re-DISCUSSION-JEP-238-Multi-Version-JAR-F
> i
>
> > les-tp5839680.html Sent from the Maven Developers mailing list
archive
> > at
> > Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
