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 On Wed, Jul 1, 2020, at 11:34 AM, Thomas Broyer wrote: > > > 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 ;-) > >> >> >> -- >> >> "--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 <[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/2d3443b6-7a6e-423b-a8ab-440998ff56c2o%40googlegroups.com > > <https://groups.google.com/d/msgid/google-web-toolkit-contributors/2d3443b6-7a6e-423b-a8ab-440998ff56c2o%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/9d37ba18-6af1-4b06-b5a2-e88b9ac910fd%40www.fastmail.com.
