Re: [gwt-contrib] Re: Required JDK version to build GWT?
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
Re: [gwt-contrib] Re: Required JDK version to build GWT?
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
Re: [gwt-contrib] Re: Required JDK version to build GWT?
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 >> 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 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.
Re: [gwt-contrib] Re: Required JDK version to build GWT?
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? -- "--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 > 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 > > 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
Re: [gwt-contrib] Re: Required JDK version to build GWT?
(which you already pointed but what matters me the most :)) On Tue, Jun 30, 2020 at 11:39 AM Goktug Gokdogan 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 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
Re: [gwt-contrib] Re: Required JDK version to build GWT?
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 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,
[gwt-contrib] Re: Required JDK version to build GWT?
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
