Kritik zum Artikel: Java Bashing

[AK]

Hallo Leute,

nachdem ich letztens ein Lob zur Artikelserie "Jenseits des Tellerrands" los geworden bin, muss ich diesmal Kritik üben.

Ich finde es ja ok wenn man Themen etwas lockerer diskutiert, wenn dann aber ein gewisser Herr mit dem Pseudonym "J.Avanie" behauptet, dass JDBC "kompletter Müll" ist, dann verschlägt es mir doch die Sprache. Hey, er schreibt von JDBC und dann noch nicht mal eine Begründung, einfach nur ein läppisches "weil man damit viel zu leicht Fehler machen kann". Spätestens ab diesem Satz konnte ich diese Diskussion nicht mehr ernst nehmen.

Was haltet Ihr von diesem Artikel?

[Stefan Gawlick]

Also ich konnte mit JDBC bisher durchaus erfolgreich und vernünftig Ziele erreichen.
JDBC hat zumindest den Vorteil, daß man erst einmal mit geringem Einarbeitsaufwand (einfache) Datenbankzugriffe hinbekommt.
Wenn man es mit kompletten Objektstrukturen zu tun bekommt, ist dem Entwickler selbstverständlich einiges an Eigenleistung abverlangt. Aber das ist ja nicht das Problem von JDBC. Es gibt durchaus Situationen, da wäre jede andere Lösung (auch JDO)überfrachtet.
Was ich damit sagen will: ich gebe meinem Vorredner recht, daß man JDBC nicht als Müll bezeichnen kann und dann nicht einmal die Nachteile (und Vorteile) klar auf den Tisch legt

[Stefan W. Wagner]

Was das soll habe ich mich auch gefragt.
Man kann sich überlegen, ob der Autor wohl dies oder jenes gemeint hat, und gutwillig unterstellen, er habe das wohl gemeint, was man selbst auch störend findet.
Das ist aber kein guter Stil, solange es nicht eine langanhaltende, weithin bekannte Diskussion über die Schwächen von JDBC gibt, auf die man sich ohne weiteres berufen kann.

Wenn der Autor hier die Begründung nachschiebt, wäre das nett

[Alwin Ibba]

Naja, der Artikel heißt ja "Java Bashing". Unter "Bashing" verstehe ich sinnloses Draufhauen ohne echte Argumente.

Selbst in diesem Zusammenhang ist es ein starkes Stück, JDBC in einem Nebensatz als Müll zu bezeichnen (weil man damit Fehler machen kann...). JDBC bildet einfach das SQL Call Level Interface (Open Group, damals X/Open) auf Java ab (ähnlich ODBC). Hätte man diesen de-facto Standard komplett ignorieren und sich ein völlig neues Interface ausdenken sollen (mit der Begründung das SQL CLI und ODBC sind sowieso Müll, da machen wir lieber was ganz neues und eigenes)?
JDBC ist ein halt ein low-level API für DB-Zugriffe. Relativ alt, stabil und bewährt. Für komplexe Anwendungen nimmt man ein API/Framework, das darauf aufsetzt

[Stefan Roock]

Hier die Begründung (die zugegebenermaßen in dem Artikel fehlt).

J.Avanie vertritt den Standpunkt, dass die Java-Platform für die meisten Problemstellungen zu kompliziert/überflexibel ist. In diesem Sinne ist auch die Kritik an JDBC zu verstehen: Für die meisten Problemstellungen wäre Otto-Normal-Entwickler besser bedient mit einer weniger flexiblen Lösung, die dafür eine höhere Abstraktion anbietet (z.B. für direkte Persistenz von Objektgraphen).

Das angesprochene Fehlerrisiko rührt aus der Konzeption von JDBC als dünne Schicht um SQL her:
* Man muss z.T. direkt datenbank-spezifische Fehlercodes auszuwerten, um vernünftig mit Problemen umgehen zu können.
* Es gibt keine Unterstützung für den sauberen Umgang mit Transaktionen und Connections: Man muss manuell sicherstellen, dass Transaktionen korrekt abgeschlossen bzw. rückgängig gemacht werden und dass die Connections als Ressource auch korrekt wieder freigegeben werden.
* ...

Keine Frage: Für bestimmte einfache oder auch sehr spezielle Probleme kommt man nach wie vor an JDBC nicht vorbei und als Basis für Frameworks eignet sich JDBC allemal (siehe Hibernate).

Natürlich kann man die Wortwahl ("kompletter Müll") kritisieren. Aber sowas kann auch einem virtuellen Kontrahenten in der Hitze eines Streitgesprächs mal über die Lippen kommen :-

[AK]

Das ist ungefähr so als würde ich einen PC als totalen Müll bezeichnen, weil man mit der Schreibmaschine genauso gut Dokumente schreiben kann und auch noch viel einfacher.

Ich denke, dass hier einfach nur provoziert werden sollte um die Auflage zu steigern.

P.S. Wenn dem Herrn J.Avanie Java und sogar JDBC zu kompliziert sind, dann kann er auch VBA mit Access nehmen. Die "Begründung" die Stefan Rook nachgereicht hat ist auch unsinnig, da ich mich frage wie man ohne Standards wie JDBC vernünftige ORM-Frameworks wie JDO, Hibernate etc. entwickeln soll. In dem Sinne ist der Titel Java-Bashing schon korrekt

[EberhardWolff]

Zunächst: Danke für das Feedback. Mich würde auch weitere Kritik an dem Artikel interessieren!

Jetzt zu meiner Begründung, warum JDBC Müll ist. Dazu zunächst: Diese Sache ist tatsächlich im Artikel nicht ausreichend begründet, aber dafür gibt es ja zum Beispiel dieses Forum.

Als erstes noch ein weiterer Hinweis: Als Technologie zum Vereinheitlichen des Zugriffs auf Datenbanken, mit denen man dann O/R Mapper usw. implementieren kann, ist JDBC sicher ein Erfolg. Aber als API ist es eben eine Katastrophe.

Nehmen wir ein Beispiel aus den Sun JDBC Tutorial http://java.sun.com/products/jdbc/book.html und zwar das OutputApplet.java. Hier findet sich:

public void run() {
String url = "jdbc:mySubprotocol:myDataSource";
String query = "select COF_NAME, PRICE from COFFEES";

try {
Class.forName("myDriver.ClassName");
} catch(Exception ex) {
setError("Can't find Database driver class: " + ex);
return;
}

try {
Vector results = new Vector();
Connection con = DriverManager.getConnection(url,
"myLogin", "myPassword");
Statement stmt = con.createStatement();
ResultSet rs = stmt.executeQuery(query);
while (rs.next()) {
String s = rs.getString("COF_NAME");
float f = rs.getFloat("PRICE");
String text = s + " " + f;
results.addElement(text);
}

stmt.close();
con.close();

setResults(results);

} catch(SQLException ex) {
setError("SQLException: " + ex);
}
}

Wieviele Fehler enthält der Code? Zunächst werden stmt.close() und con.close() nicht ausgeführt, falls irgendwo eine Exception kommt. Übrigens ist das fehlende rs.close() kein Problem, weil es mit dem stmt.close auch geschlossen wird. Diese Probleme sind in der Realität sehr unschön, denn ich habe schon erlebt, wie dann Ressourcen-Leaks gesucht werden und wie schwer man die findet.

Zudem ist die Fehlerbehandlung unschön und zeigt, dass man eigentlich nur sagen kann "Benutzer, Du hast ein Problem". Das muss man bei einer RuntimeException wie einer NullPointerException auch, weswegen SQLException eine RuntimeException sein sollte.

Wenn nun selbst die Leute, die das mehr oder minder offizielle Tutorial geschrieben haben, Probleme haben, korrekte Programme zu schreiben, dann ist die API wirklich schlecht. Es gibt natürlich Hilfsmittel wie die Spring JDBC Templates, ohne die man JDBC wohl eher nicht anfassen sollte.

Dazu kommt dann noch, dass man hier eine einfache Anfrage stellen will. Dazu benötigt man einen Unmenge an Code, bei dem nur wenig mit dem eigentlichen Problem zu tun hat. Dasselbe mit Spring JDBC Templates:

private static class StringResultSetRowMapper
implements ParameterizedRowMapper<String> {
public String mapRow(ResultSet rs, int rowNum) {
String s = rs.getString("COF_NAME");
float f = rs.getFloat("PRICE");
String text = s + " " + f;
}
}

public void run() {
setResults(getSimpleJdbcTemplate().query(
"select COF_NAME, PRICE from COFFEES",
new StringResultSetRowMapper()));
}

Fairerweise muss man sagen, dass hier natürlich die Konfiguration außen vor gelassen worden ist.

Das Problem ist nun, dass JDBC der "offizielle" Standard ist und ich denke, viele nutzen es einfach, obwohl es eben bekanntermaßen suboptimal ist und erst zum Beispiel mit Spring JDBCTemplates wird es sinnvoll benutzbar.

Im Gegensatz zu früher stehen nun Konkurrenten wie Ruby oder C# vor der Tür stehen und eine der Innovationen von C# 3.0 ist LINQ mit dem die Verarbeitung solcher Datensätze wesentlich einfacher werden wird. Dadurch gerät zumindest Standard-Java eben mehr und mehr ins hintertreffen. In JDBC 4.0 gibt es nun auch Queries mit Annotationen, die zumindest den Code-Umfang reduzieren, aber das Ressourcen-Handling scheint immer noch ein Problem zu sein. Hier ein paar Code Beispiele aus der Spec:

interface MyQueries extends BaseQuery {
@Select(sql="SELECT lastName, description FROM mammals",
tableName="mammals")
DataSet<Mammal> getAllMammals();
}

Connection con = DriverManager.getConnection(url, props);
MyQueries mq = con.createQueryObject(MyQueries.class);
DataSet<Mammal> rows = mq.getAllMammals();
for (Mammal m: rows) {
if (m.description.equals("")) {
rows.delete();
}
}

Auch hier kein Aufräumen der Ressourcen. Zudem ist die SQL Anfrage in einer Annotation, was ich zumindest komisch bzw. nicht wirklichgut motiviert finde.

Übrigens hat JDBC 4.0 auch erkannt, dass die SQLException als Cheched Exception keine gute Idee ist und hat jetzt eine RuntimeException eingeführt. Ob das jetzt sauber ist, wird man sehen...

Langer Rede, kurzer Sinn: JDBC als API ist wirklich ein Problem und direktes nutzen ist sehr umständlich und fehlerträchtig. Andere Ansätze (z.B. eben Spring, aber auch LINQ) sind meiner Ansicht nach besser durchdacht. JDBC 4.0 versucht zwar, die Problem anzugehen, aber ich bin nicht sicher, ob es da wirklich gut durchdacht ist.

Übrigens gilt ähnliches für APIs wie JMS, JavaMail usw. ..

[Alwin Ibba]

Zugegeben, die Geschichten mit den Ressourcen und den try-catch-finally-Orgien sind nervig. Bei JDBC sehe ich es ein, denn es relativ alt und gegenüber den damaligen Lösungen wie ODBC allemal einfacher im Errorhandling. Außerdem ist es ein eher technisches low-level-API, da muß man sich halt um solche Dinge kümmern. Bei JMS stört es mich ehrlich gesagt viel mehr.

Abgesehen davon sind sowohl JDBC (mit entsprechenden DB-Vorkenntnissen) als auch JMS sehr einfach zu benutzen und haben eine flache Lernkurve. Das Ressourcenhandling ist zugebenermaßen ein Problem, deshalb gleich das komplette API als "Müll" oder "Katastrophe" zu bezeichnen wird sowohl JMS als auch JDBC sicher nicht gerecht. Man muß den entsprechenden Code halt in technische Hilfsklassen auslagern, wenn man mit diesen APIs arbeitet.

"Weniger flexible Lösungen, die dafür eine höhere Abstraktion bieten", wie von Stefan Roock gefordert, sind meistens auf den ersten Blick ganz toll, weil einfach und schnell am Laufen. Beim praktischen Einsatz in größeren Projekten scheitert es dann meist an all den Feinheiten und Spezialitäten, die aufgrund der geringeren Flexibilität und hohen Abstraktion überhaupt nicht realisiert werden können. Man muß bei diesen "hoch abstrahierten" Lösungen immer seine Anwendung dem Framework anpassen. Manchmal ist das mit Klimmzügen noch möglich, oft eben nicht.

In Java hat man wenigstens noch die Wahl, welches der abertausend Frameworks man benutzen will. Frameworks für die "Persistenz von Objektgraphen" gab es schon vor EJB3 zur genüge, man musste nicht zwangsläufig CMP benutzen oder auf low-level JDBC ausweichen (wobei ich es durchaus als einen Kritikpunkt an Java sehe, das die lange Zeit offiziell propagierte und standardisierte Persistenzlösung CMP sehr unflexibel und für die geringe Flexibilität unnötig komplex war).

Diese Dinge für die Java immer gescholten wird (z.b. keine Generics vor 1.5, zuviel Code für einfache Sachen, komplizierte APIs) waren zumindest in den Projekten an denen ich beteiligt war nie ein echtes Problem. Die echten Probleme treten dann auf, wenn man irgendwelche uralten vermurksten DB-Schema auf Java abbilden muß, alte Cobol-Module auf dem Host aufrufen (mit einem so alten Host-OS, das es selbst IBM schon vergessen hat) etc. Da ist man dann über Dinge wie JDBC, Hibernate, JCA, JMS sowie die riesige Vielfalt und vermeintliche Komplexität der Java-Welt sowohl im OpenSource als auch im kommerziellen Bereich heilfroh. Ob ich dann in einem Stück Code 20 statt 5 Zeilen schreiben muß oder ob ich Generics zur Verfügung habe oder nicht, ist mir dann eigentlich wurscht. Das ist halt ein Super-Argument, wenn man seine eigene Plattform vermarkten will/muß (C#, .NET). Dann kann man solche Trivialitäten über zig Seiten ausbreiten, bis es wirklich jeder glaubt.

Das ist jetzt nicht auf den Artikel bezogen. Dieser stellt ja ein Streitgespräch dar und es werden beide Seiten betrachtet (manchmal kommen halt die echten Argumente zu kurz, siehe JDBC). Daher finde ich ihn im großen und ganzen gar nicht schlecht, denn es werden von beiden Seiten die bekannten Diskussionspunkte angesprochen/zusammengefasst.

Speziell im JavaMagazin würde ich mir aber eher einen Artikel wünschen, der eindeutig Partei für Java ergreift und versucht die bekannten Vorwürfe zu widerlegen.

Alwi

[AK]

Da muss Alwin recht geben wenn ich sehe, womit sich unsere Delphi und C++ Entwickler "rumärgern", dann bin ich über die (OpenSource)Vielfalt in der Java-Szene heilfroh. Ebenso sollten wir uns immer schön im klaren sein, dass Java die einzige wirkliche Plattformunabhängigkeit im Enterprise-Bereich bietet

[Johannes Link]

> Speziell im JavaMagazin würde ich mir aber eher einen Artikel
> wünschen, der eindeutig Partei für Java ergreift und versucht die
> bekannten Vorwürfe zu widerlegen.

Die Serie heißt nicht ohne Grund "Jenseits des Tellerrands". Viele SW-Entwickler lesen nur eine einzige Zeitschrift; ich finde es wichtig, dass gerade die auch mal andere Meinungen als nur "Bei uns ist alles gut" zu hören bekommen. Ein objektiver und möglichst ausgewogener Blick ist tatsächlich nicht der Hauptfokus der Serie.

Insofern fand ich auch, dass eine Aussage wie "JDBC ist Müll" kein Problem darstellt, wenn sie einer fiktiven Person, die zudem noch "Javanie" heißt, in den Mund gelegt wird. Es ist offensichtlich eine gewollte Provokation in der Story.

Johannes Lin

[Stefan W. Wagner]

@Johannes
Dann ist aber ein konkreter Vorwurf, der mit konkreten Beispielen arbeitet (wird in Sprache xy folgendermaßen gelöst mit jenen Vorteilen und diesen Seiteneffekten) besser, als vage Behauptungen

[Alwin Ibba]

Sehe ich auch so. Mit einem "Bei uns ist alles gut"-Artikel ist keinem gedient, mit reinen Provokationen "JDBC ist Müll" aber auch nicht. JDBC hat Vor- und Nachteile (das Ressourcenhandling ist ein Nachteil). Mit "Partei für Java ergreifen" meinte ich eigentlich, JDBC (oder allgemein Java) eben nicht wegen kleiner Schwächen runterzumachen oder als völlige Katastrophe darzustellen (wie es eben von "Fans" anderer Plattformen gerne getan wird), sondern die Vorteile etwas mehr herauszustellen (oder überhaupt mal zu erwähnen). Das kann auch im Rahmen einer "Jenseits des Tellerrands"-Serie geschehen (die mir ja im allgemeinen sehr gut gefällt)