Was ist JavaEE?

[[unsichtbar]]

Das einzige, das ich aus so vielen Internetseiten, die ich durch Google gefunden hab, herauslesen konnte, ist, dass JavaEE-Programme im Unterschied zu "SE's" auch über Webbrowser ausgeführt werden können.

Da das mir eine noch SEEEHR grobe Beschreibung dessen, was JavaEE wirklich ist, zu sein scheint, suche ich in meiner Not Rat bei Experten, was das denn nun ist oder wo ich etwas wirklich hilfreiches zu lesen finden kann.

Ich hoffe, dass ich mich jetzt für meine Inkompetenz schämen muss - o.ä..

 

[MQue]

unter Java2EE fallen die ganzen Java- Web- sachen: EJB, Spring, JMS, Enterprise Java Bus (EJB), usw.
Java2EE ist also ein weites gebiet, in diese Richtung würde ich mal mit JSP's (veraltet aber gut fürs verständnis), Servlets anfangen.
Dann weiter mit EJB3.0, Spring usw.

 

[Deadalus]

unter Java2EE fallen die ganzen Java- Web- sachen: EJB, Spring, JMS, Enterprise Java Bus (EJB), usw.
Java2EE ist also ein weites gebiet, in diese Richtung würde ich mal mit JSP's (veraltet aber gut fürs verständnis), Servlets anfangen.
Dann weiter mit EJB3.0, Spring usw.

Sorry nein, nein, und nein!

1. Das ganze heißt mittlerweile JEE ich kauf mir heute auch kein Raider mehr an der Tanke.
2. Spring hat nichts absolut gar nichts mit der JEE zu tun!
3. EJB heißt Enterprise Java Beans und EJB 3.0 ist alt 3.1 ist aktuell.
4. JSP's? willst du ihn abschrecken oder soll er was lernen? In modernen JEE Anwendungen haben JSP's nichts zu suchen.

So nun zum Threadstarter:

Die Java Enterprise Edititon ist eine standardisierte Sammlung von Spezifikationen für Frameworks, die die Entwicklung verteilter Anwendungen erleichtern sollen.

Implementiert man nun all diese Spezifikationen und schürt sie zusammen erhält man einen JEE Applikationsserver. Wie zum Beispiel GlassFish oder JBoss. (Tomcat ist kein vollständiger Application Server, da er nur teile der JEE enthält)

Willst du JEE lernen empfehle ich dir folgendes:

Lade dir Netbeans herunter, die zurzeit beste IDE für JEE Entwicklung (Eclipse hat im JEE bereich noch einiges aufzuholen). GlassFish 3 wird direkt mit installiert.

Starte mit diesem Tutorial:

Getting Started with Java EE 6 Applications
Das ganze gibt es auch als Video:
Video of Getting Started with Java EE 6 Applications


und wenn ausführlicher werden soll:
- The Java EE 6 Tutorial

Auch gut: Was ist Javascript und Java - https://www.java-forum.org/thema/was-sind-javascript-und-java-ee.132516/ & Unterschied zwischen Java EE und Java SE https://www.java-forum.org/thema/exakte-unterschied-zwischen-java-ee-und-java-se.131484/

 

[MQue]

1. Das ganze heißt mittlerweile JEE ich kauf mir heute auch kein Raider mehr an der Tanke.
2. Spring hat nichts absolut gar nichts mit der JEE zu tun!
3. EJB heißt Enterprise Java Beans und EJB 3.0 ist alt 3.1 ist aktuell.
4. JSP's? willst du ihn abschrecken oder soll er was lernen? In modernen JEE Anwendungen haben JSP's nichts zu suchen.

Freud mich für dich, dass du da auch deinen Senf dazugeben konntest.
2. Spring ist ein Framework, welches im unter anderm Java Enterprise Umfeld eingesetzt wird also würd ichs zu JEE dazuzählen -> sollte man sich mit JEE befassen (müssen) kommt man über Spring nicht hinweg.

3. ließ nach und schreib, was in der 3.1 Version alles dazugekommen ist

4. ich hoffe du hast auch in den Klammern gelesen - veraltet aber gut fürs verständnis - ws willst du ihm den Empfehlen als Frontend für den Einstieg - JSF, Flex oder gar Spring MVC, JS ...?

Dann noch auf einen NetBeans- Seite verweisen ist auch stark, 80% der Java- Programme werden mit Eclipse erstellt.

 

[mYst]

Die Java Enterprise Edititon ist eine standardisierte Sammlung von Spezifikationen für Frameworks

Kurze Verständnisfrage:
Die gesamte Servlet Technologie (JSS), JSP, JSF, Struts und JSTL sind Beispiele für solche JEE Frameworks und sind also praktisch Unterthemen von JEE.
Kann man diese Aussage so stehenlassen? Wenn nicht welchen Teil davon?

PS: Ist der Umgang mit JEE ohne Servlets überhaupt möglich?

 

[maki]

Die gesamte Servlet Technologie (JSS), JSP, JSF, Struts und JSTL sind Beispiele für solche JEE Frameworks und sind also praktisch Unterthemen von JEE.

Was soll denn "JSS" sein?

"Servlet Technolgie" ist imho schon ungenau, es handelt sich um die Servlet API, die sich aus der Servlet Spezifikation ergibt.
Die Servlet Spek. & API Teil von JEE.
JSP & JSF bauen auf der Serlvet API auf, kamen auch von SUN (Oracle) bzw. vom JCP, sind auch Teil von JEE.

Struts ist ein Framework für WebApps und baut auf der Servlet & JSP API auf, struts ist aber kein Teil von JEE, sondern einfach nur ein (mittlerweile veraltetes) Framework welches das Leben mit Servelts & JSPs vereinfachen sollte.

JEE ist eigentlich nix weiter als eine Sammlung von Speks und den APIs welche spezifiert wurden, mehr nicht.
Die Implementierungen dieser API kommen meist von anderen "Unternehmen", Tomcat zB. implementiert die Servlet & JSP API (und einige mehr), war früher sogar sie Referenzimplementierung, heute ist es GlassFish.

Die Speks. & APIs kann man sich beim JCP runterladen, die Implementierungen kommen von verschiedenen "Unternehmen".

Die "Garantie" wenn man so will war eben, dass Sun (Oracle) bzw. das JCP die Spezifikation & APIs erstellt und (früher fast ausschliesslich kommerzielle) Hersteller Implementierungen liefern, als Entwickler musste man sich nur an den Standard, die Spezifikation, halten, und theoretisch wäre deine Enterprise App auf jedem verfügbaren JEE Server ohne Änderung gelaufen.

PS: Ist der Umgang mit JEE ohne Servlets überhaupt möglich?

JEE ist nicht gleich Web

Klar, JEE denifiert viele APIs, nicht alle haben etwas mit WebApps zu tun.
Man kann EJBs nutzen ohne WebApp, genauso JPA, etc. pp., genau das macht JEE so unübersichtlich & komplex, dutzende und aberdutzende APIs werden da festgelegt.

 

[mYst]

Danke maki.

Was soll denn "JSS" sein?

In dem Wikipediaartikel zu JavaEE steht für die Servlet API die Abkürzung JSS.

 

[ARadauer]

4. ich hoffe du hast auch in den Klammern gelesen - veraltet aber gut fürs verständnis - ws willst du ihm den Empfehlen als Frontend für den Einstieg - JSF, Flex oder gar Spring MVC, JS ...?

Ich bin auch der meinung, man solle es mal gesehen haben...

 

[maki]

Danke maki.

In dem Wikipediaartikel zu JavaEE steht für die Servlet API die Abkürzung JSS.

Aber nur in der deutschen Version, ich persönlich höre das zum ersten mal, obwohl ich schon 2001 an WebApps mit Servlets gearbeitet habe (JSPs gab es damals noch nicht wirklich).

 

[Deadalus]

Freud mich für dich, dass du da auch deinen Senf dazugeben konntest.
2. Spring ist ein Framework, welches im unter anderm Java Enterprise Umfeld eingesetzt wird also würd ichs zu JEE dazuzählen -> sollte man sich mit JEE befassen (müssen) kommt man über Spring nicht hinweg.

3. ließ nach und schreib, was in der 3.1 Version alles dazugekommen ist

4. ich hoffe du hast auch in den Klammern gelesen - veraltet aber gut fürs verständnis - ws willst du ihm den Empfehlen als Frontend für den Einstieg - JSF, Flex oder gar Spring MVC, JS ...?

Dann noch auf einen NetBeans- Seite verweisen ist auch stark, 80% der Java- Programme werden mit Eclipse erstellt.

Hör mal das ist wirklich nicht böse gemeint aber du hast keine Ahnung was die JEE ist. Bitte lies den Wikipedia Artikel. Zu dein Punkten:

2. Nein nein nein und nochmal nein! Spring ist ein proprietäres Framework einer einzelnen Firma und nur weil man damit Enterprise Anwendungen in Java entwickeln kann ist es kein Bestandteil der JEE. Es kann sogar als die Konkurrenz zur JEE angesehen werden.

3. Ich weiß was genau dazu gekommen ist und das war definitiv kein Enterprise Bus.

4. Natürlich JSF , da im JEE Standard seit Version 5 JSF nun mal die vorgesehene View Technologie ist. Alle anderen Frameworks die du aufgezählt hast haben wiederum nichts mit der JEE zu tun.

Oh noch eine Sache wegen Netbeans. Für moderne JEE Entwicklung ist Netbeans Eclipse um Welten voraus.

Klar wenn man genug Plugins nachträglich installiert geht es auch mit Eclipse aber das ist was für Leute die unbedingt Eclipse benutzen wollen/müssen. Anfänger sollte man damit wirklich nicht quälen. Und nochmal ich rede hier ausschließlich von JEE Entwicklung.

Kurze Verständnisfrage:
Die gesamte Servlet Technologie (JSS), JSP, JSF, Struts und JSTL sind Beispiele für solche JEE Frameworks und sind also praktisch Unterthemen von JEE.
Kann man diese Aussage so stehenlassen? Wenn nicht welchen Teil davon?

PS: Ist der Umgang mit JEE ohne Servlets überhaupt möglich?

Du mischt mehrere Sachen. Struts ist ein Framework und kein Bestandteil der JEE!

JSP und JSF sind Spezifikationen und Teil der JEE (Ein PDF und ein paar API's). Um die Spezifikationen zu benutzen muss diese jemand Implementieren. Diese Implmentierung nennt man dann Framework.

Als Beispiel: JSF ist eine Spezifikation der JEE. Die bekannteste Implementierung ist Mojarra von Oracle (Sun) aber es existieren auch weitere Implementierungen zum Beispiel MyFaces von Apache. Wenn du eine JSF Anwendung entwickelst kannst du nun frei entscheiden welche JSF Implementierung du verwenden willst.

Ich bin auch der meinung, man solle es mal gesehen haben...

Stimme dir zu aber bitte nicht für einen Anfänger als 1. Beispiel aussuchen

 

[MQue]

Einem Anfänger zu Netbeans zu raten finde ich fahrlässig deshalb schreib ich noch ein letztes mal was zu diesem Thread.
Wenn man Eclipse verwendet, dann entscheidet man sich für ein Open-Source Produkt, was bei Netbeans nicht der Fall ist (und Java- Programmierer haben nun mal einen gewissen Freiheitsgedanken, wäre das nicht der Fall, würde man sich ja für die MS Welt entscheiden) - ich stimme zu, das NetBeans seine Vorteile hat aber versuch mal ein Web- Projekt in Netbeans und dann in Eclipse zu Strukturieren/Modularisieren - dann wirst zu die vorzüge von Eclipse mit seinen Plugins verstehen.

Und noch was: über JEE zu schreiben und Spring außen vor zu lassen find ich auch fahrlässig.
Auf die Unterschiede zwischen EJB3.0 und 3.1 warte ich noch immer - google nochmal.

 

[Deadalus]

Einem Anfänger zu Netbeans zu raten finde ich fahrlässig deshalb schreib ich noch ein letztes mal was zu diesem Thread.
Wenn man Eclipse verwendet, dann entscheidet man sich für ein Open-Source Produkt, was bei Netbeans nicht der Fall ist (und Java- Programmierer haben nun mal einen gewissen Freiheitsgedanken, wäre das nicht der Fall, würde man sich ja für die MS Welt entscheiden) - ich stimme zu, das NetBeans seine Vorteile hat aber versuch mal ein Web- Projekt in Netbeans und dann in Eclipse zu Strukturieren/Modularisieren - dann wirst zu die vorzüge von Eclipse mit seinen Plugins verstehen.

Und noch was: über JEE zu schreiben und Spring außen vor zu lassen find ich auch fahrlässig.
Auf die Unterschiede zwischen EJB3.0 und 3.1 warte ich noch immer - google nochmal.

Sag mal wo holst du deine Informationen her? Das grenzt ja schon an FUD:

Netbeans ist 100% OpenSource. Du darfst sogar zwischen 2 anerkannten OpenSource Lizenzen wählen. CDDL und GPL 2.

Und nun zum letzten mal Spring ist ein proprietäres Framework und wird mit keinem Wort innerhalb der Java Enterprise Edition Spezifikation erwähnt. Spring und die ganzen Frameworks drumherum sind die Konkurrenz zur JEE.

So und nun extra für dich ein paar Unterschiede von EJB 3.0 zu 3.1

klick mich
und ja es ist der 1. Link!

 

[tfa]

Und nun zum letzten mal Spring ist ein proprietäres Framework

Spring ist genauso viel oder wenig proprietär wie EJB oder Java.

 

[Deadalus]

Spring ist genauso viel oder wenig proprietär wie EJB oder Java.

Vorsicht das Wort "proprietär" hat mehrere Bedeutungen:

Man bezeichnet im IT-Bereich traditionell solche Dateiformate, Protokolle usw. aber auch Hardware als proprietär, die nicht allgemein anerkannten Standards entsprechen, also sozusagen „hauseigene“ Entwicklungen sind (Beispiele sind die Cisco VoIP-Telefone mit Skinny-Protokoll und die Software Skype).

Proprietär ? Wikipedia

Wenn ich sage, dass Spring proprietär ist meine ich, dass es auf keinem einheitlichen Standard aufbaut, nicht dass es unter einer proprietären Lizenz steht.

-> Spring ist also properitär, da es ein "hauseigenes" Framework der Firma Springsource ist.
-> EJB ist nicht proprietär da es ein anerkannter Standard ist.

 

[Noctarius]

Wenn ich sage, dass Spring proprietär ist meine ich, dass es auf keinem einheitlichen Standard aufbaut, nicht das es unter einer proprietär Lizenz steht.

EJB ist ein anerkannter Standard und deswegen nicht proprietär.

So würde ich das proprietär bei Spring auch definieren, dummerweise kann Spring aber mit fast allen JSR's aus dem JEE Umfeld umgehen ;-)

Trotzdem muss ich einigen der Vorredner Recht geben, klar ist Spring im Enterprise Bereich extrem weit verbreitet (zum Glück meiner Meinung nach) und man sollte es auch definitiv kennen aber trotzdem hat Spring selber nichts mit dem eigentlichen JEE Standard gemein, außer das Spring die ganzen Annotations und so trotzdem nutzen kann (neben seinen eigenen).

 

[tfa]

Ich versteh nicht, was dieses Herumgereite auf Standards soll. Java ist auch kein Standard, sondern "proprietär". In sofern müsste man C oder C++ oder gleich C# nehmen. Das sind "Standards".
Fakt ist, dass EJB3.0 ohne Spring undenkbar wäre. Warum sollte man nicht gleich das Original verwenden, wenn den Zweck gut erfüllt um am Markt die größte Verbreitung hat?

 

[Noctarius]

Weil die Frage nun mal lautet "Was ist JavaEE?" und das ist nun mal kein Spring

 

[tfa]

Weil die Frage nun mal lautet "Was ist JavaEE?" und das ist nun mal kein Spring

OK, ich war off-topic

 

[Deadalus]

Ich versteh nicht, was dieses Herumgereite auf Standards soll. Java ist auch kein Standard, sondern "proprietär". In sofern müsste man C oder C++ oder gleich C# nehmen. Das sind "Standards".
Fakt ist, dass EJB3.0 ohne Spring undenkbar wäre. Warum sollte man nicht gleich das Original verwenden, wenn den Zweck gut erfüllt um am Markt die größte Verbreitung hat?

Alles was im Rahmen eines Java Community Processes entsteht ist ein freier und anerkannter Standard.
The Java Community Process(SM) Program

EJB ohne Spring macht übrigens sehr wohl sinn.
Spring wurde ja gerade erschaffen, weil die Leute mit dem damaligen EJB Standard unzufrieden waren. Ich denke mal in dem meisten Projekten, die Spring verwenden wird kein EJB Container eingesetzt.
Natürlich kann man das kombinieren, aber mittlerweile ist das meistens nicht mehr nötig, da die JEE mit CDI und co. eigentlich auch "fast" alles kann was vorher nur mit Spring möglich war.

 

[tfa]

Alles was im Rahmen eines Java Community Processes entsteht ist ein freier und anerkannter Standard.

Genau. Die Sache ist eben eine Frage der Defnition bzw. Konvention. Wenn ich sage, in meinem Projekt/meiner Firma ist Spring Standard, dann ist das genauso gut, wie EJB zum Standard zu erheben.

Spring wurde ja gerade erschaffen, weil die Leute mit dem damaligen EJB Standard unzufrieden waren.

Genau das meinte ich mit, "EJB3 ist undenkbar ohne Spring".

 

[Deadalus]

Genau. Die Sache ist eben eine Frage der Defnition bzw. Konvention. Wenn ich sage, in meinem Projekt/meiner Firma ist Spring Standard, dann ist das genauso gut, wie EJB zum Standard zu erheben.

Nein eben nicht. Beim JCP handelt es sich um einen Standard weil viele große Firmen und Organisationen gemeinsam demokratisch in einem Komitee über einen Standard entscheiden. Nur wenn mehrheitlich beschlossen wurde, das ein Vorschlag gut ist wird er zu einem Standard erklärt.
Hier die Liste der Mitglieder des JCP's: The Java Community Process(SM) Program - Participation - Overview:Getting Involved


Wenn alles von einer Firma diktiert wird kann nicht von einem Standard geredet werden. -> Spring

Genau das meinte ich mit, "EJB3 ist undenkbar ohne Spring".

Spring wurde entwickelt, weil die Leute unzufrieden mit EJB 2 waren und wird in der Regel nicht als Ergänzung zu EJB sondern als kompletter Ersatz verwendet.

EJB 3.* ist eigentlich alle seine bisherigen Schwächen los und es macht richtig Spaß damit zu arbeiten. Spring braucht man dazu nicht.

 

[tfa]

Ja, das hatten wir alles schon. Das ist mir hinlänglich bekannt.

Aber egal. Mal anders gefragt: Was ist denn der Nachteil eines "Nicht-Standards" (wie z.B. Spring) verglichen mit einem Standard (wie z.B. EJB)?

 

[maki]

Nein eben nicht. Beim JCP handelt es sich um einen Standard weil viele große Firmen und Organisationen gemeinsam demokratisch in einem Komitee über einen Standard entscheiden. Nur wenn mehrheitlich beschlossen wurde, das ein Vorschlag gut ist wird er zu einem Standard erklärt.

Offensichtlich weisst du nicht wirklich wie das JCP funktioniert.
Ich will die ja deine Begeisterung nicht nehmen, aber es macht keinen Unterschied ob etwas vom JCP zum Standard erhoben wurde oder nicht.

Beispiel Hibernate: Hibernate ist einerseits damit groß geworden einerseits kostenlos zu sein, anderseits keine (!) Standardimplementierung zu sein.

Warum Hibernate nun einen Standard (JPA) implementiert und was aus dem alten Standard JDO geworden könntest du auch selber rausfinden, nur soviel: IBM & Oracle haben JDO abgesetzt weil sie dagegen waren dass man keine RDBMS mehr braucht, JDO konnte schon vor Jahren womit heute noch die meisten JPA Implementierungen Probleme haben. Apache hat JDO "gerettet", nicht das JCP mit seinen angeblich demokratischen Strukturen (LMFAO).

Dieses ständige Pseudoargument "Standards sind gut, alles andere nicht" ist nichts weiter als Propaganda (FUD) von diesen ach so großen Demokraten...
Spring war schon immer gut, ob standartisiert oder nicht ist vollkommen egal, ausser du bist Vertriebler für IBM/Oracle oder irgendeinen anderen großen Mitspieler

Als Techniker muss man einsehen, dass Spring 'ne gute Sache ist und heute immer noch einen Platz in JEE hat, irgendwoher muss die JCP "Mafia" ja ihre Ideen klauen

Anderen Mist hat das JCP schon mit JSF & anderen Standards verbrochen...

 

[Deadalus]

1. Höhere Akzeptanz & Verbreitung

Von einem internationalen Standard kann man ausgehen, das er auch in ein paar Jahren noch bestand hat. Für Hochschulen macht es daher zum Beispiel mehr Sinn ihre Studenten in Standards zu unterrichten, als ihnen den Umgang mit proprietäre Frameworks beizubringen.

2. Austauschbare Implementierungen

Die JEE Spezifikationen haben den Vorteil, dass man die Implementierungen dahinter austauschen kann, ohne Code ändern zu müssen.
Merke ich Hibernate ist schneller als Eclipselink wechsele ich den JPA Provider mit einer Zeile Konfiguration und meine Anwendung läuft!

Auch der Container kann gewechselt werden. So kann ich meine JEE Anwendungen auf jedem zertifizierten JEE Server laufen lassen.

3. Zukunftssicherheit
Wenn SpringSource bankrott gehen sollte wird es das mit großer Wahrscheinlichkeit für Spring gewesen sein. Passiert das im JEE Umfeld nimmt man sich einfach eine andere Implementierung des einen Frameworks und man kann weiter machen.


JEE Anwendungen sind natürlich auch viel kleiner als Spring Anwendungen, da die Dependencys ja auf dem JEE Server verfügbar sind und deshalb nicht mit in das .Ear gepackt werden müssen.

 

[maki]

1. Höhere Akzeptanz & Verbreitung

Von einem internationalen Standard kann man ausgehen, das er auch in ein paar Jahren noch bestand hat. Für Hochschulen macht es daher zum Beispiel mehr Sinn ihre Studenten in Standards zu unterrichten, als ihnen den Umgang mit proprietäre Frameworks beizubringen.

Das ist Quatsch, Spring hat jetzt schon einige dieser tollen Standards überlebt, siehe JSP.

2. Austauschbare Implementierungen

..
Merke ich Hibernate ist schneller als Eclipselink wechsele ich den JPA Provider mit einer Zeile Konfiguration und meine Anwendung läuft!
...

Ja klar, das geht auch mit Spring

Die JEE Spezifikationen haben den Vorteil, dass man die Implementierungen dahinter austauschen kann, ohne Code ändern zu müssen.
..
Auch der Container kann gewechselt werden. So kann ich meine JEE Anwendungen auf jedem zertifizierten JEE Server laufen lassen.

Offensichtlich hast du das noch nie gemacht, sonst wüsstest du dass "ohne Code ändern zu müssen" nicht stimmt, ausser du hast eine minimal Anwendung.

3. Zukunftssicherheit
Wenn SpringSource bankrott gehen sollte wird es das mit großer Wahrscheinlichkeit für Spring gewesen sein. Passiert das im JEE Umfeld nimmt man sich einfach eine andere Implementierung des einen Frameworks und man kann weiter machen.

*Gähn*
Spring ist OpenSource und damit ist egal was mit SpringSource passiert.

JEE Anwendungen sind natürlich auch viel kleiner als Spring Anwendungen, da die Dependencys ja auf dem JEE Server verfügbar sind und deshalb nicht mit in das .Ear gepackt werden müssen.

Du machst Witze....

 

[tfa]

1. Höhere Akzeptanz & Verbreitung

Wenn man sich die Geschichte von EJB(2.x) und Springframework ansieht, dieser Punkt geradezu absurd. Hier ist genau das Gegenteil eingetreten. Die Leute achten nicht auf Standard oder Nichtstandard, sondern auf Qualität.

2. Austauschbare Implementierungen

Die JEE Spezifikationen haben den Vorteil, dass man die Implementierungen dahinter austauschen kann, ohne Code ändern zu müssen.
Merke ich Hibernate ist schneller als Eclipselink wechsele ich den JPA Provider mit einer Zeile Konfiguration und meine Anwendung läuft!

Du weißt, dass Hibernate kein Standard war und sich JPA erst (u.a.) aus Hibernate heraus entwickelt hat? Siehe Beitrag von maki. Einige Hibernate-Features, die noch nicht in JPA sind, sollen übrigens mal "standardisiert" werden.

Wenn SpringSource bankrott gehen sollte wird es das mit großer Wahrscheinlichkeit für Spring gewesen sein.

Warum um Himmelswillen? Das ist Opensource. Es gibt viele Organisationen, die das weiter treiben können. Was passiert wohl, wenn Oracle pleite geht? Gibt's dann kein Java mehr? (OK, die politisieren das eher kaputt)

 

[Deadalus]

Ok da das jetzt zu einem Glaubenskrieg ausartet hier nochmal ganz kurz meine Meinung:

• Spring ist ein tolles Framework!
  
• Spring wäre nie entstanden, wenn der damalige J2EE Standard nicht komplett besch.. gewesen wäre.
  
• Es gibt keine alternative Implementierung zu Spring daher ist das Spring Framework nicht austauschbar.
  
• Große OpenSource Projektelassen sich nicht einfach ohne weiteres durch die Community weiterführen, wenn der Hauptsponsor bankrott geht.
  
• Der JEE Standard hat mit den Verbesserungen für JEE 5 gerade noch die Kehrtwende bekommen.
  
• Der JDO Standard ist und war allgemein verpönt da er zu komplex und nicht Pojo basierend war.
  
• Bewährte Ideen von proprietären Frameworks anzuschauen und in den JEE Standard einfließen zu lassen ist eine gute Praxis
  
• Solange gegen die Spezifikation programmiert wird bleiben JEE Anwendungen portabel.
  
• JEE Anwendungen sind nicht kleiner was der Code angeht.
  
• Aber die zu deployenden Archive sind physikalisch kleiner, die die Frameworks im Gegensatz zu Spring Anwendungen nicht mit in das Archiv gepackt werden sondern schon vom Container bereitgestellt werden.

 

[Noctarius]

So ich denke die Diskussion war lang genug, ob ein EAR jetzt kleiner ist weil die JARs schon im Container liegen oder ob ich meine Spring-JARs ins Tomcat Verzeichnis lege, damit diese für alle Apps verfügbar sind und nicht mit deployed werden müssen, sollte egal sein.

Daher bevor der Flamewar ausartet - ~closed~

edit: Es sollte heißen "Daher bevor es in einen Flamewar ausartet" - sorry für die scheiss Wortwahl