Argumente für Java 6

[tfa]

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]

Hiho,

hier findest du sicher noch mehr Argumente:

1.5 Release Notes
1.5 Features
1.6 What's new



bye Saxony

 

[maki]

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

 

[Wildcard]

* geglättete Schriftarten
RenderingHints.KEY_TEXT_ANTIALIASING ?

 

[Wolfgang Lenhard]

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

 

[AlArenal]

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]

Kapitulation ist echt ein toller Tipp. :roll:

 

[byte]

* 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]

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]

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.

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]

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]

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]

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

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]

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]

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.

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]

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]

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]

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]

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]

@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]

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?

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]

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]

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]

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]

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]

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.

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.

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

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

 

[Wildcard]

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]

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]

[...] 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.

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]

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]

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

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]

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]

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]

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]

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

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

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

 

[tuxedo]

>> 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]

]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]

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]

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.

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

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

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

 

[Wildcard]

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]

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]

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]

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]

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]

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]

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]

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

 

[Saxony]

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]

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]

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