GWT 1.5 nearing relase

Just had a look at the SVN logs, and found this here:

So no more betas? Would be great to have a release in near future. People are expecting GWT 1.5 to be announced at the Google IO conference this week. Lets hope so!

GWT – kein JSF wie Andy Bosch es haben will…

Danke Andy für dein Kommentar. Freut mich, dass dich mein provokanter Titel in die Session gezogen hat – das war Absicht. :-) Und es freut mich um so mehr, dass Du dir die Zeit genommen hast, ein Kommentar zu schreiben. Also auf gehts, möchte kurz auf dein Kommentar eingehen:

Um jedoch ehrlich zu sein: Ich finde die Ansätze von GWT durchaus interessant, allerdings bleibe ich doch bei meiner gewohnten JSF-Entwicklung.

Klar… :-)

Ich befinde mich im Web und programmiere auch dort. Warum muss ich das zwanghaft zu verbergen versuchen?

Was meinst du mit verbergen? Und was meinst du mit du programmierst im Web? Sowohl GWT als auch JSF definieren ein Komponentenmodell und abstrahieren von der klassischen request/response Entwicklung. Sowohl bei JSF als auch GWT hat der Entwickler wenig Kontakt mit den ursrpünglichen Web-Technologien (wann habe ich das letzte mal ein Tree von Hand in HTML geschrieben?)-

So gesehen programmierst Du nicht im Web, oder ich habe dich falsch verstanden. Weder JSPs noch das Facelets-XML sind im eigentlichem Sinne Web-Technologien, diese werden nämlich vom W3C definiert…

Auch bietet mir GWT meiner Meinung nach nicht wirklich neuartige Antworten auf Dinge, die ich in JSF nicht genauso gut lösen könnte (nur eben anders).

Das stimmt nicht. Ich kenne beide. Du nicht. Aussage gegen Aussage. ;-)

Auch in JSF gibt es einen großen und sehr guten Komponentenmarkt, der mir die Details von Html und JavaScript versteckt.

Und genau hier greift eines meiner Kritikpunkte: JSF ist kein Produkt, nur ein Standard. Die Komponenten sind teilweise inkompatibel zueinander, haben unterschiedliche Programmiermodelle, etc.

Auch habe ich keine Antwort gefunden, warum ich von einem Standard wie JSF weggehen sollte, nur um eine proprietäre und nicht standardisierte API zu verwenden.

Ja, JSF ist ein Standard. Ich weiss noch, wass ich von dem EJB Standard gewonnen habe: 3 Mal die Anwendung portieren. Bei JSF sieht es auch nicht besser aus – oder kannst du unter Websphere einfach so beliebige Komponenten und JSF Implementierungen laufen lassen? Was bringt mir da der Standard? Trägheit?

Sicherlich ist Google mit seiner Marktstärke durchaus in der Lage, auch einen eigenen “Standard” in die Welt zu setzen, aber ich setze eher auf die im Java-Umfeld etablierten Standardisierungsprozesse wie den JCP (trotz aller Kritik an ihm).

Kann ich nachvollziehen und als Argument stehen lassen. Ich habe mich mehr den technischen und konzeptionellen Themen in meiner Session gewidmet.

Eine Entscheidung, welches Framework man zukünftig nutzen möchte, muss jedoch jeder selbst treffen.

Genau. Daher ist eine Gegenüberstellung der unterschiedlichen Webframeworks um Java Umfeld mit Sinn und Verstand wichtig. Ob man dann andere Frameworks einsetzt, oder nur daraus lernt – das wird die Zeit zeigen.

Für mich war die Session sicherlich dahingegend hilfreich, um mehr über GWT zu erfahren. Aber auch, um für mich die Frage beantworten zu können, ob GWT wirklich das bessere JSF ist oder der Titel einfach nur etwas provokant gewählt wurde.

Der Titel war erstens provokant und zweitens eine Fragestellung. So wie es aussieht habe ich es genau richtig gewählt – es hat dich in die Session gelockt und dich zum nachdenken gebracht. :-)

Aber, ein paar Fragen habe ich an Dich…

  • Was ist wenn weder JSF noch GWT ein Standard wären? Würdest du dann mit JSP/ Servlets entwickeln?
  • Was ist wenn Struts der Standard geworden wäre? Wa würdest du dann nehmen?
  • Was ist wenn ich GWT benutze, um bessere JSF Komponenten zu schreiben

Würde mich freuen, von dir zu hören!

Modular apps with JBoss???

Reading MarcF blog I stumbled across this statement:

enough to call it out for what it is “an emperor has no clothes” attempt to monetize his ISV base. I will respectfully point out that all this mumbo jumbo about modularity being a “quantum leap to the next generation” is just bullshit. We were peddling modular application servers with JBoss and its JMX base back in 2000, except we had real run-time substance behind it.

Funny. I understand the “run-time substance” point, won’t argue here. I agree that JBoss was/is a beautiful piece of work, modularity already implemented back in 2000.

Yes. But we, who did develop applications on top of this runtime, who tried to use standards (regarding Java EE specs), did not have ways of modularization. We had different component models, yes. People are using OSGi to split their own application into coarse grained modules. OSGi by hand is a pain in the ass. The platform helps here. So this is runtime, yes. And they are solving problems that maybe JBoss had back at 2000, and some people who are trying to use OSGi now.

I do not see Java EE solving that. I do not see Java Dynamic Modules beeing released, I do not see that becoming part of Java EE.

SpringSource announces an application plattform

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….”