View Full Version : IBMs - Java Strategie!!!
Burgy Zapp
19-05-04, 13:04
Ok, das mit dem Ooops Nerv werde ich bei gelegenheit weitergeben.
das IBM ding das ich im kopf hatte ist eine Datenbank Entwicklungsumgebung
Ja Xwin kommt hin ist ein wenig bläulich und dunkleres grau wir reden von der selben.
Aber es liegt sicherlich nicht an schlechter programmierung dieser software kenne andere Javabeispiele und die Oberfläche bremst enorm merke das weil mein prozessor mit 450 getaktet und etwas älter ist. Von dieser Oberfläche KANN ICH NUR ABRATEN
Sie ist sicherlich ästhetisch aber unter MS betriebssystemen sehr rechenintensiv habe mal einen befreundeten programmierer gefragt abe seine erklärung vergessen warum das dinn zwingend bremst.
Danke und bis bald
Gruß BZ
Hallo,
Ok, das mit dem Ooops Nerv werde ich bei gelegenheit weitergeben.
das IBM ding das ich im kopf hatte ist eine Datenbank Entwicklungsumgebung
Ja Xwin kommt hin ist ein wenig bläulich und dunkleres grau wir reden von der selben.
Aber es liegt sicherlich nicht an schlechter programmierung dieser software kenne andere Javabeispiele und die Oberfläche bremst enorm merke das weil mein prozessor mit 450 getaktet und etwas älter ist. Von dieser Oberfläche KANN ICH NUR ABRATEN
Sie ist sicherlich ästhetisch aber unter MS betriebssystemen sehr rechenintensiv habe mal einen befreundeten programmierer gefragt abe seine erklärung vergessen warum das dinn zwingend bremst.
Danke und bis bald
Gruß BZ
Das mag mit 450 MHz stimmen, da würde ich Open Office; Eclipse und NetBeans auch nicht draufwerfen. Aber 1 Giga mehr Taktfrequenz und 512 MB Hauptspeicher lassen das wahrscheinlich anders aussehen. Der Ressourcenverbrauch von Java GUIs ist ohne jeden Zweifel höher als der von gut geschriebenen C++ GUIs auf Windows. Und die Java Runtime sollte 1.3 oder besser noch 1.4 sein.
mfg
Dieter Bender
holgerscherer
21-05-04, 22:00
Nebenbei bemerkt ist OpenOffice.Org in C++ geschrieben und läuft auch wunderbar auf meiner alten P200-Schreibmaschine. Was man zum Beispiel von IBMs ServeRaid-Software (Java ohne Ende) nicht behaupten kann. Da braucht jeder Mausklick eine halbe Minute...
-h
Hallo,
Das mag mit 450 MHz stimmen, da würde ich Open Office; Eclipse und NetBeans auch nicht draufwerfen.
Hallo Holger,
Nebenbei bemerkt ist OpenOffice.Org in C++ geschrieben und läuft auch wunderbar auf meiner alten P200-Schreibmaschine. Was man zum Beispiel von IBMs ServeRaid-Software (Java ohne Ende) nicht behaupten kann. Da braucht jeder Mausklick eine halbe Minute...
-h
ich bin nicht der ausgeprägte Open Office Experte und habe das gesamte Paket irgendwo in der Java Ecke angesiedelt, nicht zuletzt, weil die eine JVM brauchen; eine aktuelle Redcherche zeigt, dass die Java Komponenten drin haben, aber welche, weiss ich nicht; der Rest (und vermutlich die Grafik) ist wohl C++ und wird auf Source Level portiert.
Was sie letztlich optisch eher nach Java Style als nach Micky-Soft aussehen lässt.
Zum eigentlichen Thema: Java Strategie und Java Performance muss man m.E. zwischen mehreren Faktoren sauber unterscheiden:
OO Programme (gilt für Java und C++) haben mehr Overhead als prozedurale und als Assembler, wenn man die OO Features nutzt.
Ablaufumgebungen mit einer VM (virtual Machine) brauchen mehr CPU (= MegaHertz und Prozessoren) als Rechner, die ihre Programme auf der Hardware ausführen (deshalb ist eine AS400 auch langsamer als die gleiche AIX).
Gute JIT (Just in Time Compiler) Umgebungen bringen Java Performance bei komfortabel ausgestattetem Hauptspeicher und schneller CPU nahe an C++ heran.
Ursachen schlechter Performance sind oft Programm bezogen und nicht Sprachbezogen. Gerade hier fallen aus dem Sumpf generierte Programme und von Wizards gezauberte durch den Rost. Aber auch von Verstand erzeugte können hier drunter sein. (Oft kann man die Fehler sehen, wenn man weiss wo man hingucken muss: Beispiel Ooops Nerv: im Database Navigator werden gnadenlos vertikal Daten in eine JTable in einer Scrollbar geknebelt bis der Rechner schlapp macht, was bei der Menge von Monitor Daten dann fast unvermeidbar ist.
Das Beste Argument für Java habe ich mal in der
news://comp.sys.ibm.as400.misc von einem RPG Hardliner um die Ohren gesäbelt bekommen: "Java is only the hope of lazy programmers" Die Büchsen werden immer schneller und ich immer älter - irgendwann wirds Zeit für Java.
mfg
Dieter Bender
12345678901234567890 :confused:
Hallo MIPaff,
die Erwartungen der AS400 Programmierer, wenn es denn eins von beiden oder beides gibt, mögen weit weg von Java sein, die Entwicklung spricht aber eine deutliche Sprache: 5250 Applikationen haben keine Akzeptanz beim Anwender mehr und die darauf basierende Software ist unverkäuflich geworden, ob einem das gefällt oder nicht, spielt dabei keinerlei Rolle. Die immer wieder kehrende Behauptung, dass die Programmierer Produktivität in RPG höher sei, ist durch nichts belegt: tausende von Subfile Programmen mit der immer wiederkehrenden gleichen (gut, ich gestehe zu: manchmal richtig, manchmal falsch) Logik sprechen dagegen; in Java würde man dies nicht ein einziges mal programmieren müssen, da gibt es sowas fertig, als Open Source Komponente.
Was die Programmierer Seite angeht, sind Java Programmierer heute wesentlich einfacher zu finden als RPG Programmierer. Java ist die vorherrschende Sprache an Hochschulen, Fachschulen und Berufs Schulen; RPG Programmierer muss man sich selber ausbilden, wenn man welche braucht. Es ist in jedem Fall einfacher einem RPG Programmierer Java beizubringen als umgekehrt; das ist zumindest meine Erfahrung.
Die Rolle, die ein AS400 als Datenbankserver im Java Umfeld spielen kann, ist eben nicht bestimmt von der vermuteten Schwierigkeit in Java Anwendungen mit Datenbanken umzugehen (hier seinen nur Hibernate oder OJB erwähnt, die den Datenbankzugriffscode vollständig generieren), sondern hängen einzig und alleine davon ab, ob DB2/400 im Vergleich zu Oracle und DB2/UDB von IBM Konkurrenz-fähig platziert wird - hier habe ich in den letzten Jahren manchmal Zweifel entwickelt.
Die Bemerkung zu den Klassenbibliotheken mag für C++ zutreffen, für Java ist das eine Bemerkung, die vermuten lässt, dass der bisherige Kontakt zu Java nicht sehr intensiv gewesen sein mag: Java hat standardisierte Klassenbibliotheken und in keiner anderen Umgebung ist die Verfügbarkeit an Open Source Komponenten ähnlich groß, wie in Java und in vielen Bereichen gibt es hier bereits etablierte Standards und in keinem Bereich tut sich hier mehr als in Java.
Ob IBM hier eine Rolle spielt und gegebenen Falls welche? Dieser Hersteller tanzt auf 4 Hochzeiten: Mainframe, Unix, OS400 und Windows, warum sollte ausgerechnet IBM daran was ändern wollen?
mfg
Dieter Bender
12345678901234567890 :confused:
Hallo,
zu den Perspektiven von 5250 Software gibt es offenkundig unterschiedliche Einschätzungen.
Die Vorgehensweise bei der Erstellung von Java Anwendungen unterscheidet sich stark von der in der klassischen AS400 Welt verbreiteten. Für wichtige Bereiche gibt es dort (Quasi) Standards:
Change Management => CVS
Deployment => Ant
Komponenten Tests => JUnit
Was die Datenbank angeht, muss diese eigentlich nur SQL können, die Administration der Datenbank erfolgt mit den Mitteln der Datenbank.
Mit dem Support und den Lizenz rechtlichen Fragen sieht das bei Open Source Projekten, wenn sie denn die kritische Masse haben wesentlich besser und stabiler als bei kommerziellen Lösungen aus. Die Verwender von SYNON zum Beispiel, Visual Age oder Office/400 sind weit schlechter gestellt als die Anwender von Apache, Tomcat, Ant, CVS oder JUnit und all der anderen Open Source Komponenten wie Struts oder Hibernate, um nur einige exemplarisch zu nennen je dastehen können.
Was die Tools angeht, insbesondere irgendwelche GUI Zauberkästen, so wird die Rolle selbiger weit überschätzt: in OO Sprachen braucht man sowas weit weniger (um nicht überhaupt nicht zusagen) als das in RPG oder COBOL hilfreich wäre. Irgendwelche Generatoren helfen nur bei der mehrfachen Erstellung des gleichen Codes - und das ist in einer OO Sprache wie Java bereits ein Design-Fehler.
mfg
Dieter Bender
12345678901234567890 :confused:
Das Problem ist sicher nicht verstanden worden. SQL statt Repository sagt alles!
Tschüssss. :confused:
Dass ich folgenden Satz nicht verstanden habe, gebe ich gerne zu, das kann nur an mir gelegen haben.
Die standardisierten Klassenbibliotheken von Java sind schon bekannt, nur was mir fehlt ist eine IDE bei der die Entwicklung nicht von der Erstellung des GUIs geprägt/geleitet sondern die Datenbank im Vordergrund sieht. Hier braucht es ein Repository (Datenkatalog), Tools zur Verwaltung der DB-Objekte (Tabellen, Views und Index) Tool zur Programmierung von Datenbank-Logik (Berechtigungen, Trigger und Constraints) natürlich in Java und Tool um die Datenbank einer Anwendung zu administrieren (Installation und Releasewechsel).
Vielleicht wäre das confused bei diesem Statement angebrachter gewesen!
Dieter Bender