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 09:17:33 GMT
On 2 December 2015 at 09:07, Fred Cooke <fred.cooke@gmail.com> wrote:

> "You can run maven with Java 8 right now, so it is not a change in any way
> for those users."
>
> This equates to ruling out developers who are forced to use older JDKs/JREs
> if you look at it the other way.
>

Actually you are misusing my argument. My point there was whether a bump to
Java 8 should be a bump in major or minor version number.

What I am saying is that you can argue that it isn't a major change because
our API remains compatible and we are just removing JVMs that are no longer
supported.


>
> "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."
>
> As per usual, Jason has it right, IMO.
>
> Don't forget Maven is a tool, and as with libs, the decision to push
> everything above you upward is a dangerous one. As far as tools go in J
> land, they don't come much more foundational than Maven.
>

There are two points I would like to make:

1. If you and your team have a need for a Java 6 or 7 version of Maven,
please step up and continue to maintain those versions. We are not going to
drop support in the plugins (where most of the stuff matters) for Java 6
any time soon... and if you are in a restricted environment you likely
cannot pick up new features easily anyway... CALL TO ACTION: We need people
prepared to maintain the older release lines

2. Think of the plugins in 2-3 years. Right now, to build a plugin and test
it against the supported lines I sometimes have to go and set up a VM
running an old version of linux and then pull a JDK 1.5 from the archive on
oracle's download site because the installer doesn't work on newer versions
of linux and there is no installer on my primary development platform...
Similarly I need to do dancing games with older versions of windows... Now
roll forward 2-3 years... will I be similarly constrained to get a Java 7?
At least Java 8 is supported until September 2017... we can expect that it
will be somewhat easy to get a Java 8 for most platforms for at least
another 6-12 months before you start to hit the need for running VMs... the
longer we put off updating the baseline JDK *in core* the worse the pain
will be in 2-3 years for us when developing and maintaining our plugins



>
> Regards,
>
> Fred.
>
> On Wed, Dec 2, 2015 at 9:38 PM, Stephen Connolly <
> stephen.alan.connolly@gmail.com> wrote:
>
> > 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