You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by Gary Gregory <ga...@gmail.com> on 2014/08/28 02:32:33 UTC

Java 6 vs. 7

Hi All,

Now that DERBY-6213 <https://issues.apache.org/jira/browse/DERBY-6213> is
in the books, is there any interest here in deprecating Java 6 in favor of
Java 7?

Gary
-- 
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 6 vs. 7

Posted by "Dag H. Wanvik" <da...@oracle.com>.
On 28. aug. 2014 20:32, mike matrigali wrote:
> Are there "compile" level features that developers are looking for in 
> java7 and above?  A lot of my users take much longer to upgrade their
> database software, so I do work to backport fixes into older releases.
> DERBY-6213 and follow on work that changed code made backports not apply
> cleanly any more - which leads to more work and greater possiblity of 
> not correctly backporting changes.  I would like to understand the 
> likely non-backward compatible changes that this change would bring 
> about.
>
>

Apart from added API capabilities, the majrr changes on the language 
level are summarized here:


    Enhancements in Java SE 7

  * Binary Literals
    <http://docs.oracle.com/javase/7/docs/technotes/guides/language/binary-literals.html>
    - In Java SE 7, the integral types (|byte|, |short|, |int|, and
    |long|) can also be expressed using the binary number system. To
    specify a binary literal, add the prefix |0b| or |0B| to the number.
  * Underscores in Numeric Literals
    <http://docs.oracle.com/javase/7/docs/technotes/guides/language/underscores-literals.html>
    - Any number of underscore characters (|_|) can appear anywhere
    between digits in a numerical literal. This feature enables you, for
    example, to separate groups of digits in numeric literals, which can
    improve the readability of your code.
  * Strings in switch Statements
    <http://docs.oracle.com/javase/7/docs/technotes/guides/language/strings-switch.html>
    - You can use the |String| class in the expression of a |switch|
    statement.
  * Type Inference for Generic Instance Creation
    <http://docs.oracle.com/javase/7/docs/technotes/guides/language/type-inference-generic-instance-creation.html>
    - You can replace the type arguments required to invoke the
    constructor of a generic class with an empty set of type parameters
    (|<>|) as long as the compiler can infer the type arguments from the
    context. This pair of angle brackets is informally called the /diamond/.
  * Improved Compiler Warnings and Errors When Using Non-Reifiable
    Formal Parameters with Varargs Methods
    <http://docs.oracle.com/javase/7/docs/technotes/guides/language/non-reifiable-varargs.html>
    - The Java SE 7 complier generates a warning at the declaration site
    of a varargs method or constructor with a non-reifiable varargs
    formal parameter. Java SE 7 introduces the compiler option
    |-Xlint:varargs| and the annotations |@SafeVarargs| and
    |@SuppressWarnings({"unchecked", "varargs"})| to supress these warnings.
  * The try-with-resources Statement
    <http://docs.oracle.com/javase/7/docs/technotes/guides/language/try-with-resources.html>
    - The |try|-with-resources statement is a |try| statement that
    declares one or more resources. A /resource/ is an object that must
    be closed after the program is finished with it. The
    |try|-with-resources statement ensures that each resource is closed
    at the end of the statement. Any object that implements the new
    |java.lang.AutoCloseable| interface or the |java.io.Closeable|
    interface can be used as a resource. The classes
    |java.io.InputStream|, |OutputStream|, |Reader|, |Writer|,
    |java.sql.Connection|, |Statement|, and |ResultSet| have been
    retrofitted to implement the |AutoCloseable| interface and can all
    be used as resources in a |try|-with-resources statement.
  * Catching Multiple Exception Types and Rethrowing Exceptions with
    Improved Type Checking
    <http://docs.oracle.com/javase/7/docs/technotes/guides/language/catch-multiple.html>
    - A single |catch| block can handle more than one type of exception.
    In addition, the compiler performs more precise analysis of rethrown
    exceptions than earlier releases of Java SE. This enables you to
    specify more specific exception types in the |throws| clause of a
    method declaration.

Thanks,
Dag

Re: Java 6 vs. 7

Posted by mike matrigali <mi...@gmail.com>.
On 8/28/2014 10:26 AM, Rick Hillegas wrote:
> On 8/27/14 5:32 PM, Gary Gregory wrote:
>> Hi All,
>>
>> Now that DERBY-6213 <https://issues.apache.org/jira/browse/DERBY-6213>
>> is in the books, is there any interest here in deprecating Java 6 in
>> favor of Java 7?
>>
>> Gary
>> --
>> E-Mail: garydgregory@gmail.com <ma...@gmail.com> |
>> ggregory@apache.org <ma...@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
>> <http://garygregory.wordpress.com/>
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
> Thanks for raising this issue, Gary. Oracle stopped creating public
> releases of Java 6 last year:
> http://www.oracle.com/technetwork/java/eol-135779.html. However, Oracle
> continues to provide new releases of Java 6 for customers who buy
> support contracts. I can't find any information on IBM's commitment to
> Java 6. Maybe one of the IBM engineers can comment.
>
> In the interests of reducing code/testing complexity, I'd be happy to
> deprecate support for Java 6. When we deprecate a platform, we generally
> produce one last feature release for it. It is that last release which
> announces the deprecation. If we followed that convention, then next
> year's 10.12 release would still support Java 6. The first release to
> drop Java 6 support would be 10.13, due out in 2016 if we keep to our
> usual release cadence.
>
> What do other people think?
>
> Thanks,
> -Rick
>
We should eventually vote the issue, but for me I think rick's suggested 
plan should be the quickest transition.  It fits the model
that we have followed in the past, and allows warning to legacy 
applications running against Derby that would like to continue to
upgrade their db software but may not be ready to upgrade their JVM.
I would support a vote that announced deprecation with 10.12 release,
and implemented with 10.13 (or any plan longer than this).

Are there "compile" level features that developers are looking for in 
java7 and above?  A lot of my users take much longer to upgrade their
database software, so I do work to backport fixes into older releases.
DERBY-6213 and follow on work that changed code made backports not apply
cleanly any more - which leads to more work and greater possiblity of 
not correctly backporting changes.  I would like to understand the 
likely non-backward compatible changes that this change would bring about.

Re: Java 6 vs. 7

Posted by Myrna van Lunteren <m....@gmail.com>.
Hi,

I looked but cannot find any official EOS statements or dates for Java 6
from IBM.

I found that Java 5 by IBM had a EOS(or perhaps EOL?) in 2009 - just like
Oracle did; which does not imply a commitment regarding Java 6, however.

Either way, I think it's fair to deprecate Java 6 in a future feature
release - I like Rick's proposal.

Was there some specific functionality that is of concern/interest here?

Myrna


On Thu, Aug 28, 2014 at 10:26 AM, Rick Hillegas <ri...@oracle.com>
wrote:

> On 8/27/14 5:32 PM, Gary Gregory wrote:
>
>> Hi All,
>>
>> Now that DERBY-6213 <https://issues.apache.org/jira/browse/DERBY-6213>
>> is in the books, is there any interest here in deprecating Java 6 in favor
>> of Java 7?
>>
>> Gary
>> --
>> E-Mail: garydgregory@gmail.com <ma...@gmail.com> |
>> ggregory@apache.org <ma...@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 <http://garygregory.wordpress.com/
>> >
>>
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>>
> Thanks for raising this issue, Gary. Oracle stopped creating public
> releases of Java 6 last year: http://www.oracle.com/
> technetwork/java/eol-135779.html. However, Oracle continues to provide
> new releases of Java 6 for customers who buy support contracts. I can't
> find any information on IBM's commitment to Java 6. Maybe one of the IBM
> engineers can comment.
>
> In the interests of reducing code/testing complexity, I'd be happy to
> deprecate support for Java 6. When we deprecate a platform, we generally
> produce one last feature release for it. It is that last release which
> announces the deprecation. If we followed that convention, then next year's
> 10.12 release would still support Java 6. The first release to drop Java 6
> support would be 10.13, due out in 2016 if we keep to our usual release
> cadence.
>
> What do other people think?
>
> Thanks,
> -Rick
>

Re: Java 6 vs. 7

Posted by Rick Hillegas <ri...@oracle.com>.
On 8/27/14 5:32 PM, Gary Gregory wrote:
> Hi All,
>
> Now that DERBY-6213 <https://issues.apache.org/jira/browse/DERBY-6213> 
> is in the books, is there any interest here in deprecating Java 6 in 
> favor of Java 7?
>
> Gary
> -- 
> E-Mail: garydgregory@gmail.com <ma...@gmail.com> | 
> ggregory@apache.org <ma...@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 
> <http://garygregory.wordpress.com/>
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
Thanks for raising this issue, Gary. Oracle stopped creating public 
releases of Java 6 last year: 
http://www.oracle.com/technetwork/java/eol-135779.html. However, Oracle 
continues to provide new releases of Java 6 for customers who buy 
support contracts. I can't find any information on IBM's commitment to 
Java 6. Maybe one of the IBM engineers can comment.

In the interests of reducing code/testing complexity, I'd be happy to 
deprecate support for Java 6. When we deprecate a platform, we generally 
produce one last feature release for it. It is that last release which 
announces the deprecation. If we followed that convention, then next 
year's 10.12 release would still support Java 6. The first release to 
drop Java 6 support would be 10.13, due out in 2016 if we keep to our 
usual release cadence.

What do other people think?

Thanks,
-Rick