Projekte ständig aktualisieren, oder bei "veralteter" Technik bleiben?

[JanHH]

Hallo,

mal eine Frage..

im JEE-Bereich ist ja eine rasante, ständige Weitentwicklung zu beobachten.. sowohl der diversen Frameworks, als auch der JEE-Basisversionen. Das führt natürlich dazu, dass es jede Menge Web-Projekte geben wird, die nicht auf dem neuesten Stand der Technologien basieren. Andererseits ist es für uns Programmierer ein ständiger Druck, sich permanent weiterzubilden.

Wie geht ihr damit um? Macht ihr mit bestehenden Projekten ab und an ein Refactoring, um es an neue Standards anzupassen (z.B. jetzt gerade aktuell ein gerade mal ein Jahr altes , fiktives JEE5-Projekt auf JEE6 portieren)? Fangt ihr neue Projekte jeweils immer mit der aktuellen Technologie an, oder benutzt ihr auch mal ganz bewusst etwas veraltete Standards, mit denen ihr dafür routiniert und vertraut seid?

Abgesehen von der ganz allgemeinen Fragestellung will ich heute ein neues Projekt anfangen, und würde dies normalerweise auf JEE5, Seam 1, JBoss 4.2.2, JSF 1.2 und JPA 1 aufbauen (weil das halt das ist, was ich kenne und beherrsche, und weil es mir, alles in allem, immer noch recht aktuell erscheint - ich vermute, die meisten Projekte hinken technologisch auch diesem veralteten Stand noch weit hinterher). Oder sollte man den Lernaufwand investieren und gleich JEE6, JSF2.0 usw. nehmen?

Gruß
Jan

 

[Noctarius]

Ob man wechseln möchte / sollte oder nicht hängt meiner Ansicht nach von mehreren Faktoren ab:
- Bringt einem ein neues Release Vorteile?
- Wie viel Zeit muss man in die Umstellung investieren?
- Ist die neue Version stabil?
- Fehlen in der neuen Version eventuell benötigte Features die man "nachprogrammieren" müsste?
- usw

Mit Refactoring wirst du beim Wechsel auf die neuste JEE nicht weit kommen (wenn ich bisher das richtige über die aktuelle JEE Version gehört hab - benutzt selber nur Spring). Hier wird alles an Konfiguration in Annotations verlagert.

Ich würde mir zu solchen Punkten wie denen oben erstmal einen Überblick über das Projekt verschaffen und dann schauen ob es sich lohnen würde.

Eventuell ist es auch möglich neue, noch herumliegende Ideen aufzugreifen, Teile des Altsystems umzustellen und zu erweitern und nur das Frontend einem größeren Rewrite zu unterziehen (ich nutze diese Chance schon mal - wenn das System nicht viel zu groß ist).

 

[JanHH]

Ein Aspekt ist mir noch aufgefallen: Wird die ggf. alte Version, für die man sich enscheidet, auch in Zukunft noch kompatibel und damit lauffähig sein?

 

[Noctarius]

Womit kompatibel?

 

[JanHH]

Mit neueren Version von JEE, den Application-Servern usw.

 

[Noctarius]

Das kann man allgemein nicht sagen, da dies stark von dem Entwicklerteam bzw. der JSR-Group abhängt. Ich glaube zwischen 4 und 5 gab es einen Kompatibilitätsbreak, bin mir aber nicht sicher. 6 sollte aber auch 5er Anwendungen noch ausführen können.

Bei Applicationservern kommt es halt drauf an was diese noch unterstützen. Da aber mit Sicherheit die Meisten Firmen nicht mal eben auf JEE6 springen (zumal es wohl hier und da noch Macken haben soll) wird 5 noch eine Weile verfügbar sein.

Ich mein: Sieh dir die Updatepolitik vieler Firmen in Bezug auf Java an. Es gibt immer noch genug Systeme da draußen, welche Java 1.4 benötigen und da wird auch nichts dran geändert ;-)

 

[JanHH]

Es gibt ja wohl auch jede Menge wirklich grosse Systeme im praktischen Einsatz, die noch auf J2EE/java 1.4 basieren, wo ein update auf JEE6 kaum praktikabel ist, und allein schon deswegen muss das alles eigentlich so konzipiert sein, dass auch diese Dinge noch in Zukunft lauffähig sein werden.

Bedeutet also: Entscheide Dich zu dem Zeitpunkt, wo Du ein Projekt beginnst, für eine Technologie, die Dir geeignet erscheint, und vertraue dann darauf, dass diese auch in Zukunft funktionieren wird.

 

[Noctarius]

Natürlich kann man auch zwischendurch auf neue Versionen updaten. Hier ist Spring aber zum Beispiel meistens kompatibler als JEE und vor allem gradliniger in der Entwicklung. JEE 6 hat jetzt versucht viele Aspekte von Spring nachzubilden (meine Meinung) und ist damit sehr weit vom 5er Release abgekommen.

Das du auch in Zukunft noch App-Server findest die deine Version von JEE unterstützen dürfte eigentlich kein Problem darstellen.

Je nach Aufwand des Umbau ist halt anzudenken eventuelle Teile neu zuschreiben. Dummerweise geht sowas teils tatsächlich schneller.

 

[Deadalus]

Natürlich kann man auch zwischendurch auf neue Versionen updaten. Hier ist Spring aber zum Beispiel meistens kompatibler als JEE und vor allem gradliniger in der Entwicklung. JEE 6 hat jetzt versucht viele Aspekte von Spring nachzubilden (meine Meinung) und ist damit sehr weit vom 5er Release abgekommen.

Das du auch in Zukunft noch App-Server findest die deine Version von JEE unterstützen dürfte eigentlich kein Problem darstellen.

Je nach Aufwand des Umbau ist halt anzudenken eventuelle Teile neu zuschreiben. Dummerweise geht sowas teils tatsächlich schneller.

Meiner meinung nach hat die JEE sich nicht nur an Spring sondern auch an vielen anderen Frameworks wie z.B. SEAM orientiert. So fließen gute Ideen nach und nach auch in den offiziellen Standard ein. Das finde ich sehr gut und ich hoffe dieser Weg wird weiterbeschritten.

Der Sprung von JEE 6 zu JEE 5 meiner Meinung nach deutlich geringer als der Sprung von J2EE 1.4 zu JEE5. Ich hab öfters den Spruch gelesen J2EE 1.4 -> JEE5 Revolution, JEE5 -> JEE6 Evolution. Denke mal das trifft es ganz gut.

Solange man sich an die JEE hält und keine Fremdabhänigkeiten hat ist ein Wechsel zu einer neueren Version der JEE eigentlich sehr leicht, da die JEE abwärtskompatibel ist. Die Neuerungen kann man dann nach und nach dazuprogrammieren.

 

[maki]

Meiner meinung nach hat die JEE sich nicht nur an Spring sondern auch an vielen anderen Frameworks wie z.B. SEAM orientiert.

Vor JEE 5 gab es kein Seam, und damit auch keine Seam Vorlage für JEE
Kannst ja mal raten woher die Seam Jungs ihre DI Idee hatten...

So fließen gute Ideen nach und nach auch in den offiziellen Standard ein. Das finde ich sehr gut und ich hoffe dieser Weg wird weiterbeschritten.

"nach und nach" könnte man auch durch "irgendwann" ersetzen, dauert halt immer etwas bis die JCP Jungs ihre Spec. fertig haben und auf die Implementierung kann man dann nochmals warten, da sind andere, nicht JCP Projekte deutlich schneller.

Alles in allem sehe ich das auch so: Entscheide zu Projekt beginn welche Frameworks/Standards eingesetzt werden, einfachere Updates/Migrationen (wie zB. bei Spring) kann man dann immer noch machen, größere Änderungen sollten vermieden werden, ausser man hat viel Zeit...

 

[Deadalus]

Vor JEE 5 gab es kein Seam, und damit auch keine Seam Vorlage für JEE
Kannst ja mal raten woher die Seam Jungs ihre DI Idee hatten...

Ja klar da hab ich mich etwas umständlich ausgedrückt. Ich meinte natürlich beim Versionssprung von JEE5 auf JEE6.

Das andere Frameworks natürlich schneller Neuerungen umsetzen können sind steht außer Frage. Diese müssen ja auch nicht die Ideen und Wünsche von Oracle, IBM, SAP, Sun, Apache, Red Hat ... unter einen Hut bringen.
Aber ich finde insgesamt ergibt das ein gesundes Ekosystem. Frameworks bringen neue Ideen, die wenn sie sich am Martk bewährt haben in den offiziellen Standard übernommen werden.

 

[maki]

Aber ich finde insgesamt ergibt das ein gesundes Ekosystem.

Nicht falsch verstehen, will nicht die ganze Zeit dagegen reden, aber dieses System hat auch immense Nachteile... wenn man sich zB. ansieht was aus JDO geworden ist, welches abgesägt wurde weil IBM & Oracle Angst um ihre DBs hatten, als ersatz gab es dann ein sehr lückenhaftes JPA 1.0.