Re: [gwt-contrib] Re: Required JDK version to build GWT?

[Colin Alworth]

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?

['Goktug Gokdogan' via GWT Contributors]

(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?

['Goktug Gokdogan' via GWT Contributors]

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, 

Re: GWT SingleUploader gets stuck

[ahmdt]

Thanks very much.

I was using it because it allows me to modify the uploaded file name from 
the client's side. Is it possible to do that using FileUpload?


On Tuesday, June 30, 2020 at 5:27:47 PM UTC+3, Colin Alworth wrote:
>
> It looks like this isn't part of GWT itself, but an external library. 
> Here's a stackoverflow post i found from a few years ago that seems to 
> address your issue: 
> https://stackoverflow.com/questions/31424639/gwt-error-when-uploading-file-with-singleuploader
>
> It looks like the project might live on in github, but there has been 
> minimal activity there: https://github.com/manolo/gwtupload/. Check the 
> network of forks for more updated versions to see if one of them might be 
> the "new home" for this project? 
> https://github.com/manolo/gwtupload/network
>
> On Tuesday, June 30, 2020 at 8:52:36 AM UTC-5, ahmdt wrote:
>>
>> When I upload a file using SingleUploader or MultiUploader, the file gets 
>> uploaded but the uploader's progress bar gets stuck at 0% for a very, very 
>> long time.
>>
>> When I try to upload a second file in the same session, I get this 
>> message:
>>  
>>
>>> There is already an active upload, try later. 
>>>
>>>
>>
>> This is my code:
>>
>> final SingleUploader uploader = new SingleUploader();
>> uploader.setAutoSubmit(false);
>> uploader.setMultipleSelection(false);
>> uploader.setValidExtensions(".log");
>> uploader.setServletPath("/reprocess/"+userTestXml);
>> uploader.avoidRepeatFiles(false);
>>
>>
>>  Any advice here?
>>
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/9f57d3b6-956b-40de-9823-452a187094efo%40googlegroups.com.

Re: GWT SingleUploader gets stuck

[Colin Alworth]

It looks like this isn't part of GWT itself, but an external library. 
Here's a stackoverflow post i found from a few years ago that seems to 
address your issue: 
https://stackoverflow.com/questions/31424639/gwt-error-when-uploading-file-with-singleuploader

It looks like the project might live on in github, but there has been 
minimal activity there: https://github.com/manolo/gwtupload/. Check the 
network of forks for more updated versions to see if one of them might be 
the "new home" for this project? https://github.com/manolo/gwtupload/network

On Tuesday, June 30, 2020 at 8:52:36 AM UTC-5, ahmdt wrote:
>
> When I upload a file using SingleUploader or MultiUploader, the file gets 
> uploaded but the uploader's progress bar gets stuck at 0% for a very, very 
> long time.
>
> When I try to upload a second file in the same session, I get this message:
>  
>
>> There is already an active upload, try later. 
>>
>>
>
> This is my code:
>
> final SingleUploader uploader = new SingleUploader();
> uploader.setAutoSubmit(false);
> uploader.setMultipleSelection(false);
> uploader.setValidExtensions(".log");
> uploader.setServletPath("/reprocess/"+userTestXml);
> uploader.avoidRepeatFiles(false);
>
>
>  Any advice here?
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/f942772a-5013-4910-9b5d-6ea0c10eeadao%40googlegroups.com.

GWT SingleUploader gets stuck

[ahmdt]

When I upload a file using SingleUploader or MultiUploader, the file gets 
uploaded but the uploader's progress bar gets stuck at 0% for a very, very 
long time.

When I try to upload a second file in the same session, I get this message:
 

> There is already an active upload, try later. 
>
>

This is my code:

final SingleUploader uploader = new SingleUploader();
uploader.setAutoSubmit(false);
uploader.setMultipleSelection(false);
uploader.setValidExtensions(".log");
uploader.setServletPath("/reprocess/"+userTestXml);
uploader.avoidRepeatFiles(false);


 Any advice here?

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/946acfd8-47d6-4a37-a5ce-8d632818e7e7o%40googlegroups.com.

Re: Security Vulnerabilities with GWT

[Priya Kolekar]

Thank you very much for quick responses.
Here are Vulnerabilities listed -


Gwt-dev.jar -
1.1 Vulnerable version of jetty library(current version-- 9.2.14, available 
version -9.2.27+ ) 
[Associated CVEs -  
CVE-2017-7656,CVE-2017-7657,CVE-2017-7658,CVE-2017-9735,CVE-2018-12536]
1.2 Vulnerable version of commons-collections(current version - 3.2.1)  [ 
CVE-2015-6420,CVE-2017-15708,CVE-2014-3577]
1.3 Vulnerable version of org.apache.httpcomponents:httpclient(current 
version - 4.3.1)  [ CVE-2015-6420,CVE-2017-15708,CVE-2014-3577]
1.4 Vulnerable version of Google Protobuf(current version - 2.5.0, 
available version - 3.4.0) [CVE-2015-5237]
1.5  Vulnerable version of htmlunit ( current version - 2.19 , available 
version- 2.37) [CVE-2020-5529]

Gwt-servlet.jar -
1.1 Vulnerable version of Google Protobuf(current version - 2.5.0, 
available version - 3.4.0) [CVE-2015-5237]


On Monday, 29 June 2020 16:27:41 UTC+5:30, Priya Kolekar wrote:
>
>
> Hi All,
>
> Security Vulnerability have been detected in gwt-dev.jar & 
> gwt-servlet.jar(in release 2.8.2) & are reported by Dependency checker 
> tool .
>
> Below are the details -
>
> Gwt-dev.jar -
> 1.1 Vulnerable version of jetty library(current version-- 9.2.14, 
> available version -9.2.27+ )
> 1.2 Vulnerable version of commons-collections(current version - 3.2.1)
> 1.3 Vulnerable version of org.apache.httpcomponents:httpclient(current 
> version - 4.3.1)
> 1.4 Vulnerable version of Google Protobuf(current version - 2.5.0, 
> available version - 3.4.0)
> 1.5  Vulnerable version of htmlunit ( current version - 2.19 , available 
> version- 2.37)
>
> Gwt-servlet.jar -
> 1.1 Vulnerable version of Google Protobuf(current version - 2.5.0, 
> available version - 3.4.0)
>
> Given above vulnerabilities -
> 1. Are those security issues addressed in latest 2.9.0 release?
> 2. If no, is there a plan to include them in any future release say 3.x?
> 3. As we know that gwt-dev.jar is used for development purpose & can be 
> flagged as false positive, still are there any attack surfaces exists?
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/53fc57d4-6d37-44b5-b267-044aa30e878co%40googlegroups.com.

[gwt-contrib] Re: Required JDK version to build GWT?

[Thomas Broyer]

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