I think first we should put a good Java version policy into place. 
Personally I would split this policy into two policies. One for client code 
(Compiler) and one for shared/server code.

For client code GWT has two main dependencies: Eclipse JDT and Jetty. So I 
would define the minimum required Java version of GWT Compiler / DevMode as 
the maximum of the requirements of latest Jetty and latest Eclipse JDT. 
That way GWT can always aim to support latest Java language features and 
can regularly upgrade Jetty for CodeServer / DevMode once the used Jetty 
version is EOL or something else requires upgrading Jetty. I think this 
should be fine for everyone because JDK on developer machines and within CI 
docker containers can be relatively new in case it needs to be relatively 
new. 
My gut feeling says with this policy we would usually end up with the 
previous LTS version of Java as a minimum requirement. Currently 11. 

For server side code we never know how it will be deployed. Some people aim 
to use newest Java on server, some don't. Jakarta EE 9 is the first release 
using the new jakarta namespace. As it requires Java 8 we could technically 
stay on 8 while supporting both namespaces for a long time. Jakarta EE 10 
will require Java 11. 


IMHO it is important to support latest java language features in 
client/shared code. If GWT client/shared code lags behind GWT feels even 
more dated just because of missing language feature support. Thus our Java 
version policy should help us to never be blocked by server side Java 
requirements. 


-- J.

-- 
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/23ea079e-8be3-4245-a6c4-3f4c4c5553e0n%40googlegroups.com.

Reply via email to