Java 7 EOS now set for April 2015

[Gary Gregory]

FYI

<div>-------- Original message --------</div><div>From: Stephen Connolly <***@gmail.com> </div><div>Date:09/13/2014 07:56 (GMT-05:00) </div><div>To: Maven Developers List <***@maven.apache.org> </div><div>Subject: Java 7 EOS now set for April 2015 </div><div>
</div>http://mail.openjdk.java.net/pipermail/jdk7u-dev/2014-April/008910.html

Wondering if we should start thinking about upping to Java 7 as our minimum next year ;-)

Sent from my iPad

[Matt Sicker]

So would we like to do this for something like version 2.2, 2.3, or make a
3.0 version? I'm not really sure on how other projects tend to handle these
sorts of compatibility changes.

Post by Gary Gregory
FYI
-------- Original message --------
From: Stephen Connolly
Date:09/13/2014 07:56 (GMT-05:00)
To: Maven Developers List
Subject: Java 7 EOS now set for April 2015
http://mail.openjdk.java.net/pipermail/jdk7u-dev/2014-April/008910.html
Wondering if we should start thinking about upping to Java 7 as our minimum next year ;-)
Sent from my iPad

[Ralph Goers]

Log4j 1.x stuck with JDK 1.2 for many years for a reason.

Although public support for Java 6 ended in 2013, Oracle’s site [1] says Premier support is available until Dec 2015 and extended support is available until Dec 2018. Java 7’s extended support runs through 2022. So just because the “free” version will be at “end of life” doesn’t necessarily mean everyone will stop using it.

That said, I think we should have a coherent policy. For example, we could plan to upgrade our minimum version whenever Premier support ends (Java 6 until Dec 2015, Java 7 until July 2019, etc).

I also wouldn’t want to jump from version 2.x to 3.x just because we changed the minimum JDK version. At the same time I think it should be clear to users that they can’t just upgrade from 2.2 to 2.3. That may mean we would want to use 4 digit version numbers and only go to 2.1.0.0 when we switch the JDK.

I should also state that I have no problem if some of our add-on modules require a different JDK version. I also think we could do things like make things like Date formatting be pluggable so that if you are running on JDK 8 you can use it instead of whatever core normally provides.

Ralph

[1] http://www.oracle.com/technetwork/java/eol-135779.html

Post by Gary Gregory
FYI
-------- Original message --------
From: Stephen Connolly
Date:09/13/2014 07:56 (GMT-05:00)
To: Maven Developers List
Subject: Java 7 EOS now set for April 2015
http://mail.openjdk.java.net/pipermail/jdk7u-dev/2014-April/008910.html
Wondering if we should start thinking about upping to Java 7 as our minimum next year ;-)
Sent from my iPad

[Matt Sicker]

Post by Ralph Goers
For example, we could plan to upgrade our minimum version whenever Premier
support ends (Java 6 until Dec 2015, Java 7 until July 2019, etc).

Good idea.

Post by Ralph Goers
I also wouldn’t want to jump from version 2.x to 3.x just because we
changed the minimum JDK version. At the same time I think it should be
clear to users that they can’t just upgrade from 2.2 to 2.3. That may mean
we would want to use 4 digit version numbers and only go to 2.1.0.0 when we
switch the JDK.

I don't understand this four digit version number thing. Could you
elaborate?

Post by Ralph Goers
I should also state that I have no problem if some of our add-on modules
require a different JDK version. I also think we could do things like make
things like Date formatting be pluggable so that if you are running on JDK
8 you can use it instead of whatever core normally provides.

Could we do something like Spring and have some annotations for Java7 and
Java8 to mark classes that require those versions of Java? I'd have to look
into it more to see how they compile everything this way, but it seems like
a neat idea.

[Gary Gregory]

I think we should keep it simple. If some version of Java is dead, past
public update EOLs, then it's OK by me to switch _master development_ to a
supported Java version. To me, this means that all master development
should be on Java 7 now.

Perso, I do not want to support multiple Java versions in one code base,
seems like a headache and hoop jumping. Unless we have a really good
reason... ;-)

Gary

Post by Matt Sicker

Post by Ralph Goers
For example, we could plan to upgrade our minimum version whenever
Premier support ends (Java 6 until Dec 2015, Java 7 until July 2019, etc).

Good idea.

Post by Ralph Goers
I also wouldn’t want to jump from version 2.x to 3.x just because we
changed the minimum JDK version. At the same time I think it should be
clear to users that they can’t just upgrade from 2.2 to 2.3. That may mean
we would want to use 4 digit version numbers and only go to 2.1.0.0 when we
switch the JDK.

I don't understand this four digit version number thing. Could you
elaborate?

Post by Ralph Goers
I should also state that I have no problem if some of our add-on modules
require a different JDK version. I also think we could do things like make
things like Date formatting be pluggable so that if you are running on JDK
8 you can use it instead of whatever core normally provides.

Could we do something like Spring and have some annotations for Java7 and
Java8 to mark classes that require those versions of Java? I'd have to look
into it more to see how they compile everything this way, but it seems like
a neat idea.
--

[Ralph Goers]

I really don’t think there are that many features where we would need JDK specific implementations of something.

The problem is, your definition of “dead” and mine are different. I know very well that there are many users still on JDK 6. Also, IBM [1] still has not announced an end of service date for Java 6, so I am quite certain there ere a number of people using Java 6 there.

To be clear, I am very much opposed to raising the minimum JDK version as quickly as you seem to want.

Ralph

[1] http://www.ibm.com/developerworks/java/jdk/lifecycle/index.html

I think we should keep it simple. If some version of Java is dead, past public update EOLs, then it's OK by me to switch _master development_ to a supported Java version. To me, this means that all master development should be on Java 7 now.
Perso, I do not want to support multiple Java versions in one code base, seems like a headache and hoop jumping. Unless we have a really good reason... ;-)
Gary
For example, we could plan to upgrade our minimum version whenever Premier support ends (Java 6 until Dec 2015, Java 7 until July 2019, etc).
Good idea.
I also wouldn’t want to jump from version 2.x to 3.x just because we changed the minimum JDK version. At the same time I think it should be clear to users that they can’t just upgrade from 2.2 to 2.3. That may mean we would want to use 4 digit version numbers and only go to 2.1.0.0 when we switch the JDK.
I don't understand this four digit version number thing. Could you elaborate?
I should also state that I have no problem if some of our add-on modules require a different JDK version. I also think we could do things like make things like Date formatting be pluggable so that if you are running on JDK 8 you can use it instead of whatever core normally provides.
Could we do something like Spring and have some annotations for Java7 and Java8 to mark classes that require those versions of Java? I'd have to look into it more to see how they compile everything this way, but it seems like a neat idea.
--
--
Java Persistence with Hibernate, Second Edition
JUnit in Action, Second Edition
Spring Batch in Action
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

[Ralph Goers]

Oops. Sorry. The End of Service date for Java 6 on everything but z/OS (IBM mainframes) is September 2017. That would include AIX. Java 7 EOS on AIX is Sept 2019, which lines up with Oracle’s end of Premium support for Java 7.

I agree with keeping it simple. We will provide support until Oracle’s announced date for the end of Premium support. The only thing different than your “simple” proposal is you want to use the EOL of the free version of Java. That is just way too short.

Ralph

Post by Ralph Goers
I really don’t think there are that many features where we would need JDK specific implementations of something.
The problem is, your definition of “dead” and mine are different. I know very well that there are many users still on JDK 6. Also, IBM [1] still has not announced an end of service date for Java 6, so I am quite certain there ere a number of people using Java 6 there.
To be clear, I am very much opposed to raising the minimum JDK version as quickly as you seem to want.
Ralph
[1] http://www.ibm.com/developerworks/java/jdk/lifecycle/index.html

I think we should keep it simple. If some version of Java is dead, past public update EOLs, then it's OK by me to switch _master development_ to a supported Java version. To me, this means that all master development should be on Java 7 now.
Perso, I do not want to support multiple Java versions in one code base, seems like a headache and hoop jumping. Unless we have a really good reason... ;-)
Gary
For example, we could plan to upgrade our minimum version whenever Premier support ends (Java 6 until Dec 2015, Java 7 until July 2019, etc).
Good idea.
I also wouldn’t want to jump from version 2.x to 3.x just because we changed the minimum JDK version. At the same time I think it should be clear to users that they can’t just upgrade from 2.2 to 2.3. That may mean we would want to use 4 digit version numbers and only go to 2.1.0.0 when we switch the JDK.
I don't understand this four digit version number thing. Could you elaborate?
I should also state that I have no problem if some of our add-on modules require a different JDK version. I also think we could do things like make things like Date formatting be pluggable so that if you are running on JDK 8 you can use it instead of whatever core normally provides.
Could we do something like Spring and have some annotations for Java7 and Java8 to mark classes that require those versions of Java? I'd have to look into it more to see how they compile everything this way, but it seems like a neat idea.
--
--
Java Persistence with Hibernate, Second Edition
JUnit in Action, Second Edition
Spring Batch in Action
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

[Gary Gregory]

We might not be that far apart, at my work, we care very much about IBM,
AIX, the i/Series and z/Series. I just do not want to linger on an old
platform. We just need to strike a balance. Now that Java 8 is out, I see a
much stronger desire from developers to use it than I did when Java 7 came
out. Lambdas provides a sweet incentive.

Gary

Post by Ralph Goers
Oops. Sorry. The End of Service date for Java 6 on everything but z/OS
(IBM mainframes) is September 2017. That would include AIX. Java 7 EOS on
AIX is Sept 2019, which lines up with Oracle’s end of Premium support for
Java 7.
I agree with keeping it simple. We will provide support until Oracle’s
announced date for the end of Premium support. The only thing different
than your “simple” proposal is you want to use the EOL of the free version
of Java. That is just way too short.
Ralph
I really don’t think there are that many features where we would need JDK
specific implementations of something.
The problem is, your definition of “dead” and mine are different. I know
very well that there are many users still on JDK 6. Also, IBM [1] still has
not announced an end of service date for Java 6, so I am quite certain
there ere a number of people using Java 6 there.
To be clear, I am very much opposed to raising the minimum JDK version as
quickly as you seem to want.
Ralph
[1] http://www.ibm.com/developerworks/java/jdk/lifecycle/index.html
I think we should keep it simple. If some version of Java is dead, past
public update EOLs, then it's OK by me to switch _master development_ to a
supported Java version. To me, this means that all master development
should be on Java 7 now.
Perso, I do not want to support multiple Java versions in one code base,
seems like a headache and hoop jumping. Unless we have a really good
reason... ;-)
Gary

Post by Matt Sicker

Post by Ralph Goers
For example, we could plan to upgrade our minimum version whenever
Premier support ends (Java 6 until Dec 2015, Java 7 until July 2019, etc).

Good idea.

Post by Ralph Goers
I also wouldn’t want to jump from version 2.x to 3.x just because we
changed the minimum JDK version. At the same time I think it should be
clear to users that they can’t just upgrade from 2.2 to 2.3. That may mean
we would want to use 4 digit version numbers and only go to 2.1.0.0 when we
switch the JDK.

I don't understand this four digit version number thing. Could you elaborate?

Post by Ralph Goers
I should also state that I have no problem if some of our add-on modules
require a different JDK version. I also think we could do things like make
things like Date formatting be pluggable so that if you are running on JDK
8 you can use it instead of whatever core normally provides.

Could we do something like Spring and have some annotations for Java7
and Java8 to mark classes that require those versions of Java? I'd have to
look into it more to see how they compile everything this way, but it seems
like a neat idea.
--

--
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory