maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Connolly <stephen.alan.conno...@gmail.com>
Subject Re: [DISCUSS] Java version requirement for Mavan 3.4.x
Date Wed, 02 Dec 2015 08:38:11 GMT
If we look at our JVM company history, IIRC

2.0 = Java 1.4
2.1 = Java 1.4
2.2 = Java 1.5
3.0 = Java 1.5
3.1 = Java 1.6
3.2 = Java 1.6
3.3 = Java 1.7

(I may have the jump versions out as this is from memory on my phone)

So historically we have viewed bumping the minimum Java version as a minor
change. The only strong argument I can see for running with 4.0 is to align
the modelVersion... On the other hand actually having a maven version
number that matches the modelVersion might cause confusion in users... The
"oh this is moselVersion 4.0.0 so you need to use at least Maven 4"... On
the one hand, great for adoption and we will want that for modelVersion
5.0.0... On the other hand it gives a false impression...

So the question really becomes how intrinsic a part of the maven API is the
baseline Java version.

You can run maven with Java 8 right now, so it is not a change in any way
for those users.

We do have to start to recognise the risk of dependencies compiled with JDK
8... IOW when releasing bits of Maven we strictly require the release
manager to use the base Java version. That puts restrictions on what the
developers can use.

The base version for plugins will always lag behind the base version for
core. So, for example, plugins are only now getting up to Java 1.6 as a
baseline... But it is getting harder for me to get a Java 6 to compile
with... I know for building the animal sniffer signatures I couldn't get
JDKs that could be installed on my primary OS at the time (Linux) down
below 1.4... With some VMs I was able to get down to 1.3 for some JVMs and
one set of 1.2 signatures. I can't get a Java 1.5 for my Mac... The 1.6 is
getting hard we to install... So 1.7 is an effective baseline unless I
develop in a VM... What will the story be in 2-3 years? The choice we make
now affects that future.

JDK 9 or 10 will drop support for at least -target 1.6 and perhaps -target
1.7 so as I see it we have to start being more aggressive whether that
starts now or in 6 months when JDK 9 comes out is a timing question only
IMHO

On Wednesday 2 December 2015, Hervé BOUTEMY <herve.boutemy@free.fr> wrote:

> from source code point of view, you don't need to change anything to
> compile
> with JDK 8, true
>
> But what we showed with Arnaud in our ApacheCON demo (sorry to tell a lot
> about it, but that was the topic...), JDK 8 compiler may introduce Java 8
> API
> references into bytecode from source that don't have any JDK 8 reference
> See bonus demo [1] for a demo :)
>
> This is the first time in JDK history that such a behaviour happens: using
> JDK
> 8 instead of JDK 7 for launching Maven/javac does not give same result
> (unless
> using toolchains, of course).
>
> That's why I currently fear with JDK 8 that people will get some unexpected
> failures. And during the conf, for a few attendees, this demo gave a "now I
> understand what happened to me on one of my builds..." reaction
>
> Regards,
>
> Hervé
>
> [1]
> https://github.com/MavenDemo/java-evolving-en/blob/master/toolchains/bonus.sh
>
> Le mardi 1 décembre 2015 08:10:51 Kristian Rosenvold a écrit :
> > Technically, JDK8 is entirely undramatic for maven; I'm having a hard
> > time understanding why it should trigger any api changes or any other
> > "4.0" reasons.
> >
> > I cannot make heads or tails of the supposed versioning policy, the
> > language is too convoluted for me or I'm just not smart enough.
> >
> > If we are to stay aligned with current practice, jdk8 should be a
> > minor release. As for the actual topic of "should" we switch, i'm
> > always in favour of moving forwards. But not in any religious sense.
> >
> >
> > Kristian
> >
> > 2015-12-01 6:59 GMT+01:00 Mirko Friedenhagen <mfriedenhagen@gmail.com
> <javascript:;>>:
> > > +1 for Java 8 and the version bump to 4.x,.communicates the change more
> > > clearly.
> > >
> > > Regards
> > > Mirko
> > > --
> > > Sent from my mobile
> > > On Nov 30, 2015 23:44, "Stephen Connolly"
> > > <stephen.alan.connolly@gmail.com <javascript:;>>
> > >
> > > wrote:
> > >> I have no issues if we want to call the next version 4.0.x rather than
> > >> 3.4.x
> > >>
> > >> In my view there are some advantages to using the 4.0.x version
> number as
> > >> a
> > >> Java 8 bump... namely that leaves the modelVersion 5.0 changes to
> Maven
> > >> 5.0
> > >>
> > >> And let's face it, it will just be less confusing to users to say "To
> > >> build
> > >> a modelVersion 5.0 pom you need Maven 5"
> > >>
> > >> So if there is strong interest in jumping to Java 8 perhaps we just
> bite
> > >> the bullet and jump to Maven 4.0 with Java 8 now and then we can start
> > >> the
> > >> model version 5.0 debate in earnest as we plan the features for Maven
> 5.0
> > >> ;-)
> > >>
> > >> -Stephen
> > >>
> > >> On 30 November 2015 at 22:25, Jason van Zyl <jason@takari.io
> <javascript:;>> wrote:
> > >> > I agree that jumping to Java 8 would be unwise. I think we can wait
> > >> > until
> > >> > 4.x. Don’t get me wrong, I’d prefer to use Java 8 and I do for
> almost
> > >> > everything else but I don’t think there’s any dire rush.
> > >> >
> > >> > > On Nov 30, 2015, at 2:00 PM, Michael Osipov <michaelo@apache.org
> <javascript:;>>
> > >>
> > >> wrote:
> > >> > > Am 2015-11-30 um 22:18 schrieb Stephen Connolly:
> > >> > >> Picking up from
> > >>
> > >>
> http://mail-archives.apache.org/mod_mbox/maven-dev/201511.mbox/%3CCA%2BnP
> > >> nMyjogmqRweYbxLuULLB9ve2P6MPcQuH%2BPkxcNn-oN4GPg%40mail.gmail.com
> %3E>>
> > >> > >> (and my follow up to that but archive.apache.org is being
a tad
> > >> > >> slow)
> > >> > >>
> > >> > >> Here is our policy:
> > >> > >>
> > >> > >> The development line of Maven core should require a minimum
JRE
> > >>
> > >> version
> > >>
> > >> > >>> that is no older than 18 months after the end of Oracle's
public
> > >> >
> > >> > updates
> > >> >
> > >> > >>> for that JRE version at the time that the first version
of the
> > >> >
> > >> > development
> > >> >
> > >> > >>> line was released, but may require a higher minimum JRE
version
> if
> > >> >
> > >> > other
> > >> >
> > >> > >>> requirements dictate a higher JRE version
> > >> > >>
> > >> > >> (Source:
> > >>
> https://cwiki.apache.org/confluence/display/MAVEN/Version+number+policy
> > >>
> > >> > )
> > >> >
> > >> > >> OK, so it's a draft policy... but we've all been silent on
the
> > >> > >> draft,
> > >>
> > >> so
> > >>
> > >> > >> lazy consensus!
> > >> > >>
> > >> > >> Now in
> http://www.oracle.com/technetwork/java/javase/eol-135779.html
> > >> >
> > >> > they
> > >> >
> > >> > >> state:
> > >> > >>
> > >> > >> after April 2015, Oracle will not post further updates of
Java
> SE 7
> > >> > >> to
> > >> >
> > >> > its
> > >> >
> > >> > >>> public download sites
> > >> > >>
> > >> > >> So per our (draft) version number policy, we can keep Java
7 as
> the
> > >> > >> baseline :-( or we can choose to upgrade code to Java 8 (because
> we
> > >> >
> > >> > want to
> > >> >
> > >> > >> use lambdas... there's a requirement)
> > >> > >>
> > >> > >>
> > >> > >> So assuming we bump the master branch of Maven core to 3.4.0,
> what
> > >>
> > >> Java
> > >>
> > >> > >> version do we want to use as the baseline?
> > >> > >>
> > >> > >> There are thankfully only two options:
> > >> > >>
> > >> > >> Java 7
> > >> > >>
> > >> > >>   + Not actually changing things
> > >> > >>   + May make it easier to drive adoption
> > >> > >>   - Still can't use newer language features in core
> > >> > >>   - Java 7 is EOL and it may get harder for developers to
source
> > >> > >>   JDKs
> > >>
> > >> to
> > >>
> > >> > >> test and develop against
> > >> > >
> > >> > > Bumping Java requirements again in minor (!) release is insane.
I
> am
> > >> >
> > >> > against that, regardless Oracle has set this EoL or not. Folks at
> > >> > Commons
> > >> > are doing the right this. Bump requirement with a major not a minor.
> > >> > Moreover, we have too many components which have been neglected for
> > >>
> > >> years,
> > >>
> > >> > too many outstanding issues in JIRA. E.g., Doxia, I try to fix some
> > >> > once
> > >>
> > >> in
> > >>
> > >> > a while but there a too few of us to take care of the entire Maven
> > >> > ecosystem.
> > >> >
> > >> > > I would rather see us to bringing the entire system on a decent
> level
> > >> >
> > >> > before we make a big leaps which Java. It does not make sense to be
> to
> > >>
> > >> put
> > >>
> > >> > Maven on the fast lane but let other components suffer at the edge
> of
> > >> > the
> > >> > road.
> > >> >
> > >> > > Michael
> > >> > >
> > >> > >
> > >> > >
> ---------------------------------------------------------------------
> > >> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> <javascript:;>
> > >> > > For additional commands, e-mail: dev-help@maven.apache.org
> <javascript:;>
> > >> >
> > >> > Thanks,
> > >> >
> > >> > Jason
> > >> >
> > >> > ----------------------------------------------------------
> > >> > Jason van Zyl
> > >> > Founder, Takari and Apache Maven
> > >> > http://twitter.com/jvanzyl
> > >> > http://twitter.com/takari_io
> > >> > ---------------------------------------------------------
> > >> >
> > >> > Be not afraid of growing slowly, be only afraid of standing still.
> > >> >
> > >> >  -- Chinese Proverb
> > >> >
> > >> >
> ---------------------------------------------------------------------
> > >> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> <javascript:;>
> > >> > For additional commands, e-mail: dev-help@maven.apache.org
> <javascript:;>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org <javascript:;>
> > For additional commands, e-mail: dev-help@maven.apache.org
> <javascript:;>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org <javascript:;>
> For additional commands, e-mail: dev-help@maven.apache.org <javascript:;>
>
>

-- 
Sent from my phone

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message