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.
