Java ist eine brauchbare Programmiersprache. Der Umfang des JDK plus einen Datenbank-Treiber (JDBC) und einen Treiber für einen Asynchronen Transaktionsmonitor reicht. Es gab sicher einigen Wildwuchs, insbesondere bei J2EE und den diversen Tools, um Datenbank anzusprechen oder GUIs zu erstellen, aber man muss es ja nicht nutzen.
Ich sehe Java mit der „Brille“ des Back-End Programmierer, der auch in „alten“ Programmiersprachen Back-End Prozesse erstellt und hierbei von den vielen Jahrzehnten Erfahrung seiner Kollegen und Vorgänger profitiert hat. Den Fehler, die ein COBOL Programmierer 1970 gemacht hat, ja machen musste, weil es die bessere Alternative noch nicht gab und den ein anderer COBOL Programmierer 1985 ausgebaut hat und mir davon stolz erzählt hat, muss ich nicht 2015 in JAVA wieder tun, in der Hoffnung, dass 2030 ein JAVA Programmierer meine Fehler beseitigt. Als Beispiel: Speichern von Daten in hierarchischen Strukturen statt in relationale Tabellen.
Und irgendwie war mein Einstieg in die OOP nicht c++, sondern ein Buch über smalltalk, das ich vor 30 Jahren las. Damals gab es leider keine für einen Studenten bezahlbare Möglichkeit, etwas mit smalltalk auszuprobieren, aber was für eine c-Programmierer, damit auch für einen c++ Programmierer und letztlich für einen Java Programmierer ein Methoden-Aufruf ist (function call), ist für mich auch eine Nachricht (message).
Das GUI oder ein anderes Programm schickt (XML-) Messages per Asynchronen Transaktionsmonitor, der Transaktionsmonitor ruft das Programm auf, das Programm liest und schreibt mit SQL Statements auf Datenbanken, vielleicht sendet es an ein anderes Programm (XML-) Meldungen und wenn es fertig ist, schickt es einen Response an den Transaktionsmonitor, der wiederum den Aufrufer informiert.
Damit sind die Programme zustandslos, der „alte“ Zustand seht in der Datenbank, der „neue“ Zustand wird vom GUI verwaltet und am Ende steht der „neue“ Zustand in der Datenbank.
Das vielfach implementierte Vorgehen eines zustandsbehafteten Server-Prozesses führt an einige Stellen zu Problemen, die man vermeiden sollte. Zum einen geht es um die Verwaltung des Zustands des Server-Prozesses, wer sich die Beispiele für eine Entity Bean oder Stateful Session Bean anschaut, sieht einen komplexen Lifecycle. Zum anderen erzeugt jeder Aufruf einer Server-Funktion vom GUI aus einen recht grossen Overhead, einem Aufruf mit 10 kb ist zehnmal schneller wie 10 Aufrufen á einem Byte. Wenn man keine Datenbank (also Transaktionen) und keine gesicherten Transportwege (Asynchroner Transaktionsmonitor) zur Verfügung hat (beides fehlte SUN damals im Produkt-Portfolio), also die gesamte Verwaltung der Transaktionen in Java macht, muss man den Weg von EJB gehen, aber wer arbeitet heute ohne Dankbank und Transaktionsmonitor?
Einige Dinge fehlen mir oder stören mich in Java.