Ist die Java-API schlecht gestaltet und warum?

Question

Ich habe das schon oft gehört, dass die Java-API schlecht gestaltet ist. Stimmen Sie zu und wenn ja, warum? Ich weiß, dass es große Probleme mit den Calendar/Date-APIs gibt. Das Collections-API erfordert viel boilerplate-Code, um es zu verwenden. Die File/IO-API kann für einige Dinge kompliziert sein.

Aber gilt das weltweit? Und für welche Java-Versionen?

Answer 1

Kurz gesagt sind Java APIs in Ordnung.

Die längere Antwort ist, dass einige APIs Änderungen, manchmal sogar signifikante, in den verschiedenen Java-Versionen durchgemacht haben und möglicherweise seltsame Teile enthalten können. Zum Beispiel hat die Klasse Date ziemlich viele veraltete Methoden. Trotzdem ist es wichtig, dass diese APIs existieren. Java ist stark mit seiner Standardbibliothek, in der man APIs für fast alles finden kann (vielleicht nicht immer perfekte APIs, aber gut genug).

P.S. Beim nächsten Mal, wenn jemand eine solche Aussage trifft, frag ihn, wie viele Sprachen er selbst in seinem Leben entworfen hat.

Answer 2

Java war keine schlecht entworfene API. Java wurde zu einer Zeit erstellt, als die aktuellen Best Practices nicht genau bekannt waren. Viele Implementierungen wurden auf eine Weise durchgeführt, die heute nicht mehr gerne gesehen wird. Seitdem wurde sehr viel Arbeit geleistet, um bessere Techniken und Praktiken zu integrieren. Deshalb gibt es viel veralteten Code.

Einiges davon wird im ERSTAUNLICHEN Buch Effective Java diskutiert. Bloch spricht über einige der "Fehler", die bei der ersten Implementierung gemacht wurden, und wie sie daran gearbeitet haben, sie zu beheben. Wenn Sie ein ernsthafter Java-Entwickler sind und Effective Java noch nicht gelesen haben, empfehle ich es SEHR. (Ich empfehle tatsächlich alle 3 Bücher Blochs. Er ist ein ausgezeichneter Autor mit einem gründlichen Verständnis von Java.)

Answer 3

Einige der "Ist die Java-API schlecht?" wird im Buch Effective Java behandelt.

Einige Teile der API, wie java.util.Date, sind eindeutig schlecht konzipiert (fast alle Methoden sind seit JDK 1.1 veraltet).

Es gibt auch andere Dinge, wie das Fehlen von Schnittstellen bei einigen JDK 1.0-Klassen (was passierte, da es zum Zeitpunkt der Erstellung noch keine Schnittstellen gab (Schnittstellen wurden vor 1.0 hinzugefügt, aber nach 0.0).

Einige Dinge wurden nicht "richtig" gemacht, weil die Konvention nach JDK 1.1 eine Reihe von Änderungen in der AWT aufgrund von JavaBeans und den verwendeten Benennungskonventionen brachte).

Es gab auch einige Dinge, die vor Sprachänderungen wie enums und Generika nicht möglich waren.

Ein Großteil der API ist gut. Einige Teile sind schlecht. Die frühen Komponenten in JDK 1.0 wurden eindeutig für HotJava (einen reinen Java-Webbrowser) geschrieben und waren nicht wirklich für den allgemeinen Gebrauch durchdacht.

Es ist sicher zu sagen, dass je älter die API ist, desto "schlechter" ist sie. Neuere APIs werden mit dem Wissen darüber entworfen, was zuvor kam. Das gilt auch für Sprachen - Java ist (je nach Meinung) besser als C++. C++ ist (je nach Meinung) besser als C, usw..

Answer 4

Java ist alt (seine Ursprünge liegen in den frühen 90er Jahren, obwohl es erst etwa 1995 als Version 1.0 veröffentlicht wurde) und alles, was so alt ist, hat APIs, die man kritisieren kann. Es ist nicht so, dass sie an sich schlecht sind. Sie sind einfach ein Produkt ihrer Zeit und diese Philosophie wird heute als schlecht angesehen (meistens aus gutem Grund, aber nicht immer).

Um die von Ihnen aufgeführten Probleme anzugehen:

• Das Datum ist schrecklich, nur weil es veränderlich ist. Eine unveränderliche Datumsklasse wäre viel sauberer (Calendar hat das gleiche Problem);
• Ein öffentlicher Konstruktor für String ist höchstens problematisch. Es gibt Uneinigkeit darüber, ob dies überhaupt ein Problem ist oder nicht. Meiner Meinung nach ist es das, aber es ist keineswegs ein großes Problem;
• Die java.io.* Klassen erinnern mich ein wenig an die C++ iostream-Bibliothek, in dem Sinne, dass sie ein Experiment waren, das meines Erachtens sich nicht als Erfolg (wenn nicht sogar als Misserfolg) erwiesen hat. Schauen Sie sich nur den Code an, den Sie schreiben müssen, um eine Textdatei in einen String zu lesen. Die meisten anderen Sprachen haben einen Standardaufruf, der dies erledigt.

Und einige andere:

• Die Sammlungen vor Version 1.2 sind problematisch. Josh Bloch (bekannt durch sein Werk "Effective Java") war der Architekt für die Änderungen am Java Collections Framework in Version 1.2. Es war eine massive Veränderung zum Guten und beinhaltete Schnittstellen für alle Klassen, abstrakte Implementierungen, usw;
• java.util.Properties erweitert Hashtable. Dies ist ein klassisches Beispiel für ein Produkt seiner Zeit. In den 90er Jahren neigten Objektrahmen dazu, von etwas zu erben. Heutzutage ist die Tendenz (zu Recht) eher Komposition statt Vererbung, aber das war vor 10-15 Jahren nicht der Fall.

Answer 5

Sie könnten argumentieren, dass es "schlecht gestaltet" ist, weil die Autoren es jetzt anders aufbauen würden. Trotzdem haben sie über die Jahre hinweg lobenswerte Anstrengungen unternommen, um das Beste daraus zu machen. Rückblickend betrachtet ist jedoch alles klarer.

Die Java-API hat dasselbe Problem wie jede Bibliothek, die sich "weiterentwickeln muss, während sie läuft".

Es ist schon so viele Jahre her, seit Java zum ersten Mal herauskam, und viele Designentscheidungen in Bezug auf Sprache und Bibliothek haben sich weiterentwickelt. Die Notwendigkeit, abwärtskompatibel zu sein, hindert jedoch die API daran, sich zu ändern.

Es gibt viele spezifische Beispiele für Benutzerfreundlichkeitsprobleme (ich habe sie in den letzten Jahren studiert), aber mal ehrlich, nur wenige APIs sind perfekt.