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 <
[hidden email] <http:///user/SendEmail.jtp?type=node&node=5854925&i=0>>
wrote:
On 2 December 2015 at 09:07, Fred Cooke <[hidden email]
<http:///user/SendEmail.jtp?type=node&node=5854925&i=1>> 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 <
[hidden email] <http:///user/SendEmail.jtp?type=node&node=5854925&i=2>>
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 <[hidden email]
<http:///user/SendEmail.jtp?type=node&node=5854925&i=3>>
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 <
[hidden email] <http:///user/SendEmail.jtp?type=node&node=5854925&i=4>
<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"
<[hidden email]
<http:///user/SendEmail.jtp?type=node&node=5854925&i=5> <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 <[hidden email]
<http:///user/SendEmail.jtp?type=node&node=5854925&i=6>
<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 <
[hidden email]
<http:///user/SendEmail.jtp?type=node&node=5854925&i=7>
<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: [hidden email]
<http:///user/SendEmail.jtp?type=node&node=5854925&i=8>
<javascript:;>
For additional commands, e-mail: [hidden email]
<http:///user/SendEmail.jtp?type=node&node=5854925&i=9>
<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: [hidden email]
<http:///user/SendEmail.jtp?type=node&node=5854925&i=10>
<javascript:;>
For additional commands, e-mail: [hidden email]
<http:///user/SendEmail.jtp?type=node&node=5854925&i=11>
<javascript:;>
---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
<http:///user/SendEmail.jtp?type=node&node=5854925&i=12>
<javascript:;>
For additional commands, e-mail: [hidden email]
<http:///user/SendEmail.jtp?type=node&node=5854925&i=13>
<javascript:;>
---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
<http:///user/SendEmail.jtp?type=node&node=5854925&i=14>
<javascript:;>
For additional commands, e-mail: [hidden email]
<http:///user/SendEmail.jtp?type=node&node=5854925&i=15>
<javascript:;>
--
Sent from my phone
--
Cheers
Tibor
------------------------------
If you reply to this email, your message will be added to the discussion
below:
http://maven.40175.n5.nabble.com/DISCUSS-Java-version-requirement-for-Mavan-3-4-x-tp5853427p5854925.html
To start a new topic under Maven Developers, email
[email protected]
To unsubscribe from Maven Developers, click here
<http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=142166&code=dGlib3JkaWdhbmFAYXBhY2hlLm9yZ3wxNDIxNjZ8LTI4OTQ5MjEwMg==>
.
NAML
<http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
