Java auf der AS400

Java ist Ressourcen intensiv und benötigt in erster Linie Mega Hertz an Prozessorleistung und GigaByte an Hauptspeicher und das multipliziert sich mit der Anzahl der JVMs, die man parallel betreiben will. Batch und Interaktive Leistung und CPW sind Java auch auf der AS400 ziemlich egal, was zählt sind schnelle Prozessoren der neuesten Baureihen.

Java läuft nicht besonders schnell auf einer AS400, auf kleineren Maschinen sollte man eher Enttäuschungen mit einkalkulieren; durch die große Skalierbarkeit der Plattform wird es dann im Highend auch schnell - die Stärke der AS400 liegt aber eher in ihrer Gutmütigkeit, die zuweilen mit einer gewissen Behäbigkeit einhergeht.

Die neueren Grafik Komponenten, die heute für Clients bevorzugt werden, sind im Package javax.swing enthalten und gehören damit zu den Erweiterungen, die auf der AS400 nicht implementiert ist. Die AS400 ist also eine typische Java Server Maschine und als Client nur eingeschränkt verwendbar.

Die wichtigsten anderen javax Packages gehören vorwiegend in die Ecke Server Java und werden zumeist durch die Installation eines Application Servers auf die AS400 gebracht. Die meisten Application Server sind Java Anwendungen und lassen sich somit auf der AS400 installieren; es gibt also durchaus Alternativen zu WebSphere, der als AS400 Lizenzprodukt auf die AS400 kommt. Manche Bestandteile von Java, wie zum Beispiel die XML Parser, sind auch als separate Packages im Web verfügbar - oft als Open Source und Freeware.

Die Sache Remote AWT hört sich zunächst ein wenig exotisch, aber harmlos an - ist es aber durchaus nicht: zum Package AWT gehören nicht nur die Mäuse und die Fenster, sondern auch die Druck Unterstützung, die es mithin auf der AS400 nicht gibt! Dafür empfiehlt IBM dann seine Toolbox für Java auf der AS400, dazu wird noch einiges zu bemerken sein!

Damals war in allen Empfehlungen angesagt fleißig CRTJVAPGM zu machen, obwohl die Kompilate damals sowenig wie heute, von den Classloadern der Application Server verwendet werden, WebSphere eingschlossen. Seit einiger Zeit hat die AS400 das, was IBM einen Just in Time (JIT) Compiler nennt, auch wenn das Ding trotzdem assoziierte statische Compilate erzeugt. Letzteres steht zwar nicht in der Doku, oder ich habe es nicht gefunden, aber seitdem jemand genau das in einer Newsgroup verlautbart hat, habe ich ihn angemailt und gefragt, woher er das so genau weiß - es war der Entwickler des Compilers. Ich war trotzdem ungläubig, aber ein Blick mit DSPJVAPGM belehrte mich eines besseren.

Mittlerweile lautet die Empfehlung eher JIT zu verwenden, was auch dem Default entspricht und das bedeutet, man macht garnix und das ist mir auch am sympathischsten. Zumal da meistens eh noch der Classloader einer ängstlichen Spinne oder einer Miezekatze dazwischen ist, dem das sowieso egal ist, der findet die assozierten Programme, so hidden und native die auch sein mögen, sowieso nicht und mittlerweile ist die resultierende Performance auch akzeptabel auf der AS400, wenn man denn genug davon hat. Wiewohl sich manchmal ein Versuch dennoch im wahrsten Sinne des Wortes rentieren kann, den Application Server auf einem + 2 GigaHertz Intel Rechner mit ebensoviel Giga Hauptspeicher laufen zu lassen.

Der Effekt von CRTJVAPGM ist ohnehin lediglich eine bessere Ladezeit der Java Programme. In Batchprogrammen ist das gerade bei Langläufern kein Thema, die Applkationsserver interessiert es sowieso nicht und vom Mix RPG Java rate ich eindeutig ab. Bleibt als Zone des Nachdenkens vielleicht noch ein Java Serverdienst. Die schnellste und radikalste Lösung ist ohnehin alles vorzustarten und dann ist JIT sogar im Vorteil! Hinzu kommt, dass die Strategie mit CRTJVAPGM ohnehin Auslaufmodell ist; der Mainstream in Java macht JIT auf allen Plattformen und das wird auf der AS400 auch noch die Leistungsfähigkeit erreichen, die es auf anderen Plattformen bereits hat - das dauert halt nur ein wenig länger.

Mit V5R4 ist da mehr oder weniger lautlos noch die 32 Bit JVM hinzugekommen, die hin vielerlei Kontext schneller als die 64 Bit Version ist; IBM hält sich da ein wenig bedeckt, es ist aber zu vermuten, dass die Original JVM von der AIX (neudeutsch p) in einer Art Pase Umgebung ist; installieren muss man selbige jedenfalls nicht zusätzlich. Unter V6R1 erscheint mir die AS/400 immermehr ein Gastbetriebssystem einer RS6000 zu sein, neben der 32 Bit JVM nähert sich die 64 Bit JVM auch immer mehr der p Variante an, zumindest wenn man der Doku glauben schenken will. Die einzelnen Java Runtimes werden jetzt auch analog zum Standard über Umgebungsvariable JAVA_HOME angesteuert; die Details hierzu findet man in der Doku des JDK für die AS/400.

Wenn man in einer OS400 Befehlszeile unvermittelt QSH oder STRQSH eintippt, dann landet man in einer anderen Welt, die für OS400 Kenner zumeist fremd ist und für manchen dem OS400 fremd ist, vertraut sein könnte. Was man jetzt vor sich hat, ist ein magerer, aber immerhin Unix prompt. Man könnte jetzt mit Herbert G. fragen: Was soll das?, aber was in diesem Zusammenhang interessiert, ist dass diese Unix Befehlszeile Java kann, von javac über jar bis java und dabei alle Parameter versteht, so wie sie eine jede Unix Befehlszeile eben versteht. Was mir an dem QSH Befehl am besten gefällt ist, dass man im Parameter CMD gleich einen Befehl für die Qshell mitgeben darf und das ist genau das, was ich bevorzuge, wenn ich aus einem OS400 Programm ein Java Programm starten will. Und hier lassen sich auch alle Einstellungen der Java Ablaufumgebung als Parameter für den Java Aufruf unterbringen und ich kann auf die mir eher suspekten Umgebungsvariablen verzichten.

Diese spezifische Charakteristik erfordert eine hinreichende Trennung verschiedener Ablaufumgebungen, wenn die Ressourcen optimal genutzt werden sollen. Problemlos ist das immer dann, wenn man für jede Workload einen eigenen Rechner hat; sobald man Anwendungen mit sehr unterschiedlichen Anforderungen auf derselben Maschine laufen lässt, wird manches komplexer. Wer hier das Schlagwort Server Konsolidierung im Hinterkopf hat, der muss sich auch Gedanken darüber machen, dass man nicht nur weniger Rechner zu betreuen hat, sondern auch kompliziertere Abläufe steuern muss. Nach meiner Erfahrung ist es durchaus positiv seine ersten Java Erfahrungen nicht auf der AS400 zu machen und dann über Konsolidierung nachzudenken. Der Versuch den umgekehrten Weg zu gehen wird oft unternommen, hat aber meist mehr negative als positive Auswirkungen. Insbesondere sieht man solchen Java Anwendungen oft an, dass sie für eine AS400 entwickelt wurden, bis hin zu stammelnden Feldnamen, fehlender Modularisierung, alle Komponenten static und was sonst in einem Java Programm noch alles RPG like aussehen kann.

Saubere Trennungen sind durch clustering auf der AS400 relativ elegant abzubilden, wenn die Hardware die Voraussetzungen dafür nicht mitbringt, hat man sowieso keine typische Java fähige AS400. Lässt man die komplette Verarbeitung auf einer einheitlichen Maschine laufen, sollte man zumindest die Hauptspeicher Anforderungen über Speicherpools voneinander trennen und muss dann natürlich die automatische Balancierung über die Änderung des Systemwertes QPFRADJ abschalten.

Java kennt Datenbanken und greift per JDBC auf Tabellen, Views, Procedures und Functions zu und mehr hat die AS400 hier auch nicht und mehr braucht man für neue Anwendungen kaum, allenfalls noch Streamfiles. Zu jedem AS400 spezifischen Schnörkel der Toolbox existiert eine Java Standard Alternative, die Leistungs fähiger ist als diese Sammlung von Work arounds, der mit Ausnahme des JDBC Treibers allenfalls nostalgischer Wert bescheinigt werden kann.

Das Grundproblem besteht nicht darin AS400 Spezifika in einer Java Anwendung abzubilden, sondern ist viel allgemeiner: es geht um die Einbindung vorhandener Komponenten und das anbieten neuer Komponenten unabhängig von der eingesetzten Technologie und dafür sind Lösungen zu suchen im Anwendungsdesign und die Technik liefert nicht Java und erst recht nicht RPG, sondern eher SQL CORBA, Web Services und andere Standards.

der native Treiber ist vom Typ 2 und läuft nur auf der AS400 und kann nur an die lokale Datenbank verbinden. Dieser Treiber ist Bestandteil des Java Developer Kits der AS400 und wird auch damit ausgeliefert. Diesem Treiber werden zuweilen Wunderdinge in Bezug auf die Performance nachgesagt, die sich nicht immer messtechnisch realisieren lassen. Momentan wird wesentlich häufiger von anderen Plattformen auf die AS400 zugegriffen als lokal, sodass dieser Treiber wesentlich seltener benutzt wird als der universellere Toolboxtreiber. Das hat in jedem Fall zur Folge, dass der Toolboxtreiber nach meinen Erfahrungen der ausgereiftere Treiber ist, für den Fehlerbehebungen auch schneller zu bekommen sind. Nach Messungen wird von mir auch beim Zugriff auf die lokale Datenbank oft der Toolboxtreiber bevorzugt.

Den Toolboxtreiber bekommt man als Bestandteil der AS400 Toolbox für Java, einem nicht separat Kosten pflichtigen Lizenzprogramm, oder in der Open Source Variante mit dem jtopen.jar (Mr. Google weiss wo). Die Open Source Variante ist in der Funktion umfassender und aktueller. Wenn man den Toolbox Treiber auf der AS400 verwendet, ist es von Vorteil eine statisch kompilierte Variante zu verwenden, die oft dieselbe Geschwindigkeit erreicht wie der native Treiber. Beim lizenzierten Treiber muss man ein Java Archiv mit associated JVAPGM in den Classpath aufnehmen; bei jtOpen bleibt nur der eigene compile mit CRTJVAPGM (was mir aber noch nie ohne Probleme gelungen ist). Bei den Treiber Properties habe ich früher für den extended dynamic support plädiert, der geringfügige Vorteile durch das cachen von Zugriffsplänen in einem sogenannten SQL Package bringen kann. Seit bei einem fehlerhaften Stand des Treibers enorme Laufzeitprobleme genau mit diesem Feature aufgetreten sind, ist mir der Einsatz zu riskant und ich rate mittlerweile definitiv davon ab. Das Schadenspotential überschreitet jeden von mir beobachteten Nutzen bei weitem. Ob ein Archiv statisch kompiliert ist, oder nicht, kann man auch einfach mit dem OS400 Command DSPJVAPGM selber prüfen.

Wenn wir schon bei den Treiber Einstellungen sind, die sollte man immer am SQL Standard orientieren und alle AS400 Sonderlocken meiden; das betrifft Commit level, naming conventions und natürlich auch sowas wie LIBL. Für mich ein Anachronismus ersten Ranges, nicht nur in Java. Erst entscheidet man sich für eine Datenbank mit referentieller Integrität und allem Schnickschnack und dann programmiert man nach dem Muster seh mal zu wo du passende Dateien findest und gibt sich selbst damit zufrieden, dass eine halbe Buchung in die Testumgebung geschrieben wird und die andere Hälfte in die Echtumgebung (und sage da keiner: das ist noch nie passiert).

Wenn es denn WebSphere auf der AS400 sein soll, dann versuchen Sie das garnicht erst auf einem kleinen oder alten System; zum produktiven Einsatz ist das dann eh' nicht schnell genug und zum spielen macht Tomcat auf Intel unter Linux oder selbst mit Windows mehr Spass. Beim Stichwort Tomcat: der läuft auch auf AS400 und nicht einmal schlecht.

Wer jetzt glaubt, dass es aber einfacher und schneller ist das alles auf einer Büchse laufen zu lassen, der sollte bevor er weiter denkt erst mal zählen: jeder Serverdienst, der intensiv genutzt wird braucht einen eigenen Prozessor, sonst wird das nix! Unter Zwei Prozessoren ist also eine Webanwendung nicht flott zum laufen zu bringen, einer für die Servlet Engine und einer für die Datenbanklast. Hat man dann noch einen EJB Server, dann sind wir schon bei drei, kommt interaktive Workload hinzu, sind es vier, wenn die nicht darunter leiden soll. Im Grunde hat jede JVM genügend Last, dass sie eine eigene CPU beschäftigen kann, Nachtigall ick hör dir trappsen, fällt mir doch gerade ein warum man Java aus RPG relativ einfach aufrufen kann.

Sollte der Abzählreim ergeben haben, dass man alles auf einer Büchse haben will, dann sollte diese sorgfältig skaliert werden, selbstredend von jemand, der sich mit AS400 und Java auskennt (ich habe schon Maschinen gesehen...), neue CPUs massig Hauptspeicher, schneller L2 Cache, schnelle und ausreichend viele Platten - sonst landet man später ohnehin wieder bei dezidierten Systemen für jeden Server. Nicht zu verschweigen ist auch, dass man am Workmanagement nacharbeiten muss, damit WebSphere beim Start die AS400 nicht zum PC machen kann; und QPFRADJ muss selbstredend abgestellt werden, damit die ausbalancierte Ressourcenverteilung nicht wieder auf eine Seite umfällt. In vielen praktischen Projekten hat sich schnell herausgestellt, dass zwei Rechner schneller waren als einer und billiger sind die dann zumindest in der Anschaffung.

Mit RPG und COBOL400 sieht das noch ein wenig komplizierter aus, da kommen zu den bei C Java Mix auftretenden Problemen noch technische Probleme hinzu und der Programmierstil des typischen COBOL oder RPG Entwicklers unterscheidet sich doch ein wenig vom gängigen C-Stil und ist weit entfernt vom typischen Java Stil und Objekt orientiertem Denken. Technisch gesehen sind die Java und die RPG/COBOL Ablaufumgebung miteinander komplett inkompatibel. Java läuft nur in einem Multi-threaded Umfeld, das erfordert schon der sogenannte garbage Collector, RPG und COBOL haben dagegen eine runtime, die nicht threadsafe ist, also im Multithreaded Umfeld instabil wird (unpredictable results nennt man das dann in technical references). Den Java Effekt erkennt man daran, dass sogenannte BCI (Batch immediate) Jobs auftauchen, sobald Java die Bühne betritt, an den RPG/COBOL Effekten hat man rumgedoktort mit Compile Options, die das Problem aber auch nicht vollständig beheben.

Die technische Lösung besteht letztlich darin, dass man innerhalb desselben Jobs tunlichst nur Java oder nur RPG laufen lässt und dann gegebenen Falls asynchron über Queues miteinander kommuniziert. In RPG hat man den synchronen Aufruf von Java sogar in den Compiler eingebaut, der daraus JNI Aufrufe generiert; offenkundig eine Hardware Absatz fördernde Maßnahme von IBM. Hier wird in jedem Job, der solche Aufrufe macht eine eigene JVM gestartet, die beim Start in der Größenordnung sec. CPU zieht und im Betrieb in der Größenordnung 100 MB Speicher braucht: Da kann einiges zusammen kommen, wenn das flott gehen soll.

Wir können aber doch nicht alles neu schreiben, gehört zu den häufigen Argumenten, mit denen ich oft konfrontiert werde. Das erste, worüber man sich klar werden muss (unabhängig von Java) ist, dass es Software gibt, die nicht mit vertretbarem Aufwand gerettet werden kann: die läuft bis zum Ground Zero und dann muss völlig abgelöst werden. Wenn vorhandene Software modular aufgebaut ist, dann sehen die Voraussetzungen zur Modernisierung besser aus, dann gibt es natürlich Komponenten, zum Glück meist in der sogenannten Business Logic, die weiter verwendet werden können. Heute würde man solche Komponenten außerhalb des AS400/RPG Ghettos (dieser Ausdruck brachte mir mal eine gelbe Karte in einer Java Mailing Liste ein) als CORBA Komponenten, WebServices, oder als Message Driven Beans einbinden, alles Dinge für die im AS400 Umfeld keine standardisierten Lösungen als Middleware vorhanden sind. In vielen konkreten Fällen geht es aber auch eine Nummer kleiner und eine Handvoll Schnittstellen Funktionen reichen aus, um vorhandene Komponenten in Java einzubinden und Java Dienste für RPG und COBOL Anwendungen verfügbar zu machen.

Aus der Sicht von Java ist für Übergänge zur nicht Java Welt für synchrone Aufrufe, die dann im Prozess der JVM laufen, das Java native Interface (JNI) vorgesehen. Für nicht Java Aufrufe bedeutet das, dass man eine Java Methode als native deklariert und dann generiert man sich beim Java Compile daraus einen C Prototypen, ILE Programmierern sollte das vielleicht was sagen, den man dann mit einer C Funktion implementieren muss. Rein theoretisch könnte man diesen C Prototypen dann auch in RPG implementieren, aber wer kann das schon (außer T*R und B*M und S*K) und wenn man es täte, dann scheitert das am Multithreading (ja, ich weiß, das es da Erweiterungen am ILE gibt... ab V6R1 hätte man da wirklich eine Chance, aber vorhandene RPG Programme haben an sowas nie gedacht!!!).

Java hat auch asynchrone Wege anzubieten, mehr als sich ein RPG Programmierer meist so vorstellt, aber alle scheitern letztlich daran, dass RPG keinen der gängigen Standards unterstützt und der übrigbleibende Möchtegern-Standard MQ-Series im AS400 Umfeld selten zu finden ist. Für Aufrufe von Java nach RPG wäre das ohnehin Overkill, da es da einfachere Wege gibt. Für die Einbindung von Komponenten verwendet man gemeinhin Enterprise Java Beans, WebServices oder CORBA, aber all dies ist in der Welt von RPG nicht vorgesehen und die zarten Pflänzchen, wo einige Enthusiasten versuchen RPG mit XML zu verknoten konnten mich bisher nicht überzeugen.

Die Java Toolbox, sprich das Projekt jt400, hat eine ProgrammCall Klasse anzubieten, aber je mehr ich micht mit dieser DollSchachtel beschäftige, umso weniger mag ich diese in Java gegossene RPG Denke. Die Verwendung eines proprietären Serverdienstes wäre noch zu vertreten, wenn wenigstens dieses PCML zu gebrauchen wäre. Als ich das erste Mal im CRTRPGMOD über den Parameter PGMINFO gestolpert bin, dachte ich zunächst warum sagt einem das keiner früher, was es hier für tolle Sachen gibt und habe erwartungsfroh *PCML da rein getippt, um mich während des Compiles meinem Kaffee widmen zu wollen, den ich sicher verschüttet hätte, wenn ich schneller zur Tasse Java gegriffen hätte: der Compile eines in Produktion befindlichen Moduls ist schnöde abgeschmiert. Entsetzen machte sich bei mir breit, eine Quelle, die sich nicht wandeln lässt und das Modul in Produktion und kein CVS weit und breit... es war nicht das Modul, PCML geht nur, wenn keine Rückgabe Parameter verwendet werden, oder eine integer zurück gegeben werden. Verwendbar ist das also ohne Probleme für OPM Programme und alte MS DOS Schinken, die einen ERRORLEVEL zurück geben (sowas gibts auch bei C). Da rate ich lieber von ab, eh jemand auf die Idee kommt, dass man kein ILE oder kastriertes ILE macht, damit das dann besser mit Java zusammen passt.

Ich habe mir das Beste (unter Blinden ist der Einäugige König) bis zum Schluss aufgehoben, übrig bleibt der Aufruf von stores Procedures über JDBC. Auf keiner anderen Plattform ist es so einfach jede vorhandene Komponente zur stored Procedure und damit auch aufrufbar über JDBC zu machen, wie auf einer AS/400 und nachedem DB2/400 nicht mehr UDB heißt, wird sich das auch nicht mehr ändern. Der JDBC Treiber übernimmt die Konvertierung der Parameter, JDBC kümmert sich um die Synchronisation, womit die RPG Programme alle in einem single threaded Umfeld laufen, in den Java Programmen gibt es keine Byte Arrays und alles, was man irgendwo reinschieben kann, kriegt man klaglos wieder raus. Man kann Connection Pools seiner Wahl verwenden, oder es lassen, wenn die RPG Komponenten nicht unter Amnesie leiden sollen und Statusinformationen aus der Historie ihrere Aufrufe brauchen. Es bleibt ein Haar in der Suppe: es wandert Funktion in die Datenbank, die dort normalerweise nix zu suchen hätte, aber solange man das kapselt und nicht der Versuchung unterliegt das zum Prinzip zu machen (naja, die Vertreter der Linie: soviel RPG wie möglich und so wenig Java wie es geht, lesen meine FAQ eher nicht, sondern bevorzugen die java400-l), halte ich das für vertretbar.

Da gibt es ja noch Java stored Procedures, aber die können nur static Methoden und die JVM ist noch weniger kontrollierbar, als bei den JNI Aufrufen, die der RPG Compiler aus den *JAVA Klamotten in RPG Quellen generiert. Auch das kann es aus meiner Sicht nicht sein. Zu den Varianten per QCMDEXEC eine Java Anwendung mit main aufzurufen und damit eine Dataarea zu füllen (vielleicht kommt man per Toolbox und ein paar Hilfs CLs sogar an den LDA dran), die man dann im RPG wieder ausliest, überlege ich mir mal einen Vortrag für die Informatiker Fassenacht der Lauschbacher Eiskaale vorzubereiten. Damit bliebe für dieses Kapitel eigentlich nur ein allgemeiner Teil über, was man nun alles programmieren muss, um einen eigenen Serverdienst zu schreiben, der Javadienste für RPG Programme bereitstellt. Das war mir zu wenig und deshalb fehlte der Teil Java2RPG RPG2Java auch bisher und man musste dann schon im deutschen AS/400 Forum suchen, wenn man meine Meinung dazu ansehen wollte.

Die Grundidee ist relativ einfach: man startet eine JVM, die man resident hält und lässt in dieser JVM einen Listener an einem Datenkanal auf Aufträge warten, die von RPG Programmen in den Kanal gestellt werden und auf Antwort eines Java Programms warten, dass die Anforderung verarbeitet und die Antwort kommuniziert. Variatioansmöglichkeiten gibt es viele und da ist dann doch einiges zu programmieren, ehe der erste Aufruf erfolgen kann. Wenn man das aus der Java Perspektive betrachtet, dann ist das ein Applikations Server, der für RPG Java Komponenten verfügbar macht. Ich will an dieser Stelle nicht alle Überlegungen diskutieren, warum ich für meinen Entwurf AppServer4RPG mich im einzelnen für oder gegen diese oder jene Variante entschieden habe, aber die Zielrichtung war von Anfang an so ein Teil als OpenSource Projekt aufzuziehen und damit es kein Rohrkrepierer wird, habe ich mit der realen Ankündigung gewartet bis das Teil als Beta vorliegt.

Ach ja, finden tut man den Application Server für RPG auf meiner Homepage, oder auch auf SourceForge, wobei sich beides momentan noch nicht unterscheidet.

ArdGate ist in mehrerlei Hinsicht interessant, es ist Open Source und steht in Konkurrenz zu Produkten, die zig-Tausende kosten und kann dabei mehr als die meisten alternativen Lösungen. Gerade diese Alleinstellungs Merkmale hindern die Verbreitung eher und begrenzen ArdGate zum Geheimtip, der in Foren und Publikationen eher totgeschwiegen wird. Mittels ArdGate kann man von allen SQL Interfaces der AS/400 auf alle JDBC fähigen Datenbanken zugreifen, Satzweise, in Echtzeit, mit minimiertem Ressourcenverbrauch. Die Daten, die mit DB2 ausgetauscht werden sind recht wirr strukturiert und ließen sich nicht mit PCML beschreiben, wenn man das denn wollte. Die native Schicht ist in RPG implementiert und minimal schmal; die Applikation ist fast komplett in Java geschrieben, aus Aufwandsgründen, da die Programmierer Produktivität in Java ungleich größer ist.

Im Zentrum des lernens muss von Beginn an die Entwicklung des Verständnisses für Objekt Orientierung stehen, sonst wird der Schritt zu einer Veränderung des Denkens in Richtung Objekt Orientierung gehemmt und nicht gefördert. Dies ist der wesentliche Grund dafür, dass alle Ansätze nach dem Motto Java für RPG Programmierer zum scheitern verurteilt sein müssen, so gut oder schlecht die Bücher und nicht zuletzt die Übersetzungen auch sein mögen. An derselben Krankheit leiden auch die abgeschwächten Versionen Java auf der AS400. Und hier liegt auch die Ursache dafür, dass alle Zauberer, soweit man überhaupt an diese glaubt, nicht weiterhelfen. Auch diese schaden eher, da hier Wiederverwendbarkeit durch Generierung ersetzt wird und das ist für den Anfang extrem schädlich und später zumindest fragwürdig.

Zur Ergänzung und zum Nachschlagen eignet sich für Anfänger auch noch Bruce Eckels Thinking in Java, das allerdings ein wenig C lastig ist und Guido Krügers Java Buch, die beide im Web verfügbar sind (zumindest waren). Für Spezialthemen gibt es eine breite Palette von Tutorials mit stark streuender Qualität, zu den schwächeren zähle ich in diesem Bereich die Redbooks, die stark Produkt zentriert sind und bei denen der Anfänger nicht entscheiden kann, was davon Marketing ist, was funktioniert und dennen fast allen gemeinsam ein grauenhafter Java Stil ist.

Grundsätzlich gilt für Selbst Studium, dass es nicht jedermanns Sache und nur für die wenigsten der schnellste Weg zu Java ist. Einer der größten Nachteile ist, dass man keinen hat, den man fragen kann und oft fehlt es an ausreichender Selbstkritik oder Hartnäckigkeit. Zu den Vorteilen kann aber auch zählen, dass man sogar tiefer in Dinge reinarbeiten kann, wenn man denn von beidem genug hat. Ich jedenfalls, habe nie einen Java Kurs besucht.

Bei den Angeboten, die sich an Umsteiger richten, sind die auf C aufbauenden Kurse des Java Mainstreams für die meisten RPG/COBOL Entwickler weniger gut geeignet, hier werden einfach zu viel Syntax Komponenten vorausgesetzt. Bei den Spezialangeboten für die AS400 Klientel sollte man darauf achten, dass die Grundkenntnisse und Objekt Orientierung nicht zu schwach gewichtet sind. Für einen Grundkurs solte man eine Woche veranschlagen und sich als reiner Anfänger auf Grundlagen der Objekt Orientierung, Einstieg in die Sprache Java und allgemein verwendbare Komponenten konzentrieren, wichtig ist noch, dass ein ausreichendes Gewicht auf praktische Übungen gelegt wird und das Ganze nicht auf ein bestimmtes Werkzeug zentriert ist, egal welches das sein mag. In dieser Phase geht es darum die Sprache zu lernen und nicht darum ein meist viel zu komplexes Werkzeug zu verwenden.

Im zweiten Schritt geht die Reise dann für die meisten AS400 Programmierer in Richtung Server Programmierung, oder alternativ in Richtung Client Programmierung mit graphischen Frontends. Jetzt ist es wichtig auch damit anzufangen sich mit Anwendungsdesign zu befassen, wer dies nicht spätestens jetzt macht und auf quick and dirty setzt, der wird es sehr schwer haben jemals über dieses Stadium hinaus zu kommen, wer mit Ruck Zuck beginnt, landet fast immer bei Husch Pfusch (gilt übrigens nicht nur für Java). Bei der Auswahl von Kursen sollte man genau auf die Voraussetzungen und die angestrebten Ziele achten. Web Facing hat zum Beispiel mit Java nichts zu tun und wenn sich ein Kurs zu 80% mit einem Produkt befasst, dann sollte er zumindest kostenlos sein, egal ob es sich um einen Application Server oder eine Entwicklungsumgebung handelt. Eine Bemerkung am Rande noch: für die Verwendung der AS400 Toolbox braucht man keinen Kursus, wenn man halbwegs Java kann - da ist es vielleicht sinnvoller sich mit SQL oder JDBC zu beschäftigen. Solide SQL Kenntnisse (können auch von embedded SQL in RPG stammen) sind auch dann unumgänglich, wenn man später ein Framework wie Hibernate für den Datenbankzugrigff verwendet.

Was immer man jetzt tut, ohne Praxis geht das ganze gelernte jetzt wieder flöten und es bleibt dann oft nur der Nutzen für seine Programmiertätigkeiten in der vorher ausgeübten Sprache, aber auch das kann den Aufwand wert sein.

Bei Web Anwendungen darf der Datenbankzugriff keinesfalls in den JSPs erfolgen, hier scheiden sowohl die SQL Tags der Standard Tag Libs und erst recht die wie sauer Bier offerierten IBM Data Access Beans aus, die sogar Visual Age überlebt haben und jetzt als dab Taglib traurige Wiedergeburt feiern. Ein rauf und runter programmieren der AS400 Toolbox bringt ebenfalls nicht weiter, ob es nun per Wizard oder zu Fuß erfolgt ist hier eigentlich egal.

5 bis 10 Browser Seiten als Java Server Pages; Model View Controller sollte das Design schon erkennen lassen, vieleicht ein kleines Servlet als eigener Controller, Struts ist in dieser Phase schon ehrgeizig, Datenbankzugriff per eigener Klassen, wenn es sich um maximal 3 Tabellen handelt, sind es mehr, dann darf es bereits Hibernate sein. Zum Kennenlernen der Arbeit mit Frameworks und Standard Komponenten bietet sich hier in jedem Fall log4J an, das braucht man sowieso.

Unverzichtbar sind da ganz andere Dinge, die in der Java Welt Standard sind. CVS zum Beispiel zur Verwaltung der Sourcen, auf Linux, wenn es irgendwie geht, zur Not auf Winows NT. Bei hochmodularen Anwendungen gibt es sonst irgendwann Huddel mit den Source Ständen und Varianten.

Zum erstellen und verteilen von Anwendungen ist Ant angesagt, der universelle Plattform unabhängige Batch Interpreter,den es für die AS400 leider noch nicht gibt (wäre doch mal ein Open Source Projekt für die AS400 Freelancer Fraktion?!), der ganze WDSC wizard Kram ist doch Spielzeug, da holt man sich höchstens einen Mausarm, soweit man selbigen noch nicht von Ooops Nerv oder vom Tennis spielen hat.

Log4j ist unverzichtbare Komponente jeder Server Anwendung und auch auf dem Client hilfreich, nimmt man gleich noch commons-logging hinzu wird es einfacher zu verwenden und erspart einem mit und ohne diesem den Debugger.

jUnit wäre eigentlich gerade für dei AS400 Fraktion ein guter Einstieg in eine neue Art zu arbeiten, mit automatischem testen statt dem Prinzip Hoffnung, ist aber ähnlich der Lektüre von Ernst Bloch für den Anfang nicht ganz einfach zu verstehen.

Ein wenig Erleichterung kann man sich gerade am Anfang verschaffen durch den Verzicht auf WebSphere und die Verwendung von Tomcat.

Wenn man nicht auf EJBs verzichten will, dann nimmt man zum Start vielleicht wenigstens JBoss, hiermit hat man ebenso wie mit Tomcat dann eine Garantie für die Einhaltung von Standards.

Neben Standards gibt es auch noch Selbstverständlichkeiten, wie den Verzicht auf Scriptlets in JSPs.

Für den Datenbankzugriff, darf es keineswegs record level access sein, gegen den nicht nur spricht, dass er Zeugs enthält, das schon in der zehnten Version nicht funktioniert (ich sage nur Column Headings), was keinen Spass macht. Hier waren Leute am Werk, die lieber bei RPG geblieben wären und ergänzt sei: sie hätten es auch tun sollen! JDBC ist hier Standard, SQLJ hat sich leider nicht etabliert und Hibernate in vielen Fällen ohnehin die einfachere Lösung, mit Funktionalitäten, die erst mal programmiert sein wollen, wie caching von Daten, automatisches dirty checking, lazy fetch und sauberes Transaktions Handling.

In die Abteilung Ehrgeiz zählt jetzt schon oder noch der Einsatz von EJBs oder die Verwendung eines Frameworks wie Struts, aber das kann auch seinen Reiz und seine Vorteile haben.