[
https://issues.apache.org/jira/browse/CALCITE-2027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16238507#comment-16238507
]
Julian Hyde commented on CALCITE-2027:
--------------------------------------
[~elserj], You seem to work across more projects than I do. Is there any best
practice to figure out which components to upgrade, and when? It seems to be a
haphazard push-pull of enthusiasm and inertia.
Staying on old versions of components seems to be asking for problems such as
security bugs, but when you upgrade you get scowls from other projects about
causing incompatibility. Surely there's a better way?!
> Drop support for Java 7 (JDK 1.7)
> ---------------------------------
>
> Key: CALCITE-2027
> URL: https://issues.apache.org/jira/browse/CALCITE-2027
> Project: Calcite
> Issue Type: Bug
> Reporter: Julian Hyde
> Assignee: Julian Hyde
>
> Drop support for Java 7 (also known as JDK 1.7):
> * The code would no longer compile under JDK 7
> * Compiler would have source 1.8 target 1.8
> * Class files would run on JDK 8 and higher
> * Developers can use Java 8 syntax such as lambdas and default methods
> We would continue to build and run under JDK 8 and 9.
> I think it would be best to wait a while before converting existing code to
> Java 8 style (e.g. converting SAM anonymous classes to lambdas) because code
> changes might be extensive.
> I expect there will be cases that we want to change interfaces so that they
> are easier to use as lambdas. Let's make those changes cautiously when we
> come across them, and mark existing interfaces and methods deprecated until
> we remove them in 2.0.
> Let's give at least one release notice of this change. In 1.15 (the next
> release) let's announce that this will be the last release that supports Java
> 7. So this will be fixed for 1.16.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
