[
https://issues.apache.org/jira/browse/CALCITE-2027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16306947#comment-16306947
]
Piotr Bojko commented on CALCITE-2027:
--------------------------------------
As for CALCITE-1994 - I'm not into the sqlline deep enough to know why its
class-path contains both the elasticsearch2 and elasticsearch5 modules in the
first place. Maybe only one, latest should be as a dependency, the second if
needed - can be handled in a specific way (new artifact/project derived from
sqlline in which elasticss2 is a depdency and elasticss5 is not).
As for dropping support for jdk 7 - this version should die, especially in
commercial world (from which I've come from ;) ).
I thought that moving from source/target 1.7 to 1.8 is not connected to
dependencies versions bumb. For all (strictly commercial, big internal)
projects I have taken part in which JDK was updated to 1.8 - all of them has
came along with a strategy of "grenade in a toilet". Update, test what you can
an deploy. No casualties registered worth to mention. So, if dependencies could
be treated independent - I would leave them when upgrading JDK. Maybe they can
be handled incrementally later.
> 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
> Priority: Trivial
> Fix For: 1.16.0
>
>
> 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)
