Time to require JDK 8?

[t.br...@gmail.com]

Hi all,

3½ years ago, we announced 2.8.0-beta1 and that it now required JDK 7, and that started quite a long discussion: https://groups.google.com/d/topic/google-web-toolkit-contributors/TzsINiDf5xg/discussion

A few days ago, there's been renewed interest into upgrading the Jetty version GWT is using (for reasons I don't support, but that's orthogonal to the point): https://github.com/gwtproject/gwt/issues/9606

Upgrading Jetty however means requiring JDK 8; and we have people volunteering to do this work.

We're in April 2019, Oracle just gave the keys of OpenJDK 11 updates to RedHat, them already being the stewards for OpenJDK 8 and 7.

JDK 6 is dead and buried (Oracle's extended support ended last December, and it looks like even Azul Systems –the company that, to my knowledge, sells the longest support– no longer provides paid support for OpenJDK 6 either)

OpenJDK 7 will receive free updates for only one more year (June 2020), though some vendors will provide paid support 'til 2022 (e.g. Azul, even providing "passive" support –whatever it means– 'til 2024); for Oracle JDK 7, Oracle's Premier Support will end in July this year (tick tock tick tock), and extended support will last 'til 2022.

OpenJDK 8 will receive free updates until June 2023 (4 years from now, almost the same time that has passed since 2.8.0-beta1, just sayin')

For people sharing code with Android, correct me if I'm wrong, but latest tooling improvements (D8) mean that you can use libraries targeting JDK 8 even on older Android devices (basically, D8 integrates retrolambda into the Android toolchain), so even Android is no longer an excuse.

Maybe it's time to switch to JDK 8 as the new baseline for GWT: by the time we release a 2.9 (who knows when), OpenJDK 7 will only have months to go (tick tock, 14 months from now).

Fwiw, my reasoning for mostly/only caring about free updates to the JDK are:

• AFAICT, GWT receives no money. Some companies (possibly?) dedicate time for maintaining GWT, but it mostly runs on the free time and free will of a few people (I wouldn't even count myself in any longer)
• Companies that run those older JDK versions likely pay for support. If they have money for that, they can also build their own version of GWT that still supports those older JDK versions (either adapting the most recent GWT version to bring compatibility with older JDKs, or backport fixes to older GWT versions).
• Companies that run older JDKs without paying for support, besides being crazy (particularly if their servers are exposed on the Internet), can IMO live with older GWT versions too (for JDK 7, in a year from now, that'll still include GWT up to 2.8.2, the current latest release)

[raymond...@gmail.com]

All makes perfect sense to me. I don't really see any pluses of failing to support some people who are helping push gwt forward just so it continues to work with an outdated jdk.

[Jens]

I am totally fine with requiring JDK 8 when using GWT. 

Personally I would even like to see requiring at minimum the Java version we provide emulation for. That would free us from super sourcing emulation tests for newer Java APIs / syntax which is quite annoying. Also your ANT build could require at least Java 9 so we can use javac -release 6,7,8,.. parameter to more easily cross compile during build. If we would have that, we could refactor the ANT build to produce Java 7 or Java 8 jars used on server side (gwt-servlet, gwt-servlet-deps, requestfactory-server) while requiring a way newer Java version during development (gwt-user.jar, gwt-dev.jar, gwt-codeserver.jar).

-- J.

[krypto...@gmail.com]

Totally agree with everything said above

[alexande...@gmail.com]

I am afraid that HEAD-SNAPSHOT already requires Java 8 for client code compilation. At least I found this one for JDT - https://bugs.eclipse.org/bugs/show_bug.cgi?id=488273 (in short - JDT build switched to Java 8 baseline).

IIUIC the client code may not be compiled with JDK7 due to this change. May be I am wrong and someone may to confirm that HEAD-SNAPSHOT is still compatible with JDK7 under some configurations.

But very simple project generated in GWT Eclipse plugin failed to compile with UnsupportedClassVersionError for one of JDT classes (as expected, I think).

[miha...@gmail.com]

Fully support both java 8 and Jetty update.

[Goktug Gokdogan]

Could we proceed with dropping java 7 support? This has been causing rework for us to make tests compile with Java7.

[Marcin Szałomski]

Definitely yes, as I believe it's the only way to move forward. 

Spending effort on supporting of outdated JDK is not the way to go.

 

If about legacy projects, I think it's clear: legacy JDK = legacy GWT.

Dropping of support for legacy JDK with future GWT releases is also a motivation for community to migrate their projects if possible or creating a new sub-project following current standards.

Also, it's worth mention that JDK8 is currently considered as the minimum in Java world when think about the JDK11 LTS. Also, JDK14 is coming.

This everything should rather make the case of legacy JDK super clear.

It's also worth mentioning that upcoming GWT 2.9 has, at least partial, support for JDK10 features and compiles well with JDK11. 

To sum up, personally I don't see any longer a room for JDK7.

[Ahmad Bawaneh]

I also agree to the upgrade and reduce the burden from supporting older java versions, Java is moving faster now and brings new features that are also good to have in GWT world, so focus in supporting those feature rather than supporting very old java versions.

On Thursday, April 25, 2019 at 7:31:36 PM UTC+3, t.b...@gmail.com wrote:

[Jérôme Barotin]

Hi,

I'm in charge of migrating GWT 2.8.2 to 2.9.0 in my company. We need an 9.4+ embedded jetty (we are using intellij and GWT plugin). From what I understand, the upgrade of jetty is blocked cause of the support of JDK 7.

But, I read on your mailing list, that nobody is against the drop of "support of java 7".

Could you help me understand what's still blocking?

Best,

Jérôme