GWT and standards compliance

P.G.Taboada — Sun, 30 Jan 2011 17:11:14 +0000

This is a sort of “standard” question when it comes down to the topic web frameworks, Java and finally the Google Web Toolkit (GWT).

My first though is, what exactly is meant with “standard”?

A short look at Wikipedia shows:

Open Standard: An open standard is a standard that is publicly available and has various rights to use associated with it, and may also have various properties of how it was designed (e.g. open process). There is no single definition and interpretations do vary with usage.

De facto standard: A de facto standard is a custom, convention, product, or system that has achieved a dominant position by public acceptance or market forces (such as early entrance to the market). De facto is a Latin phrase meaning “concerning the fact” or “in practice”.

Internet standard: In computer network engineering, an Internet Standard (STD) is a normative specification of a technology or methodology applicable to the Internet. Internet Standards are created and published by the Internet Engineering Task Force (IETF).

No, no, no! Not that kind of standard, right? Ah, ok, the Java EE standard!

Again, looking at Wikipedia you will find the following under “nomenclature, standards and specification“:

Java EE is defined by its specification. As with other Java Community Process specifications, providers must meet certain conformance requirements in order to declare their products as Java EE compliant.

Java EE includes several API specifications, such as JDBC, RMI, e-mail, JMS, web services, XML, etc., and defines how to coordinate them. Java EE also features some specifications unique to Java EE for components. These include Enterprise JavaBeans, Connectors, servlets, portlets (following the Java Portlet specification), JavaServer Pages and several web service technologies. This allows developers to create enterprise applications that are portable and scalable, and that integrate with legacy technologies.

Which leaves us just a few options: the Servlet/ JSP and the JavaServer Faces specifications. While the Servlet and JSP specifications focus on how to handle HTTP request/ responses, the JSF specification defines a GUI component model for web applications.

The problem here is: there is no room anymore for another “compliant” web framework – JSF made it into the Java EE specification – end of line. But, despite of a wide industry support, JSF is not the only web framework being used today by Java developers. And to make things a little more trickier, typical Web 2.0 web applications do not render the UI on the server side but in the browser.

Fancy “Web 2.0″ applications are not written in Java. Rich user interfaces are being rendered completely in the browser, avoiding the server roundtrip and minimizing latency. How? By simply using DHTML (technologies defined by the W3C).

So is this the end of Java? No! You will find people using Java backends for “Web 2.0″ applications. But even as a backend technology we won’t be abiding by the rules of standard compliance by using RMI or SOAP to communicate: it is common to send lightweight JSON over HTTP. All you need for that is a Servlet and a little bit of JSON <-> Java objects mapping. People developing RIAs and using JSON back and forward to the server are measuring latency in milliseconds.

So, if you will be building a Web 2.0 application, don’t look for a specification at the Java EE side. It is the wrong side, as Java is actually the backend, not the frontend. That brings us back to the first standards I cited above: open standards, de facto standards and internet standards.

This is how things were before JSF, and this is how things became after Web 2.o.

So, back to the question, is GWT standard compliant or not? Well, besides of those blue boxes on the picture above I would say yes!

The compiler is not standard, but I would not know what a standard compiler would be or mean to development anyway
The GWT-RPC mechanism is highly GWT proprietary, don’t use it if you don’t like it. But it is my belief that there aren’t too many developers out there that can code something better than GWT-RPC by hand…

SpringSource recently announced the Spring Aplication Platform, and this announcement is generating a lot of fuss. Google has recently launched the Google App Engine. From an Java enterprise developers point of view it is shamelessly easy to use, deploy, etc. Well, unfortunately it only takes Python apps for now, but it is stated that there will be more languages supported in the future. But it’s Google again putting its finger into the Java EE wound (first GWT with webapps, then Android shaking the Java ME world, and now App Engine showing how runtimes should look like).

Looking at Googles App Engine I thought how nice it would be to have the deployment, packaging and runtime of Java EE applications redesigned. Those deployment descriptors really suck. As it seems (heard it at the Jax from speakers “off the record”) Java Dynamic Modules and Java Superpackages aren’t going to make it into the next Java relase – Java 7.

From this point of view, the Spring Application Platform is bringing fresh air into the Java EE development. The Java EE dream of a runtime didn’t come through. Modularization got lost somewhere in the way. Packaging and deployment is a nightmare, and tools didn’t solve the problem. Since Java EE 5 is being adopted very slowly and Java EE 6 is really far away, this is surely the best time to drop in an alternative. Well done. Though beeing an alternative, there seems to be some level of commitment regarding Java EE deployment support.

IMHO the real shock came with the change in licensing terms. We are used to SpringSource licensing their products under the Apache 2 license. The license is clear and accepted by most companies. The Spring Application Platform is licensed under the GPL. GPL is, IMHO, the most misunderstood license we have in the OSS. I do not have nothing against the GPL, I only have a problem with the different interpretations. And if a license can be misunderstood, how can we rely on it? I won’t start another blog about how GPL works – please go read the GPL and the GPL FAQ, it’s worth it. A nice reply from Will Hartung about GPL on the TSS thread can be found here.

Does nobody actually, you know, READ these licenses?
Users who change GPL code have absolutely no, zero, zippo, big bagel, goose egg obligation to give back to “the community”.
I can take this code, make all the changes I want, sell it to my customers, and you can come knock on my door saying “I want the code, it’s GPL! Give me the code!” and I can nod and smile knowingly and tell you to pound sand. “Give me $100K and I’ll give you the software.

Thanks Will. It’s beautiful.

Rod argues that if someone takes the code, makes changes and starts selling it, this someone will, sooner or later, have to provide the source code to a major number of customers and hence the changes will be available for the community, especially for SpringSource. Rod, I hope I did quote you right, sorry if I didn’t.

Another great statement from Will comes a few postings later:

But you certainly aren’t going to take back contributions that don’t have at least shared copyright, because as soon as that happens you can’t relicense the whole under something other than GPL. So, there’s not a whole lot of value to the community there.

Later Rod makes a nice statement about what’s ok:

1. Using the platform to run closed source applications is OK. This immediately covers the vast majority of companies and developers who are end users. This would cover for example, software use by companies like Google, banks, media companies etc.
2. Modifying and extending the platform and “hiding” (closing) it is OK, unless you redistribute. So if you modify it in your own company, or you modify it and distribute your modifications in GPL open source, that’s OK. If you modify it and distribute a closed source product including those modifications, that is not OK. This would exclude Oracle, for example, from modifying the server and redistributing it as a closed source product. We believe this is a Good Thing.
3. It is fine to run closed source applications on the platform. Whether you can redistribute them as one closed product (bundling the platform) would depend if they constituted a derivative work.

I liked this one too:

Wow, 174 replies and counting, mostly about GPL, hmm, i knew I should have done law!!! ha ha
Lets stay technical please, even though it clearly doesn’t pay !!!

This is perfectly showing how GPL, although commonly used in OSS projects, is really badly misunderstood by people.

IMHO GPL licensing was a bad idea. SpringSource targets the enterprise, the enterprise dislikes GPL, that’s a fact. Linux seems to be the exception to the rule. It’ nice to see how SpringSource understands GPL – but this understanding is not binding. What if someone wakes up next week and says – “oh sorry, I think we have to rethink our GPL understanding….”

pgt » java ee

GWT and standards compliance

SpringSource announces an application plattform