cyberspirit.net

Für 3 Tage hatte ich eine Schulung zum Thema Java EE 5/6 Patterns, Idiome und Best-Practices bei Adam Bien. Ich kann sie nur empfehlen!
Man merkt sehr schnell, dass das, was man bisher objektorientierte Entwicklung nennt, nicht der Wahrheit entspricht. Mit Hilfe von JEE 6 ist aber das möglich: Eigenschaften eines Objekts zu kapseln und über Methoden das Verhalten eines Objekts zu implementieren. Und das macht Spaß! Und es kann so einfach sein!
Das ist natürlich nur ein kleiner Teil, was man in der Schulung lernt. Aber für mich ist das das Entscheidende!

In den letzten Monaten hatte ich mich irgendwie daran gewöhnt, dass die Entwicklungsumgebung IBM® Rational® Application Developer for WebSphere® einem die Arbeit mehr erschwert als erleichtert. Man ist meistens damit beschäftigt angebliche Compiler-Fehler zu korrigieren.
Angebliche? Ja! Aus irgendwelchen Gründen werden nach einem Start des Workspaces die Abhängigkeiten nicht richtig aufgelöst und das führt dann zu hunderten von Compiler-Fehlern. Die Korrektur kann unterschiedlich sein: Schließen und Öffnen eines Projektes, Update EAR libraries nutzen, Clear Project usw.

Dies sollte der Vergangenheit angehören durch einen Wechsel auf MyEclipse Blue Edition.
Leider wurde diese mit Hilfe der Testversion diese Entwicklungsumgebung nicht vorab getestet.
Denn ein Feature, das für andere Application Server genutzt werden kann, ist aus Sicht des WebSphere AS eher als Bug anzusehen: Wenn ein Punkt in einem Projektnamen vorkommt, so wird alles nach dem letzten Punkt beim Deployment abgeschnitten. Dann weißt der WebSphere darauf hin, dass bereits ein EAR mit dem gleichen Namen deployed wurde.
Dieses “Feature” soll seit mehreren Jahren deaktivierbar gemacht werden; bis heute ist nichts passiert! So wird man genötigt, alle Punkte aus den Projektnamen zu entfernen.

Wenn dann gleichzeitig noch ein Wechsel der Application Server Version gemacht wird, ist die Verwirrung perfekt! Ist die neue Entwicklungsumgebung oder die neue Version des Application Servers schuld, dass etwas nicht funktioniert? So gehen wieder unendliche Stunden für das Handling einer Entwicklungsumgebung drauf.

Wahrscheinlich ist die Vorgehensweise eine falsche: Sollte man vielleicht besser auf dem lokalen Rechner mit einem leichtgewichtigeren Application Server testen? Denn nicht nur die Probleme innerhalb der Entwicklungsumgebung machen die Entwicklungsarbeit schwer, sondern auch das Warten beim Starten und Stoppen des Application Servers.
Wenn man dann auf einem anderen Application Server deployed, muss man vielleicht einmal die Applikationen anpassen. Aber man umgeht dann vielleicht die Probleme, die bei jedem Entwickler immer wieder erneut auftreten und sich so die verlorene Entwicklungszeit mit jedem Entwickler mutlipliziert.

Es ist doch durchaus interessant, wenn man etwas aus seinem Studium in “freier Wildbahn” wiederfindet. So ging es mir heute!

Bei einem Meeting wurde offiziell der Start eines neuen Projektes eingeläutet. Dabei soll einem externen Unternehmen Know-How vermittelt werden. Dies ist erstmal nichts wirklich Spannendes. Überrascht hat mich dann aber das beschriebene Vorgehen jenes Unternehmens. Es fielen Begriffe wie Robustnuss Analyse, Boundaries, Entities – irgendwie kamen mir diese sofort bekannt vor. Nach kurzer Suche bei Google hatte ich auch sofort wieder den Namen des Vorgehensmodells parat: ICONIX. Dabei handelt es sich um UseCase-getriebene Objektmodellierung mit UML.

Schlaue Leute haben eine Lücke zwischen UseCase-Diagramm und Sequenz-Diagram entdeckt. Diese Lücke wird bei ICONIX mit Hilfe des Robustness-Diagramms geschlossen. Mit Controllern, Boundary und Entity Objekten wird in einem solchen Diagramm die Kommunikation zwischen zwei Klassen und dem Verhalten der Software dargestellt.

Die Modellierung beginnt also mit dem UseCase-Diagramm, welches zusammen mit der UseCase-Beschreibung in dem Robustness-Diagramm aufgeht. Abschließend entsteht im Sequenz-Diagramm das detailierte Design. Durch das Schließen der Lücke zwischen UseCase- und Sequenz-Diagramm entsteht eine direkte Verknüpfung zwischen den Diagrammen. Für jeden UseCase gibt es ein Robustness- und ein Sequenz-Diagramm.

Ich bin sehr gespannt, wie sich das entwickelt!

Da ich mitbekommen habe, dass nach meinem Namen bei Google ab und zu gesucht wird, habe ich mir gedacht, dass ich etwas verändern muss.
Der Blog war mir etwas zu düster, deshalb habe ich das Aussehen etwas verändert.

Ich möchte den Menschen natürlich auch ein paar Informationen über mich bieten und so habe ich außerdem eine neue Seite mit meinen Kompetenzen erstellt, die natürlich (unregelmäßig) aktualisiert wird. Auch die Seite Projekte wird nun in unregelmäßigen Abständen aktualisiert.

Im aktuellen Projekt verwenden wir JNI zum Aufruf einer C-API.
Dabei habe ich verschiedene Herausforderungen gemeistert.

Die größte Herausforderung betrifft die Bibliothek, die im Java-Code über System.loadLibrary(String) geladen werden soll. Diese muss im java.library.path liegen. Diesen kann man beim Aufruf über die Konsole angeben: java -Djava.library.path=<path_to_lib> JNICall.
Unter Sun Solaris kann man dafür auch die Umgebungsvariable LD_LIBRARY_PATH nutzen; unter Windows ist es PATH. Dann benötigt man den Parameter beim Aufruf nicht mehr.
Im Websphere 6.1 ist das etwas schwieriger. Dort kann man die Variable java.library.path als benutzerdefiniertes Merkmal für die JVM definieren. Für jeden Anwendungsserver kann man unter Java- und Prozessverwaltung in der Prozessdefinition unter Java Virtual Machine ein entsprechendes Merkmal hinzufügen.

Das Kompilieren des C-Codes war leider auch nicht ganz so einfach. Unter Windows haben wir dazu GCC von MinGW genutzt. Unter Sun Solaris hatten wir CC zur Verfügung. Mit Hilfe eines Ant-Scripts konnten wir relativ einfach für die entsprechenden Umgebungen mit kleinen Anpassungen den Code compilieren.

Die größte Herausforderung war allerdings das Laden der Bibliothek unter Solaris. Während es unter Windows eine *.dll ist, ist es unter Solaris eine *.so! Unter Solaris kommt allerdings noch ein Präfix dazu: lib. Das bedeutet, dass unter Windows die Bibliothek z.B. Demo.dll heißen muss, unter Solaris jedoch libDemo.so!

Ich hoffe, dass diese Informationen dem einen oder anderen dabei helfen können, selbst über JNI C-Code aufzurufen.

Nachtrag:
weiter lesen