# Java EE vs. Spring/Hibernate



## deamon (30. Jun 2008)

Hallo,

die Motivation für Spring waren die Mängel von J2EE, allen voran den Mängeln von EJB 2. Nun gibt es EJB 3, das ebenfalls auf Pojos und Depency Injection setzt. Auch wenn man Spring und Java EE vielleicht nicht in allen Bereichen vergleichen kann, verfolgen sie doch das gleiche große Ziel, nämlich den Entwickler bei der Erstellung von komplexen Geschäftsanwendungen zu unterstützen.

Nachdem ich den Artikel http://www.devx.com/Java/Article/32314/0/page/1 gelesen habe, erscheint mir EJB einfacher und eleganter, wenn auch etwas weniger flexibel. Man braucht bei EJB weniger (XML-)Konfiguration als bei Spring/Hibernate, die Transaktionsunterstützung scheint etwas eleganter zu sein, Skalierbarkeit kann mit einem Java-EE-Server scheinbar leichter erreicht werden und es gibt auch einen Standard für Authentifizierung und Autorisierung. Bei Spring benutzen vielleicht die meisten Spring Security (Acegi), was aber auch kein Standard ist.

Besser gefällt mir bei Spring aber, dass es sowas wie das Unterprojekt Spring MVC für Webanwendungen gibt. Da gibt es bei Java EE aus meiner Sicht nichts direkt vergleichbares. JavaServer Faces kümmert sich z. B. um die Validierung der Benutzereingaben., die aber eigentlich nichts in der Präsentationsschicht verloren hat. Außerdem mag ich JSF noch aus anderen gründen nicht und würde es in einem Projekt nicht einsetzen wollen. Aber dann hätte man bei einer Java-EE-Anwendung keine Framework-Unterstützung bei der Validierung.

Was spricht aus eurer Erfahrung für und gegen Spring bzw. Java EE?


----------



## ps (1. Jul 2008)

Gefährliches Thema hier. Ich hatte vor kurzem eine ähnlich gelagerte Diskussion losgetreten:
-> http://www.java-forum.org/de/topic70293_ejbs-will-die-alternativen-soa.html


Letztendlich bin ich doch bei EJBs gelandet - der Einfachheit halber und weil meine Anwendung aus Server, Web und Standalone Client besteht. Die IDE Unterstützung ist ausgezeichnet und man kommt recht schnell zu Ergebnissen.
Mit EJB 3.1 wird alles noch leichtgewichtiger und man kann sich die benötigten Teile heraussuchen.

Zum Webframework: JSF erscheint mir auch aus vielen Gründen nicht ideal. Ich benutze Struts2 und habe diese Wahl bisher nicht bereut. Es ist sehr mächtig - wenn man ein Actionbasiertes MVC Framework sucht sollte man es sich unbedingt ansehen. Einige Gedanken dazu habe ich vor über einem Jahr niedergeschrieben, das meiste ist auch heute noch gültig: http://blogs.cuetech.eu/roller/psartini/entry/java_webframeworks_die_qual_der
Spring MVC kenne ich allerdings nicht.

Natürlich gibt es ausser JSF noch mehr komponentenbasierte Frameworks: wicket scheint zB. nicht verkehrt zu sein.


----------



## Gast (1. Jul 2008)

Hallo,

Vorsicht vor irgendwelchen Vergleichen "irgendwelcher" Webseiten von irgendwelchen Personen die irgendwelche Versionen vergleichen und sich meist nur in Spring ODER EJB auskennen.

http://www.devx.com/Java/Article/32314/0/page/3

Als Beispiel im Bereich Persistence

Table 3. Equivalent Transaction Management Functionality in Both Spring and EJB 3.0.

Feature                                  Spring      EJB 3.0  
Configuration                             XML     Transactional by default, override with annotations or XML 

Das ist FALSCH! Es gibt in Spring die Transactional Annotation mit der das Transactionsverhalten gesteuert werden kann.




> Man braucht bei EJB weniger (XML-)Konfiguration als bei Spring/Hibernate, die Transaktionsunterstützung scheint etwas eleganter zu sein,



Zur Transaktionsunterstuetzung siehe oben.... Desweiteren wuerde ich folgenden Vergleich vorziehen: Spring/JPA im Vergleich zu EJB. Dann kannst du den Persistenceteil einfach streichen, da beide Frameworks die gleiche Spezifikation nutzen. Meine SpringConfig


> <context:annotation-config/>
> 
> <context:component-scan base-package="de" scoped-proxy="targetClass">
> <context:exclude-filter type="annotation" expression="org.springframework.stereotype.Controller"/>
> ...



Finde ich jetzt nicht unbedingt viel. Mit Securtiy, Quartz, MVC wird das natuerlich deutlich mehr.

In Spring 3.0 soll das angeblich auch noch deutlich reduziert werden...



Es bleibt also der "Kern EJB" Bereich im Vergleich zum Spring Universum uebrgig.

Leider kann ich darueber keine Auskunft geben, da mein Wissen ueber EJB sich auf das Querlesen eines EJB Buches beschraenkt und dabei bei mir der Eindruck entstanden ist, dass EJBs immer etwas "hinterherhinken" gegenueber Spring...


Gruesse


----------



## byte (1. Jul 2008)

deamon hat gesagt.:
			
		

> Nachdem ich den Artikel http://www.devx.com/Java/Article/32314/0/page/1 gelesen habe, erscheint mir EJB einfacher und eleganter, wenn auch etwas weniger flexibel. Man braucht bei EJB weniger (XML-)Konfiguration als bei Spring/Hibernate, die Transaktionsunterstützung scheint etwas eleganter zu sein, Skalierbarkeit kann mit einem Java-EE-Server scheinbar leichter erreicht werden und es gibt auch einen Standard für Authentifizierung und Autorisierung. Bei Spring benutzen vielleicht die meisten Spring Security (Acegi), was aber auch kein Standard ist.


Ich finde die Aussage der vermeintlich einfachereren Konfiguration bei EJB gegenüber Spring etwas trügerisch. Der größte Unterschied zwischen Spring und EJB ist erstmal, dass Spring ein Framework ist, während EJB eher als Plattform zu verstehen ist. Ich halte die korrekte Konfiguration eines Application Servers wie Websphere für den produktiven Einsatz wesentlich aufwändiger als das konfigurieren von Spring-Beans. Letzteres erfolgt nach einem einfachen Prinzip und geht - auch wenn ich selbst beileibe kein Freund von XML Konfigurationen bin - recht einfach von der Hand, zumal es gute IDE-Integration gibt (z.B. Spring IDE für Eclipse).



> Was spricht aus eurer Erfahrung für und gegen Spring bzw. Java EE?


Wie oben schon geschrieben, ist für mich der große Vorteil von Spring, dass das Framework sehr flexibel ist, wie man die Services bereit stellt. Es stellt keine Vorraussetzungen an die eingesetzte Infrastruktur. Es ist ohne weiteres möglich, Spring Services Remote über RMI, Tomcat oder einen Application-Server bereit zu stellen. Bei EJB bin ich auf einen Application-Server angewiesen. Solange der Application-Server tatsächlich Aufgaben für mich übernimmt, ist das eine gute Sache, häufig ist das aber eben nicht der Fall, denn Spring deckt einen Großteil dessen ab, was EJB und der Application-Server kann.
Häufig fällt in dem Zusammenhang dann noch das Argument der Skalierbarkeit, die bei einem Application-Server ja besser sei. Auch dafür brauche ich aber keinen Application-Server, es sei denn ich brauche verteilte Transaktionen oder dergleichen. Auch mit einem einfachen Tomcat kann man Skalierbarkeit problemlos mittels Load Balancing erreichen.

Aber letztlich muss das jeder für sich selbst entscheiden, was er besser findet.

Was das Thema Standard vs Nicht-Standard angeht: Ich finde, dass man das Werkzeug wählen sollte, was für die Erfüllung einer Aufgabe am besten geeignet ist. Natürlich sind Standards schön, aber für micht ist das nicht der ausschlaggebende Faktor.


----------



## ps (1. Jul 2008)

byto hat gesagt.:
			
		

> Der größte Unterschied zwischen Spring und EJB ist erstmal, dass Spring ein Framework ist, während EJB eher als Plattform zu verstehen ist.



Das finde ich jetzt ein bisschen trügerisch - Spring ist ebenso eine Platform und ein Container wie EJB. Ohne diesen läuft nichts. Das ein JavaEE Server einiges mehr mitbringt ist eine andere Sache.. aber auch EJB3 ist schon embeddable und kann zB. einfach in Tomcat integriert werden (zB. OpenEJB).



> Ich halte die korrekte Konfiguration eines Application Servers wie Websphere für den produktiven Einsatz wesentlich aufwändiger als das konfigurieren von Spring-Beans. Letzteres erfolgt nach einem einfachen Prinzip und geht - auch wenn ich selbst beileibe kein Freund von XML Konfigurationen bin - recht einfach von der Hand, zumal es gute IDE-Integration gibt (z.B. Spring IDE für Eclipse).



Das ist richtig - einen AS für den produktiven Einsatz zu konfigurieren ist nicht ohne. Beschränkt man sich aber auf EJBs, ist das IMHO recht simpel. Und für die Entwicklung ist die IDE Unterstützung sowieso ausgezeichnet (eigentlich braucht man genaugenommen garnichts konfigurieren um seine JavaEE Anwendung zú testen)



> Solange der Application-Server tatsächlich Aufgaben für mich übernimmt, ist das eine gute Sache, häufig ist das aber eben nicht der Fall, denn Spring deckt einen Großteil dessen ab, was EJB und der Application-Server kann.



IMHO ist Spring eine weitere Schicht welche mir ausser Komplexität nicht viel anzubieten hat. Da ich JavaEE 4 nicht mitbekommen habe konnte ich auch nie wirklich verstehen welche Daseinsberechtigung es hat 



> Häufig fällt in dem Zusammenhang dann noch das Argument der Skalierbarkeit, die bei einem Application-Server ja besser sei. Auch dafür brauche ich aber keinen Application-Server, es sei denn ich brauche verteilte Transaktionen oder dergleichen. Auch mit einem einfachen Tomcat kann man Skalierbarkeit problemlos mittels Load Balancing erreichen.



Bei einfachen Webanwendungen ist das sicher richtig - aber die Webanwendung ist nicht immer der Mittelpunkt eines Systems.. 



> Aber letztlich muss das jeder für sich selbst entscheiden, was er besser findet.



Weise Worte - letztendlich ist es jedem selbst überlassen. Das ist IMHO übrigens einer der großen Vorteile von Java. Es ist aber auch ein Fluch, weil es die Leute im Regen stehen lässt und man eine Weile braucht sich zu orientieren. Es gibt keine Vorgaben ala: Dieses Problem wird in der Regel so und so gelöst. Es heisst: Wähle eines dieser 4395 Frameworks.


----------



## byte (1. Jul 2008)

ps hat gesagt.:
			
		

> byto hat gesagt.:
> 
> 
> 
> ...


Ohne Container kannst Du aber gewisse Schlüssel-Features von EJB nicht mehr benutzen, wie z.B. Persistenz. OpenEJB schafft das, aber auch nur, weil es eine weitere Schicht auf JPA drauf setzt. Das ist um Grunde das gleiche wie Spring und nicht mehr Standard.



> Das ist richtig - einen AS für den produktiven Einsatz zu konfigurieren ist nicht ohne. Beschränkt man sich aber auf EJBs, ist das IMHO recht simpel. Und für die Entwicklung ist die IDE Unterstützung sowieso ausgezeichnet (eigentlich braucht man genaugenommen garnichts konfigurieren um seine JavaEE Anwendung zu testen)


Das mag sein. Aber spätestens wenn Du die Anwendung für den produktiven Einsatz testen willst (das macht man besser zu früh als zu spät), wirst Du u.U. vom AS erschlagen.



> IMHO ist Spring eine weitere Schicht welche mir ausser Komplexität nicht viel anzubieten hat. Da ich JavaEE 4 nicht mitbekommen habe konnte ich auch nie wirklich verstehen welche Daseinsberechtigung es hat


Daran sieht man, dass Du Dich offenbar nie ernsthaft mit Spring beschäftigt hast.



> > Häufig fällt in dem Zusammenhang dann noch das Argument der Skalierbarkeit, die bei einem Application-Server ja besser sei. Auch dafür brauche ich aber keinen Application-Server, es sei denn ich brauche verteilte Transaktionen oder dergleichen. Auch mit einem einfachen Tomcat kann man Skalierbarkeit problemlos mittels Load Balancing erreichen.
> 
> 
> 
> Bei einfachen Webanwendungen ist das sicher richtig - aber die Webanwendung ist nicht immer der Mittelpunkt eines Systems..


Was hat das bitte mit Webanwendungen zu tun? ???:L Du hast offenbar nicht verstanden, wie das ganze funktioniert. Der HTTP-Verkehr wird hierbei entsprechend verteilt, so dass Du die Last auf beliebig viele Server (Tomcat-Instanzen) verteilen kannst. Es spielt überhaupt keine Rolle, welches Frontend sich verbindet.


----------



## ps (1. Jul 2008)

byto hat gesagt.:
			
		

> Ohne Container kannst Du aber gewisse Schlüssel-Features von EJB nicht mehr benutzen, wie z.B. Persistenz. OpenEJB schafft das, aber auch nur, weil es eine weitere Schicht auf JPA drauf setzt. Das ist um Grunde das gleiche wie Spring und nicht mehr Standard.



EJB hat nicht mehr sehr viel mit der Persistenz zu tun - das wurde in JPA ausgelagert und ist völlig unabhängig. (JPA ist freilich aus EJB3 hervorgegangen...) Hibernate, Toplink Essentials bzw. jetzt EclipseLink, OpenJPA - das läuft alles komplett ohne JavaEE Container. EJBs erlauben es mir nur mittels @PersistenceContext den EntityManager zu "injizieren". Mehr wird an dieser Stelle aber nicht gezaubert.



> Das mag sein. Aber spätestens wenn Du die Anwendung für den produktiven Einsatz testen willst (das macht man besser zu früh als zu spät), wirst Du u.U. vom AS erschlagen.



Das ist wie vieles Ansichtssache. Ich würde von Spring erschlagen werden 



> Daran sieht man, dass Du Dich offenbar nie ernsthaft mit Spring beschäftigt hast.



Das würde ich so nichit behaupten...  provokant ausgedrückt, ein gehypter DI Container um den sich ein ganzes Ecosystem mit allen möglichen Modulen gebildet hat. Diese Module bieten _mir_ aber nichts an, es ist nichts dabei was ich nicht ohne Spring auch hätte.
Würde ich Spring für DI benutzen, wäre es evtl. die logische Wahl auch auf andere Komponenten zurückzugreifen. So aber steigert es nur die Komplexität und meine Abhängigkeiten.

Im Prinzip ist es bei mir meist so: Der Großteil der Anwendung ist sowieso mit POJOs aufgebaut. Das Domainmodell inkl. Geschäftslogik ist möglichst technologieneutral. EJBs wiederum stellen eine sehr dünne Serviceschicht dar.

Das kann ich mit Spring auch so nachbilden - aber wo ist der Vorteil?



> Was hat das bitte mit Webanwendungen zu tun? ???:L Du hast offenbar nicht verstanden, wie das ganze funktioniert. Der HTTP-Verkehr wird hierbei entsprechend verteilt, so dass Du die Last auf beliebig viele Server (Tomcat-Instanzen) verteilen kannst. Es spielt überhaupt keine Rolle, welches Frontend sich verbindet.



achso, du meinst für das Remoting? Da sehe ich eigentlich nicht wieso ich HTTP als Protokoll einsetzen sollte... ausser für Webservices. Manchmal praktisch um an Firewalls vorbeizukommen, aber ich habe das Glück den Admins entsprechende Vorgaben machen zu können.


----------



## byte (1. Jul 2008)

ps hat gesagt.:
			
		

> EJB hat nicht mehr sehr viel mit der Persistenz zu tun - das wurde in JPA ausgelagert und ist völlig unabhängig. (JPA ist freilich aus EJB3 hervorgegangen...) Hibernate, Toplink Essentials bzw. jetzt EclipseLink, OpenJPA - das läuft alles komplett ohne JavaEE Container. EJBs erlauben es mir nur mittels @PersistenceContext den EntityManager zu "injizieren". Mehr wird an dieser Stelle aber nicht gezaubert.


Es ging mir darum, dass man beim JEE-Ansatz auf den Container (AS) angewiesen ist, weil dieser (korrigiere mich, wenn ich falsch liege) für die Transaktionsverwaltung zuständig ist.



> Das ist wie vieles Ansichtssache. Ich würde von Spring erschlagen werden


Spring ist sicher nicht komplexer als EJBs. Zumal man sich immer nur die Module angucken braucht, die einen interessieren.



> Würde ich Spring für DI benutzen, wäre es evtl. die logische Wahl auch auf andere Komponenten zurückzugreifen. So aber steigert es nur die Komplexität und meine Abhängigkeiten.


Ich finde es interessant, dass Du von der Abhängigkeit einer Jar-Datei zurück schreckst, Du offenbar aber kein Problem damit hast, Dich von einem AS-Koloss abhängig zu machen. Da scheint mir letzteres doch wesentlich kritischer zu sein, wenn man sich mal die üblichen Verdächtigen anguckt (Websphere und Konsorten).

Springs DI ist im übrigen Kinderleicht zu verstehen und man braucht es auch nur für die Teile zu verwenden, wo man Spring-Beans braucht. Wir haben hier z.B. einen Swing-Client, der per Spring-Remote auf den Server zugreift. DI wird dort auch lediglich dafür verwendet, um an die Service-Proxies zu kommen. Der Rest des Clients ist Plain Old Java. 



> Im Prinzip ist es bei mir meist so: Der Großteil der Anwendung ist sowieso mit POJOs aufgebaut. Das Domainmodell inkl. Geschäftslogik ist möglichst technologieneutral. EJBs wiederum stellen eine sehr dünne Serviceschicht dar.


Genauso ist es bei uns doch auch. Das Domainmodell ist mit JPA / Hibernate gemappt. Die Services sind POJOs die den Clients per Spring Remote verfügbar gemacht werden. Darüber hinaus unterstützt Spring halt beim Transaktionshandling, bietet hilfreiche Utilities für die DAOs und hilft, Querschnittsbelange per AOP wegzukapseln.



> Das kann ich mit Spring auch so nachbilden - aber wo ist der Vorteil?


Kein AS, wo keiner nötig ist. 
Spring ist nichts weiter als ein Jar, das im Classpath liegt. EJB zwängt mir gleich seine Infrastruktur mit auf.



> achso, du meinst für das Remoting? Da sehe ich eigentlich nicht wieso ich HTTP als Protokoll einsetzen sollte... ausser für Webservices. Manchmal praktisch um an Firewalls vorbeizukommen, aber ich habe das Glück den Admins entsprechende Vorgaben machen zu können.


Das Glück wirst Du in großen Konzernen wohl selten haben. Wir benutzen HTTP wegen Sicherheitsaspekten (Auth. Cookies, HTTPS, ...).


Nachtrag: Es wäre übrigens ganz interessant zu sehen, wo EJB ohne Spring heute wäre. Selbiges trifft auf JPA und Hibernate zu...


----------



## ps (1. Jul 2008)

byto hat gesagt.:
			
		

> Es ging mir darum, dass man beim JEE-Ansatz auf den Container (AS) angewiesen ist, weil dieser (korrigiere mich, wenn ich falsch liege) für die Transaktionsverwaltung zuständig ist.



Ja, das ist schon richtig. Aber macht es wirklich einen unterschied ob Spring mir den JTA Dienst anbietet oder JavaEE? ;-)
Oder benutzt man in einer Spring Applikation dann RESOURCE_LOCAL?



> Spring ist sicher nicht komplexer als EJBs. Zumal man sich immer nur die Module angucken braucht, die einen interessieren.



Das was man (gut) kennt erscheint einem immer wenig komplex zu sein. 



> Ich finde es interessant, dass Du von der Abhängigkeit einer Jar-Datei zurück schreckst, Du offenbar aber kein Problem damit hast, Dich von einem AS-Koloss abhängig zu machen. Da scheint mir letzteres doch wesentlich kritischer zu sein, wenn man sich mal die üblichen Verdächtigen anguckt (Websphere und Konsorten).



Ich finde es interessant das du von Kolossen sprichst. Ich habe in der Tat kein Problem damit mich von einem JavaEE 5 Server abhängig zu machen - Glassfish braucht hier zB. nicht sehr viel länger zum starten als Tomcat. Darüber hinaus bietet es mir viele Vorteile.. ich kann dank der JavaEE Spezifikation sehr viele Dienste ausserhalb meiner Anwendung ändern (Mail Service, Transaktionen, DataSources, Persistence Units, etc).
Bei Spring müsste ich - korrigiere mich bitte wenn ich falsch liege - meine Anwendung neu bauen und deployen. Bei JavaEE weiß die Anwendung von diesen äusseren Umständen nichts (und sollte es IMHO auch nicht müssen).

Mit Java EE 6 und EJB 3.1 wird alles noch mehr aufgesplittet und leichtgewichtiger (durch die Profile). Bei OpenEJB habe ich nur eine WAR Datei von der ich abhängig bin und eben Tomcat. So schlimm finde ich das nicht.



> Springs DI ist im übrigen Kinderleicht zu verstehen und man braucht es auch nur für die Teile zu verwenden, wo man Spring-Beans braucht. Wir haben hier z.B. einen Swing-Client, der per Spring-Remote auf den Server zugreift. DI wird dort auch lediglich dafür verwendet, um an die Service-Proxies zu kommen. Der Rest des Clients ist Plain Old Java.



Ja - im Prinzip geht es hier ja auch nur um eine Technologiefrage. Die Architektur beeinflusst das ja meistens kaum. Am Ende hast du es ja vorhin schon sehr schön gesagt: Es ist eine Frage des persönlichen Geschmacks. 



> Kein AS, wo keiner nötig ist.



Ich bin überzeugt in einer mittelgroßen Anwendung endet man auch mit Spring am Ende bei einem Großteil der APIs welche einen AS ausmachen (Mail API, JMS, JTA, etc)
Mir missfällt diese Lose Sammlung welche per XML zusammengehalten wird - aber wie gesagt: Geschmackssache 



> Nachtrag: Es wäre übrigens ganz interessant zu sehen, wo EJB ohne Spring heute wäre. Selbiges trifft auf JPA und Hibernate zu...



Ja, Spring hat hier sicher einiges an Bewegung hereingebracht. Konkurrenz belebt das Geschäft, siehe Eclipse und NetBeans. Aber oft ist das "alte" nach kurzer Zeit doch wieder vorne weg  
Bei JPA... ich weiß nicht. ORM Mapper haben finde ich jetzt nicht so viel mit Spring zu tun. Mit Toplink und anderen gibt es schon lange sehr gute Lösungen.


----------



## byte (1. Jul 2008)

ps hat gesagt.:
			
		

> Ja, Spring hat hier sicher einiges an Bewegung hereingebracht. Konkurrenz belebt das Geschäft, siehe Eclipse und NetBeans. Aber oft ist das "alte" nach kurzer Zeit doch wieder vorne weg
> Bei JPA... ich weiß nicht. ORM Mapper haben finde ich jetzt nicht so viel mit Spring zu tun. Mit Toplink und anderen gibt es schon lange sehr gute Lösungen.


Soviel zu der Relevanz der Technologien am US Markt:


----------



## ps (1. Jul 2008)

was interessieren mich trends am us markt wenn ich ein problem zu lösen habe? ;-)
btw.. toplink ist einiges älter als hibernate. Toplink Essentials ist die Referenzimplementation für JPA, Toplink, welches von Oracle mittlerweile unter dem Namen EclipseLink komplett freigegeben wurde wird die RI für JPA 2.0

und: glaube nie einer statistik welche du nicht selbst gefälscht hast:


----------



## byte (1. Jul 2008)

ps hat gesagt.:
			
		

> und: glaube nie einer statistik welche du nicht selbst gefälscht hast:



Die ist tatsächlich gefälscht. :applaus: 















			
				ps hat gesagt.:
			
		

> btw.. toplink ist einiges älter als hibernate. Toplink Essentials ist die Referenzimplementation für JPA, Toplink, welches von Oracle mittlerweile unter dem Namen EclipseLink komplett freigegeben wurde wird die RI für JPA 2.0


Ändert aber nichts daran, dass die Relevanz von Toplink am Markt = null ist.


----------



## tfa (1. Jul 2008)

ps hat gesagt.:
			
		

> was interessieren mich trends am us markt wenn ich ein problem zu lösen habe? ;-)


Die Leute am US-Markt haben sicherlich auch alle Probleme zu lösen...

Gibt's so eine Seite auch für den deutschen Markt? Ich hab nur was für UK gefunden:
http://www.jobstats.co.uk/jobstats.d/SKILL.html
(BTW: EJB=0,4%, Spring=1,0%  :wink: )


----------



## byte (1. Jul 2008)

Kenne keine deutsche Seite. Wenn man sich aber mal die reine Anzahl Suchergebnisse anguckt bei jobs.de, dann kommt folgendes raus:

"java spring" : 647
"java ejb" : 459

"java hibernate" : 687
"java toplink" : 8 (lol)


----------



## ps (1. Jul 2008)

byto hat gesagt.:
			
		

> Ändert aber nichts daran, dass die Relevanz von Toplink am Markt = null ist.



Das würde ich so nicht stehen lassen wollen. Wenn du deine Middleware von Oracle beziehst, ist Toplink nicht weit  Und das Oracle keine Relevanz hat - ich weiß nicht.

Davon abgesehen das mit diesem Mapper seit 1994 Anwendungen gebaut werden (erst nur Smalltalk, seit 1998 auch Java). Eine Lösung welche derart lange den Markt dominiert hat ist nicht so einfach totzukriegen und noch vielerorts im Einsatz.

Ich jedenfalls freu mich das ein derart ausgereiftes Produkt nun als OpenSource zur Verfügung steht. Dafür hat man vor einigen Jahren noch richtig Asche hinlegen müssen.

Und zu deinen Jobvergleichen:
Spring mit EJB zu vergleichen ist wie Äpfel und Birnen. J2EE/JavaEE und Spring ist schon wesentlich passender. Beides sind konkurrierende Plattformen. Wenn ich jemanden brauche der JavaEE macht, kann ich davon ausgehen das er EJBs beherrscht. In eine Jobbeschreibung würde ich also nur JavaEE 4/5 schreiben.

[edit: @tfa: sicher haben die auch probleme zu lösen. aber ich löse meine probleme trotzdem mit den werkzeugen welche ich für geeignet halte - und nicht mit dem werkzeug das gerade am meisten eingesetzt wird  
]


----------



## byte (1. Jul 2008)

ps hat gesagt.:
			
		

> byto hat gesagt.:
> 
> 
> 
> ...


Selbst Wikipedia zeigt, wie "wichtig" TopLink offenbar ist: http://de.wikipedia.org/w/index.php?title=TopLink&action=edit&redlink=1

:roll:




> Spring mit EJB zu vergleichen ist wie Äpfel und Birnen. J2EE/JavaEE und Spring ist schon wesentlich passender. Beides sind konkurrierende Plattformen. Wenn ich jemanden brauche der JavaEE macht, kann ich davon ausgehen das er EJBs beherrscht. In eine Jobbeschreibung würde ich also nur JavaEE 4/5 schreiben.


Wenn Du Dich mit Spring ein bißchen näher beschäftigt hättest, wüsstest Du, dass das Käse ist. Der Einsatz von Spring schließt JEE nicht aus. Im Gegenteil: Spring ist eine Ergänzung zu vielen Teilen der JEE-Spezifikation. Zugleich macht Spring einige Teile der Spezifikation obsolet (wie z.B. EJBs).


----------



## ps (1. Jul 2008)

byto hat gesagt.:
			
		

> Selbst Wikipedia zeigt, wie "wichtig" TopLink offenbar ist: http://de.wikipedia.org/w/index.php?title=TopLink&action=edit&redlink=1



Wikipedia.. wenn das kein Argument ist ^^
Guck hier: -> http://en.wikipedia.org/wiki/TopLink



> Wenn Du Dich mit Spring ein bißchen näher beschäftigt hättest, wüsstest Du, dass das Käse ist. Der Einsatz von Spring schließt JEE nicht aus. Im Gegenteil: Spring ist eine Ergänzung zu vielen Teilen der JEE-Spezifikation. Zugleich macht Spring einige Teile der Spezifikation obsolet (wie z.B. EJBs).



Spring war als Alternative zu dem damals sher umständlichen und langwierigen JavaEE 4 gedacht. Natürlich kann man es auch mit JavaEE mischen. Das ändert aber nichts daran: Wenn ich in eine Jobbeschreibung "JavaEE 4/5" schreibe, wird jeder Bewerber EJBs in der Version 2 oder 3 beherrschen. Du hast deine Argumentation auf Trends im Jobmarkt aufgebaut, nicht ich ;-)

[edit:
hier noch ein paar Links:
Toplink Opensource Version:
-> http://www.eclipse.org/eclipselink/
-> http://www.oracle.com/technology/products/ias/toplink/index.html
]

Ich bin raus aus der Diskussion - ich werde mich sicher nicht darüber streiten ob eine 14 Jahre alte ORM Lösung welche erst von TOP, dann durch BEA und jetzt durch Oracle in ihrer Middleware eingesetzt wird noch Relevanz am Markt hat. Irgendwo hörts auf ^^


----------



## byte (1. Jul 2008)

ps hat gesagt.:
			
		

> Spring war als Alternative zu dem damals sher umständlichen und langwierigen JavaEE 4 gedacht. Natürlich kann man es auch mit JavaEE mischen. Das ändert aber nichts daran: Wenn ich in eine Jobbeschreibung "JavaEE 4/5" schreibe, wird jeder Bewerber EJBs in der Version 2 oder 3 beherrschen. Du hast deine Argumentation auf Trends im Jobmarkt aufgebaut, nicht ich ;-)


Spring *ist* ein JEE-Framework. Suchst Du nach JEE-Jobs werden auch unweigerlich Spring-Jobs darunter sein. Deswegen ist es absolut sinnfrei, JEE-Jobs mit Spring-Jobs zu vergleichen. 

Aber nichts für ungut. Wollte Dich in Deinem Elfenbeinturm nicht stören. :roll:


----------



## ps (1. Jul 2008)

byto hat gesagt.:
			
		

> Spring ist ein JEE-Framework.



JavaEE (Java Enterprise Edition) ist eine Spezifikation, mittlerweile in Version 5. Früher nannte man das J2EE (Java Platform 2 Enterprise Edition) 
Diese Spezifikationen definieren sehr genau was JavaEE ist und was nicht. 

Aber eigentlich ist mir diese Erbsenzählerei hier wirklich zu doof. Waren wir nicht schon bei dem Punkt das jeder einfach das nehmen soll mit dem er am schnellsten zum Ziel kommt? Diese Glaubensdiskussionen bringen rein garnichts. Spring ist toll, hat sicher seine Daseinsberechtigung sonst würden es nicht so viele Leute einsetzen. Wenn du meine Posts aufmerksam ließt, tue ich nur meine Meinung Kund. Wenn du daraufhin versuchst irgendwelche Beweise mit Job Trends anzutreten... wers braucht. 

Werde glücklich mit deinem Spring, deinem Hibernate und deinem Eclipse. 
Ich werde glücklich mit meinem JavaEE, meinem Toplink/EclipseLink und NetBeans.

Alle sind happy, alles ist gut


----------



## tfa (1. Jul 2008)

ps hat gesagt.:
			
		

> [edit: @tfa: sicher haben die auch probleme zu lösen. aber ich löse meine probleme trotzdem mit den werkzeugen welche ich für geeignet halte - und nicht mit dem werkzeug das gerade am meisten eingesetzt wird
> ]


Darfst du ja. Aber möglicherweise gibt es ja einen Zusammenhang zwischen "Werkzeug ist zur Problemlösung besonders gut geeignet" und "Werkzeug wird besonders häufig eingesetzt"


----------



## byte (1. Jul 2008)

ps hat gesagt.:
			
		

> Alle sind happy, alles ist gut


Einverstanden.


----------



## BjörnBu (17. Jul 2008)

Ich habe vor kurzem im Rahmen einer Studienarbeit mit einem zusammen mit einem Kommilitonen einen Vergleich zwischen einem Design wie in Domain Driven Design von Eric Evans beschrieben (keine blutleeren Javabeans als Domain Modell sondern ein reiches Modell mit Logik) und klassischen, EJB basierten JEE Anwendungen durchgeführt.

Die DDD Anwendung hat dabei konsequent Spring genutzt, da sich spring als nicht-invasives framework perfekt mit den Prinzipien von DDD versteht. 

Im Endeffekt wurde der eigentliche Vergleich vor allem durch die Abhängigkeit von einem EJB Container gestört. TestNG und embedded JBoss waren beispielsweise die reinste Katastrophe und mit sehr viel Aufwand verknüpft. 

Auch wenn beide Ansätze ihre Berechtigung haben und in gewissem Maße alles geschmackssache ist, hab ich mich als Spring-Fan gerade genötigt gefühlt dieses Argument noch anzuführen.

Liebe Grüße
Björn


----------



## maki (17. Jul 2008)

> Im Endeffekt wurde der eigentliche Vergleich vor allem durch die Abhängigkeit von einem EJB Container gestört. TestNG und embedded JBoss waren beispielsweise die reinste Katastrophe und mit sehr viel Aufwand verknüpft.


Tja, sobald ein EJB Container involviert ist, sind Unittests nicht mehr möglich, sondern nur noch aufwändige, aber vor allem langsame(!!!) Integrationtests.


----------



## byte (17. Jul 2008)

Wer macht schon Unittests.


----------



## maki (17. Jul 2008)

byto hat gesagt.:
			
		

> Wer macht schon Unittests.


Hehe... diejenigen welche nie Bugs in ihrem Code hatten und bei denen der allererste Designentwurf immer 100% richtig ist brauchen keine, der Rest wäre mit viel besser bedient


----------



## byte (17. Jul 2008)

Jo. Und ich mags, wenn alles auf "grün" is.


----------



## maki (17. Jul 2008)

red/green/refactor
red/green/refactor
red/green/refactor
red/green/refactor
red/green/refactor
red/green/refactor
red/green/refactor
red/green/refactor
red/green/refactor
red/green/refactor
red/green/refactor
red/green/refactor
red/green/refactor
red/green/refactor
.... 

*g*


----------

