Folgende zwei Codezeilen bewirken z.B. die Ausgabe der Fehlermeldung:  Dead store to local variable.

List<Artikel> artikelListe = new List<Artikel>();
artikelListe = dao.getWarenkorbArtikel();

Können Sie die Fehlerursache entdecken?

Analyse des Codes:

Zeile 1: In der zweiten Zeile wird die lokale Variable artikelList angelegt und der Referenzzeiger der Variable in den Stack gelegt. Im Heap wird ein Objekt Liste<Artikel> erzeugt. Der Referenzzeiger zeigt auf dieses Listenobjekt.

Zeile 2: Die Methode dao.getWarenkorbArtikel liefert als Ergebnis ein Objekt vom Typ List<Artikel> zurück. Durch die Zuordnung in dieser Zeile wird die gerade erst erzeugte Referenzzuordnung von artikelListe gestrichen und der Zeiger artikelListe zeigt nun auf das von dao.getWarenkorbArtikel zurückgegebene Objekt.

Das heisst, sofort nach der Erzeugung des ListObjekts  ist dieses Objekt nach der Folgezeile auch schon wieder Müll, bereit für die Garbadge Collection und belegt nur Speicherplatz.

Richtig:  Aus den Diagrammen wird klar, dass für das obige Beispiel das Statement sinnvollerweise folgendermaßen lauten müsste:

List<Artikel> artikelListe = dao.getWarenkorbArtikel();

Siehe auch:

Wikipedia: Funktionsweise von FindBugs
Sourceforge: FindBugs Projektseite

Heute ist Anmeldeschluß
Ursprünglich war für die Beta-Testphase der July 2009 angesetzt worden.  Dieser Termin hat sich um mehrere Monate verschoben.

Heute, den 18. Januar 2010 läuft die Anmeldefrist für die kostenlose Teilnahme am Beta-Testprogramm ab.  SUN sucht bereits zertifizierte und unzertifizierte Programmierer, mit viel und wenig Javaerfahrung, aus verschiedenen Ländern, und, und, und … und wird sich dann einen “repräsentativen” Mix von Testkandidaten zusammenstellen.

Diejenigen, die von SUN eine Teilnahmemöglichkeit zugesagt bekommen, werden dann voraussichtlich im Zeitraum von Januar und Februar 2010 die Prüfung in einem Prüfungscenter ablegen müssen.

Wer sich also noch anmelden will, möge sich beeilen.

P.S.: Tut mir leid, dass dieser Blogbeitrag so brandaktuell ist. Habe selbst erst heute von der neuen Deadline erfahren.

P.S.-Zwei: Als Anmeldebestätigung versendet SUN Microsystems übrigens eine fast leere Seite.  Nicht darüber wundern. Laut Aussage von SUN ist das ein Systemfehler, der kurzfristig nicht mehr behoben werden kann. Die Anmeldungen würden aber ankommen und man würde im positiven Fall benachrichtigt werden.

Um es vorwegzunehmen, ich halte Webservices für etwas ganz Tolles. Kapselung des Codes, definierte Aufrufschnittstelle, Verknüpfung von heterogenen Systemen/Programmiersprachen das sind alles Pluspunkte für mich, aber nach dem Lesen des Buches erschließt sich für mich nicht, warum ich Webservices nach REST Style programmieren sollte, was mir dieser Ansatz für einen Zusatznutzen bringt.

Warum habe ich als Java Programmierer überhaupt ein PHP-Buch gelesen. Zum einen kann man nicht leugnen, dass PHP insbesondere im Bereich der Frontendprogrammierung marktrelevant ist und seit der Version PHP 5 ist die Skriptsprache stark objektorientiert.  Das Buch “RESTful Java Webservices” soll erst gegen Ende des Jahres herauskommen. Kernpunkt meines Interesses war die Idee der Restprogrammierung kennenzulernen. Die Codebespiele sind in diesem Buch natürlich allesamt in PHP geschrieben, aber in welcher Programmiersprache man die  grundsätzliche Idee des REST Ansatzes umsetzt (PHP oder Java) ist von zweitrangiger Bedeutung.  Es ist für einen Programmierer absolut leicht den PHP-Code des Buchs zu verstehen und sich das Java Gegenstück dazu gedanklich vorzustellen.

Es wird immer wieder betont, dass REST (Representational State Transfer) keine neue Programmiersprache ist und auch kein neues Programmierframework, sondern ein Softwarearchitekturstil.  Und ich glaube, dass diese Kernaussage auch den Nutzen und die Limitierung von REST beschreibt. REST wird sich nicht weiterentwicklen, weil es keine Möglichkeit zur Weiterentwicklung gibt. Stillstand ist aber in der Softwareentwicklung für jede gute Idee fatal.

In der REST Programmierung wird alles als Ressource mit eigener URI deklariert und es ist verpönt, Parameter zu übergeben.

Wenn beispielsweise der Bibliotheksbenutzer (ID=4) das Buch mit der ID= 6 ausleiht, so würde man vielleicht normalerweise
pfad/kunde.php?client=4&book=6
schreiben.

Im REST Stil mit der verpönten Parameterübergabe schreibt man dann
pfad/kunde/4/book/6

Es tut mir leid, aber ich kann dabei keinen großen Unterschied sehen. Auch wenn dies nun als Ressource (URI) geschrieben wurde, bleibt es für mich doch grundsätzlich eine Parameterübergabe.

Auch bei der REST-Schreibweise existiert physikalisch keine Datei in dem angegebenen Pfad und wir kommen zu meinem ersten Kritikpunkt an REST. Für jeden Ressourceaufruf wie pfad/kunde/4/book/6 ist ein Controller zu programmieren, der den Ressourceaufruf erst einmal wieder auseinanderbaut, um dann letztendlich die erforderlichen Verarbeitungs- bzw. Datenaufbereitungsschritte durchzuführen.

Während man bei HTTP-Aufrufen sonst nur mit GET und POST agiert, so wird von REST fast das volle Repertoire (GET, POST, PUT, DELETE) eingesetzt.  Dies wird einem als großer Vorteil gegenüber einem normalen Webservice Aufruf verkauft, bei dem man den Modus explizit mitgibt. Aber ob ich nun den Modus des Webservices als Parameter übergeben bekomme oder ihn mir erst durch Betrachtung des HTTP-Befehls (GET, PUT, …) erschließen muss, bleibt sich für mich doch gleich.  Der Modus muss und wird auf jeden Fall übergeben, ob auf die eine oder andere Art.  Theoretisch gesehen, mag die REST Methode die sauberere Art der Modussteuerung sein, praxisbezogen würde ich sie allerdings als die schlechtere Verfahrensweise bezeichnen. Aus Sicherheitsgründen wird oft der PUT-Befehl auf Servern deaktiviert (insbesondere bei externen Serverbetreibern), so dass man mit einem Programm, welches auf der REST-Architektur basiert, ein richtiges Problem beim Deployment bekommt.  Was nützt einem das beste theoretische Konzept, wenn es auf dem Produktionsserver nicht läuft!

Um die URIs aufzulösen, braucht es einen Controller, der den HTTP-Befehl auflöst, dann die Parameter (die ja keine Parameter sind) interpretiert um dann in einer Art Kaskadierung mit vielen “wenn dann” Fallbetrachtungen irgendwann einmal das zuständige Aufbereitungsprogramm/die zuständigen Aufbereitungsprogramme bestimmt zu haben.
Bei einfachen Webservices mag das ja noch angehen, wenn mit steigender Komplexität sehe ich auch eine steigende Fehlerträchtigkeit mit dieser Architektur und damit einhergehend eine Verschlechterung der Wartbarkeit der Software.

Das Thema REST wird bald von einem anderen Strohfeuer abgelöst werden. Die durchaus vorhandenen, positiven Gedankenanstöße von REST (zustandslose Webservices, keine Notwendigkeit von Cookies) werden hoffentlich von anderen, noch kommenden Techniken aufgegriffen und weitergeführt.

REST ist und bleibt das Kapitel 5 der Dissertation von Roy Thomas Fielding aus dem Jahr 2000.