IBMs - Java Strategie!!!

[Burgy Zapp]

1:1 Umwandlung kann eine interessante Sache sein (Zeit sparen) aber fast immer ist menschliche Überarbeitung nötig um den Code wieder zu optimieren und oder sprachenspezievische Vorteile nutzen zu können.
Vieleicht bietet es sich auch an einige alte Segmente kompett neu aufzusetzen und platformübergreifende Anwendungsschnittstellen komplett in Java umzusetzen. z.B. AS mit Internet oder AS mit PS etc.
Kenne mich mit AS/400 Programmiersprachen nicht besonders gut aus, habe aber festgestellt das z.B. Microsoft und mitschuldig SUN es geschafft haben das sich Java unter Windows immer wie ein Fremdkörper anfühlt. Das geht schon bei der grafischen Oberfläche los die alptraumhaft langsam ist.

Hallo Forum,
wir haben Kontakt mit einem Anbieter eines Tools, dass aus
RPG oder COBOL Programmen Java Programme 1:1
erstellen kann. Bei Bedarf kann ich gerne einen Kontakt
herstellen.

[BenderD]

Hallo,

ich würde zu beidem Widerspruch anmelden wollen:

1:1 Umwandlung kann eine interessante Sache sein (Zeit sparen) aber fast immer ist menschliche Überarbeitung nötig um den Code wieder zu optimieren und oder sprachenspezievische Vorteile nutzen zu können.
Vieleicht bietet es sich auch an einige alte Segmente kompett neu aufzusetzen und platformübergreifende Anwendungsschnittstellen komplett in Java umzusetzen. z.B. AS mit Internet oder AS mit PS etc.
Kenne mich mit AS/400 Programmiersprachen nicht besonders gut aus, habe aber festgestellt das z.B. Microsoft und mitschuldig SUN es geschafft haben das sich Java unter Windows immer wie ein Fremdkörper anfühlt. Das geht schon bei der grafischen Oberfläche los die alptraumhaft langsam ist.

1:1 Umsetzung macht keinerlei Sinn, insbesondere bei 5250 Anwendungen und Java. Die Ablaufumgebungen sind miteinander unvereinbar (im interaktiven Job läuft kein Java, in Java kein 5250). Sogenannte 1:1 Migrationen von 5250 in Browser basierte Anwendungen bringen eine prozedurale Anwendung in ein Multithreaded Umfeld, was bedeutet, dass entweder Multithreading nicht genutzt werden darf (schlechte Performance und Skalierbarkeit) oder die Anwendung instabil wird.
Im Endeffekt entsteht eine Situation, dass ich eine Anwendung in der einen Sprache schreibe und in einer völlig anderen Umgebung laufen lasse. Für eine RPG, COBOL oder andere native 5250 Anwendung einer AS400 gibt es allerdings keine bessere Ablaufumgebung als 5250.
Eine solche "Migration" stellt auch keinen Zwischenschritt auf dem Weg von prozedural nacht Obejkt orientiert dar, sondern verhindert ihn.

Was Java Programme unter Windows angeht, hat sich das längst gewandelt, dazu nur ein paar Beispiele:
- Die Java Anwendung WebSphere läüft unter Windows schneller und stabiler als unter OS/400.
- Die Java Anwendung Tomcat gehört zu den besten Servlet/JSP Servern des Marktes mit immenser Verbreitung und läuft auf nahezu allen Plattformen (iklusive Windows) performant und stabil.
- Die Java Umgebungen Eclipse und NetBeans sind in Java geschrieben und laufen bestens auf Windows, Linux und Co.
- Die Java Anwendung Open Office kann durchaus mit Micky Soft mithalten und das als Freeware.

mfg

Dieter Bender

[TARASIK]

Hallo Forum,
nicht dass es falsch verstanden wird: die Umsetung bietet
die Funktinalität der vorherigen Programmiersprache
erweitert durch Javafunktionen. Und wenn ich solche
Anwendungen auf der AS/400 laufen habe, brauche ich
keine Windows oder Linux Maschinen, welche einen
zusätzlichen Platz- oder Bedienaufwand erfordert.
Interessant wird das ganze mit dem neuen R530.

[Burgy Zapp]

Danke für die Richtigstellung BenderD klingt alles sehr richtig und logisch wengleich ich kein programmierer bin.

Eine Frage bleibt mir doch: Mit welcher grafischen Oberfläche laufen die von Dir genannten Java Programme. Denn die von SUN ist eine unverschämtheit auch wenn die Programme dahinter so gut sind wie die Natur selbst frist diese grafische Umsetzung der Bedienoberfläche fast all meine Systemresourcen.

Benutze mein Notebook nur zum arbeiten obwohl es ein T21 ist funzt w2k und alle von mir eingesetzte software wie Adobe etc schnell und flüssig. Dann habe ich mir ein winziges UML Programm (unter anderen) geholt das mit einer entsetzlichen Java Oberfläche läuft. Wenn mein Rechner nicht abschmiert braucht er 3 minuten um das winzige häuflein code zu öffnen.

Glaube mich aber an eine andere grafische Oberfläche von IBM für java zu erinnern die hervorragend war und sehr schnell und flüssig gerendert wird.
Gruß BZ

[BenderD]

Hallo,

Danke für die Richtigstellung BenderD klingt alles sehr richtig und logisch wengleich ich kein programmierer bin.

Eine Frage bleibt mir doch: Mit welcher grafischen Oberfläche laufen die von Dir genannten Java Programme. Denn die von SUN ist eine unverschämtheit auch wenn die Programme dahinter so gut sind wie die Natur selbst frist diese grafische Umsetzung der Bedienoberfläche fast all meine Systemresourcen.

Benutze mein Notebook nur zum arbeiten obwohl es ein T21 ist funzt w2k und alle von mir eingesetzte software wie Adobe etc schnell und flüssig. Dann habe ich mir ein winziges UML Programm (unter anderen) geholt das mit einer entsetzlichen Java Oberfläche läuft. Wenn mein Rechner nicht abschmiert braucht er 3 minuten um das winzige häuflein code zu öffnen.

Glaube mich aber an eine andere grafische Oberfläche von IBM für java zu erinnern die hervorragend war und sehr schnell und flüssig gerendert wird.
Gruß BZ

Schlechte Programme lassen sich in allen Programmiersprachen der Welt schreiben, die Schleifen zulassen, relativ einfach geht das mit allen Programmiersprachen in denen man dynamisch Speicher anfordern kann. Ich tippe mal darauf, dass das kein Java Phänomen ist.
Was das Aussehen der GUIs angeht, kann das Geschmacksache sein, oder eben auch eine Verirrung des Programmierers. Gute Java Oberflächen (verwenden Swing) sehen meist anders aus als MS/Windows, vielleicht ein wenig mehr X-Windows style, aber schlechter (oder auch besser) würde ich das nicht nennen.

Wenn das mit der IBM Oberfläche stimmen sollte, dann sollte denen mal jemand sagen, dass die das für den Ooops Nerv nehmen sollen.

mfg

Dieter Bender

[Burgy Zapp]

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

[BenderD]

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]

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.

[BenderD]

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

[MiPaff]

12345678901234567890

[BenderD]

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

[MiPaff]

12345678901234567890