Java gibt es nun schon seit mehr als 10 Jahren und es hat sich viel Unnötiges angesammelt:
- Veraltete Methoden, Klassen und Pakete, die nie entfernt werden,
- Pakete, die kaum jemand benutzt (wann haben Sie das letzte Mal javax.sound.midi benutzt?), und
- Sprachmerkmale, die sich anders entwickelt haben, als wir es uns vorgestellt haben:
- Pakete waren als Namensräume gedacht, um identisch benannte Klassen zu trennen. Da jedoch Paketnamen in der Regel recht lang sind und die durchschnittliche Java-Klasse Dutzende von anderen Klassen importiert und wir dann die Importliste in unserer IDE zusammenklappen, neigen wir dazu, uns zu ärgern, wenn eine gleichnamige Klasse in mehreren Paketen existiert.
- Die Unterscheidung zwischen java und javax sollte zum Ausdruck bringen, dass javax-Pakete Erweiterungen der Standard-Klassenbibliothek sind. Da JavaSE jetzt jedoch viele javax-Pakete enthält, ist dies nicht mehr der Fall.
Man könnte diese Dinge als
rudimentäre Strukturen von Java bezeichnen. Sie erfüllten irgendwann in der Entwicklung von Java einen Zweck, haben aber inzwischen ihre Funktion verloren. Leider hindert uns die Abwärtskompatibilität daran, diese Funktionen wahllos zu entfernen.
Jedenfalls ist das Gleiche mit der JavaEE-Spezifikation passiert.
Nach fast 10 Jahren Java-Spezifikationen für Unternehmen (beginnend mit der Servlet-API im Jahr '97) können wir feststellen, dass sich die folgenden APIs nicht wirklich als das erwiesen haben, was wir uns von ihnen versprochen haben:
- EJB 1.x und 2.0 - ersetzt durch EJB 3.0.
- JDO - wurde von JPA verdrängt, bevor es jemals wirklich genutzt wurde.
- JAAS - ist für Client-Anwendungen gedacht, wird aber in JavaEE-Anwendungsservern auf verworrene Weise verwendet.
- JAX-RPC - nur eine Version später durch JAX-WS ersetzt!
- JSF - noch ganz frisch, aber ich habe das Gefühl, dass es sich im Vergleich zu den unzähligen Web-Frameworks, die es bereits gibt, nicht durchsetzen wird.
- JavaBeans Activation Framework - wird für JavaMail und JAX-RPC benötigt, ist aber ziemlich beschissen.
Und mit etwas mehr Nachdenken ließe sich die Liste noch etwas erweitern. Wie auch immer, ich schreibe dies nicht, um all diese APIs zu kritisieren; es gibt wahrscheinlich schon genug Blogs, die das tun. ;-)
Nein, ich denke, das Problem liegt tiefer als das.
Das Problem ist, dass JavaEE versucht, ein Programmiermodell zu sein, obwohl wir eigentlich eine Schnittstelle zum Anwendungsserver und seiner Umgebung brauchen.
Lassen Sie mich das erklären. Vergleichen Sie die Servlet-Spezifikation mit der JSP-Spezifikation. Ohne die Servlet-Spezifikation kommen Sie nicht aus, denn sie definiert den Vertrag zwischen Ihrer Anwendung und dem Anwendungsserver. Wenn Sie Ihre Anwendung für die Servlet-API schreiben, können Sie sie auf jedem Anwendungsserver ausführen. Die Servlet-API bietet uns also die begehrte Eigenschaft der Portabilität.Oberflächlich betrachtet gilt das Gleiche für JSPs. Sie könnten einfach ein Servlet einbinden, um Ihre JSPs zu interpretieren (ich weiß es,
ich habe eines geschrieben), und das würde Ihnen dieselbe Funktionalität bieten, sogar noch mehr Portabilität zwischen Anwendungsservern (keine Abhängigkeit von bestimmten JSP-Compiler-Funktionen), aber auch mehr Flexibilität, um das Servlet zu ändern.
Die JSP-Spezifikation ist wirklich nur dazu da, dem JavaEE-Entwickler ein Programmiermodell zur Verfügung zu stellen. Wir könnten auf die JSP-Spezifikation verzichten, wenn wir nur Portabilität zwischen JavaEE-Anwendungsservern bräuchten.
Andere APIs, die diese Vorstellung von JavaEE als Programmiermodell unterstützen, sind:
- EJB
- JDO
- JPA
- JSF
- JAX-RPC, JAX-WS
- JAXR, JAXB, JAXM
- SAX, DOM, JAXP
- JavaMail
- JavaBeans Action Framework
Die folgenden APIs sind eigentlich Schnittstellen zwischen Ihrer Anwendung und dem Anwendungsserver und seiner Umgebung (Datenbankserver, Messaging-Infrastruktur usw.) und unterstützen das Konzept von JavaEE als Schnittstelle zum Anwendungsserver:
- JMS
- JDBC
- JTS
- und natürlich die Servlet-API
Es ist kein Zufall, dass leichtgewichtige JavaEE-Frameworks wie das Spring-Framework die letztere Art von APIs verwenden und die erste Art ersetzen! Außerdem werden Sie feststellen, dass die Liste der Schnittstellen-APIs viel kürzer ist als die erste und auch keine APIs enthält, die veraltet sind (JAX-RPC wurde nach nur einer J2EE-Version veraltet!).
Es wäre sehr vorteilhaft für den JavaEE-Stack, wenn sich die nächste Version von JavaEE auf das konzentrieren würde, was sie wirklich tun muss, und nicht versuchen würde, die .NET-Umgebung durch Hinzufügen von Dingen wie JSF oder JPA zu emulieren. Dadurch würden wir eine kleinere, stabilere JavaEE erhalten und die Anbieter von Anwendungsservern würden sich nicht auf das konzentrieren, was sie tun müssen: wirklich schnelle Servlet-Container und ähnliches implementieren. Die meisten Leute verwenden ohnehin schon die leichtgewichtigen Alternativen zu den JavaEE-als-ein-Programmiermodell-APIs.
In der Zwischenzeit können die Programmiermodell-APIs der freien Software-Gemeinschaft überlassen werden, die damit in den letzten 5 Jahren ziemlich gute Arbeit geleistet hat und sich als fähig erwiesen hat, sich schneller an veränderte Anforderungen anzupassen als die JavaEE-Spezifikation es vermochte.
