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"
On Tuesday, June 30, 2020 at 3:45:36 AM UTC+2, Colin Alworth wrote:
>
> 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?
>
--
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-contributors+unsubscr...@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.
