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 <[email protected]> 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 <[email protected]> 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 <[email protected]> wrote: >> On 13 September 2014 19:03, Ralph Goers <[email protected]> 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 <[email protected]> >> >> >> >> -- >> E-Mail: [email protected] | [email protected] >> 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 >
