search

GoogleCloudPlatform / appengine-plugins

A client Java library to manage App Engine Java applications for any project that performs App Engine Java application management. For example, the Maven, Gradle and Eclipse App Engine plugins, custom user tools, etc.
Apache License 2.0
40 stars 26 forks source link

Compile to java 8 #886

Closed elefeint closed 2 years ago

elefeint commented 2 years ago

I introduced an unintented target Java version upgrade when updating to compile-time Java 17 compatibility.

chanseokoh commented 2 years ago 
      <id>java9_and_up</id>
      <activation>
        <jdk>[9,]</jdk>
      </activation>
            ...
            <configuration>
              <!-- For Java 8, the plugin is overridden below, without errorprone -->
              <source>1.8</source>
              <target>1.8</target>

I think this setup can be confusing. First of all, it currently generates the following warning:

Warning:  [options] bootstrap class path not set in conjunction with -source 8

See this and this SO answers.

What the repo was doing with the Java 11 GitHub Action job in the past was to (1) use JDK 11 to compile the project source to see if it compiles well; and (2) use Java 11 to run tests to see if it runs well on Java 11. It was sort of an optional test for future Java 11 migration.

Specifying --source 1.8 tends to convey the intention that "I want the compiler to consider only Java 8 language rules when compiling source", which is almost always unnecessary when using higher Java versions because practically it never happens that language rules become incompatible in newer versions. So usually the intention is to specify both --source 1.8 and --target 1.8, hoping that you want to compile and generate Java 8-compatible binaries using, say, Java 11. However, as the warning says, it is not generating Java 8-compatible binaries; you need to specify the bootstrap class path of JDK 8. But at that point, you'd rather just use JDK 8 to compile. Right now, the setup is basically generating a Java 11 binary and testing it on Java 11.

elefeint commented 2 years ago

That makes sense. I wanted to make sure target is 1.8, so we don't accidentally end up generating Java 11 bytecode if/when kokoro configuration changes to run on Java 11.

So it sounds like as long as we aim for Java 8 minimum runtime compatibility, we should not upgrade kokoro's version of Java.

elefeint commented 2 years ago

(and then _java9_andup profile will remain purely for testing)