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.
On Tue, Jun 30, 2020 at 1:36 AM Thomas Broyer <[email protected]> wrote: > 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 [email protected]. > 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 > <https://groups.google.com/d/msgid/google-web-toolkit-contributors/fd84b4c8-bfcb-4427-8698-4edc6da42f9do%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAN%3DyUA0muqfTpnkHFWj23q5QiKP-Zo%2BbfriyRbE3KfauqXuNPg%40mail.gmail.com.
