(which you already pointed but what matters me the most :)) On Tue, Jun 30, 2020 at 11:39 AM Goktug Gokdogan <[email protected]> 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. > > 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%3DyUA3bOeXyxe2oyaDhn2tg0rKo-PFzX3-xfqUaN8AbtL_Rmw%40mail.gmail.com.
