You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by Gary Gregory <ga...@gmail.com> on 2014/09/13 23:16:05 UTC
Fwd: Java 7 EOS now set for April 2015
FYI
<div>-------- Original message --------</div><div>From: Stephen Connolly <st...@gmail.com> </div><div>Date:09/13/2014 07:56 (GMT-05:00) </div><div>To: Maven Developers List <de...@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
Re: Java 7 EOS now set for April 2015
Posted by Gary Gregory <ga...@gmail.com>.
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
On Sat, Sep 13, 2014 at 11:04 PM, Ralph Goers <ra...@dslextreme.com>
wrote:
> 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
>
> On Sep 13, 2014, at 7:47 PM, Ralph Goers <Ra...@dslextreme.com>
> wrote:
>
> 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
>
> On Sep 13, 2014, at 7:03 PM, Gary Gregory <ga...@gmail.com> wrote:
>
> 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
>
> On Sat, Sep 13, 2014 at 9:58 PM, Matt Sicker <bo...@gmail.com> wrote:
>
>> On 13 September 2014 19:03, Ralph Goers <ra...@dslextreme.com>
>> wrote:
>>
>>> 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.
>>
>> --
>> Matt Sicker <bo...@gmail.com>
>>
>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> 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
>
>
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
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
Re: Java 7 EOS now set for April 2015
Posted by Ralph Goers <ra...@dslextreme.com>.
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
On Sep 13, 2014, at 7:47 PM, Ralph Goers <Ra...@dslextreme.com> wrote:
> 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
>
> On Sep 13, 2014, at 7:03 PM, Gary Gregory <ga...@gmail.com> wrote:
>
>> 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
>>
>> On Sat, Sep 13, 2014 at 9:58 PM, Matt Sicker <bo...@gmail.com> wrote:
>> On 13 September 2014 19:03, Ralph Goers <ra...@dslextreme.com> wrote:
>> 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.
>>
>> --
>> Matt Sicker <bo...@gmail.com>
>>
>>
>>
>> --
>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> 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
>
Re: Java 7 EOS now set for April 2015
Posted by Ralph Goers <ra...@dslextreme.com>.
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
On Sep 13, 2014, at 7:03 PM, Gary Gregory <ga...@gmail.com> wrote:
> 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
>
> On Sat, Sep 13, 2014 at 9:58 PM, Matt Sicker <bo...@gmail.com> wrote:
> On 13 September 2014 19:03, Ralph Goers <ra...@dslextreme.com> wrote:
> 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.
>
> --
> Matt Sicker <bo...@gmail.com>
>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> 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
Re: Java 7 EOS now set for April 2015
Posted by Gary Gregory <ga...@gmail.com>.
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
On Sat, Sep 13, 2014 at 9:58 PM, Matt Sicker <bo...@gmail.com> wrote:
> On 13 September 2014 19:03, Ralph Goers <ra...@dslextreme.com>
> wrote:
>
>> 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.
>
> --
> Matt Sicker <bo...@gmail.com>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
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
Re: Java 7 EOS now set for April 2015
Posted by Matt Sicker <bo...@gmail.com>.
On 13 September 2014 19:03, Ralph Goers <ra...@dslextreme.com> wrote:
> 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.
--
Matt Sicker <bo...@gmail.com>
Re: Java 7 EOS now set for April 2015
Posted by Ralph Goers <ra...@dslextreme.com>.
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
On Sep 13, 2014, at 2:16 PM, Gary Gregory <ga...@gmail.com> wrote:
> 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
Re: Java 7 EOS now set for April 2015
Posted by Matt Sicker <bo...@gmail.com>.
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.
On 13 September 2014 16:16, Gary Gregory <ga...@gmail.com> wrote:
> 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 <bo...@gmail.com>