Java EE vs. Spring/Hibernate

Status
Nicht offen für weitere Antworten.

deamon

Bekanntes Mitglied
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

Bekanntes Mitglied
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.
 
G

Gast

Gast
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"/>
</context:component-scan>

<tx:annotation-driven/>

<context:property-placeholder location="/WEB-INF/datasource.properties,/WEB-INF/application.properties"/>

<bean id="transactionManager" class="org.springframework.orm.jpa.JpaTransactionManager">
<property name="dataSource" ref="dataSource"/>
<property name="entityManagerFactory" ref="entityManagerFactory"/>
</bean>

<bean id="entityManagerFactory" class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean">
<property name="dataSource" ref="dataSource"/>
<property name="persistenceUnitName" value="businessplan"/>
</bean>

<bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close">
<property name="driverClassName" value="${dataSource.driverClassName}"/>
<property name="url" value="${dataSource.url}"/>
<property name="username" value="${dataSource.username}"/>
<property name="password" value="${dataSource.password}"/>
</bean>

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

Top Contributor
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

Bekanntes Mitglied
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

Top Contributor
ps hat gesagt.:
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).
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

Bekanntes Mitglied
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

Top Contributor
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

Bekanntes Mitglied
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

Top Contributor
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:

jobgraph.png


jobgraph.png


jobgraph.png
 

ps

Bekanntes Mitglied
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:

jobgraph.png
 

byte

Top Contributor
ps hat gesagt.:
und: glaube nie einer statistik welche du nicht selbst gefälscht hast:

jobgraph.png

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

jobgraph.png


jobgraph.png




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.
 

byte

Top Contributor
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

Bekanntes Mitglied
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

Top Contributor
ps hat gesagt.:
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.
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

Bekanntes Mitglied
byto hat gesagt.:

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

Top Contributor
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

Bekanntes Mitglied
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

Top Contributor
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" ;)
 

BjörnBu

Aktives Mitglied
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
 
M

maki

Gast
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.
 
M

maki

Gast
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 ;)
 
M

maki

Gast
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*
 
Status
Nicht offen für weitere Antworten.
Ähnliche Java Themen
  Titel Forum Antworten Datum
D Spring 3 vs. Java EE 6 Allgemeines EE 33
T Java ServerFaces Anwendung mit XHTML & CSS Allgemeines EE 1
E modulare Java-Anwendung verteilen (Camel) Allgemeines EE 0
B Java Mail und idle() mit zig Emailadressen? Allgemeines EE 59
H JWebUnit Fehler: java.lang.NoClassDefFoundError: org/apache/regexp/RESyntaxException Allgemeines EE 24
B Java mail API - möchte nur eine gewisse Anzahl von Emails in die Liste holen Allgemeines EE 3
M Rest mit Java 11 Allgemeines EE 6
M java.lang.SecurityException: class "javax.persistence.TupleElement"'s signer information does not match ... Allgemeines EE 1
F Java Programmierer Allgemeines EE 13
R Wie viel DevOps sollte ein Java-Entwickler kennen, der sich in Microservices spezialisiert? Allgemeines EE 5
Dimax JSP Probleme mit Java in JSP Allgemeines EE 21
Dimax JSP Auf button click java methode ausführen.Ist das möglich? Allgemeines EE 6
B Logging (log4j) in JAVA EE application - WildFly Allgemeines EE 15
A Java EE (am Cleint) und websocket Allgemeines EE 8
J Ich kann Java JDK nicht downloaden Allgemeines EE 6
R Aufbau zum Java EE Entwickler - Schulungen Allgemeines EE 0
G Java EE Hosting ? Allgemeines EE 6
P Java EE Videotutorials Allgemeines EE 1
R Java Enterpise entwickeln mit Virtualbox Allgemeines EE 6
A OutOfMemoryError: Java heap space Allgemeines EE 7
I Start Word from Java Allgemeines EE 1
T Java Jersey Interceptor Allgemeines EE 7
R Post Variable in Java Allgemeines EE 8
L JSP Fehlermeldung bei Verwendung von Java-Expression-Language Allgemeines EE 8
K Wie habt ihr Java EE gelernt? Allgemeines EE 11
hjpsoft JSF Lösung einer Aufgabe im "Workshop Java EE7" Allgemeines EE 5
S Welcher Java EE Applikationserver für RESTful Webservice? Allgemeines EE 2
T Java Login Allgemeines EE 1
L Certified Master Java Enterprise Architect Java EE Allgemeines EE 3
R Java EE 6, eclipse, maven, jsf, hibernate, mysql Allgemeines EE 8
D Einfaches Java Projekt funktioniert nicht Allgemeines EE 3
W Authentifizierung und Sessions in Java EE7 Allgemeines EE 0
OnDemand Task in Java ee Allgemeines EE 7
OnDemand JSF - java File Verständnisfrage Allgemeines EE 5
OnDemand Deployen ohne .java Files Allgemeines EE 0
E Wie kann ich über einen Suchfeld in Java Server Pages nach Datenbankinhalten suchen? Allgemeines EE 11
V Java EE 7 CDI, annotations und beans Allgemeines EE 1
G Bachelorthesis: Java oder PHP (CMS) Allgemeines EE 7
X Konsolenausgabe einer java klasse in eine jsp umleiten Allgemeines EE 7
S Aufruf eines EJBs aus einer nativen Java-Applikation Allgemeines EE 1
T Fertiges html javascrip css template in java EE application Allgemeines EE 0
F Eclipse/Java EE Debug-Problem Allgemeines EE 1
D Java Projekt goes Webservice Allgemeines EE 6
L Button Handling in JSP mit Java-Backend Allgemeines EE 2
Shams Frage zu Dowload von JAVA SDK Allgemeines EE 5
T Größeres Java EE Beispiel Projekt Allgemeines EE 4
N JavaScript schickt und Java empfängt? Allgemeines EE 4
O Java EE in Netbeans + allgemeine Fragen Allgemeines EE 5
H java selenium spezis? Allgemeines EE 4
H java selenium test connection refused Allgemeines EE 6
M Java EE-Technologie-Lern-Wahl Allgemeines EE 5
B [EJB] javax.inject.DefinitionException: bean not a Java type Allgemeines EE 5
J Java Dependencies auslesen Allgemeines EE 19
2 installation java EE Allgemeines EE 12
J PHP oder Java? Allgemeines EE 12
L Webseiten Formulare über Java Oberfläche ausfüllen? Allgemeines EE 2
T Java CMS Entwicklung : Welcher Weg ist besser? Allgemeines EE 9
F Gesucht: Gratis Server für Java Entwickler Allgemeines EE 4
J Einstieg in Java EE Allgemeines EE 5
aze Eclipse Java EE Web Project:Wo liegen die Servlets ? Allgemeines EE 4
S java Entities Problem Allgemeines EE 19
D Grundüberlegung Java Webprojekt Allgemeines EE 10
F Einstieg in Java EE - Beispielanwendungen Allgemeines EE 52
R JAVA EE - eigene Klassen aus EJB übernehmen Allgemeines EE 2
T "normales" Java Programm auf einen Server laufen lassen Allgemeines EE 3
M EE6+EJB+JavaLib: Error in annotation processing: java.lang.NoClassDefFoundError Allgemeines EE 4
G java ResourceLocator Allgemeines EE 12
M Was ist mit Java möglich? Allgemeines EE 13
T Komponenten zusammenhänge Java EE Allgemeines EE 7
A Java CMS Allgemeines EE 2
P Architektur Java EE <-> HTML5 Allgemeines EE 3
A Java Tomcat findet Website nicht Allgemeines EE 8
F Java EE Server nutzung kostenlos an Schule? (zB. mit Glassfish) Allgemeines EE 6
B Java EE, kickstart my heart Allgemeines EE 10
P Frage zu Java EE Design Patterns Allgemeines EE 3
G EJB und Java EE - No Persistence provider Allgemeines EE 5
zilti Java EE Hosting, worauf muss ich achten? Allgemeines EE 5
M Java EE6: Wie Login-Vorgang durchführen? Allgemeines EE 2
MQue Java Web- Application -> MVC Allgemeines EE 4
G Java <-> Flex Allgemeines EE 2
Spin Ant - Java Beans umsetzen Allgemeines EE 4
V "null" durch NICHTS ersetzen jsp und java beans Allgemeines EE 3
M Serialisierung und Klonen in Java Allgemeines EE 5
W JAVA Optionen auslesen Allgemeines EE 3
MQue CMS in Verbindung mit Java Allgemeines EE 16
X3TitanCore Java Servertechnologie Allgemeines EE 7
C WebStart Fehler nach update auf Java 1.6 Allgemeines EE 2
R Variablen statt Java-Methoden in EL's Allgemeines EE 4
T Suche Buch für: Large Scale Web-Apps | Clustering | Scaling in Java ? Allgemeines EE 4
G Vergleich zwischen Java Spirng und Ruby on Rails Allgemeines EE 9
K EJB Enterprise Java Beans Allgemeines EE 32
F Ich will mit Java Internetseiten bauen, aber wo hosten? Allgemeines EE 14
J OOP Java Array Problem Allgemeines EE 2
T Problem mit Java Transaction API Allgemeines EE 2
R Java EE Anfänger will mehr. Allgemeines EE 7
A Fragen zum Einstieg in Java EE Allgemeines EE 11
M Evolution der Web-Entwicklung im Java-Bereich Allgemeines EE 15
N erstes Java EE Projekt - Server/ EJB-Verbindung-Anfängerfage Allgemeines EE 17
G Von Java SE nach JavaEE umsteigen Allgemeines EE 31
K Java Application Server + ganttproject *.jar Anwendung Allgemeines EE 6

Ähnliche Java Themen

Neue Themen


Oben