[
https://issues.apache.org/jira/browse/CALCITE-2027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16238562#comment-16238562
]
Josh Elser commented on CALCITE-2027:
-------------------------------------
bq. 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?!
:) that's the trick, isn't it.
My opinion has changed over the years, most recently influenced by some of your
decisions on Calcite, actually. My general thought process is this:
* Minimize dependencies that are "visible" to your downstream components.
* With JARs that don't have any shading (e.g. calcite-core), curate the list of
dependencies that it requires and versions that we know work with it. We always
have at least one version that we know is compatible. This enables downstream
folks who *want* to minimize the size of an application to do so.
* For "client-side" dependencies, publish a shaded artifact that includes as
many dependencies as possible relocated to make sure your client can work
regardless of classpath (things like loggers suck as you often can't relocate
safely). This enables folks who "don't care" to just solve classpath conflict
issues via a large application disk usage.
* For "server-side" things, if you're sure that the "server" doesn't run inside
of anything else, do nothing. e.g. Avatica with the Jetty server is
self-contained, so dependency compatibility isn't a concern. However, if we
think of Avatica as a container which could be deployed into Tomcat or JBoss,
then we need to do the same as we do for "client-side".
https://www.elastic.co/blog/to-shade-or-not-to-shade is a nice little post that
covers the consequences of shading well.
The biggest concern with shading dependencies into an artifact that we publish
is that this puts an onus on Calcite to watch for security issues in every
dependency that we bundle. We're more like a an operating-system packager at
this point -- e.g. if Calcite bundles guava in a shaded jar and there is a
Guava CVE, we need to make a new release of Calcite that includes the patched
Guava version.
This is all a long winded way of getting Calcite into a place where we _don't
have to care_ when we upgrade dependencies. We can choose to upgrade them at
our choosing, because there is no impact on those downstream. We're in charge
of our own destiny :)
> 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)
