GWT 2.5 Java 5 runtime(!) compatibility

[Lars Ködderitzsch]

Hi all,

while trying to upgrade to GWT 2.5 I noticed that all jars (incl. gwt-servlet.jar) are now build with target 1.6 (class file version 50.0).

This removes ability to host a GWT application on older application servers (e.g. Websphere 6.1).
While I understand that at least at build time during GWT-compile Java 6 is a requirement, I don't understand this restriction on the runtime environment.

Can somebody from the team please shed some light if this is intentional (if so why?) or just an oversight, which would be fixed in subsequent releases?

Thanks,
Lars

[Samyem Tuladhar]

This was part of the plan and set as a requirement for GWT 2.5: https://developers.google.com/web-toolkit/gettingstarted

[Lars Ködderitzsch]

Yes, for build-time this makes absolute sense - however applying the same constraint on the server runtime (where gwt-servlet is needed as a dependency to host GWT-RPC services and such) appears unnecessary and artificial.

Effectively this is shutting out alot(!) of enterprise adopters from GWT 2.5 (and possibly later) - since they are usually not as quick to upgrade their servers.
For instance we are still stuck with Websphere 6.1 (running on a IBM Java 5 VM), with no current upgrade path.

[Jens]

Since November 2009 Java5 isn't supported anymore by Sun/Oracle and we are reaching 2013. So it should be fine that GWT now requires Java 1.6 and their jar files are also build using target 1.6.

Also Websphere 6.1 reaches its EOL in september 2013 (increased by one year. Original date was september 2012). You should start thinking about updating your server in the very near future or accept that it's legacy and you can't use newer GWT versions anymore.

-- J.

[Lars Ködderitzsch]

Sigh, if it were my decision... but it isn't... there are lots of other powers involved (management, operations and so forth)...

Still, other then saying that it is so because it has been said so - I still don't see an argument why the gwt-servlet.jar would technically require Java 1.6.

[Jens]

Still, other then saying that it is so because it has been said so - I still don't see an argument why the gwt-servlet.jar would technically require Java 1.6. 

True, but some day you have to make the cut. Technically they probably have used a Java 1.6 API somewhere thats not available in Java 1.5. So if you compile using target 1.5 you still can't use the library because a Java 1.5 JVM does not provide the needed API. In that case you would get a NoSuchMethodError at runtime.

A good example for this is String.isEmpty() which has been introduced in Java 1.6.

-- J.

[Samyem Tuladhar]

You can always stay with GWT 2.4 as well. 

[Philippe Lhoste]

Another example can be the usage of @Override on interface method implementations, etc.
If they don't use Java 6-specific features, I suppose you can build our own jar with Java
5, that's the advantage of open source...

--
Philippe Lhoste
-- (near) Paris -- France
-- http://Phi.Lho.free.fr
-- -- -- -- -- -- -- -- -- -- -- -- -- --

[Lars Ködderitzsch]

Yeah, well.

To put some kind of closure to it, it appears Jens is right about the Java 6 API use.

I tried to be super-smart by running gwt-servlet.jar through retrotranslator - which can also verify the result against a given classpath.
Turns out there are several occasions where String.getBytes(Charset), String.isEmpty, java.util.Deque is being used in GWT 2.5. server-side codebase.

Bummer, at least this finally confirms that anyone doomed to still use Java 5 based servers will be unable to user anything newer than GWT 2.4 from this point on.

That's really disappointing...

[Chris Lercher]

On Tuesday, October 30, 2012 5:42:11 PM UTC+1, Lars Ködderitzsch wrote:

Bummer, at least this finally confirms that anyone doomed to still use Java 5 based servers will be unable to user anything newer than GWT 2.4 from this point on.

What I find interesting is, that companies who are afraid to update an extremely old closed source server, would be willing to update to the cutting edge version of an open source web framework, which has been released just a few days ago?

[Lars Ködderitzsch]

Well, that's just corporate politics.
Using new framework versions is can be decided by development department, whereas upgrading server infrastructure involves upper managment, operations department and the external hosting provider - so it's literally impossible.

So we measly devs are trying to scrape by with what infrastructure we are provided, while still trying to keep up with current technology/frameworks.