"Eine Grundsatzfrage: Brauchen wir Java EE überhaupt noch?"


#1

So, jetzt bin ich gespannt, was die Profis sagen. Ziemlich kontrovers diese Aussage:

weiterlesen…


#2

Prinzipiell brauchen wir JEE nicht mehr: Zu monolithisch, zu unflexibel, zu “opinionated”, zu objektorientiert (*). Modularisiert, modernisiert und offener für neue Ansätze könnte ich mir eine Zukunft vorstellen, aber danach sieht es eher nicht aus.

(*) Oder wie ich es gerne nenne: dysfunktional. Gemeint ist nicht, dass OO prinzipiell schlecht ist, sondern dass zu viele Probleme, die wir ohne State und mit referentieller Transparenz gar nicht hätten, mit schwergewichtigen OO-Pattern und aufwändigen Synchronisierungsmechanismen “gelöst” werden. So passt JEE auch schlecht mit reaktiven Ansätzen, Aktoren u.s.w. zusammen.


#3

@Landei da stimme ich Dir nicht zu.

Es wird doch modularisiert bzw. JEE war dies schon immer. Die verschiedenen Spezifikationen sind meiner Meinung nach eigene Module. Gebündelt werden diese doch erst durch den AppServer. Und diese laden mittlerweile nur die Bereiche, die sie benötigen.

Spring ist eine wirklich gute Alternative. Aber gibt es noch viele andere (in der Java-Welt)?


#4

Z.B. das Play-Framework


#5

Habe ich noch nicht mit arbeiten dürfen. Sah für mich immer sehr klein und sehr auf Web bezogen aus.

Kann es REST, SOAP, verschiedene DBs (und evtl. Transaktionshandling)? Bietet es eine gute IDE Unterstützung? Gibt es viele ausgereifte Frameworks?

Und inwiefern ist dies nun weniger monolithisch und flexibler als z.B. ein Wildfly-swarm oder Payara?


#6

Wikipedia:

Play 2.5.x makes use of several popular Java libraries:

  • Netty or Akka-HTTP for the web server
  • Akka Streams for all asynchronous IO and streaming
  • No required ORM, but Anorm (Scala), Slick (Scala) and Ebean (Java) are included for database access
  • Twirl (Scala) as the template engine
  • Built in hot-reloading
  • sbt as the build tool and for dependency management

The following functionality is present in the core:

  • a clean, RESTful framework
  • CRUD: a module to simplify editing of model objects
  • Secure: a module to enable simple user authentication
  • a validation framework based on annotations
  • JSON and XML parsers and marshallers
  • a persistence layer based on JPA
  • an embedded database for quick deployment/testing purposes
  • a full embedded testing framework
  • an automatic file uploads functionality
  • multi-environment configuration awareness
  • a modular architecture, which enables bringing new features in the core easily
  • OpenID and web services clients

Also nicht ganz so umfangreich wie JEE, aber mehr als genug für die meisten Anwendungsfälle, und leidet nicht unter dem “Not Invented Here” Syndrom.


#7

Ich sehe da leider nicht, was jetzt besser sein soll. Mit einem Wildfly-Swarm bin ich sehr schnell mit dem web-profile unterwegs.

Und was die Hersteller der Frameworks dokumentieren und was man nachher wirklich nutzen kann, sind meist unterschiedliche Dinge.

Hast Du damit denn Erfahrungen machen können? Vielleicht in einem großen verteiltem Umfeld?


#8

Ich habe damit nur etwas rumgespielt, fand es aber ziemlich bequem (auch dank Unterstützung von IDEA).

Im Job haben wir ganz langweilig Spring und Hibernate.


#9

Wieso sollte man EE nicht mehr brauchen? Es ist ua auch ein “Bollwerk” gegen MS. Auch wenn das für viele kein Grund ist, EE einzusetzen.


#10

Ein Artikel mit ziemlichen Bias, aber ich stimme trotzdem vielem zu:

https://networknt.github.io/light-4j/architecture/jee-is-dead/

Man muss meiner Meinung nach nicht unbedingt alles auf Microservices runterbrechen, aber die Zeit der Monolithen ist wirklich vorbei. Javas Versprechen “write once, run everywhere” wird von JEE-Webservern gebrochen, man ist dort genauso eingesperrt und abhängig, wie man es in der M$-Welt wäre.


#11

Inwiefern? JEE-Container laufen doch auf allen Umgebungen, auf denen Java läuft? Und da diese mittlerweile auch in ein Jar gebundelt werden können, stimmt die Aussage doch.


#12

Auch etwas biased.
Normalerweise reicht ein Rest-Endpoint und die Möglichkeit statisches HTML+JS+CSS auszuliefern. Bei Microservice-Architektur auch mehrere.

Das schaffen heute alle. Das sage ich nicht nur weil ich React oder Angular toll finde im Gegensatz zu server-rendering, sondern weil man da alles dranflanschen kann. Desktop (Swing, JavaFX, SWT, Native, Commandline), Mobil (Android, iOS) oder eben HTML und Hybride wie Electron.

Aus diesem Standpunkt können alle anderen JEE das Wasser reichen.

Entscheidend sind also andere Dinge, finde ich genügend Entwickler die sich damit auskennen, wie stabil ist die Api. Werden Bugs beseitigt. Wird weiterentwickelt. Wie ist die Dokumentation. Wie schnell/effizient lassen sich mit dem gegebenen Team Anwendungen entwickeln.

Da fallen viele kleine und leichtgewichtige Geschichten weg, weil einfach zu klein oder noch zu wenig Historie vorhanden ist um das zu beurteilen. So bleiben noch JEE und Spring übrig.

Speicherverbrauch ist mit dem was heute zur Verfügung steht fast schon zu vernachlässigen, zumindest der Overhead den der Appserver mit sich bringt. Anwendungslogik braucht natürlich immer Speicher und je mehr zur Verfügung steht, desto mehr wird auch vereinnahmt anstatt den GC zu überanspruchen.

Bei der Performance stellt sich auch immer die Frage, ob dies der wichtigste Punkt ist und ob Java dann überhaupt die richtige Antwort ist. Geht man von Business-Anwendungen aus, dann liegt der Fokus auf Geschäftslogik und wie diese implementiert werden kann.

JEE ist zumindest insoweit stabil, solange man nicht Herstellerspezifische Sachen des Application Servers verwendet. Zumal es sich so langsam zu einer Best-Practice entwickelt, den Application Server zu Bundeln oder ein fertiges Docker-Image zu deployen.

Mit neuen Features kann gerechnet werden, erst recht, wenn die Abhängigkeit zu Oracle geringer wird. Genauso mit besserer Performance, wenn man eine “alte” Anwendung, auf einem “modernen” Server deployen kann. WebSocket-Support zum Beispiel ab JEE7.


#13

fixed… :slight_smile:


#14

AFAIGoogled
Java Api for WebSocket 1.0 in JEE7, 1.1 in JEE8

Der Unterschied liegt lediglich darin begründet, dass es zwei zusätzliche Methoden gibt einen MessageHandler hinzuzufügen, der eben auch als Lambda definiert sein kann.


#15

Ja, das stimmt. Vollumfänglich im JEE Stack (als mit JSF) ist dieses Feature allerdings erst mit JEE 8 verfügbar.


#16

Ich habe noch keine größere JEE-Anwendung gesehen, die ohne Probleme von einem JEE-Webserver auf einen anderen umziehen konnte. Irgendwo wird immer etwas herstellerspezifisches verwendet, oder etwas programmiert, was man laut Standard nicht machen sollte, aber auf “seinem” Webserver so läuft. Mag sein dass mein Wissen diesbezüglich etwas veraltet ist (weil ich JEE scheue wie der Teufel das Weihwasser), aber auf der anderen Seite habe ich die JEE-Funktionalität auch nie vermisst.


#17

Aber “write once, run everywhere” bezieht sich auf Java und nicht auf das laufen in unterschiedlichen AppServern. Diese laufen nämlich überall, wo auch Java läuft.


#18

Aber im Endeffekt läuft es darauf hinaus, dass ich Java-Code habe, der - ohne wirklich überzeugenden Grund - eine sehr spezifische Umgebung benötigt.


#19

< offtopic >
Man verzeihe bitte meine Unkenntnis (ich hacke hauptsächlich in C auf eingebetten Systemen herum, bin hier also eigentlich fachfremd), aber zum Verständnis der Debatte möchte ich mal kurz nachfragen: Gibt es denn etwas das man mit JEE gar nicht/nur unzureichend/nur mit unverhältnismäßigem Aufwand für die Beteiligten realisieren kann? Oder kann man alles, für das man mal JEE benötigte, heute auch einfacher erreichen?
JEE ist immerhin eine Art Standard, der auch von einem unbedarften Anwender vergleichweise leicht bereit gestellt werden kann. Gibt es mittlerweile “bessere” (für alle Beteiligten, nach welchen Kriterien auch immer…) Alternativen zu diesem Standard?
< /offtopic >


#20

Das sehe ich anders. Wenn Du Dich an die Spec hältst und keine propritären Dinge des AppServers nutzt ist schon länger der Server auch wechselbar. Davon ab, ist dies meist einfach nicht nötig, weil der Server eben auf allen Umgebunden läuft.
Und natürlich benötigt der Enterprise-Java-Code auch eine spezifische Umgebung. Das benötigt Spring auch. Das benötigt auch eine Node-Lösung. Ich glaube kaum, dass Du einen REST-Service mit Java Boardmitteln bereitstellst, oder?

Bis auf den Bereich des Testens (der in JEE wirklich schwierig ist, wie ich finde) kannst Du damit alles erreichen. Mit den neuen gebundelten Servern (wie Wildfly swarm) bist Du auch schnell dabei. Aber es kommt immer auch die Anforderung und die Skills des Teams an, wie schnell Du bist.