classpathx
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Classpathx] Project Java Standard


From: Chris Burdess
Subject: Re: [Classpathx] Project Java Standard
Date: Sun, 19 Jan 2014 08:23:01 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0

On 18/01/14 23:25, Conrad T. Pino wrote:
> The /trunk/mail/INSTALL states: GNU JavaMail requires at least version 1.4
> of the Java libraries.
> 
> Given last Sun/Oracle Java 1.4 general release was 1.4.2_19, all later
> updates for Solaris only, and Wikipedia stating support and security updates
> for Java 1.4 ended in October 2008 which mean security vulnerabilities are
> aggregating at this Java level.
> 
> Given last Sun/Oracle Java 5.0 general release was 1.5.0_22 and J2SE 5.0
> reached the end of its service life as well, see:
> http://www.oracle.com/technetwork/java/javase/releasenotes-142123.html, and
> Wikipedia states public updates ended as of November 3, 2009.
> 
> Given last Sun/Oracle Java 6.0 general release was 6u45 and J2SE 6.0, and
> Wikipedia states public updates ended as of April 2013.
> 
> My general ignorance of GNU Compiler for the Java Programming Language (GCJ)
> specifics is limited to
> http://gcc.gnu.org/onlinedocs/gcj/Limitations.html#Limitations which implies
> to me Java 1.2 with some 1.4 features.  Does this mean GCJ is already
> unsupported by this project?
> 
> In general GCJ really lags, so how shall we balance GCJ progress versus what
> the broad Java world generally uses?
> 
> In general I suggest Oracle seems to be shortening their Java product
> support lifecycle; should we follow suit as well?
> 
> I assert Java 1.4 is no longer acceptable leaving Java 5.0 the lowest
> acceptable standard.
> 
> In particular I propose elevating the project minimum standard to the Java
> SE 6.0 level.
> 
> That said what is the project consensus for an acceptable balance?

We now use some 1.5 language features, which are supported by free Java
compilers such as gcj and ecj, in the interests of readability and
maintainability.

We don't yet use any API methods introduced in 6.0 or onward; if there
is a compelling case to do so then we could look at whether classpath
supports them since this is the reference J2SE API implementation for
free Java.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]