Details

    • Type: Bug
    • Status: Open
    • Priority: Trivial
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: 1.16.0
    • Component/s: None
    • Labels:
      None

      Description

      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.

        Issue Links

          Activity

          Hide
          julianhyde Julian Hyde added a comment -

          I now think that jackson-2.6.5 is too conservative. The latest is jackson-2.9.2, and I see that calcite runs fine with that; I also see from DRILL-5986 that drill is planning to move to jackson-2.7.9.1.

          Anyone object to jackson-2.9.2?

          Show
          julianhyde Julian Hyde added a comment - I now think that jackson-2.6.5 is too conservative. The latest is jackson-2.9.2, and I see that calcite runs fine with that; I also see from DRILL-5986 that drill is planning to move to jackson-2.7.9.1. Anyone object to jackson-2.9.2?
          Hide
          elserj Josh Elser added a comment -

          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

          Show
          elserj Josh Elser added a comment - 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
          Hide
          julianhyde Julian Hyde added a comment -

          Josh Elser, 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?!

          Show
          julianhyde Julian Hyde added a comment - Josh Elser , 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?!
          Hide
          elserj Josh Elser added a comment -

          Exciting stuff

          Sounds good, Julian!

          Show
          elserj Josh Elser added a comment - Exciting stuff Sounds good, Julian!
          Hide
          julianhyde Julian Hyde added a comment -

          Let's consider upgrading other components as well. Staying up to date reduces the chances we run into a security issue. Runtime components:

          • prefer guava-21 (but continue to support as early as guava-14.0.1)
          • prefer jdk-9 (but continue to support 8)
          • upgrade to jetty-9.3.8.v20160314 (from jetty-9.2.15.v20160210)
          • upgrade to jackson-2.6.5 (from jackson-2.6.3)
          • upgrade to janino-2.7.8 (from janino-2.7.6)

          Build and testing components:

          • prefer maven-3.5.x (but continue to support maven-3.3.x)
          • upgrade to java-diff-1.1.1 (from java-diff-1.1)
          • upgrade to h2-1.4.196 (from h2-1.4.185)
          • upgrade to hsqldb-2.4.0 (from hsqldb-2.3.1)
          • upgrade to javacc-maven-plugin-2.6 (from 2.4)
          • upgrade to forbiddenapis-2.4.1 (from 2.3)

          Also, start thinking about obsoleting joda. (People can use java.time instead since we've dropped JDK 7.)

          Look for and replace "javase/7" in URLs (.java and .md files).

          Show
          julianhyde Julian Hyde added a comment - Let's consider upgrading other components as well. Staying up to date reduces the chances we run into a security issue. Runtime components: prefer guava-21 (but continue to support as early as guava-14.0.1) prefer jdk-9 (but continue to support 8) upgrade to jetty-9.3.8.v20160314 (from jetty-9.2.15.v20160210) upgrade to jackson-2.6.5 (from jackson-2.6.3) upgrade to janino-2.7.8 (from janino-2.7.6) Build and testing components: prefer maven-3.5.x (but continue to support maven-3.3.x) upgrade to java-diff-1.1.1 (from java-diff-1.1) upgrade to h2-1.4.196 (from h2-1.4.185) upgrade to hsqldb-2.4.0 (from hsqldb-2.3.1) upgrade to javacc-maven-plugin-2.6 (from 2.4) upgrade to forbiddenapis-2.4.1 (from 2.3) Also, start thinking about obsoleting joda. (People can use java.time instead since we've dropped JDK 7.) Look for and replace "javase/7" in URLs (.java and .md files).
          Hide
          michaelmior Michael Mior added a comment -

          Sounds like a good plan to me. I don't really see any need to convert existing code unless a) that code is being changed for other reasons or b) we want to add new interfaces to support Java 8 features.

          Show
          michaelmior Michael Mior added a comment - Sounds like a good plan to me. I don't really see any need to convert existing code unless a) that code is being changed for other reasons or b) we want to add new interfaces to support Java 8 features.

            People

            • Assignee:
              julianhyde Julian Hyde
              Reporter:
              julianhyde Julian Hyde
            • Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

              • Created:
                Updated:

                Development