Sounds like a plan (I'd personally let "ant doc" fail, or possibly fail the build with an explicit error message, rather than skipping)
On Wednesday, July 1, 2020 at 6:48:34 PM UTC+2, Colin Alworth wrote: > > 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/74bd33cc-a1cb-4bc7-b6b7-57e390ce2620o%40googlegroups.com.
