Required JDK version to build GWT?

[Colin Alworth]

As of somewhere in the time leading up to the GWT 2.9.0 release, it is no longer possible to build GWT with Java7, and similarly the decision was made to no longer officially support running on Java7 (jsinterop-annotations use of "TYPE_USE", newer jetty version too I believe).

There is still some defunct wiring in the build to handle Java 7 vs Java 8 though, mostly with regards to running tests - since we first javac our java classes, and then run gwtc on them, we need to make sure that the java version being use can correctly compile those tests.

The issue https://github.com/gwtproject/gwt/issues/9683 is tracking some of the existing work on this: the main remaining piece is to decide how to handle javadoc. GWT has its own custom doclet to handle a few custom tags, "example", "gwt.include", and "tip". None of this compiles after Java 8, since Java 9 came with a new, incompatible API to build custom tags, so either we drop Java 8 support for building the toolkit, require _only_ Java 8 to build, support two parallel copies of the custom doc wiring, or drop the doc wiring entirely and remove these custom tags throughout the codebase.

Since the release of GWT 2.9 and my own work on the above ticket, I've been picking back up some Java 9/10/11 JRE emulation work that I had previously paused, and I'm running into the issue described at the top - if you write a test that calls Map.of() and run it on Java8 as a GWTTestCase, you'll get a compile error.

Two basic ways I can easily see to fix this: we can make two copies of each test, one as an empty "real" java type and one as supersource, or we can guard those tests behind java version args in the build glue like we did for Java7 vs Java8. The first option is clunky, and while I see this was done for `com.google.gwt.dev.jjs.test.Java8Test`, it clearly wasn't done for JRE emulation tests, and I assume there was a reason for that. The second option requires changing our CI to build+test on some new JRE...

...and given the constraints of the Java LTS system, and the java 8/9 divide for custom doclet stuff, it seems like the clearest win is to move all the way to Java11, though continue to target java 8 releases, and test on all JREs up until current.

So that's my pitch. For completeness, some other options that seem workable, keeping in mind that at present there are about 3 important JRE versions to support well: Java 8, Java 11, and the current stable release.

 * Require Java8 for javadoc, supersource tests

 * Allow any JRE 8+, use ant filters for tests for each version, maintain two javadoc builds

 * Allow any JRE 8+, use ant filters, only actually produce javadoc on java9+ builds

Other technical ways to deal with this, or have a missed an easier solution to one of these problems?

[Goktug Gokdogan]

wrt running tests:

See https://gwt-review.googlesource.com/c/gwt/+/13861 for the pattern used in JRE earlier; and the CI was updated to run in both 7 and 8 at the same time.

PS: Compiler tests ("jjs.test.Java8Test") was different because we really needed to run the compiler tests with new syntax inside Google which didn't have the Java8 VM at the time. It wasn't a deal breaker to be not able run Java8 JRE tests at the time so they are not super sourced.

I recommend the same approach.

--
You received this message because you are subscribed to the Google Groups "GWT Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/0aa0701b-4287-4e4c-bbef-23952898c64an%40googlegroups.com.

[Matt Davis]

I agree with this statement: "it seems like the clearest win is to move all the way to Java11, though continue to target java 8 releases, and test on all JREs up until current."

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAN%3DyUA1L4gAaaEkqgWnqL%3DiKDX_aUjX1L0WThdG4yuxUyHdQMQ%40mail.gmail.com.

[Colin Alworth]

Right - the excludes via ant are certainly an option ("use ant filters"), my main hope is to avoid adding another stanza of xml for the emulation for each release. Cutting out Java7 and adding a "java 11 or higher" to lump all the java 9, 10, 11 tests in would at least be a net equal in XML from what we have today (since compiling under Java 7 isn't an option), but still a bit messier than I'd like - especially if we agree that "run all internal tests in Java11" is reasonable (plus another few build steps to validate the build under other versions of Java).

If that isn't deemed reasonably, we'll need a Java9 check (for the new of() methods), Java 10 check (new optional methods, collections copyOf), Java 11 check (string methods) to get caught up with the JDT we're using today, and 12, 13, 14 are out now, with 15 soon. Again, not impossible, just perhaps messy - and unwinding the "java8" flag (which really seems to mean "newer than java7") is less fun than I'd like.

-- 

  Colin Alworth

  co...@colinalworth.com

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAN%3DyUA1L4gAaaEkqgWnqL%3DiKDX_aUjX1L0WThdG4yuxUyHdQMQ%40mail.gmail.com.

[Goktug Gokdogan]

I was clarifying what I was expecting the setup to look like wrt different versions supported.

I agree that the granularity of the supported version doesn't need to be lower than what is useful to us (which I think is driven by both LTS and also by GWT releases).

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/f2219bb2-6ce3-409e-bcff-63c560be67b0%40www.fastmail.com.

[Thomas Broyer]

So, IIUC, there are 2 distinct issues, but both related to JDK versions.

First, the doclet/taglet where JDK8 has com.sun.javadoc and JDK9+ have jdk.javadoc.doclet. This is an internal tool, so it would be wasted effort to maintain 2 versions. Either we keep the current code and require JDK8, or we migrate to the new API and require JDK.lts or JDK.latest. Those requirements only apply to building the javadoc though, i.e. to actually cut the releases.

Next, the tests. If we want to be able to test JDK9+ syntax and/or APIs, then we either have to require such a JDK (for those tests at least), or supersource the code so it can run with JDK8.

So what are the pros and cons?

• Require a specific JDK:
• do we require JDK.lts? or JDK.latest? (currently, JDK.lts would be enough, but as soon as we add newer language syntax and/or APIs, we'd have to use JDK.latest to test those)
• do we require it only for those specific tests (aka "use ant filters") or for the whole build? (and using "--release 8" for non-test code to target JDK 8; BTW, can we use "--release 8" at all? not all JDK8 APIs are available that way, specifically "internal" APIs)
  requiring recent JDKs for the whole build means we no longer test with JDK8, and we have to migrate the doclets to the new API. Those are rather big cons if you ask me.
• Assuming ant filters then:
• pro: tests are easy to write/maintain, you only have to follow a naming convention for the test class
• con: testing everything requires the JDK.lts/JDK.latest; running the tests with JDK8 only covers JDK8-compatible code. If we keep the doclets on JDK8, this means we have to run the build twice when cutting a release: once with JDK.lts/JDK.latest to make sure the tests pass, and then once with JDK8 to actually build the artifacts.
• con: requires setting up the new JDKs, and new jobs, on the CI server. If we keep using the current build.gwtproject.org, this puts the burden on Google; that'd likely precipitate the replacement of the server.
• con: requires 2 builds to make sure things still build/run with JDK8
• Supersourcing
• pro: tests can run with JDK8, so the whole build is JDK8-compatible and still covers all tests
• con: requires somehow maintaining the tests twice, keeping the javac'd and supersourced versions in sync (AFAIK, the javac'd version has to have the test methods so they're detected by JUnit, even if their body is empty; so it would be rather easy to add a test to the supersourced version and never actually run it because the method is missing from the javac'd version)

The situation requiring the minimum effort in the short term would be keeping the doclets as they are and using supersourcing for the tests.

In the long run, as JDK9+ tests grow, supersourcing might become unsustainable, but the impact on the CI server et al. is non-negligible. We could still possibly, at least temporarily, build only with JDK8, and only run the JDK9+ tests once in a while (at release time?), manually on a developer's machine as a smoke test.

So, my vote would be: "require JDK8 for javadoc, supersource tests", with a fallback to an option you didn't list: "Allow any JDK 8+, use ant filters, only actually produce javadoc on JDK8 builds", and if/when someone wants to put the effort then migrate the doclets and move on to your third option: "allow any JDK8+, use ant filters, only actually produce javadoc on JDK9+ builds"

[Goktug Gokdogan]

Super sourcing with tests is errorprone; it is easy to get one method added in one version but note the other and basically you end up testing nothing.

--

You received this message because you are subscribed to the Google Groups "GWT Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-co...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/fd84b4c8-bfcb-4427-8698-4edc6da42f9do%40googlegroups.com.

[Goktug Gokdogan]

(which you already pointed but what matters me the most :))

[Colin Alworth]

Thanks Goktug for clarifying - I am personally in favor of a more coarse approach, more future proofed approach that will end up with making changes now rather than later. And to your followup, agreed, all else equal, let's avoid supersource.

Thomas - While I made a Java8-first option was the first bullet at the end of my email, I deliberately skipped the option of "we can either produce build artifacts, or test the output, but not both in the same build", but it may be worth considering, even if it means each release has to be built twice.

My thinking on the javadoc wiring is that it is better done once, and better done sooner than later. There are other advantages to modernizing the javadoc: dropping the deprecated API, search, etc. If the concern is only saving the effort of this work, then I'm happy to own this task, if we think it would be preferred to only produce output artifacts using Java8 then it seems it wouldn't make sense to try it at all, at least until we get closer to something resembling a Java 8 EOL, or find ourselves needing a baseline higher than Java 8 for other reasons. That is, optimizing for minimum-effort-today has its advantages, but my current mindset was to seek to future proof a bit, as long as I'm excising Java7-specific things and ensuring other code builds on Java9+.

With the assumption that Javadoc is handled, is there any objection to requiring Java 11+ to run tests, Java 9+ to produce a complete build? It sounds like this is the direction everyone is moving, only supporting tests in a limited range of versions, only supporting releases in a limited range of versions (or, just one), or is the objection specifically to dropping Java 8 as the build version of choice?

--

"--release 8" - this is actually required (and implicit?) when running j2cl_library at the moment. All of the Java 9, 10, 11 emulation I have working now uses only java 8 language features, but still seem to compile correctly even when building Java9+ features, as long as it is internally consistent. This makes sense, since we were doing this before too, targeting and running on java7, but with java8 classes available to gwt projects. Tests are a different story, as discussed.

On Tuesday, June 30, 2020 at 4:40:29 PM UTC-5, Goktug Gokdogan wrote:

(which you already pointed but what matters me the most :))

On Tue, Jun 30, 2020 at 11:39 AM Goktug Gokdogan <gok...@google.com> wrote:

Super sourcing with tests is errorprone; it is easy to get one method added in one version but note the other and basically you end up testing nothing.

To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscribe@googlegroups.com.

[Thomas Broyer]

On Wednesday, July 1, 2020 at 3:32:34 AM UTC+2, Colin Alworth wrote:

Thanks Goktug for clarifying - I am personally in favor of a more coarse approach, more future proofed approach that will end up with making changes now rather than later. And to your followup, agreed, all else equal, let's avoid supersource.

Thomas - While I made a Java8-first option was the first bullet at the end of my email, I deliberately skipped the option of "we can either produce build artifacts, or test the output, but not both in the same build", but it may be worth considering, even if it means each release has to be built twice.

My thinking on the javadoc wiring is that it is better done once, and better done sooner than later. There are other advantages to modernizing the javadoc: dropping the deprecated API, search, etc. If the concern is only saving the effort of this work, then I'm happy to own this task, if we think it would be preferred to only produce output artifacts using Java8 then it seems it wouldn't make sense to try it at all, at least until we get closer to something resembling a Java 8 EOL, or find ourselves needing a baseline higher than Java 8 for other reasons. That is, optimizing for minimum-effort-today has its advantages, but my current mindset was to seek to future proof a bit, as long as I'm excising Java7-specific things and ensuring other code builds on Java9+.

With the assumption that Javadoc is handled, is there any objection to requiring Java 11+ to run tests, Java 9+ to produce a complete build? It sounds like this is the direction everyone is moving, only supporting tests in a limited range of versions, only supporting releases in a limited range of versions (or, just one), or is the objection specifically to dropping Java 8 as the build version of choice?

I'm concerned with dropping JDK 8 testing. If we want to make sure it works with JDK 8, we have to test with JDK 8. If we want to make sure it works with JDK 11, we have to test with JDK 11. (IMO, supporting JDK14, then 15, etc. would only be a bonus)

Given how Ant works, this probably does not mean *building* (the non-test code) with either, i.e. we could probably build and test with JDK8 (JAVA_HOME=… ant build) and then run tests with JDK 11 (JAVA_HOME=… ant test, in the same directory, reusing the classes already compiled by the previous build with the other JDK), or the reverse.

Of course, it also depends what we want to test!

Unfortunately, JDK 8 and JDK 9+ are different enough (at runtime) that we'd really want to test both (AFAIK, we(you) only did smoke tests with JDK 11 for GWT 2.9.0, and smoke tests might actually be enough)

So, what do we want to achieve?

• Make it possible to "ant dist-dev" and "ant test" with JDK 11 (or even 14)? to run JDK9+ specific tests (and make it easier for anyone to contribute)
• Make it possible to "ant clean elemental dist" with JDK 11 (or even 14)? (this could/would mean dropping support for JDK 8 for "ant doc", but keep "ant dist-dev" and "ant test" working)

In any case, I believe we should keep "ant dist-dev" and "ant test" working with both JDK 8 and JDK 11 (or even 14), and ideally actually run with both JDKs nightly (possibly one after the other in the same directory, or even have the Ant build call the other JDK during a single build, whatever; it's probably easier currently to just run the build twice).

This is easier said than done though ;-)

[Colin Alworth]

Okay, sounds good, I think these are compatible goals. Restating here to make sure I understood clearly, then I'll make a few notes on the existing tickets, new tickets to track this:

• ant test (more or less) should correctly filter out java9+ jre emulation tests when run from Java 8. All tests will be run in Java 11 (or Java.latest, when we add tests that require a newer JDK)
  
• ant dist-dev should run correctly in Java 8, Java 11, and Java.latest
  
• Based on the current status of javadoc, ant dist will for now run on Java8 only, then later only on any Java9+. (elemental hasnt actually been removed yet, but I have a patch for it...)
  

Steps to achieve this, roughly in order:

• Remove Java 7/8 filters in ant wiring, make everything run cleanly/simply on Java 8 alone
  
• Finish making the distribution part of the code run cleanly on Java >=9 (https://gwt-review.googlesource.com/c/gwt/+/22640 is the last step until this is finished)
  
• Update build to skip any doc tasks when on Java >8
  
• Add Java <11 filters to ant wiring, allowing specific tests to be excluded when running on something older than Java 11 in anticipation of this emulation to be finished, landed.
  
• Update Javadoc to support >8 only, update build to skip any doc tasks when on Java 8
  

To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-co...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/2d3443b6-7a6e-423b-a8ab-440998ff56c2o%40googlegroups.com.

[Thomas Broyer]

Sounds like a plan (I'd personally let "ant doc" fail, or possibly fail the build with an explicit error message, rather than skipping)

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/2d3443b6-7a6e-423b-a8ab-440998ff56c2o%40googlegroups.com.