in fact, it's sad to require JDK 9 to compile to Java 7 and not support
compiling directly with JDK 7
Perhaps the most simple action will be to check that JDK 8 or 9 is not used
for crosscompilation to Java 7 or less, since it is not reliable
Regards,
Hervé
Le lundi 27 juillet 2015 20:07:10
I tested the new -release flag and it works like a charm: not only is it easier
to use (1 flag instead of 3 = source/target/bootclasspath), but it avoids the
famous covariance problem previously found [1] (and that happens with JDK 9
when not using this new -release flag)
Then I think it's
Hi Hervé,
there's no such thing as version specific configuration. And I don't think
it is really an issue.
With almost every new major version come new javac arguments, such as -s
for JDK6, -profile for JDK8.
IMHO it is up to the user to specify the release value and add an enforcer
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
that's it: I couldn't find this in assembly descriptor configuration
fix merged
thank you Robert
Le jeudi 9 juillet 2015 19:15:29 Robert Scholte a écrit :
unpackOptions
excludes
exclude/META-INF/**/exclude
/excludes
/unpackOptions
?
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
to the discussion
below:
http://maven.40175.n5.nabble.com/DISCUSSION-JEP-238-Multi-Version-JAR-Files-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
unpackOptions
excludes
exclude/META-INF/**/exclude
/excludes
/unpackOptions
?
Robert
Op Thu, 09 Jul 2015 01:07:52 +0200 schreef Hervé BOUTEMY
herve.bout...@free.fr:
Hi,
In april, we had a discussion about Multi-Version JAR Files.
Since
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
-INF/versions/8
With the patched version of the JRE 8 we should use the enhanced J8 version
while in =J7 we should use the default one.
--
View this message in context:
http://maven.40175.n5.nabble.com/DISCUSSION-JEP-238-Multi-Version-JAR-Files-tp5829748p5832950.html
Sent from the Maven
Today I received this message from the core-libs-dev mailing list by
Joseph D. Darcy
{quote}
Note that one possible feature of JDK 9 is a -platform N option to javac
which would allow compiling against older versions of the platform
libraries:
JEP draft: Compile for Specific Platform
Yes it is exactly the option Brian presented to us.
For me (perhaps it's name is misleading) the -platform is the option that
allows to compile mvjars (partial code on top of default one).
But I agree that it's not clear the relationship/constraint/control between
source/target/platform
On Thu,
I see comparison with an EAR, but instead of bundling artifacts, you could
unpack certain dependencies to the META-INF/java/x folder.
What I like about this solution that it is very clear which compiler
version is used. Even if we are able to put all sources into 1
MavenProject, it is still
To compile classes for a mvjar I understand that we'll need only the most
recent version (J9+) and with the right options (perhaps in several calls)
it will do the job.
For tests (multi modules or several executions in one module) if you really
want to test your code in a real situation you'll
As discussed with Brian Goetz, in the JCP/JEP side, AFAIU, the build tool
(javac with platform target option to build only a part of a class) will be
only J9+. It won't be a frankenstein build (in their mind) mixing parts
built with several JDKs.
I totally agree about the risk to use wrong APIs
Clearly Brian told us that the goal was only to cover the needs at the core
JRE level.
They don't want (at least now) to offer such feature for something else.
I think it is really a change of mindset compared to few years ago when
they wanted to build a solution that may cover many many needs.
Here is what Brian gave to us :
{quote}
I’ve attached the (unreviewed) patch that is slated for Java 8 — this is
the runtime-only, with no dev tools support (e.g., jar, jar signer,
compiler.) So it will let you RUN with an mvjar. I can send you the 9
patch as well if you like. Usual disclaimer
WRT compiling: no, you should always try to compile with the target JDK.
My classic example:
Suppose you have the following method in your code:
public void check( String breathSpray )
{
if ( breathSpray.isEmpty() )
{
System.out.println( Go to Quiki Mart );
I suspect that in the case of mvjars you will need to compile with J9 and
it will give you an option to down compile or J8.
It would not go lower than J8 as J7 is EOL in 2 weeks so they need only
support J8+ and when running on J8 an mvjar need only ignore all the stuff
in META-INF, IOW the only
the build tool should not care about JDK because it is totally
uppon the deployer whether the timestamps should break the bytecode
compatibility or not.
--
View this message in context:
http://maven.40175.n5.nabble.com/DISCUSSION-JEP-238-Multi-Version-JAR-Files-tp5829748p5832950.html
Sent from
Le lundi 13 avril 2015 12:19:57 Paul Benedict a écrit :
This is the example project structure I had in mind:
mvjar-example/
minjava/
src/main/java
src/test/java
java7/
src/main/java
src/test/java
java8/
src/main/java
src/test/java
The minjava
Yes net beans does support it, jesse Glick (who is a net beans fanboy...
Because he used to be a net beans developer) foisted a JDK 6 for src/main
and JDK 8 for src/test on us at work... Where we all are left cursing
IntelliJ for not supporting same
On Tuesday, April 14, 2015, Milos Kleint
On Mon, Apr 13, 2015 at 11:16 PM, Jörg Schaible joerg.schai...@gmx.de
wrote:
Hi Arnaud,
Arnaud Héritier wrote:
In short/middle term the lack of IDE integration isn't a real problem for
now.
Like Brian said, they know that users won't use such feature before
several years.
The
On Tue, Apr 14, 2015 at 8:29 AM, Hervé BOUTEMY herve.bout...@free.fr
wrote:
Le lundi 13 avril 2015 12:19:57 Paul Benedict a écrit :
This is the example project structure I had in mind:
mvjar-example/
minjava/
src/main/java
src/test/java
java7/
src/main/java
Actually this is worse. This would be Maven forcing us to create modules
because IDEs do not support different JDK levels for source code paths in
the one module
On 14 April 2015 at 09:32, Arnaud Héritier aherit...@gmail.com wrote:
On Tue, Apr 14, 2015 at 8:29 AM, Hervé BOUTEMY
For now yes it is probably the only solution but the JCP should work with
IDE teams to have this solved.
I don't want to see Maven doing crappy stuffs because of IDEs
There are already a lot of limitations in IDE (at least some of them)
compared to Maven like the ability to have several classpaths
Hi Arnaud,
Arnaud Héritier wrote:
On Mon, Apr 13, 2015 at 11:16 PM, Jörg Schaible joerg.schai...@gmx.de
wrote:
[snip]
IMHO, mvjars will create a bigger maintenance mess than the current
solutions.
I don't know. I think it really depends if your are provider or consumer
of mvjars. If
On Tue, Apr 14, 2015 at 11:55 AM, Jörg Schaible
joerg.schai...@swisspost.com wrote:
Hi Arnaud,
Arnaud Héritier wrote:
On Mon, Apr 13, 2015 at 11:16 PM, Jörg Schaible joerg.schai...@gmx.de
wrote:
[snip]
IMHO, mvjars will create a bigger maintenance mess than the current
solutions.
In addition, even if IDEs were to support the MVJAR spec, that doesn't
answer how Maven should natively answer the spec. Relying on IDE support
isn't a good total answer, but it is a good complimentary answer. Maven
just has to answer it with configuration and command line tooling too.
Cheers,
On Tue, Apr 14, 2015 at 10:32 AM, Arnaud Héritier aherit...@gmail.com
wrote:
On Tue, Apr 14, 2015 at 8:29 AM, Hervé BOUTEMY herve.bout...@free.fr
wrote:
Le lundi 13 avril 2015 12:19:57 Paul Benedict a écrit :
This is the example project structure I had in mind:
mvjar-example/
I don't see this as forcing to create modules. This is purely a packaging
issue, not a programming issue. Rather than providing distinct jars per the
Java version you're targeting (which people have done for years when
needed), you're just binding things up at the end. Forget this is about the
My 0.02
The current approach to use multiple modules, poms,... is a pita and
mvjar would fix that, while bringing new interesting problems such as
testing the possible combinations. But that is ok.
Lack of IDE support shouldn't stop us, if it is useful for maven users
that may push the IDEs
If
In short/middle term the lack of IDE integration isn't a real problem for
now.
Like Brian said, they know that users won't use such feature before several
years.
The runtime part providing the compatibility for the JRE should be
backported to Java 8 but only Java 9 JDK will provide required tools
FWIW, I do not like 'minjava'. OTOH 'java7' is clear, not why not just
stick to 'java#'?
Gary
On Mon, Apr 13, 2015 at 10:19 AM, Paul Benedict pbened...@apache.org
wrote:
This is the example project structure I had in mind:
mvjar-example/
minjava/
src/main/java
src/test/java
Gary, I made a point in my email to note these aren't special names. These
are just example names to denote what kind of project material was inside.
Cheers,
Paul
On Mon, Apr 13, 2015 at 12:53 PM, Gary Gregory garydgreg...@gmail.com
wrote:
FWIW, I do not like 'minjava'. OTOH 'java7' is clear,
Hi Arnaud,
Arnaud Héritier wrote:
In short/middle term the lack of IDE integration isn't a real problem for
now.
Like Brian said, they know that users won't use such feature before
several years.
The runtime part providing the compatibility for the JRE should be
backported to Java 8 but
afaik netbeans does support it (having different source/target level for
test and main source) Not from the UI, but if you have your compiler plugin
setup properly, it will take it into account.
Milos
On Sat, Apr 11, 2015 at 11:35 PM, Kristian Rosenvold
kristian.rosenv...@gmail.com wrote:
This is the example project structure I had in mind:
mvjar-example/
minjava/
src/main/java
src/test/java
java7/
src/main/java
src/test/java
java8/
src/main/java
src/test/java
The minjava and java7 and java8 are not special names (just names to
denote what
I expect we could run the unit test suite on JDK 6 / 7 / 8 in parallel with
7/8 specific code being used for the JDK that do support them, so I wonder
such a multi-module setup would work in this scenario, or would need yet
another maven module for tests :'(
2015-04-12 23:33 GMT+02:00 Hervé
Le samedi 11 avril 2015 21:42:50 Paul Benedict a écrit :
I've been giving this subject lots of thought in some of spare time. IMO,
the most straightforward way of meeting the requirement of the MVJAR is to
break up one's JAR project into separate modules. One module would contain
the version
This was part of the discussion we had with Brian,
The need for some way to address multi-JDK target environment without
just using the poorest API is a common thing for tools/framework/library
developers. They use to rely on complex profile-based maven builds,
hack-ish ant/gradle scripts, etc
IDE support for multiple source trees seems quite far off ?
Kristian
2015-04-11 8:51 GMT+02:00 Hervé BOUTEMY herve.bout...@free.fr:
Hi,
Yesterday at DevoxxFR, Carlos Sanchez, Arnaud Héritier, Nicolas de Loof and me
met Brian Goetz and discussed about the objective of JEP 238 and what we
Hi,
Yesterday at DevoxxFR, Carlos Sanchez, Arnaud Héritier, Nicolas de Loof and me
met Brian Goetz and discussed about the objective of JEP 238 and what we could
get from such a feature.
Having a face to face explanation in front of a white board gave interesting
ideas: then, *as library
A few weeks ago I came up with an additional idea and I'm sure we probably
all recognize this :)
MVJars should also cover dependencies. Several Maven plugins use
reflections to detect if they can use newer methods of of the Maven
Runtime.
In the end this code looks also like
if
Technically we support main scoped sources in java6 and test
scoped sources in java7 today, but the feature is largely unusable
since IDE support is totally missing. Even IntelliJ does not support
it (https://youtrack.jetbrains.com/issue/IDEA-85478 and other issues)
:(
There might be some hope of
Le samedi 11 avril 2015 15:35:02 Kristian Rosenvold a écrit :
Technically we support main scoped sources in java6 and test
scoped sources in java7 today, but the feature is largely unusable
since IDE support is totally missing. Even IntelliJ does not support
it
Le samedi 11 avril 2015 10:54:34 Kristian Rosenvold a écrit :
IDE support for multiple source trees seems quite far off ?
IDE support for current situation, where we mix multiple Java API versions in
one single source tree, is even more far off!
With separate source trees, IDE support starts
if I read correctly the dicussion on JEP 238 list, there was already someone
who had such idea on more generic multi-profile JAR files, jdk being just one
type of profile [1]
but that seems really complex
for Maven, we have the classloader as Classworlds, then we could do what we
want at this
I've been giving this subject lots of thought in some of spare time. IMO,
the most straightforward way of meeting the requirement of the MVJAR is to
break up one's JAR project into separate modules. One module would contain
the version independent code, and then other modules would be per Java
in context:
http://maven.40175.n5.nabble.com/DISCUSSION-JEP-238-Multi-Version-JAR-Files-tp5829748p5829837.html
Sent from the Maven Developers mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: dev-unsubscr
I totally agree. This feels like a royally bad idea that is totally counter to
the idea for slim runtime and fast startup times. I would much rather have some
additional info somewhere in the archive that documents used bytecode,
supported runtime and things like that.
On the Maven side it
This can be a candidate of Delta SNAPSHOT JAR.
Not much advantages with release version JAR, however useful in Release
Candidates RCx.
--
View this message in context:
http://maven.40175.n5.nabble.com/DISCUSSION-JEP-238-Multi-Version-JAR-Files-tp5829748p5829837.html
Sent from the Maven
I think a use-case that supports the JEP would be the Spring Framework.
They are typically supporting a couple versions of Java at once *in one
release* and they have some utility code to access the latest features *if*
they are available in the running JRE. However, to do that, they use class
I'm just reading http://openjdk.java.net/jeps/238 and I encourage everyone else
to as well. Mark talked about this at EclipseCon and I'm not sure what this
buys you. I can see the goals in the JEP but it isn't really clear about the
problem this JEP is trying to solve. I will pop on the mailing
I agree on the feels wrong.
I don't think it will become that much heavier, assuming most of the time
you don't need multi-version classes in an archive. Now you know for sure
that a number of classes won't be used, but in general you always get
overhead from classes in jars which aren't
Also have a look at
http://cr.openjdk.java.net/~psandoz/jdk9/MultiVersionJar-8u60-9-design.md
it looks more complete and has some additional usecases
Robert
Op Fri, 20 Mar 2015 17:24:08 +0100 schreef Jason van Zyl ja...@takari.io:
I'm just reading http://openjdk.java.net/jeps/238 and I
Hi,
we've been asked to give our opinion on the JEP 238: Multi-Version JAR
Files
Here's a quote from Rory O'Donnels e-mail:
---
It's goal is to extend the JAR file format to allow multiple, JDK
release-specific versions of class
files to coexist in a single file. An additional goal is to
The level of granularity feels wrong.
This sounds like it would make jar heavier, potentially a lot heavier.
Another angle would be to manage versions 1-1 with jars, one jar for java
7, one for java 8, and so on. With 1 version in one jar, I am FORCED to
download versions of class files I'll
58 matches
Mail list logo
