everflux

Wenn man dem Gridgain JIRA Issuetracker glauben darf, dann gibts einen Tag nach Nikolaus das Gridgain 2.1 release. In den Release notes finden sich dabei die gefixten Bugs, neuen Features – und auch Einblicke ins Marketing. So gibt es Tasks wie „Google ad Gridify Websphere„, die wohl über Google Adwords neue Kunden auf GridGain aufmerksam machen sollen.

Was ist interessant am neuen Release? Für mich bedeutet vor allem die Verfügbarkeit von GridGain über ein Maven Repository, dass es leichter wird, mit GridGain Projekte umzusetzen, die für ein breites Publikum leicht verfügbar und baubar sind.

Sicherlich ist auch die verbesserte Spring Integration von GridGain aufregend: Neben Annotation zum injekten von Spring Beans kann nun auch das gesamte GridGain von Spring konfiguriert und instantiiert werden.

Am meisten fasziniert mich die neue Classloader-Philosophie: Schon von Anfang an war ich von der GridGain Art begeistert: Einfach starten, und ein Programm kann im Grid laufen. Direkt aus Eclipse, Netbeans oder auch als Anwendung von der Kommandozeile, GridGain hat sich um alles transparent im Hintergrund gekümmert.  Der einzige – mehr oder minder – Haken war, dass es einen Classloader pro „Task“ gab. Damit ist es schwer bis unmöglich, bestimmte Ressourcen zu teilen. Gerade „teure“ Ressourcen, oder umfangreichere Datenstrukturen können so einige Programmierkniffe erforderlich machen.
Mit GridGain 2.1 soll es zukünftig möglich sein, alles, was lokal als geteilte Ressourcen verfügbar ist, auch zwischen GridGain Tasks zu teilen – wohlgemerkt auch ohne zusätzliche Deployment-Schritte.

Wer neugierig geworden ist, sollte sich einfach einmal ein Stündchen mit GridGain beschäftigen. Auch auf Javalobby/Dzone findet sich ein Artikel zum GridGain 2.1 Preview. Zur Homepage von Gridgain gehts hier: http://www.gridgain.com/

Update: GridGain 2.1 ist jetzt verfügbar.

Die integrierte Entwicklungsumgebung Netbeans ist in Version 6.5 erschienen, einen kompletten Überblick über die Netbeans Features findet sich hier. Neben IntelliJ IDEA und Eclipse hat sich Netbeans zu einem sehr attraktiven, offenen und schnellen Produkt entwickelt, das nicht nur Java Entwicklern zu empfehlen ist.

Gerade die Unterstützung verschiedener Programmiersprachen, von JavaScript über PHP zu Python, Ruby und natürlich Java ist teilweise besser in Netbeans als in Eclipse gelöst. Zusätzliche Features lassen sich als Plugins nachinstallieren, und auch mit „der“ (kommerziellen) IDE IntelliJ muss Netbeans den Vergleich keineswegs scheuen. In meinen Augen für Java Desktop Entwickler ist weiterhin der GUI Builder Matisse und als freies UML Tool zum Designen und Reverseengineering das UML Tool von Netbeans wirklich herausragend.

Ajax ist eine tolle Erfindung – bis auf ein paar „Kleinigkeiten“. Z.B. ist nicht vorgesehen einen Dateiupload mittels Ajax zu realisieren. Da muss schon ein echtes Formular her.

Doch wenn dennoch eine Datei im Hintergrund hochgeladen werden soll – also ein „echter“ Ajax File upload realisiert werden soll – greift man in die kreative Trickkiste. Die üblichen Verdächtigen für solche Aufgaben sind DWR, jQuery, Dojo. DWR bringt in der Inkarnation 3.0 dann auch Support für Ajax Fileupload, inclusive einem Mapper. Also zurück zu den Basics – was tun, wenn ein XmlHttpRequest nicht da ist? Richtig! Unsichtbares iframe nehmen. Weiterlesen »

Der heute veröffentliche OpenFire 3.6.1 schließt eine gravierende Sicherheitslücke, über die sogar administrativer Zugriff unberechtigter möglich war. Eine Übersicht der anderen Änderungen findet sich im Openfire changelog.

Openfire ist ein Java basierter XMPP (Jabber) Server, der trotz des umfangreichen Featureumfangs als OpenSource frei verfügbar ist, und von Ignite Realtime entwickelt wird. Aufgewertet wird OpenFire auch über die Möglichkeit durch Plugins zusätzliche Features zu ergänzen.

Speicher ist immer zu knapp – das ist nichts neues. Aus Zeiten als 64MB noch recht viel waren, stammt der Default Wert für eine Java VM: 64MB für den Heap, da muss die Applikation reinpassen.

Normalerweise stellt man (mittels -Xmx) eine entsprechend größere Heap Größe für die Java VM ein, insbesondere für Applikationsserver. Einen Sonderfall des „out of memory error“ ist der „GC overhead limit exceeded“ Fehler. Dieser wird dann erzeugt, wenn der Garbage Collector zu viel Zeit damit zu bringt, Speicherplatz frei zu räumen, und die Applikation nicht mehr dazu kommt, zu arbeiten. (GC Dokumentation)

Abhilfe schafft hier ebenfalls ein größerer Heap Space für die JVM, bzgl. ein Profiling der Applikation, um Speicherlecks zu finden. (Wird eine Applikation per Maven-jetty-Plugin testweise gestartet, wird hier übrigens keine separate JVM gestartet, sondern die von Maven weiter verwendet. Damit hilft hier MAVEN_OPTS entsprechend zu konfigurieren.)

Wie im Blog von Graeme Rocher und Guillaume Laforge nachzulesen, ist SpringSource auf Einkaufstour: G2One, die Firma die Groovy und Grails Entwicklung sponsort gehört nun zu SpringSource. Venture Kapital dass sicherlich nicht schlecht angelegt ist.

Auch der Spring Philosophie, alles zu vereinfachen und zu vereinheitlichen steht Groovy und Grails in nichts nach – es geht auch hier darum, Anwendungsentwicklung zu vereinfachen und zu beschleunigen. Da bei Grails die Idee war, vorhandene Technologien zu recyclen und einen Rails ähnlichen Ansatz für die Entwicklung zu verfolgen, basiert Grails auch bereits auf dem Spring Framework. Graeme Rocher schreibt, dass er sich eine noch engere Integration und synergistische Effekte für die Zukunft erhofft.

Man darf in jedem Fall gespannt sein, ob nun auch für Groovy und Grails das Schwert des SpringSource vendor-lock-in über den Köpfen baumelt, oder alles wie gewohnt bleibt.

Wie man hier lesen kann, ist am 6. November der neue Glassfish v3 Application Server veröffentlicht worden.

Glassfish ist ein modularer Application Server, der inzwischen nicht nur die Java Plattform unterstützt. (PHP, (J)Ruby on Rails, Grails, … sind ebenfalls verfügbar.) Was macht Glassfish zu etwas besonderem?
Als Referenzimplementierung werden erste Features von JEE 6 (Java Enterprise Edition) in dem Glassfish v3 zu sehen sein. Ebenfalls mit an Bord ist OSGi Support, Comet, RESTful web Services. Dank Metro ist die Interoperabilität mit .net sichergestellt, Tooling für Netbeans und Eclipse steht dem Entwickler ebenfalls zur Seite.

Fazit: Glassfish hat das Potential durch die schlanke aber auch modular erweiterbare Struktur ein attraktive Plattform für verschiedenste Applikationen zu werden.

Einen guter Überblick über Glassfish und die neuen Glassfish Features findet man auch in den Sun Screencasts. (Wer noch garnicht mit Glassfish gearbeitet hat, findet einen guten Einstieg in diesem Screencast: Introducing Glassfish v3)

Eclipse Ganymede kommt mit der aktuellen WTP Version 3.0.x – dazu gehört im Eclipse auch ein JSP Syntax Validator, der helfen soll, korrektes JSP zu schreiben.

Bei der Entwicklung einer Spring basierten Anwendung jedoch hat sich Eclipse als besonders zickig problematisch dargestellt: Es hagelt JSP Syntax Fehler, obwohl – eigentlich – alles in Ordnung ist. Auch beim Deployment der Webanwendung gibt es keine Probleme – nur Eclipse motzt. Das ganze sieht dann z.B. so aus:

- Syntax error on token "}", delete this token
- Syntax error on token "catch", Identifier expected
- Syntax error, insert "Finally" to complete TryStatement

Und natürlich in Zeile „0“ – sehr hilfreich. Auch die angeprangerten Statements sind nirgends zu sehen. Erste Vermutung: Eclipse Webtools JSP Validator hat Probleme mit Taglibs. Hätte längst jemand gemerkt, denke ich mir. Also kann das schonmal nicht ursächlich sein.

Weiterlesen »

Netbeans 6.5 kommt – der RC1 wurde gestern veröffentlicht. Schon seit geraumer Zeit arbeite ich gerne mit den nightly builds, die einen stabilen Eindruck machen. Was bringt Netbeans neues, und was hat Netbeans 6.5 auch für nicht-Java Entwickler zu bieten? Weiterlesen »

Spring Framework – damals revolutionäre Konzepte, weg von „bloated enterprise committee driven“, „lightweight“ war angesagt. Spring setzte sich rasend schnell durch, die Macher verdienten mit Consulting, Training und Büchern.

Die „Community“ verhalf Spring zum Erfolg – Menschen, die in neuen Projekten den Mut aufbrachten auf Spring zu setzten. Entwickler, wie ich, die Bücher kauften, Bugs meldeten, testeten und Marketing betrieben.

SpringSource wurde geboren – Venture Capital floß. Nach der Enterprise Application Platform und JavaOne T-Shirts die furchtbar die Wäsche verfärben kommt jetzt der absolute Knüller: Wer nicht zahlt erlebt ein Debian revival: Veraltete Version benutzen oder „unstable“ fahren. Wobei Debian wenigstens Security Fixes noch in den antiken Versionen bereitstellt.

Wer zahlt, der bekommt eine stabile Version – jedoch unter einer Lizenz, die es nicht erlaubt diese Version weiterzugeben. Ich weiß nur, dass ich nach dem Theater mit der ext-js Lizenz ganz schnell bei jquery war, und sicher da bleiben werde. Bleibt abzuwarten, wie es mit Spring weiter geht.

Einen Blick auf Google Guice und pico container habe ich bereits geworfen – doch Spring ist mehr. Vendor lockin auf allen Ebenen, das tut weh.

• Rod Johnson Interview auf dzone
• Stefan Reuter zu den Lizenzänderungen beim Spring Framework
• SpringSource Licensing FAQ
• Analyse: Wie sehr ist Spring eigentlich „OpenSource“
• Diskussions Thread bei TheServerSide

Rod Johnson hat sicherlich Recht, dass SpringSource „über 100 OpenSource Releases pro Jahr“ machte, aber wie wird die Zukunft aussehen? Sicher, Bandbreite für Dokumentation, Maven Repo, Amazon S3, das kostet alles Geld – jedoch zumindest für diejenigen, die selber Spring kompilieren, könnte ein SVN Tag bereitstehen. Ich bin gespannt, wann jemand svn revision Nummern zu enterprise releases als Mapping zur Verfügung stellt.

Das könnte auch SpringSource helfen – zumindest wenn gewünscht ist, dass die Community weiterhin BugReports einreicht, und das nicht nur noch enterprise Kunden per Support Ticket sollen/dürfen: Doppelte Bugreports und Reports zu längst gefixten Problemen dürften die Regel statt die Ausnahme werden. Oder eben man schaltet bei „Community“ komplett auf taub.

Update:
Wie Rod Johnson im SpringSource Team Blog erläutert, hat SpringSource dank des umfangreichen Community-Feedback Änderungen an den Änderungen vor. Grob gesagt: Spezielle Preise für kleine Unternehmen und ständige Verfügbarkeit von Releases aus dem aktuellen Zweig.

Damit kann man gut leben – Unternehmen, die gerne ältere Versionen gepflegt haben möchten, haben auch die Ressourcen das zu finanzieren.