maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tibor Digana <tibor.dig...@googlemail.com>
Subject Re: [DISCUSS] Java version requirement for Mavan 3.4.x
Date Mon, 14 Dec 2015 00:16:08 GMT
i agree with stephenc that major version change = API change.

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

We can always open a Vote but then some users may loose a fix been
important for them in old version of Maven @ Java 7.

Maybe another argument to jump to Java 8.
@all Do you see any Java 8 API which is terribly important?
hint: immutable objects, date time API, Files


On Wed, Dec 2, 2015 at 10:17 AM, Stephen Connolly <
stephen.alan.connolly@gmail.com> wrote:

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



-- 
Cheers
Tibor

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