Archiv der Kategorie: Java & Co.

Java in den Wolken

May we live in interesting times…

again…

and again…

It's cloudy. I can't see the sun...
It's cloudy and I can't see the sun...

Wenn das nicht mal spannende Zeiten. Erst vor ein paar Tagen (7. April) kommt Google völlig aus dem Nichts heraus und überrascht mit einem 3-fach Release: GWT 1.6 (ok, das war nicht überrraschend), Java auf der GAE (Google Application Engine) und dazu noch das passende Plugin, damit auch alles schön aus Eclipse heraus benutzt werden kann.

„Hui“, dachte ich…

Wäre da nicht „IBM will Sun kaufen“ (Heise Meldung vom 18. März), dann doch nicht (Heise Meldung vom 6. April), dann schnappt plötzlich Oracle zu (Heise Meldung vom 20. April) – dann hätten wir sicherlich viel länger über Java und GAE gesprochen. Aber die vielen offenen Fragen (Java, JCP, Openoffice, MySQL, Sparc), prominente  Meinungen (hier und hier) und Reaktionen rund um Suns Zukunft (oder Javas Zukunft) haben alles überdeckt. Irgendwo habe ich noch ein Kommentar aufgeschnappt: „Google hat im Cloud-Geschäft Amazon ein Bein abgebissen“. Ob es jetzt ein Bein oder ein Finger war kann ich nicht sagen, aber ich finde die Metapher gut und da will ich drauf aufbauen…

Oracle hat doch jetzt den eigenen Java EE Appserver, Glassfish und zeigte bereits Interesse (Heise Meldung vom 24. März) an Red Hat (und damit auch an JBoss) – alle zusammen durchaus nennenswerte AppServer. Oh, und ja, auf der anderen Seite, im Schatten der Nachrichten haben wir noch Amazon (ohne Bein) und IBM (mit einem AppServer den sie nur noch „über Bande“ verkaufen wollen und Geronimo aka Websphere Community Edition).

Tja – und heute kommt die nächste Nachricht. Amazon (AWS) bietet jetzt IBM Produkte im Elastic Cloud (EC2) an. Irgendwie bietet sich die Metapher an, dass Amazon jetzt mit schicken neuen Krücken los humpelt. Und das ist eine böse Metapher und die will ich gar nicht laut gedacht haben.

„Seufz“, denke ich.

„Es bleibt spannend!“

Java in den Wolken weiterlesen →

How to use the SimpleHttpInvokerServiceExporter

The JRE 1.6 ships with small HTTP-Server implementation. The Javadocs can be found here.

Spring has provides many different ways of configuring remote access to beans (aka spring remoting), but the remoting documentation fails when it comes to the usage of the HTTP Service exporter that works with the new JRE 1.6 HttpServer.

So here is a small example on how wire up the embedded JDK HttpServer and spring remoting.

How to use the SimpleHttpInvokerServiceExporter weiterlesen →

Jira Plugin & Log4J

I came across this problem lately when I was working on a Jira plugin. A Jira plugin does not rely on a OSGi container or some similar plugin framework. The plugin consists mainly of a jar file that gets deployed with (I mean inside…) the Jira Java EE web application.

Logging is an issue in such an environment: the surrounding application configures the logging API – there is no way to provide log4j configuration fragments.

Jira Plugin & Log4J weiterlesen →

Stop this “my support is better than yours” discussion!

Ok, someone is making money with support.
Ok, someone is not contributing to OSS.
But wait – is offering support not exactly that? Contributing to OSS by doing the dirty work no one wants to do?

That’s why I do not agree entirely with the label “parasites”. It is not easy to offer support, IMHO it is a Job that no one likes to do. I don’t know if it is true for everyone – but I am very happy to be a developer and not to be a support guy.

Stop this “my support is better than yours” discussion! weiterlesen →

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!