# Argumente für Java 6



## tfa (28. Feb 2008)

Moin!

Offiziell müssten wir uns in unserem Projekt noch mit Java 1.4 herum quälen. 
Wir versuchen allerdings (schon seit langer Zeit), die Firma dazu zu bewegen,
wenigstens Java 5 freizugeben - oder besser noch Java 6. 
Im Moment werden Argumente für Version 6 gesammelt:


* Allgemeine Verbesserung der Performance
* Verbesserte GC-Algorithmen
* Geringerer Speicherverbrauch
* geglättete Schriftarten
* bessere plattformspezifischen Look&Feel unter Swing
* besseres HTML-Rendering
* erweiterte API für z.B. Webservices, XML

Fällt jemandem noch ein Vorteil ein?


----------



## Saxony (28. Feb 2008)

Hiho,

hier findest du sicher noch mehr Argumente:

1.5 Release Notes
1.5 Features
1.6 What's new



bye Saxony


----------



## maki (28. Feb 2008)

1.4 wird doch nicht mehr unterstützt von Sun?
D.h. keine Updates, Bugfixes etc.


----------



## Wildcard (28. Feb 2008)

* geglättete Schriftarten 
RenderingHints.KEY_TEXT_ANTIALIASING ?


----------



## Wolfgang Lenhard (28. Feb 2008)

Applikationen starten deutlich schneller.
Teilweise erhebliche Geschwindigkeitssteigerungen bei einfachen Rechenoperationen (z. B. Kopieren von int-Arrays ca. 25% schneller).


----------



## AlArenal (28. Feb 2008)

maki hat gesagt.:
			
		

> 1.4 wird doch nicht mehr unterstützt von Sun?
> D.h. keine Updates, Bugfixes etc.



Never change a running system. Guter alter Leitsatz, der auch heute noch Gültigkeit hat. Ich kenne persönlich Gepflogenheiten aus weltweit agierenden Konzernen, da stellst du an der einen Stelle eine Anforderung (Aufnahme Java 5 in die Installationsprofile der Nutzer), dann muss diese intern von der Technik an die Zentrale in die USA geschickt werden, dort dauert es dann Wochen und Monate, ehe sich jemand darum kümmert und schlussendlich sagt "Iss nicht" und dafür eine sehr heftige interne Rechnung zurückschickt.

Manchmal muss man sich einfach seinem Schicksal ergeben.


----------



## byte (28. Feb 2008)

Kapitulation ist echt ein toller Tipp. :roll:


----------



## byte (28. Feb 2008)

Wildcard hat gesagt.:
			
		

> * geglättete Schriftarten
> RenderingHints.KEY_TEXT_ANTIALIASING ?


Es ist aber extrem nervig, bei jeder Standard-Komponente erstmal die paintComponent() zu überschreiben, nur um die RenderingHints im Graphics-Objekt zu setzen, wenn man sonst gar kein Custom-Painting macht.


----------



## byte (28. Feb 2008)

Für Java 5 spricht auch noch:
- Synth Look & Feel (einfache Anpassung des Looks über XML-Datei)

Nimbus wird afaik per Synth gebaut.

Letzteres spricht im übrigen für Java 6, da soll Nimbus ja per Update nachgereicht werden.


----------



## maki (28. Feb 2008)

AlArenal hat gesagt.:
			
		

> maki hat gesagt.:
> 
> 
> 
> ...


Ist richtig, hab ich auch festgestellt.

Allerdings sind bei Konzernen manche Manager nicht mehr so stur wenn man ihnen erzählt, dass sie Software einsetzen die nicht mehr unterstützt wird, eventuelle Bugs und Sicherheitslücken nicht mehr behoben werden.
Wenn dieser Konzern aber einen Vertrag mit zB. IBM hat, der ihnen Support für Java 1.3 zusichert, ist dieses Argument keines mehr.


----------



## AlArenal (28. Feb 2008)

Das kann man erklären, wie man will. Dennoch haben die intern ihre Prozesse, nach denen sie verfahren und da die Honks in der Zentrale sich superwichtig vorkommen und auch keinen Bock haben jede Software zu testen, ob diese nicht in Java 5 oder 6 vielleicht nicht mehr korrekt läuft, wird sich da so schnell nüscht ändern.


----------



## ARadauer (28. Feb 2008)

klar! was erwartet ihr?



> da die Honks in der Zentrale sich superwichtig vorkommen



Nur weil ein kleiner Programmierer daher kommt und die Vorzüge von java 1.5 nützen will, sollen in einem konzern ca 20.000 - 30.000 Arbeitsplatz Rechner upgedatet werden? Ist das euer ernst!
Wer übernimmt die Verantwortung wenn die Server von 1.4 auf 6 umgestellt werden und in einer Aussenstelle, die wichtige Core Prozess Schnittstellen zur Verfügung stellt, gehen auf einmal die Webservices nicht mehr. Weil vielleicht mal jemand lustig war und glue 1.0 verwendet hat. (ist uns passiert, die haben enum in ihren package namen verwendet)

Ich wollte auch, das die BMW AG auf java 6 umstellt, natürlich haben sie das nicht gemacht. Dann geht man halt zum Support, besorgt sich für die 10 Rechner für die es relevant ist, Admin Rechte und macht es selber. Is zwar nicht ganz der offizelle Weg, aber naja bevor ich zig Tausend Rechner updaten lasse....


----------



## byte (28. Feb 2008)

ARadauer hat gesagt.:
			
		

> klar! was erwartet ihr?
> 
> 
> 
> ...


Es geht doch nicht darum, dass alle konzernweiten Java-Anwendungen auf Java 6 umgestellt werden. Es geht darum, dass Java 5 und 6 vom Konzern offiziell freigestellt werden, so dass man neue Anwendungen mit aktueller Technik entwickeln oder auch bestehenden Anwendungen falls gewünscht migrieren kann. Alte Anwendungen können weiterhin auf der alten VM laufen.
Im übrigen muss man an den Clients überhaupt nichts verändern, wenn man die Anwendungen per Webstarter anbietet, so wie es bei uns im Konzern der Fall ist. Der lädt die benötigte JRE einfach mit.

Ich finde es traurig, dass Ihr offenbar schon vor der Obrigkeit kapituliert.  Wenn nicht die Entwickler mit der technischen Erfahrung Empfehlungen für eine Technologie aussprechen, wer sollte das dann tun? Das Management sicherlich nicht.
Einen Versuch, etwas zu ändern, ist es allemal wert. Wer nicht mal mehr versucht, etwas zu bewirken, der hat schon verloren.


----------



## ARadauer (28. Feb 2008)

stimmt auch wieder.
Man stumpft halt mit der Zeit ab, wenn vorschläge für neue Techniken dauernd ignoriert werden und Datenbank Modelle wie vor 30 Jahren eingesetzt werden....


----------



## tfa (28. Feb 2008)

Erstmal danke für die Antworten. Ich werde weiter sammeln.

Ich finde, man sollte sich (auch als "kleiner Programmierer") nicht alles vom Management gefallen lassen, oder macht es euch Spaß, mit völlig veralteten Versionen arbeiten zu müssen? 
Besonders wenn es überhaupt keine stichhaltigen Argumente dafür gibt, außer "Wir haben keinen Bock das zu verantworten." Sicherlich kann man nicht von heute auf morgen einen Versionswechsel in Produktivsystemen
machen, aber ein Test - und daran hapert es schon bei uns - sollte mindestens möglich sein.



			
				ARadauer hat gesagt.:
			
		

> Nur weil ein kleiner Programmierer daher kommt und die Vorzüge von java 1.5 nützen will, sollen in einem konzern ca 20.000 - 30.000 Arbeitsplatz Rechner upgedatet werden? Ist das euer ernst!


Ist das dein ernst, dass das ein Problem ist? Also wir verteilen unsere Software übers Intranet durch
ein Update-Applet. Die nötige JRE-Version wird selbstverständlich automatisch mit verteilt. 



> Wer übernimmt die Verantwortung wenn die Server von 1.4 auf 6 umgestellt werden und in einer Aussenstelle, die wichtige Core Prozess Schnittstellen zur Verfügung stellt, gehen auf einmal die Webservices nicht mehr. Weil vielleicht mal jemand lustig war und glue 1.0 verwendet hat. (ist uns passiert, die haben enum in ihren package namen verwendet)


Das ist das Problem, die Verantwortung. Aber irgendjemand hat doch auch Verantwortung für einen Umstieg auf 
1.4 übernommen. Sonst müssten wir ja uns noch mit Java 1.1 herumquälen -- ohne Swing und ohne 
Collection-Framework. Außerdem gibt es ja noch ausführliche Tests (siehe oben).


----------



## Wildcard (28. Feb 2008)

Ein JRE Wechsel ist bei einem größeren Programm kein kleiner Schritt. Die Seiteneffekte können mitunter massiv sein.
Bei uns ist für Kundeninstallationen mittlerweile nichtmehr nur die JRE Version, sondern sogar die Update Nummer der Version vorgeschrieben.
Ich will gar nicht darüber nachdenken wieviel Stunden schon dafür drauf gegangen sind die VM Parameter exakt auf Java Version X Update Y zuzuschneiden und dreckige Classloader Tricks einzubauen, nur damit der Mist später läuft und keine Deadlocks produziert.
Never change a running system unless you have to und mit 1.4 drückt der Schuh nicht mehr ganz so sehr wie mit Java 1.1 und Konsorten.
Müsste ich das entscheiden, wären für mich  Enums, foreach und Generics auch kein zwingender Update Grund.


----------



## tfa (28. Feb 2008)

Dann sollte wohl jemand bei Sun anrufen und sagen, sie brauchen Java nicht weiter zu entwickeln. 
Und DOS war sicherlich auch schon ein "Running System" (jedenfalls einige Versionen von bestimmten Anbietern).


----------



## byte (28. Feb 2008)

Wildcard hat gesagt.:
			
		

> Ein JRE Wechsel ist bei einem größeren Programm kein kleiner Schritt. Die Seiteneffekte können mitunter massiv sein.
> Bei uns ist für Kundeninstallationen mittlerweile nichtmehr nur die JRE Version, sondern sogar die Update Nummer der Version vorgeschrieben.
> Ich will gar nicht darüber nachdenken wieviel Stunden schon dafür drauf gegangen sind die VM Parameter exakt auf Java Version X Update Y zuzuschneiden und dreckige Classloader Tricks einzubauen, nur damit der Mist später läuft und keine Deadlocks produziert.
> Never change a running system unless you have to und mit 1.4 drückt der Schuh nicht mehr ganz so sehr wie mit Java 1.1 und Konsorten.
> Müsste ich das entscheiden, wären für mich  Enums, foreach und Generics auch kein zwingender Update Grund.


Haben grade ein Projekt auf von 1.4 auf 5 umgestellt, dass aus ~4500 Klassen besteht. Klar wars kein kleiner Schritt, aber hat im Grunde recht problemslos geklappt. Aber wie gesagt: Es geht ja nicht da drum, zwanghaft alte Anwendungen auf Java 5 oder 6 zu migrieren. Es geht darum, neuen Projekten die Chance zu ermöglichen, direkt mit der aktuellen Version die Entwicklung zu beginnen. Selbst da hapert es ja oft in großen Konzernen, wenn die aktuelle Java-Version noch nicht genehmigt ist.


----------



## ARadauer (28. Feb 2008)

> Haben grade ein Projekt auf von 1.4 auf 5 umgestellt, dass aus ~4500 Klassen besteht.


mir persönlich fallen eigentlich fast keine problemstellen ein, wo es happern könnte. ausser bei der vorher schon erwähnte glue lib. in der enum in einem package namen vorkam.

wo könnte es noch zu problemen kommen?


----------



## Wildcard (28. Feb 2008)

@tfa
Die Weiterentwicklung hat damit nichts zu tun, es geht darum das es keinen Grund für den Wechsel gibt, nur weil der Programmierer das gerne hätte. Erst wenn es um 'echte' Features geht, die den Aufwand rechtfertigen, kann man das als Unternehmen in Betracht ziehen.

@byto


> Es geht ja nicht da drum, zwanghaft alte Anwendungen auf Java 5 oder 6 zu migrieren. Es geht darum, neuen Projekten die Chance zu ermöglichen, direkt mit der aktuellen Version die Entwicklung zu beginnen.


Sofern nichts bestehendes tangiert wird, gebe ich dir Recht, sehe ich ähnlich.

@ARadauer


> wo könnte es noch zu problemen kommen?


Die naturgemäße Volatilität eines OSGi Containers oder Application Servers und deren komplexe Classloader Hierarchien können äusserst empfindlich auf Wechsel in der Java Version reagieren.
Auch Embedded Swing in SWT is ein absoluter Graus wenn sich in Java Version X Update Y mal wieder eine minimale Änderung im Focus Subsystem oder Ähnliches ergibt.
Die Korrektheit ist teilweise absolut untestbar und du *willst* keine JRE austauschen solange es nicht unumgänglich ist.


----------



## quippy (28. Feb 2008)

ARadauer hat gesagt.:
			
		

> > Haben grade ein Projekt auf von 1.4 auf 5 umgestellt, dass aus ~4500 Klassen besteht.
> 
> 
> mir persönlich fallen eigentlich fast keine problemstellen ein, wo es happern könnte. ausser bei der vorher schon erwähnte glue lib. in der enum in einem package namen vorkam.
> ...



Z.B. hatten wir extreme Probleme mit der stillschweigenden Änderung in BigDecimal, daß toString ab jetzt nur noch in wissenschaftlicher Notation ausgibt und die alte Mimik nach dem Zwergenaufstand der Reviewer gnädigerweise in der Methode "toPlainString" wieder auferstehen durfte.

Damit funktioniert z.B. JCo nicht mehr. Lapidare Antwort von SAP: "in den Systemvoraussetzungen steht doch eindeutig nur Java 1.4 drin!" Das hilft weiter!
Auch unser Java-CICS-Bridge, welche auch mit BigDecimal arbeitet, hatte plötzlich Anpassungsbedarf.

Mal ganz davon abgesehen, daß sich einige Entwickler in ihren Projekten eine eigene Enum-Klasse gebastelt hatten X(

Also, so einfach ist das alles mit dem Umstellen nicht - da muss man schon genau wissen, was man tut - und ein Mixbetrieb kann wiederum andere unschöne Folgen haben, z.B. wenn eine serialisierte Bean aus einem JBoss4/Java5 Umfeld an ein JBoss3.2.3/Java4-Umfeld gehen soll und die Java-Maschine kleinere Probleme mit der Deserialisierung bekommt.


----------



## byte (28. Feb 2008)

Wildcard hat gesagt.:
			
		

> Die Weiterentwicklung hat damit nichts zu tun, es geht darum das es keinen Grund für den Wechsel gibt, nur weil der Programmierer das gerne hätte. Erst wenn es um 'echte' Features geht, die den Aufwand rechtfertigen, kann man das als Unternehmen in Betracht ziehen.


Ich sehe die neuen Sprachfeatures von Java 5 nicht nur als syntactic sugar. Sie haben einen direkten Einfluss auf die Code-Qualität und Wartbarkeit, was letztendlich die Entwicklungszeit verringert und somit Kosten spart. Ganz davon abgesehen gibt es mit Java 5 und 6 auch viele Änderungen, die sich beispielsweise in der erhöhten Performance äußern, der Enduser also direkt zu spüren bekommt.


----------



## tuxedo (28. Feb 2008)

An alle "never change a running system"-Gläubigen:

In Punkto Sicherheit etc.:

Erzählt mal einem Root-Serverbetreiber was von "never change a running system" und "update erst wenn es "echte" features gibt" ...

Die Jungs fangen an im Dreieck zu hüpfen. Okay, vielleicht ist ein Root-Server auch etwas angreifbarer als eine Java-Anwendung. Dennoch sollte - nein, anders .. - darf es nicht unversucht bleiben neue Versionen einzuspielen um Bugfixes zu erhalten und damit auch Sicherheitslöcher zu stopfen. Natürlich vorher in einem Testsystem wirklich ausgiebig testen.

Der Versuch allein heisst ja nicht dass man's unbedingt und unter allen Umständen durchziehen soll. Aber man muss es zumindest versucht haben.

Meine Meinung. Andere dürfen gerne andere Meinungen haben.

- Alex


----------



## AlArenal (28. Feb 2008)

tfa hat gesagt.:
			
		

> Erstmal danke für die Antworten. Ich werde weiter sammeln.
> 
> Ich finde, man sollte sich (auch als "kleiner Programmierer") nicht alles vom Management gefallen lassen, oder macht es euch Spaß, mit völlig veralteten Versionen arbeiten zu müssen?



Spaß bezahlt einem keine Rechnungen. Ich kann schlecht zur BP oder Conti gehen und sagen, sie sollen sich ihre 1.4er JVM in den Anus schieben und mir andere Kunden suchen... 



> Besonders wenn es überhaupt keine stichhaltigen Argumente dafür gibt, außer "Wir haben keinen Bock das zu verantworten." Sicherlich kann man nicht von heute auf morgen einen Versionswechsel in Produktivsystemen
> machen, aber ein Test - und daran hapert es schon bei uns - sollte mindestens möglich sein.



Wie gesagt, wenn die internen Kosten für diesen Test höher sind als die Projektsumme, wie soll man das verkaufen? Und mal ehrlich: Brennt irgendwo was ab, wenn Leute nicht auf einmal geglättete Schriften zu sehen bekommen? Hat der Kunde davon einen Konkurrenzvorteil? Pustekuchen...

Und letzten Endes entwickelt man eben nicht für sich und die eigene Bequemlichkeit und den Spaß, sondern für den Nutzen des Kunden. Wenn man mal überlegt, dass SAP R/3 noch nicht lang her ist nud man mal schaut was für olle Systeme, teils noch DOS-basierend allerorten im Einsatz sind, dann kann man sich zu Tode argumentieren und wird dennoch nicht umhin kommen zu sagen, dass auch diese Tools ihren Job gemacht bekommen.




> Das ist das Problem, die Verantwortung. Aber irgendjemand hat doch auch Verantwortung für einen Umstieg auf
> 1.4 übernommen. Sonst müssten wir ja uns noch mit Java 1.1 herumquälen -- ohne Swing und ohne
> Collection-Framework. Außerdem gibt es ja noch ausführliche Tests (siehe oben).



Korrekt und darum kann man ja auch hoffen, dass man irgendwann mal gesagt bekommt "Hey, nach 8 Jahren ausführlicher Tests haben wir nun Java 5 (natürlich nur die 01, aber immerhin)". ;-)


----------



## AlArenal (28. Feb 2008)

alex0801 hat gesagt.:
			
		

> An alle "never change a running system"-Gläubigen:
> 
> In Punkto Sicherheit etc.:
> 
> Erzählt mal einem Root-Serverbetreiber was von "never change a running system" und "update erst wenn es "echte" features gibt" ...



Ich betreibe einige Root-Server und die meisten Probleme ergeben sich nicht im Betrieb, sondern bei Updates (gilt auch für die darauf laufenden Software-Systeme). Es hat schon einen Grund warum die Jungs und Mädels von Debian lieber ein Feature Freeze machen und nur sicherheitsrelevante Patches aus neueren Versionen zurück portieren.



> Meine Meinung. Andere dürfen gerne andere Meinungen haben.



Wie generös von dir!


----------



## tfa (28. Feb 2008)

AlArenal hat gesagt.:
			
		

> tfa hat gesagt.:
> 
> 
> 
> ...


Ansichtssache. Arbeit kann auch Spaß machen. Und ein bisschen Idealismus habe ich noch. Vielleicht rede ich in ein paar Jahren auch anders. Wer weiß? Ein paar Leute, die den Fortschritt vorantreiben, gibt es hoffentlich immer.



> Ich kann schlecht zur BP oder Conti gehen und sagen, sie sollen sich ihre 1.4er JVM in den Anus schieben und mir andere Kunden suchen...


Das will ich auch nicht. Aber man versuchen, das System  langsam zu ändern. Argumente sammeln und Verbündete suchen; daran arbeite ich.
Wenn mir die Situation im Projekt zu blöd würde (soweit ist es nicht), wär ich glaub ich auch bereit den Kunden bzw. Arbeitgeber zu wechseln. Über ein mangelndes Angebot können wir uns glaub ich nicht beklagen.


> > Besonders wenn es überhaupt keine stichhaltigen Argumente dafür gibt, außer "Wir haben keinen Bock das zu verantworten." Sicherlich kann man nicht von heute auf morgen einen Versionswechsel in Produktivsystemen
> > machen, aber ein Test - und daran hapert es schon bei uns - sollte mindestens möglich sein.
> 
> 
> ...


Ich glaube in diesem Thread wurden genug Vorteile genannt, die über geglättete Schriftarten hinausgehen.


----------



## Wildcard (28. Feb 2008)

tfa hat gesagt.:
			
		

> Ansichtssache. Arbeit kann auch Spaß machen. Und ein bisschen Idealismus habe ich noch. Vielleicht rede ich in paar Jahren auch anders. Wer weiß? Ein paar Leute, die den Fortschritt vorantreiben, gibt es hoffentlich immer.


Meine Arbeit macht mir Spaß, auch mit Java 4. Ausserdem machst du dir die Sache zu einfach. Ich bin auch für einen Java 5 Umstieg, wenn ich das allerdings verantworten müsste, wäre ich auch gegen einen Umstieg solange er keine markanten Vorteile bringt.



> Ich sehe die neuen Sprachfeatures von Java 5 nicht nur als syntactic sugar. Sie haben einen direkten Einfluss auf die Code-Qualität und Wartbarkeit, was letztendlich die Entwicklungszeit verringert und somit Kosten spart.


Ja, sogar massiv. Durch foreach spart man mindestens eine halbe Sekunde, wenn nicht eine ganze pro Schleife.
Auch enums sind toll, aber es geht auch ohne, und der Code ist auch weiterhin wartbar.
Nimmt man den Test und Portierungsaufwand hinzu, amortisiert sich die Sache also (je nach Entwicklerzahl) nach ein paar *Jahren*.
Aus Entwickler Sicht: klar, immer her mit den netten kleinen Extras, aber realistisch betrachtet, lohnt der Umstieg fast nur, wenn wichtige Bibliothek X Java Version Y braucht. *Das* ist ein Argument.


----------



## AlArenal (28. Feb 2008)

Ich sehe es wie Wildcard.

Zusätzlich frage ich mich, ob denn vor Java 5 niemand in der Lage gewesen ist Spaß an seiner Arbeit zu haben.


----------



## Saxony (29. Feb 2008)

AlArenal hat gesagt.:
			
		

> [...] nud man mal schaut was für olle Systeme, teils noch DOS-basierend allerorten im Einsatz sind,



Ich möchte in diesem Zusammenhang mal an COBOL erinnern.



			
				Monster.de hat gesagt.:
			
		

> *Jährlich bis zu 15 Millionen neue Cobol-Codezeilen*
> 
> Denn Totgesagte leben länger: Nach einer Gartner-Studie existierten im Jahr 2003 rund 200 Milliarden Codezeilen in Cobol - zwei Drittel der weltweiten Software. Betrachtet man allein Großanwendungen, werden drei Viertel dieser Programme in Cobol geschrieben, schätzt Tucek. Und laut Gartner kommen jährlich weltweit circa fünf Milliarden Cobol-Codezeilen für völlig neue Applikationen dazu. "85 Prozent des Welthandels laufen über Cobol", ergänzt Gerhard Goos, emeritierter Informatikprofessor der TH Karlsruhe. Vor allem Banken und Versicherungen, aber auch die Großindustrie und der Handel wollen sich in absehbarer Zeit nicht von dem stabilen, revisionsfähigen System verabschieden. "Sonst hätten sie bei der Jahr-2000-Umstellung nicht Milliarden Euro in die Aktualisierung gesteckt", begründet Acucorp-Spezialist Tucek. Anders als die moderne Konkurrenz laufe Cobol über Jahre ohne Unterbrechung, "während man bei Windows oder Java einen Absturz pro Woche allgemein akzeptiert". Er nennt Cobol den Dieselmotor der Softwareindustrie: altmodisch, aber zuverlässig.



Aus diesem Grund werden auch immer wieder neue COBOL Programmierer gesucht um die alten Systeme zu pflegen.

Weiters kann hier nachgelesen werden.

bye Saxony


----------



## Janus (29. Feb 2008)

das liegt aber schlicht daran, dass jahrelang niemand aufgepasst hatte und sich der ganze cobol code stickum heimlich in unwartbare spaghettimonster verwandelt hat. das risiko einer neuentwicklung ist zu hoch, die system funktionieren (zuverlässig) und es finden sich immer noch leute, die cobol beherrschen.

das ist aber bei weitem kein grund, cobol zu unterstützen. wenn es nach mir geht, gehört der ganze cobol müll in die tonne. aber wie bereits erwähnt: portierung nahezu ausgeschlossen.


----------



## tfa (29. Feb 2008)

Wildcard hat gesagt.:
			
		

> Ausserdem machst du dir die Sache zu einfach. Ich bin auch für einen Java 5 Umstieg, wenn ich das allerdings verantworten müsste, wäre ich auch gegen einen Umstieg solange er keine markanten Vorteile bringt.


Uns sind die Vorteile markant genug. Und überhaupt versteh ich nicht, warum man so viel Angst davor hat, die Verantwortung zu übernehmen. Verantwortung gehört zum Job. Es sei denn man möchte ein Programmierknecht sein, der gesagt bekommmt, auf welche Knöpfe er zu drücken hat. 


> > Ich sehe die neuen Sprachfeatures von Java 5 nicht nur als syntactic sugar. Sie haben einen direkten Einfluss auf die Code-Qualität und Wartbarkeit, was letztendlich die Entwicklungszeit verringert und somit Kosten spart.
> 
> 
> Ja, sogar massiv. Durch foreach spart man mindestens eine halbe Sekunde, wenn nicht eine ganze pro Schleife.
> ...


Warum beschränkt ihr euch ständig nur auf die Billig-Features. Enums, Foreach, geglättete Schriftarten?  :bahnhof: 


> Aus Entwickler Sicht: klar, immer her mit den netten kleinen Extras, aber realistisch betrachtet, lohnt der Umstieg fast nur, wenn wichtige Bibliothek X Java Version Y braucht. *Das* ist ein Argument.


Das halte ich eher für unwahrscheinlich.


----------



## tfa (29. Feb 2008)

Saxony hat gesagt.:
			
		

> Ich möchte in diesem Zusammenhang mal an COBOL erinnern.
> [...]
> Weiters kann hier nachgelesen werden.


Also erstmal: glaube nicht alles, was in der Zeitung steht, nur weil es in der Zeitung steht. Zumal hier
ein "Cobol-Anbieter" interviewt wird, der etwas verkaufen will. Was erwartest du, das er sagt? 

Ich war die letzten Jahre damit beschäftigt, ein altes robustes Cobol-System auf Java zu portieren. 
Das alte hat gut funktioniert und hatte viele Anwender, ein typisches "Running System" eben. 
Es würde sicherlich auch heute noch funktionieren. Aber irgendjemand hatte die Ambitionen (und den
Mut, die Verantwortung zu übernehmen), etwas neues in Java machen zu lassen. Das System früher
bestand aus Eingabemasken im Textmodus, in die endlose Zahlenkolonnen eingehackt wurden. Jetzt können
z.B. online technische  Zeichnungen online angesehen werden, Arbeitsabläufe per Videofilm analysiert werden,
Montagelinien grafisch dargestellt werden (auf Wunsch in 3D), usw. Kein Wunder, dass die Produktivität dadurch 
gesteigert wurde. Von den Anwender trauert -- nach anfänglicher Skepsis -- auch keiner dem alten Cobol-System 
nach.  Außerdem: warum gibt es so sehr viel mehr  Stellen für Java oder C# als für Cobol. Irgendwas stimmt doch da nicht...
Ich glaube ich schweife ins allgemeine ab, es ging ja nur um ne neue Java-Version.


----------



## tuxedo (29. Feb 2008)

Das "Skepsis-Verhalten" bzgl. neuer Versionen von Software (mit Java als exemplarisches Beispiel) erinnert doch irgendwie an die Tage, in denen Dampfmaschinen erfunden wurden:

"Wie? Eine Kutsche ohne Pferde aus viel neumodischem Stahl welche sich wie von Zauberhand alleine bewegt? Das muss vom Teufel persönlich sein..."

LOL

Bin ganz tfa's Meinung...


----------



## AlArenal (29. Feb 2008)

Saxony hat gesagt.:
			
		

> Aus diesem Grund werden auch immer wieder neue COBOL Programmierer gesucht um die alten Systeme zu pflegen.



Ich stolperte erst dieser tage über eine Produktnews von ILOG bzgl. Rules for COBOL. Und ich dachte immer ILOG würde exklusiv auf Java stehen...


----------



## AlArenal (29. Feb 2008)

tfa hat gesagt.:
			
		

> Und überhaupt versteh ich nicht, warum man so viel Angst davor hat, die Verantwortung zu übernehmen. Verantwortung gehört zum Job. Es sei denn man möchte ein Programmierknecht sein, der gesagt bekommmt, auf welche Knöpfe er zu drücken hat.



Man beißt nicht die Hand die einen füttert, denn dazu sitzt man am falschen Ende der Nahrungskette. Wenn man für Kunden entwickelt muss man den Weg gemeinsam mit dem Kunden bestreiten und ihm eine Lösung auch dann bieten können, wenn man sich nicht alles aussuchen kann.
Es ist noch nicht so lange her, da konnten wir nicht mit Ressourcen um uns schmeißen, sondern mussten um jedes Byte Speicher und jeden Taktzyklus kämpfen. Da haben auch nicht alle genöllt sie hätten keinen Spaß und wollten nicht Knecht eingeschränkter Systemressourcen sein 



			
				alex0801 hat gesagt.:
			
		

> Das "Skepsis-Verhalten" bzgl. neuer Versionen von Software (mit Java als exemplarisches Beispiel) erinnert doch irgendwie an die Tage, in denen Dampfmaschinen erfunden wurden:
> 
> "Wie? Eine Kutsche ohne Pferde aus viel neumodischem Stahl welche sich wie von Zauberhand alleine bewegt? Das muss vom Teufel persönlich sein..."
> 
> ...



Und kann der Lokführer etwa bestimmen auf welche Technik sein Brötchengeber setzt?


----------



## tuxedo (29. Feb 2008)

>> Und kann der Lokführer etwa bestimmen auf welche Technik sein Brötchengeber setzt?

nein, kann er nicht. Aber wenn er einen klugen Brötchengeber hat, dann hat der sich zuerst die altbewährte Pferde-Kutsche angesehen und danach das "moderne Werk des Teufels" und sich dann entschieden was für ihn besser ist.

An vielen Stellen dieser Diskussion wird ja von vornherein gesagt: "Nö, wieso updaten wenn's das alte auch tut?". Man sollte sich nicht gegen Neuerungen (in diesem Fall Bugfixes, bessere Performance, weitere Pflege durch den Hersteller, ...) scheuen. Auch wenn man die neuere technik/Technologie nicht einsetzt: Man sollte sie zumindest objektiv betrachtet und Nutzen und Gefahren abgeschätzt haben. Gleich zu sagen: "Nö, kommt nicht in Frage" ist das von mir im letzten Post beschriebene "uralte" Verhalten.

- Alex


----------



## HLX (29. Feb 2008)

alex0801 hat gesagt.:
			
		

> ]nein, kann er nicht. Aber wenn er einen klugen Brötchengeber hat, dann hat der sich zuerst die altbewährte Pferde-Kutsche angesehen und danach das "moderne Werk des Teufels" und sich dann entschieden was für ihn besser ist.



Nun hat der Brötchengeber das "moderne Werk des Teufels" gekauft als es hochmodern war. Nach 2 Jahren allerdings gab es neues, noch bessers Teufelswerk - und die Lokführer mussten damit leben, weiterhin auf ihren 2 Jahre alten Ranzkisten zu sitzen, während die Kollegen von der U-Bahn Niemandsland bereits tolle Konsolen mit geglätteter Schrift im Cockpit hatten.  :wink:


----------



## tuxedo (29. Feb 2008)

Ich sagte ja: Wie die entscheidung ausfällt ist Sache des entscheiders. Aber der Entscheider hat halt nix zu entscheiden wenn er nicht die Wahl hat weil er der Meinung ist, dass nix über die alte, gutbewährte Pferdekutsche geht und alles "neumodische", ohne es genauer betrachtet zu haben, zu viel Risiko mit sich bringt. 

DAS ist der Knackpunkt. 

Soll heissen: Ja, man muss immer und immer wieder den Entscheiden klar machen: Hey, da gibts ne Alternative. Wir sollten uns das mal im Detail anschauen und nicht von vornherein verwerfen. Denn wenn man drauf wartet, dass die Entscheider von selbst drauf kommen, dann kann man lange warten.

- Alex


----------



## tfa (29. Feb 2008)

AlArenal hat gesagt.:
			
		

> Man beißt nicht die Hand die einen füttert, denn dazu sitzt man am falschen Ende der Nahrungskette. Wenn man für Kunden entwickelt muss man den Weg gemeinsam mit dem Kunden bestreiten und ihm eine Lösung auch dann bieten können, wenn man sich nicht alles aussuchen kann.


Nichts weiter will ich. Gemeinsam mit dem Kunden neue Möglichkeiten ausprobieren, Berater machen sowas.


> Es ist noch nicht so lange her, da konnten wir nicht mit Ressourcen um uns schmeißen, sondern mussten um jedes Byte Speicher und jeden Taktzyklus kämpfen. Da haben auch nicht alle genöllt sie hätten keinen Spaß und wollten nicht Knecht eingeschränkter Systemressourcen sein


Du vielleicht nicht. Aber irgendjemand wird irgendwann genölt haben. Sonst hätten wir ja immer noch 
eingeschränkte Systemressourcen. 


> alex0801 hat gesagt.:
> 
> 
> 
> ...


Wenn du dich mit einem Lokführer gleichsetzen willst, bitte...


----------



## Wildcard (29. Feb 2008)

tfa hat gesagt.:
			
		

> Im Moment werden Argumente für Version 6 gesammelt:
> ...
> 
> Fällt jemandem noch ein Vorteil ein?


Wenn du in einem Internet Forum nach Argumenten fischen musst, dann ist die Notwendigkeit offensichtlich nicht wirklich groß, sonst hättest du bereits zwingende Argumente.
Ist wohl eher ein frommer Wunsch geboren aus einer gewissen Technik Affinität. 
Es spricht ja auch nichts dagegen diesen Vorschlag zu unterbreiten, ein Entwickler sollte die Entscheidungsträger darüber informieren wie sie die Produktivität maximieren können. 
Die andere Seite ist, das in diesem Thread die einhellige Meinung zu bestehen scheint, das selbige Entscheidungsträger rückständig seien. 
Das kann man meiner Meinung nach so nicht stehen lassen, sie sind in einer anderen Position und müssen Risiken und Wirtschaftlichkeit abwägen.
Wenn ihr an deren Stelle wärt, würdet ihr (sofern ihr euren Job gut macht) auch nicht anders denken.
Der Umstieg lohnt erst bei echtem Mehrwert, der die Testzeit, Migration und die Risiken rechtfertigt.


----------



## AlArenal (29. Feb 2008)

Ich denke ihr verkennt die Situation. Wenn es bei euch möglich ist mit dem Kunden zu sprechen und ihn auf dem kurzen Dienstweg dazu zu bekommen Java 6 abzunicken - toll!

Ich berichtete aber von großen Konzernen, wo du das knicken kannst! Konzerne, wo Unternehmensanwendungen ausschließlich in eigenen Rechenzentren laufen dürfen und für die man Genehmigungsverfahren durchlaufen muss, als wolle man ne Audienz beim Papst. Da kann man mal kungeln, stattdessen irgendwo in einem Büro nen Rechner ins Netz zu stellen der den Server macht (bei kleineren Sachen die nur standortbezogen benötigt werden), aber ansonsten bist du gearscht. 

Da die deren Userprofile komplett zentralisiert gemanaged werden, kann du auf den Clients nada installieren (du hast eh keine Admin-Rechte) und um ein Go für Java 5 für Clients zu bekommen, muss der Antragsteller ohne Ende Zeit und Geld mitbringen. Da kannst du noch so sehr betteln und speichellecken, da wirst du nichts dran ändern können. Da haben auch die Deutschland-Zentralen nichts zu melden. 
Es ist sogar so, dass wir bei meinem Ex-Brötchengeber mal ein Problem hatten, welches ich auf Netzwerk/Firewall zurückführte. Aber nichtmal die Standort-IT hat die Möglichkeit die Regeln auch nur einzusehen, geschweige denn daran was zu drehen. Was nur blieb war ne Anfrage in die USA zu schicken....

AFAIK ist die BP der einzige Kunde von MS; für den MS Kundenanpassungen durchführt. Die gehen dort mit ihrem Code of Conduct und dem Prozessmanagementhandbuch ins Bett. Ganz andere Umgebung als bei irgendeinem Krauter oder Mittelständler...


----------



## AlArenal (29. Feb 2008)

tfa hat gesagt.:
			
		

> Wenn du dich mit einem Lokführer gleichsetzen willst, bitte...



Jedenfalls bin ich nicht der Chef meiner Kunden. Ich kann beraten, aber ob der Rat angenommen wird, ist allein deren Entscheidung. Wenn ich damit nicht leben kann, muss ich mir nen anderen Beruf suchen.


----------



## HLX (29. Feb 2008)

Wildcard hat gesagt.:
			
		

> Die andere Seite ist, das in diesem Thread die einhellige Meinung zu bestehen scheint, das selbige Entscheidungsträger rückständig seien.


Bitte? Stimmt doch garnicht.

Ich z.B. habe die gleichen Erfahrungen wie AlArenal gemacht und stimme ihm daher (wie einige Andere) voll zu.


----------



## Wildcard (29. Feb 2008)

HLX hat gesagt.:
			
		

> Bitte? Stimmt doch garnicht.


Nichts für ungut, ich bezog mich auf die lautstarke Gegenseite für die wir 'gebrannten Kinder' wohl feige bis rückständig erscheinen...


----------



## tfa (29. Feb 2008)

Wildcard hat gesagt.:
			
		

> Wenn du in einem Internet Forum nach Argumenten fischen musst, dann ist die Notwendigkeit offensichtlich nicht wirklich groß, sonst hättest du bereits zwingende Argumente.
> Ist wohl eher ein frommer Wunsch geboren aus einer gewissen Technik Affinität.


Das ist Unsinn. Ausreichend Argumente waren schon vorhanden (du hast sie nicht mitzitiert). Mich hat nur interessiert, ob jemandem noch andere Vorteile einfallen. 


> Es spricht ja auch nichts dagegen diesen Vorschlag zu unterbreiten, ein Entwickler sollte die Entscheidungsträger darüber informieren wie sie die Produktivität maximieren können.


Nichts weiter will ich.

Wenn ich mir eure Erzählungen und Meinungen so durchlese, muss ich sagen, dass ich mit einem
momentanen Projekt, der Projektleitung und den Kollegen wohl unglaubliches Glück gehabt habe. 
Die sehen die Sache jedenfalls aufgeschlossener und progressiver...


----------



## Wildcard (29. Feb 2008)

tfa hat gesagt.:
			
		

> Das ist Unsinn. Ausreichend Argumente waren schon vorhanden (du hast sie nicht mitzitiert).


      * Allgemeine Verbesserung der Performance
Für den Kunden irrelevant solange es nicht schon performance Probleme gibt
      * Verbesserte GC-Algorithmen
Für den Kunden ebenfalls irrelevant
      * Geringerer Speicherverbrauch
Nur interesant bei 1. Größeren Programmen 2. schwachen Systemen
      * geglättete Schriftarten
Kann auch mit Java 1.4 gemacht werden
      * bessere plattformspezifischen Look&Feel unter Swing
Für den Kunden irrelevant (zumindest in fast allen Zielgruppen)
      * besseres HTML-Rendering
Schreibt ihr einen Browser?
      * erweiterte API für z.B. Webservices, XML
Nur neue Bibliotheken in der Klassenbibliothek, nichts was man nicht selbst linken könnte


----------



## tfa (29. Feb 2008)

Woher willst du wissen, was für _meinen_ Kunden in meinem Projekt relevant ist und was nicht??


----------



## Saxony (29. Feb 2008)

tfa hat gesagt.:
			
		

> Woher willst du wissen, was für _meinen_ Kunden in meinem Projekt relevant ist und was nicht??



Wildcard is der einzige hier im Forum mit ner Glaskugel.


----------



## Wildcard (29. Feb 2008)

Also tut mir leid, aber verbesserte GC Algorithmen mögen für eine hochlast Serveranwendung relevant sein, aber das passt nicht mit 'verbessertes Look and Feel' zusammen.
Überhaupt ist Performance immer nur relevant wenn sie ein Problem ist. Wenn ihr massive performance Probleme habt, und es mit Java 6 deutlich besser läuft, dann ist es definitiv ein Argument.



> * bessere plattformspezifischen Look&Feel unter Swing
> Für den Kunden irrelevant (zumindest in fast allen Zielgruppen)


Wie du siehst hab ich's eingeschränkt. Für sehr spezielle Zielgruppen kann das tatsächlich ein Faktor sein. Ob es für dich relevant ist, kann nur dein Kundenkreis beantworten.


----------



## maki (29. Feb 2008)

Für meinen aktuellen Kunden sind das keine Gründe (kann aber bei anderen kunden anders sein), das einzige was hier zieht ist eben die "Angst" Masche: Keine Updates für Bugs und Sicherheitslöcher, stellen sie sich vor, es passiert etwas... bitte bedenken sie...


----------



## bronks (29. Feb 2008)

Das Hauptproblem liegt darin, daß eine Software in einer JVM einwandfrei funktioniert und in einer aktuelleren JVM gibt es unvorhersehbare Probleme, die einen extremen Schaden anrichten können. Ich habe auch schon gesehen, daß ein Javaprogramm auf einem PC funktionierte, aber auf einem Computer nicht, obwohl die Version der JVM gleich war.


----------



## Jockel (29. Feb 2008)

tfa hat gesagt.:
			
		

> * erweiterte API für z.B. Webservices, XML


Witzig, dass in Java 6 JAX-WS 2.0 mitgeliefert wird, habe ich nur als störend empfunden und keineswegs als Vorteil. Ich hatte hier vor kurzem ein Projekt, welches JAX-WS 2.1 benötigte und habe es ums verrecken nicht zum laufen bekommen, da die JRE trotz aller Bemühungen sich nicht davon überzeugen ließ die 2.1er Version zu nehmen (und ja, mir ist der endorsed-Mechanismus bekannt). Kann auch sein, dass es zusätzlich noch woanders hakte, aber nach viel verschwendeter Zeit war ein Downgrade auf Java 5 die sinnvollste Lösung.


----------



## Gast (29. Feb 2008)

Hab alles nur ueberpflogen, also kann sein dass das Argument schon gefallen ist.

Fuer 1.5 spricht ganz klar:

GENERICS,

ANNOTATIONS

mehr muss man dazu eigentlich nicht mehr sagen....

Wer heutzutage keine Generics benutzt hat selber schuld....

Ebenso Annotation alleine das schreiben von UnitTest wird deutlich konfortabler.

Ein anderes Argument ist, dass viele Frameworks unter 1.4 nicht mehr lauffaehig sind oder in naher Zukunft sein werden.

Spring 3.0 wird mit Generics arbeiten...
JPA ,EJB 3.0 etc...

Fuer ein 1.6 spricht z.B. die isEmpty Methode bei Springs. Kleines aber nettes Feature...


----------



## Wildcard (29. Feb 2008)

Jockel hat gesagt.:
			
		

> Witzig, dass in Java 6 JAX-WS 2.0 mitgeliefert wird, habe ich nur als störend empfunden und keineswegs als Vorteil. Ich hatte hier vor kurzem ein Projekt, welches JAX-WS 2.1 benötigte und habe es ums verrecken nicht zum laufen bekommen, da die JRE trotz aller Bemühungen sich nicht davon überzeugen ließ die 2.1er Version zu nehmen (und ja, mir ist der endorsed-Mechanismus bekannt). Kann auch sein, dass es zusätzlich noch woanders hakte, aber nach viel verschwendeter Zeit war ein Downgrade auf Java 5 die sinnvollste Lösung.


Mit dem Problem hatten wir auch zu kämpfen. Noch ärgerlicher war allerdings, das JaxB integriert wurde. Jetzt müssen die Klassen nämlich neu generiert werden aus der integrierten JaxB Version, da der JaxBContext sonst nicht kompatibel ist.
Das wiederum führt dazu, das es ab dann nur noch mit Java 6 läuft, was inakzeptabel ist (zumal es mit Java 6 auch an vielen anderen Stellen knallt).


----------



## maki (29. Feb 2008)

> Ebenso Annotation alleine das schreiben von UnitTest wird deutlich konfortabler.


Annotations sind eigentlich ein "Feature" von dem ich sehr wenig halte, hab nix dagegen wenn sie im Rahmen eingesetzt werden und dann nur vor einer Methode und nicht mitten im Quellcode.


----------



## AlArenal (29. Feb 2008)

maki hat gesagt.:
			
		

> Für meinen aktuellen Kunden sind das keine Gründe (kann aber bei anderen kunden anders sein), das einzige was hier zieht ist eben die "Angst" Masche: Keine Updates für Bugs und Sicherheitslöcher, stellen sie sich vor, es passiert etwas... bitte bedenken sie...



Aber was ist wohl wahrscheinlich, die plötzlich in einer recht alten und lange auf dem Markt befindlichen VM gefundenen tollen neuen Sicherheitslöcher, oder Sicherheitslöcher im neuesten Flaggschiff, mit dem noch nicht so viele Erfahrungen vorliegen? 

Und überhaupt: Auf alten Pferden lernt man das Reiten! 

Was übrigens den angeführten Performance-Aspekt von Java 6 angeht:
Wer mit Java 5 massive (! - so wurde hier geschrieben) Performance-Probleme hatte, dem hilft doch unter Beibehaltung aller anderen Parameter nicht allein ein Update auf Java 6. Das müsste ja schon ein allgemeiner Performancegewinn um Größenordnungen sein. 

Hey, das soll kein Aufruf sein jetzt irgendwelche Mikrobenchmarks rauszuwühlen


----------



## byte (29. Feb 2008)

Ehrlich gesagt erstaunt es mich doch sehr, was ich auf den letzten vier Seiten lesen musste. Ich kann einfach nicht glauben, wie ein Java-Entwickler leugnen kann, dass es massive Unterschiede zw. Java 1.4 und Java 5 gibt und dass diese eben nicht nur kosmetischer Natur sind.
Ganze vier Seiten hats gedauert, bis es ein Gast mal auf den Punkt bringt:



			
				Gast hat gesagt.:
			
		

> Hab alles nur ueberpflogen, also kann sein dass das Argument schon gefallen ist.
> 
> Fuer 1.5 spricht ganz klar:
> 
> ...



Ich kann nur voll und ganz zustimmen. Alleine die Tatsache, nicht Hibernate Annotations nutzen zu können, wäre für mich persönlich ein no-go, von Generics ganz zu schweigen. Ich habe nicht schlecht gestaunt, diesbezüglich Argumente zu lesen à la "früher gings doch auch ohne". Das ist natürlich ein prima Argumentationsstil, um auf der Stelle zu treten. Warum nicht gleich Lochkartenprogrammierung? Hat doch auch funktioniert.

Hier mal ein Beispiel dass die Mächtigkeit von Java 5 veranschaulicht:
Ein Kollege von mir leitet seit ein paar Monaten ein Projekt, wo ein Logistiksystem im Bahnbereich aufgebaut werden soll. Es wurde von Beginn an auf Java 6 gesetzt und massiv gebrauch von Annotations gemacht. Das Objekt Modell ist mit Hibernate Annotations gemappt, so dass Hibernate das DB Schema generiert. 
Der Clew ist nun, dass noch eigene Annotations definiert wurden. Ein eigens geschriebener Mechanismus liest die Annotations ein und generiert daraus automatisch die Swing GUI-Masken für die spätere Anwendung. Das Objektmodell ist derzeit wohl erst zu 20% fertig und wird stetig in Zusammenarbeit mit dem Fachbereich des Bahnunternehmens erweitert. Dank der Annotations spart man sich bei jedem neuen Objekt die Programmierung der GUI, da diese automatisch erzeugt wird.

Es tut mir wirklich leid, aber ich habe nur ein müdes Lächeln übrig für Leute, die die Java 5 Sprachfeatures als syntatic sugar abtun. Und noch mehr tuts mir leid, dass manchen Ihr Idealismus wohl schon komplett abhanten gekommen ist.


----------



## HLX (29. Feb 2008)

Wenn du die letzten 4 Seiten richtig gelesen hättest, wäre dir aufgefallen, dass die wenigsten aus freien Stücken bei älteren Java-Versionen bleiben. :roll:


----------



## maki (29. Feb 2008)

AlArenal hat gesagt.:
			
		

> maki hat gesagt.:
> 
> 
> 
> ...


Hey hey, ich sagte nicht das ich glaube was ich da sage 

Manchmal muss man eben seine Kinder ähhh... Kunden anlügen, weil man nur ihr Bestes (=Geld) will und für sich selbst den Komfort der aktuelleren Versionen *g*

Oder wie willst du deinem Kunden klarmachen dass er trotz hoher Kosten kaum Vorteile hat, dafür aber ein nicht zu unterschätzendes Risiko?


----------



## AlArenal (1. Mrz 2008)

byto hat gesagt.:
			
		

> Ich kann nur voll und ganz zustimmen. Alleine die Tatsache, nicht Hibernate Annotations nutzen zu können, wäre für mich persönlich ein no-go, von Generics ganz zu schweigen. Ich habe nicht schlecht gestaunt, diesbezüglich Argumente zu lesen à la "früher gings doch auch ohne". Das ist natürlich ein prima Argumentationsstil, um auf der Stelle zu treten. Warum nicht gleich Lochkartenprogrammierung? Hat doch auch funktioniert.



Bitte nicht verallgemeinern. Niemand schrieb er sei updateunwillig wegen grober Unlust. Nur kann es sich nicht jeder leisten im Stile von SAP das Wort "Kundenanpassung" als "Anpassung des Kunden an das Pordukt" durchzuführen und diesem dafür auch noch tief in die Tasche zu greifen.
Abgesehen davon verbringen wir nicht alle unsere gesamte Zeit damit völlig neue Projekte aus dem Nichts zu schaffen und völlig freie Hand bei der Planung zu haben. Und all die netten neuen Features in alten Code einpflegen? Gott-o-Gott... 



> Hier mal ein Beispiel dass die Mächtigkeit von Java 5 veranschaulicht:
> Ein Kollege von mir leitet seit ein paar Monaten ein Projekt, wo ein Logistiksystem im Bahnbereich aufgebaut werden soll. Es wurde von Beginn an auf Java 6 gesetzt und massiv gebrauch von Annotations gemacht. Das Objekt Modell ist mit Hibernate Annotations gemappt, so dass Hibernate das DB Schema generiert.
> Der Clew ist nun, dass noch eigene Annotations definiert wurden. Ein eigens geschriebener Mechanismus liest die Annotations ein und generiert daraus automatisch die Swing GUI-Masken für die spätere Anwendung. Das Objektmodell ist derzeit wohl erst zu 20% fertig und wird stetig in Zusammenarbeit mit dem Fachbereich des Bahnunternehmens erweitert. Dank der Annotations spart man sich bei jedem neuen Objekt die Programmierung der GUI, da diese automatisch erzeugt wird.
> 
> Es tut mir wirklich leid, aber ich habe nur ein müdes Lächeln übrig für Leute, die die Java 5 Sprachfeatures als syntatic sugar abtun. Und noch mehr tuts mir leid, dass manchen Ihr Idealismus wohl schon komplett abhanten gekommen ist.



Nun, wenn man die Wahl hat ist das schön. Wenn man diese nunmal nicht hat, muss man sich hier aber auch nicht so nen Stuss aufdrängen lassen müssen wie, dass man unproduzktiv wäre oder keinen Spaß an der Arbeit haben könne.

Klar emofinden viele es als schöner sich lieber neuen Dingen zu widmen, als Legacy Code zu pflegen, aber die Realität sieht anders aus. Es muss auch gut gewarteten alten Code geben, der eben nicht ständig neue Überraschungen parat hält und der solide und praktisch erprobt ist.

Wenn unsere Eltern so handeln würden, wie einige sich hier den Job des Entwicklers schönmalen, hätten die meisten von uns ihre eigene Geburt nicht erlebt. "Schatzo mein Bauch ist dick und ich muss ständig pullern - ich treibe ab! Lass uns ein besseres Kind 2.0 machen, dass kleiner ist und ne kürzere Tragzeit hat!"....

Ich erinnere mich vor Jahren gesagt zu haben, dass Webentwicklung öde geworden ist. Nun bin cih wieder mittendrin mit meiner meistgehassten Sprache PHP und zwar OHNE dessen OOP-Features. Spaß machts dennoch


----------



## Wildcard (1. Mrz 2008)

Al' mag zwar für ihn unüblich viele Schreibfehler gemacht haben, was für mich den Verdacht erweckt, dass er mindestens ebenso betrunken ist wie ich, aber viel besser kann man es dennoch nicht sagen:


> Nun, wenn man die Wahl hat ist das schön. Wenn man diese nunmal nicht hat, muss man sich hier aber auch nicht so nen Stuss aufdrängen lassen müssen wie, dass man unproduzktiv wäre oder keinen Spaß an der Arbeit haben könne.


----------



## Leroy42 (1. Mrz 2008)

Wildcard hat gesagt.:
			
		

> Al' mag zwar für ihn unüblich viele Schreibfehler gemacht haben, was für mich den Verdacht erweckt, dass er mindestens ebenso betrunken ist wie ich, aber viel besser kann man es dennoch nicht sagen:
> 
> 
> > Nun, wenn man die Wahl hat ist das schön. Wenn man diese nunmal nicht hat, muss man sich hier aber auch nicht so nen Stuss aufdrängen lassen müssen wie, dass man unproduzktiv wäre oder keinen Spaß an der Arbeit haben könne.


LOL!  :applaus:


----------



## byto woanners (2. Mrz 2008)

Einigen wir uns einfach darauf, dass keiner Unrecht hat.  Klar ist es in manchen Projekten den Aufwand nicht wert, auf eine neue Java-Version zu migrieren. In anderen hingegen geht das mehr oder weniger problemlos. Klar kann man auch ohne die neuen Sprachfeatures Spaß am entwickeln haben. Andererseits machts auch ne Menge Spaß, neues auszuprobieren.
Unterm Strich sind wir uns aber wohl einig, dass es durchaus Argumente gibt, die dafür sprechen, im Konzern zumindest die Möglichkeit zu bieten, eine aktuelle Version benutzen zu dürfen. Daher kann man ja durchaus nach Argumenten suchen, um die Obrigkeit zu überzeugen.


----------



## AlArenal (2. Mrz 2008)

Leroy42 hat gesagt.:
			
		

> Wildcard hat gesagt.:
> 
> 
> 
> ...



So ist das, wenn man nach Jahren erstmals wieder Bier im Haus hat..


----------

