Re: [DISCUSSION] JEP 238: Multi-Version JAR Files

Wed, 15 Apr 2015 12:27:12 -0700

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" );
       }
    }
You've set source+target to 1.5 and compile this code with JDK6. Build success!
Now I run this code with JDK5 and get: java.lang.NoSuchMethodException: String.isEmpty()
The problem is that this method was introduced with JRE6. When compiling code, the compiler uses the JDK6 String, even though you had specified 1.5 as target.
You could do a check afterwards with Animal Sniffer (if people are aware of this tool), but it would have been better if the compiler had failed. 

I don't expect this to change with newer versions of the JDK.
WRT testing, I'm already working on this for the maven-invoker-plugin, but that's targeting Maven Runtime / JDK combination, but that made me aware that I must think of a lot of the whole process.
1 module == 1 JDK source/target for compiling == 1 JDK source/target for testing 


thanks,
Robert
Op Wed, 15 Apr 2015 20:14:11 +0200 schreef Arnaud Héritier <aherit...@gmail.com>: 


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 need to have locally all 
the targeted JRE and use the JDK toolchain to use them.
WDYT ?


On Wed, Apr 15, 2015 at 8:07 PM, Robert Scholte <rfscho...@apache.org>
wrote:
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 best to compile java5 source with JDK5, java6
sources with JDK6, etc.
And what about unit testing? Test them with the whole range of JDKs?
Downside might be that with the multimodule solution you'll end up with
artifacts which should(?) never be installed/deployed, but should only be 
bundled in the mvjar.
Do we expect this to be THE new way of development or are these still rare cases? If it is considered rare, then I don't mind offering a multimodule 
solution, where every module does its less complex job very good.

Robert

Op Tue, 14 Apr 2015 17:39:56 +0200 schreef Paul Benedict <
pbened...@apache.org>:


 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,
Paul

On Tue, Apr 14, 2015 at 10:14 AM, Carlos Sanchez <car...@apache.org>
wrote:

 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 the Maven user wants to use mvjar by putting sources in
src/main/java8 src/main/java9 or whatever convention we decide, then
the compiler, jar,... plugins should transparently handle all the
necessary compilations and packaging without extra pom configuration.
If they decide to stick with multimodule, they can still do that.

So if we are ok with the plugins recognizing these mvjar projects then
it is left for someone to implement some jira issues in the best way
possible while retaining backwards compatibility.

Cheers


On Tue, Apr 14, 2015 at 4:50 PM, Paul Benedict <pbened...@apache.org>
wrote:
> 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
> MVJAR initiative because this is just how you would solve this minus
the
> special packaging.
>
>
> Cheers,
> Paul
>
> On Tue, Apr 14, 2015 at 5:53 AM, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
>> 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 <
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
>> > > >      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 kind of Java source is inside). As Herve noted,
"minjava"
>> > > would
>> > > > contain the source minimum Java version; "java7" would contain 
the
>> java
>> > > > 7-specific sources, and "java8" would contain the java
8-specific
>> > > sources.
>> > > like Gary answered, I think that it'll be better if we stick with 
>> java#,
>> > > or j#
>> > >
>> > > And in this example, we'll require another module for the mvjar, 
that
>> > will
>> > > combine result fo every other module
>> > >
>> >
>> >
>> > I really hate when maven enforces us to create modules for its own 
>> > technical reasons. (And I know I'm not the only one)
>> >
>> >
>> > >
>> > > >
>> > > > I don't see any added difficulty with regard to testing. If you 
>> already
>> > > > have code that tests a specific Java X version, just extract
that
>> into
>> > > its
>> > > > own test case file and place it in the appropriate project. At 
most
>> all
>> > > > you're doing is minor refactoring.
>> > > after thinking at it, true
>> > > this module layout is definitely really clear, that's a big
advantage!
>> > > one thing that it makes really clear is javadoc, too, since
javadoc
in
>> a
>> > > mv-
>> > > module is a challenge :)
>> > >
>> > > we should try it with plexus-utils, in another branch
>> > >
>> > > >
>> > > > This will create three JARs of course (or at least today). I
don't
>> see
>> > > that
>> > > > as a big deal since authors may decide to distribute this way
where
>> > MVJAR
>> > > > isn't supported (like pre-Java 9 JVMs).
>> > > IMHO, not really, since the minimum version module will contain
>> > absolutely
>> > > every classes, but the other modules will contain only a few
classes =
>> > the
>> > > few
>> > > code that is rewritten to take advantage of newer JDK
>> > >
>> > > Compatibility with old jdks that do not support mvjar is built
into
>> mvjar
>> > > JEP:
>> > > a JVM that does not support mvjar extension will see minimum
version
>> > > modules
>> > > (and useless content in /META-INF/versions/)
>> > >
>> > > notice that every module will ave its own GAV coordinates: the
last
>> mvjar
>> > > module will have the end-user coordinates, where every
>> > JDK-version-specific
>> > > module will have an artifactId = artifactId-java# (that's a
generic
>> > > convention
>> > > we should try to push forward)
>> > >
>> > > > However, if we can bind up all the
>> > > > jars into one in a post-processing phrase, you can then meet the 
>> MVJAR
>> > > > specification.
>> > > >
>> > > > PS: I really don't know if an "mvjar" type is necessary.
Honestly, I
>> > hope
>> > > > it's not. I thought it was needed in the beginning, but am not 
sure
>> > > > anymore. Opinions appreciated.
>> > > I don't know if the merging will require a dedicated packaging:
we'll
>> see
>> > > later
>> > >
>> > > now it's time to test on plexus-utils: givent this idea doesn't
involve
>> > > much
>> > > new things in maven, I'm pretty sure we can make it full
functional!
>> > >
>> > > I'll try to do it tonight if nobody beats me at it
>> > >
>> > > Regards,
>> > >
>> > > Hervé
>> > >
>> > > >
>> > > >
>> > > >
>> > > > Cheers,
>> > > > Paul
>> > > >
>> > > > On Mon, Apr 13, 2015 at 1:28 AM, nicolas de loof <
>> > > nicolas.del...@gmail.com>
>> > > >
>> > > > wrote:
>> > > > > 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é BOUTEMY <
herve.bout...@free.fr
>:
>> > > > > > 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 independent code, and then other modules would 
be
>> per
>> > > Java
>> > > > > > > version.
>> > > > > >
>> > > > > > more precisely: the first module would contain the source
for
>> > minimum
>> > > > >
>> > > > > Java
>> > > > >
>> > > > > > version: sometimes, it will contain code that won't run with 
>> later
>> > > JRE
>> > > > > >
>> > > > > > > This kind of slicing is necessary because you do need
different
>> > > > > > > kinds of compiler directives (like -source), different
JREs
to
>> > run
>> > > > > > > unit
>> > > > > > > tests differently, and most importantly, the different
JREs
to
>> > > allow
>> > > > > > > debugging according to the Java version you want to test. 
>> > > > > > >
>> > > > > > > The other piece that doesn't yet exist is a way to bundle 
the
>> > > modules
>> > > > > >
>> > > > > > into
>> > > > > >
>> > > > > > > one jar. Perhaps this can be accomplished by introducing a 
new
>> > > "mvjar"
>> > > > > > > Maven type.
>> > > > > >
>> > > > > > I didn't imagine this scenario: no Maven plugins updates nor 
IDE,
>> > > "just"
>> > > > >
>> > > > > a
>> > > > >
>> > > > > > new
>> > > > > > feature to merge multiple modules into on MV jar
>> > > > > >
>> > > > > > interesting idea, in fact: this would seriously reduce the 
impact
>> > on
>> > > > > > tooling,
>> > > > > > even if the result is less compact, ie creates a lot of
Maven
>> > modules
>> > > > > >
>> > > > > > and I am wondering what unit tests will look like for
additional
>> > > > >
>> > > > > versions:
>> > > > > > the
>> > > > > > good thing is that they can be tweaked easily. Then bad
thing
is
>> > > that we
>> > > > > > may
>> > > > > > end up in copy/pasting them
>> > > > > >
>> > > > > > Regards,
>> > > > > >
>> > > > > > Hervé
>> > > > > >
>> > > > > > > Paul
>> > > > > > >
>> > > > > > >
>> > > > > > > Cheers,
>> > > > > > > Paul
>> > > > > > >
>> > > > > > > On Sat, Apr 11, 2015 at 9:37 AM, Hervé BOUTEMY <
>> > > herve.bout...@free.fr>
>> > > > > > >
>> > > > > > > wrote:
>> > > > > > > > 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 (https://youtrack.jetbrains.com/issue/IDEA-85478
and
>> > other
>> > > > > >
>> > > > > > issues)
>> > > > > >
>> > > > > > > > > :(
>> > > > > > > > >
>> > > > > > > > > There might be some hope of gaining some kind of
traction
>> to
>> > > both
>> > > > > > > > > source and main-level support of multi-language-level 
>> > modules.
>> > > > >
>> > > > > Maybe
>> > > > >
>> > > > > > > > > something like (src/main/java and src/test/java =
"default
>> > > > >
>> > > > > language"
>> > > > >
>> > > > > > > > > level) while src/[main|test]/java-8 would be a
specific
>> > > language
>> > > > > > > > > level. This sounds infinitely cool,
>> > > > > > > >
>> > > > > > > > yes, that's what I did in plexus-utils jdep-238 branch 
>> > > > >
>> > > > >
>> > https://github.com/codehaus-plexus/plexus-utils/tree/jep-
238/src/main
>> > > > >
>> > > > > > > > > but also like a great can of worms
>> > > > > > > > >
>> > > > > > > > > :)
>> > > > > > > >
>> > > > > > > > yes, I fear it's not so easy for IDEs...
>> > > > > > > >
>> > > > > > > > > I assume minimum compiler requirement would be java-8 
for a
>> > > > > > > > > project
>> > > > > > > > >
>> > > > > > > > > with src/main/java-8 ?
>> > > > > > > >
>> > > > > > > > yes, I think that's what makes such support hard at the 
>> moment:
>> > > > > require
>> > > > >
>> > > > > > > > the
>> > > > > > > > highest JDK, and signature for every lower JDK to avoid 
newer
>> > > APIs
>> > > > > > > > unless JDK 9 can safely compile for any older target,
>> checking
>> > > the
>> > > > >
>> > > > > API
>> > > > >
>> > > > > > > > (without having to run Animal Sniffer after that)
>> > > > > > > >
>> > > > > > > > Regards,
>> > > > > > > >
>> > > > > > > > Hervé
>> > > > > > > >
>> > > > > > > > > K
>> > > > > > > > >
>> > > > > > > > > 2015-04-11 15:11 GMT+02:00 Hervé BOUTEMY <
>> > > herve.bout...@free.fr>:
>> > > > > > > > > > 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 like 
we
>> are
>> > at
>> > > > > > > > > > the
>> > > > > > > >
>> > > > > > > > moment =
>> > > > > > > >
>> > > > > > > > > > no IDE support
>> > > > > > > > > >
>> > > > > > > > > > but IDEs that want to do something about it have a 
>> chance:
>> > > > > > > > > > that's
>> > > > > >
>> > > > > > the
>> > > > > >
>> > > > > > > > big
>> > > > > > > >
>> > > > > > > > > > difference IMHO
>> > > > > > > > > >
>> > > > > > > > > > Regards,
>> > > > > > > > > >
>> > > > > > > > > > Hervé
>> > > > > > > > > >
>> > > > > > > > > >> 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 could get from such a feature.
>> > > > > > > > > >> >
>> > > > > > > > > >> > Having a face to face explanation in front of a 
white
>> > > board
>> > > > >
>> > > > > gave
>> > > > >
>> > > > > > > > > >> > interesting ideas: then, *as library
maintainer*, I
>> > tried
>> > > to
>> > > > > > > > > >> > modifiy
>> > > > > > > > > >> > plexus-utils code to use MVJAR for Java 7
enhancement
>> > that
>> > > > > > > > > >> > are
>> > > > > > > > > >> > currently
>> > > > > > > > > >> > triggerred through reflection
>> > > > > > > > > >> >
>> > > > > > > > > >> >
>> > > > > > > > > >> > Here is the result [1]:
>> > > > > > > > > >> >
>> > > > > > > > > >> > I extracted 2 little xxxMv classes containing
only
the
>> > few
>> > > > > >
>> > > > > > methods
>> > > > > >
>> > > > > > > > that
>> > > > > > > >
>> > > > > > > > > >> > had to be enhanced when runing on Java 7,
replacing
>> the
>> > > > > > > > > >> >
>> > > > > > > > > >> >     if (Java7Detector.isJava7()) {
>> > > > > > > > > >> >
>> > > > > > > > > >> >       // java 7
>> > > > > > > > > >> >
>> > > > > > > > > >> >     } else {
>> > > > > > > > > >> >
>> > > > > > > > > >> >      // Java 5
>> > > > > > > > > >> >
>> > > > > > > > > >> >     }
>> > > > > > > > > >> >
>> > > > > > > > > >> > stanza with the default Java 5 code in the main 
>> > > src/main/java
>> > > > > > > > > >> > source
>> > > > > > > > > >> > tree
>> > > > > > > > > >> > and Java 7 reimplementation in src/main/java-7
source
>> > tree
>> > > > > > > > > >> >
>> > > > > > > > > >> > and I did cleanup: removed Java7Detector and
moved
>> > > NioFiles
>> > > > > > > > > >> > to
>> > > > > >
>> > > > > > this
>> > > > > >
>> > > > > > > > > >> > java-7
>> > > > > > > > > >> > specific source tree
>> > > > > > > > > >> >
>> > > > > > > > > >> >
>> > > > > > > > > >> > the result is a main src/main/java source tree
that
>> can
>> > be
>> > > > > >
>> > > > > > compiled
>> > > > > >
>> > > > > > > > > >> > with
>> > > > > > > > > >> > JDK 5 and a src/main/java-7 source tree that is 
>> minimal
>> > > to be
>> > > > > > > >
>> > > > > > > > compiled
>> > > > > > > >
>> > > > > > > > > >> > with JDK 7
>> > > > > > > > > >> >
>> > > > > > > > > >> >
>> > > > > > > > > >> > I still didn't try to update pom.xml to see what 
>> > > > > > > >
>> > > > > > > > maven-compiler-plugin
>> > > > > > > >
>> > > > > > > > > >> > and
>> > > > > > > > > >> > maven-jar-plugin configurations could look like. 
>> > > > > > > > > >> >
>> > > > > > > > > >> > and I don't know if javac will be enhanced to do 
the 2
>> > > > > >
>> > > > > > compilations
>> > > > > >
>> > > > > > > > in
>> > > > > > > >
>> > > > > > > > > >> > 1
>> > > > > > > > > >> > command like "javac -target 1.5 src/main/java
-target
>> > 1.7
>> > > > > > > > > >> > src/main/java-7"
>> > > > > > > > > >> > or if it'l have to launch 2 javac one after the 
other
>> > > > > > > > > >> >
>> > > > > > > > > >> > I didn't look at maven-jar-plugin to see if it
uses
>> > "jar"
>> > > > > >
>> > > > > > command
>> > > > > >
>> > > > > > > > that
>> > > > > > > >
>> > > > > > > > > >> > will be enhanced to mix multiple target/classes 
or
if
>> it
>> > > uses
>> > > > > > > >
>> > > > > > > > JarFile
>> > > > > > > >
>> > > > > > > > > >> > class then will need to code the mix
>> > > > > > > > > >> >
>> > > > > > > > > >> > and I don't know if javac will have tru
crossplatform
>> > > > > >
>> > > > > > compilation
>> > > > > >
>> > > > > > > > > >> > option,
>> > > > > > > > > >> > to avoid using 2 JDKs (ie JDK 5 for compiling
java
5
>> > code
>> > > and
>> > > > > >
>> > > > > > being
>> > > > > >
>> > > > > > > > > >> > sure
>> > > > > > > > > >> > there is no Java 7 API reference, and JDK 7 for 
the
>> > java 7
>> > > > >
>> > > > > part)
>> > > > >
>> > > > > > > > > >> > I see there will be impact on tooling, and if
javac
>> > does a
>> > > > >
>> > > > > part
>> > > > >
>> > > > > > of
>> > > > > >
>> > > > > > > > the
>> > > > > > > >
>> > > > > > > > > >> > job,
>> > > > > > > > > >> > this will be a lot easier to implement at Maven 
level
>> > > > > > > > > >> >
>> > > > > > > > > >> >
>> > > > > > > > > >> > But at the moment, my objective was not from
Maven
>> point
>> > > of
>> > > > >
>> > > > > view
>> > > > >
>> > > > > > > > > >> > but
>> > > > > > > > > >> > library developper point of view: show a real
world
>> case
>> > > of
>> > > > >
>> > > > > how
>> > > > >
>> > > > > > an
>> > > > > >
>> > > > > > > > > >> > existing library could be refactored to use the 
>> feature,
>> > > > > >
>> > > > > > expecting
>> > > > > >
>> > > > > > > > that
>> > > > > > > >
>> > > > > > > > > >> > the new source code would be easier to maintain 
>> > > > > > > > > >> >
>> > > > > > > > > >> >
>> > > > > > > > > >> > WDYT?
>> > > > > > > > > >> >
>> > > > > > > > > >> > Regards,
>> > > > > > > > > >> >
>> > > > > > > > > >> > Hervé
>> > > > > > > > > >> >
>> > > > > > > > > >> >
>> > > > > > > > > >> >
>> > > > > > > > > >> >
>> > > > > > > > > >> > [1]
>> > > > > >
>> > > > > >
>> > >
>> https://github.com/codehaus-plexus/plexus-utils/tree/jep-
238/src/main/j
>> > > > > >
>> > > > > > > > > >> > av
>> > > > > > > > > >> > a-7/org/codehaus/plexus/util>
>> > > > > > > > > >> >
>> > > > > > > > > >> > Le jeudi 19 mars 2015 23:38:32 Robert Scholte a 
écrit
>> :
>> > > > > > > > > >> >> 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
>> > > > > > > >
>> > > > > > > > backport
>> > > > > > > >
>> > > > > > > > > >> >>   the
>> > > > > > > > > >> >>
>> > > > > > > > > >> >> run-time changes to
>> > > > > > > > > >> >>
>> > > > > > > > > >> >>   JDK 8u60, thereby enabling JDK 8 to consume
>> > > multi-version
>> > > > > >
>> > > > > > JARs.
>> > > > > >
>> > > > > > > > For
>> > > > > > > >
>> > > > > > > > > >> >>   a
>> > > > > > > > > >> >>
>> > > > > > > > > >> >> detailed discussion,
>> > > > > > > > > >> >>
>> > > > > > > > > >> >>   please see the corresponding thread on the
>> > > core-libs-dev
>> > > > > >
>> > > > > > mailing
>> > > > > >
>> > > > > > > > > >> >>   list.
>> > > > > > > > > >> >>   [1]
>> > > > > > > > > >> >>
>> > > > > > > > > >> >>   Please keep in mind that a JEP in the
Candidate
>> state
>> > > is
>> > > > > >
>> > > > > > merely
>> > > > > >
>> > > > > > > > an
>> > > > > > > >
>> > > > > > > > > >> >>   idea
>> > > > > > > > > >> >>
>> > > > > > > > > >> >> worthy of consideration
>> > > > > > > > > >> >>
>> > > > > > > > > >> >> by JDK Release Projects and related efforts; 
there
>> is
>> > > no
>> > > > > > > >
>> > > > > > > > commitment
>> > > > > > > >
>> > > > > > > > > >> >>   that
>> > > > > > > > > >> >>
>> > > > > > > > > >> >> it will be delivered in
>> > > > > > > > > >> >>
>> > > > > > > > > >> >>   any particular release.
>> > > > > > > > > >> >>
>> > > > > > > > > >> >>   Comments, questions, and suggestions are
welcome on
>> > the
>> > > > > > > >
>> > > > > > > > corelibs-dev
>> > > > > > > >
>> > > > > > > > > >> >> mailing list. (If you
>> > > > > > > > > >> >>
>> > > > > > > > > >> >> haven’t already subscribed to that list then 
please
>> > do
>> > > so
>> > > > > >
>> > > > > > first,
>> > > > > >
>> > > > > > > > > >> >> otherwise your message will be
>> > > > > > > > > >> >>
>> > > > > > > > > >> >>   discarded as spam.)
>> > > > > > > > > >> >>
>> > > > > > > > > >> >>   [0] http://openjdk.java.net/jeps/238
>> > > > > > > > > >> >>   [1]
>> > > > >
>> > > > >
>> >
http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-February/031
>> > > > >
>> > > > > > > > > >> >> 461
>> > > > > > > > > >> >> .ht ml
>> > > > > > > > > >> >>
>> > > > > > > > > >> >> ---
>> > > > > > > > > >> >>
>> > > > > > > > > >> >> IIUC the original request was to have different 
>> version
>> > > of
>> > > > >
>> > > > > the
>> > > > >
>> > > > > > > > > >> >> same
>> > > > > > > > > >> >> class
>> > > > > > > > > >> >> within the same artifact. On the mailinglist I 
>> noticed
>> > a
>> > > > > > > > > >> >> more
>> > > > > > > > > >> >> interesting
>> > > > > > > > > >> >> idea: you need a mechanism to map Classes,
Methods or
>> > > Fields
>> > > > > >
>> > > > > > from
>> > > > > >
>> > > > > > > > one
>> > > > > > > >
>> > > > > > > > > >> >> version to the other.
>> > > > > > > > > >> >>
>> > > > > > > > > >> >> From a Maven perspective I don't see that much 
>> issues
>> > > with
>> > > > >
>> > > > > the
>> > > > >
>> > > > > > > > > >> >>  original
>> > > > > > > > > >> >>
>> > > > > > > > > >> >> idea. You should already be able to do it right 
now
>> > with
>> > > a
>> > > > >
>> > > > > lot
>> > > > >
>> > > > > > of
>> > > > > >
>> > > > > > > > > >> >> execution-blocks.
>> > > > > > > > > >> >> However, I don't see how users would maintain
>> different
>> > > > > >
>> > > > > > version of
>> > > > > >
>> > > > > > > > the
>> > > > > > > >
>> > > > > > > > > >> >> same class (within an IDE).
>> > > > > > > > > >> >> To me this all looks quite complex for rare
cases.
>> > > > > > > > > >> >> If you really want multiple JDK versions of the 
same
>> > > > >
>> > > > > artifact,
>> > > > >
>> > > > > > I
>> > > > > >
>> > > > > > > > would
>> > > > > > > >
>> > > > > > > > > >> >> probably split them into classified artifacts. 
>> > > > > > > > > >> >>
>> > > > > > > > > >> >> Any other comments?
>> > > > > > > > > >> >>
>> > > > > > > > > >> >> thanks,
>> > > > > > > > > >> >> Robert
>> > > > > > > >
>> > > > > > > >
>> > > ------------------------------------------------------------
--------
>> > > > > > > > -
>> > > > > > > >
>> > > > > > > > > >> >> To unsubscribe, e-mail:
>> > dev-unsubscr...@maven.apache.org
>> > > > > > > > > >> >> For additional commands, e-mail:
>> > > dev-h...@maven.apache.org
>> > > > > > > >
>> > > > > > > >
>> > > ------------------------------------------------------------
--------
>> > > > > > > > -
>> > > > > > > >
>> > > > > > > > > >> > To unsubscribe, e-mail:
>> > dev-unsubscr...@maven.apache.org
>> > > > > > > > > >> > For additional commands, e-mail:
>> > > dev-h...@maven.apache.org
>> > > > > >
>> > > > > >
>> > ------------------------------------------------------------
---------
>> > > > > >
>> > > > > > > > > >> To unsubscribe, e-mail:
>> dev-unsubscr...@maven.apache.org
>> > > > > > > > > >> For additional commands, e-mail:
>> > dev-h...@maven.apache.org
>> > > > > >
>> > > > > >
>> > ------------------------------------------------------------
---------
>> > > > > >
>> > > > > > > > > > To unsubscribe, e-mail:
dev-unsubscr...@maven.apache.org
>> > > > > > > > > > For additional commands, e-mail:
>> dev-h...@maven.apache.org
>> > > > >
>> > > > >
>> --------------------------------------------------------------------- 
>> > > > >
>> > > > > > > > > To unsubscribe, e-mail:
dev-unsubscr...@maven.apache.org
>> > > > > > > > > For additional commands, e-mail:
dev-h...@maven.apache.org
>> > > > > > > >
>> > > > > > > >
>> > > ------------------------------------------------------------
--------
>> > > > > > > > -
>> > > > > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.
org
>> > > > > > > > For additional commands, e-mail:
dev-h...@maven.apache.org
>> > > > > >
>> > > > > >
>> > ------------------------------------------------------------
---------
>> > > > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> > > > > > For additional commands, e-mail: dev-h...@maven.apache.org 
>> > >
>> > >
>> > >
---------------------------------------------------------------------
>> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> > > For additional commands, e-mail: dev-h...@maven.apache.org
>> > >
>> > >
>> >
>> >
>> > --
>> > -----
>> > Arnaud Héritier
>> > http://aheritier.net
>> > Mail/GTalk: aheritier AT gmail DOT com
>> > Twitter/Skype : aheritier
>> >
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org






---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Reply via email to