RPG und Java mit JNI integrieren: Setup

12. November 2008 | Von admin | Kategorie: Load`n`go, Programmierung

Diese Reihe befasst sich mit der Integration von Java in RPG-Anwendungen. Der erste Teil zeigt Ihnen, wie Sie Ihre Programmierumgebung vorbereiten. Die meisten herkömmlichen iSeries-Anwendungen bestehen ausschließlich aus RPG-Programmen und einigen unterstützenden CL-Routinen. Doch langsam aber sicher bahnt sich Java seinen Weg in diese Anwendungen.

Read Offline:

Download PDF

Download ePub

von Gary Guthrie und Brian Farrar

Übersetzer

Übersetzt und für den deutschsprachigen Markt überarbeitet von Mathias Spateneder

Und auch wenn es für eingefleischte RPG-Anhänger blasphemisch klingen mag: für bestimmte Aufgaben ist Java einfach besser geeignet als RPG. Wenn Sie sich jetzt fragen, wofür Java in einer iSeries-Anwendung besser geeignet sein könnte, stellen Sie sich nur einmal eine Anwendung mit einer Browser-Oberfläche und RPG-Prozessen im Hintergrund vor. Zu solch einer Oberfläche passt Java sicher besser als RPG.

Ein anderes Beispiel:

Es gibt bereits fertige, robuste Socket-Routinen in Java, warum sollte man also RPG-basierte Socket-Server und -Clients schreiben. Es würde eigentlich genügen, eine RPG-Schnittstelle zu den Java-Socketroutinen zu realisieren. Die Qualität von Anwendungen, die sowohl RPG als auch Java verwenden, hängt nicht davon ab, ob eine der beiden Sprachen besser ist, sondern davon, wie gut die beiden in einer Anwendung zusammenspielen.

Bei der Integration von Java und RPG werden Sie sich oft zwischen verschiedenen Alternativen entscheiden müssen, wenn es darum geht, welche Technik für einen bestimmten Aspekt Ihrer Anwendung die richtige ist. Wie soll z.B. Java von RPG aus aufgerufen werden? Sollen Datenbankzugriffe mit JDBC (Java Database Connectivity), mit Routinen aus IBMs Java Toolbox oder mit nativen I/O-Routinen realisiert werden? In dieser Serie über die Integration von Java und RPG lernen Sie die Perspektive eines RPG-Entwicklers und die eines Java-Entwicklers kennen. Keiner von beiden kannte die Welt des anderen bevor sie zusammen an einem Projekt arbeiteten. Wir werden Ihnen zeigen, wie eine Java-Umgebung auf der iSeries eingerichtet und verwendet wird. RPG-Entwickler werden lernen, wie man Programme schreibt, die mit Hilfe von JNI (Java Native Interface) Java-Programme aufrufen und mit ihnen interagieren. Umgekehrt lernen Java-Programmierer, wie sie über JNI mit Prozeduren in RPG-Serviceprogrammen kommunizieren können. Bevor wir uns eingehender mit JNI befassen, stellen wir sicher, dass Sie für Java eingerichtet sind. Wir sagen Ihnen, welche Software Sie brauchen, richten eine Java-Umgebung ein, und kompilieren ein Java-Programm und führen es aus.

Erforderliche Software

Um unsere Beispiele optimal nach vollziehen zu können, benötigen Sie OS/400, V5R1 oder höher. Mit V5R1 wurden signifikante Erweiterungen vorgenommen, die die Integration von RPG und Java zu einer sinnvollen Aufgabe machen. Außerdem brauchen Sie noch einige iSeries-Lizenzprogramme, die in Abbildung 1 aufgelistet sind.

Produkt-ID	Option	Beschreibung
5722SS1	30	OS/400 Qshell-Interpreter
5722JV1	*BASE	Developer Kit for Java
5722JV1	3	Java Developer Kit 1.2
5722JV1	4	Java Developer Kit 1.1.8
5722JV1	5	Java Developer Kit 1.3
5722JC1	*BASE	Toolbox for Java

Abbildung 1: Erforderliche Lizenzprogramme

Februar Utility der NEWSolutions
load`n`go	Load`n´ go zu diesem Artikel JavaProps.java Java Setup-Routinen Lies mich Win95

Das erste Programm in der Liste, der Qshell-Interpreter (QSH) ist ein optionaler Bestandteil von OS/400 (Option 30). Der Qshell-Interpreter (oder shell) ist eine Umgebung mit Unix-ähnlichen Befehlen und Utilities. Qshell ist wichtig für die Java-Entwicklung auf der iSeries, weil es die Standard-Utilities und -Schnittstellen bereitstellt, die Java-Entwickler auf anderen Plattformen benutzen und weil Java in der Shell läuft. Neben der Basisversion sind in der Tabelle drei Versionen des Java Developer Kit (JDK) aufgelistet. Jede Version verfügt über bestimmte Fähigkeiten. Sie müssen nicht unbedingt alle drei Versionen laden, aber unter Umständen können Sie Kompatibilitätsprobleme vermeiden, wenn Sie über alle drei Versionen verfügen. Das letzte Element in der Tabelle ist die IBM Toolbox for Java, ein optionales Produkt mit Routinen, die die Java-Entwicklung auf der iSeries vereinfachen sollen. Wir führen die Toolbox als erforderliche Software, weil wir Sie verwenden, um verschiedene Techniken zu vergleichen und gegeneinander abzugrenzen. Prüfen Sie zusammen mit Ihrem Systemadministrator, ob die erforderliche Software auf Ihrem System vorhanden ist. Sie können sich viel Ärger (und Zeit) ersparen, wenn Sie Ihren Administrator bitten, dafür zu sorgen, dass Ihr System auf dem aktuellen PTF-Stand ist, vor allem in Bezug auf das aktuelle Java-Gruppen-PTF. Ohne das aktuelle Java-Gruppen-PTF kommt es so gut wie sicher zu eigenartigen Ergebnissen, für die Sie keine Erklärung finden. Das kennen wir ja alle!

Einrichten der Umgebung

Für die Entwicklung kommerzielle Java-Anwendungen verwenden Sie am besten ein robustes Entwicklungspaket wie z.B. Web Sphere Studio Application Developer (WSAD) unter Windows. Damit editieren und kompilieren Sie Ihre Java-Quellen. Sie können sogar einen Windows-Fileserver als Speicherort für kompilierte Java-Programme verwenden. Wenn die Entwicklung abgeschlossen ist, kopieren Sie die kompilierten Java-Dateien auf die iSeries, auf der die Anwendung laufen soll. Aber es ist ja nicht unser Ziel, eine robuste Java-Entwicklungsumgebung aufzubauen. Wir wollen nur sichergehen, dass Sie unsere Java-Code-Beispiele verwenden können, und dass Sie Grundkenntnisse über die Java-Umgebung der iSeries haben. Deshalb verwenden wir die iSeries zum Entwickeln und Ausführen. Sehen wir uns also an, wie Ihre iSeries eingerichtet werden muss. Das Einrichten der iSeries-Umgebung für Java ist keine monumentale Aufgabe, aber ganz trivial ist es auch nicht. RPG-Programmierer müssen sich an ein neues Vokabular gewöhnen. Aber keine Angst, wir helfen Ihnen dabei. Zum Einrichten der Umgebung und Ausführen von Java-Programmen müssen Sie folgende Aufgaben beherrschen:

Java-Quellcode editieren
die JDK-Version festlegen
Java-Quellcode kompilieren
kompilierten Java-Code zur Laufzeit finden
Java-Programme ausführen

Wenn Sie sich die Liste näher ansehen, entspricht das den Dingen, die Sie auch für die typische iSeries-Entwicklung benötigen. Wir wollen uns jetzt etwas genauer mit den einzelnen Punkten befassen.

Java-Quellcode editieren

Java-Quellcode ist auf der iSeries in Form von Streamfiles mit der Dateierweiterung „.java“ im integrierten Dateisystem (IFS) gespeichert. Der CL-Befehl EDTF startet einen einfachen Editor. Mit dem Befehl

EDTF STMF(‚/home/brian/JavaProps.java‘)

erstellen Sie die Java-Quellendatei „JavaProps.java“ im Home-Verzeichnis des Benutzers Brian (/home/brian). Dazu einige wichtige Hinweise:

1. Die Java-Umgebung unterscheidet im Gegensatz zur Befehlsoberfläche der iSeries zwischen Groß- und Kleinschreibung. Sie sollten deshalb unseren Angaben exakt folgen. 2. Der Java-Compiler erwartet eine Quellendatei im ASCII-Format. Der Befehl EDTF erstellt jedoch standardmäßig Dateien in EBCDIC-Codierung. Wenn Sie also eine neue Java-Quelle mit EDTF erstellen möchten, müssen Sie vorher dafür sorgen, daß das System mit ASCII-Encoding arbeitet. Auf der iSeries wird der zu verwendende Zeichensatz mit einer CCSID (Code Character Set Identifier) angegeben. Sobald Sie eine EDTF-Sitzung geöffnet haben, drücken Sie die Taste F15, und Sie gelangen in die Service-Anzeige, in der Sie die CCSID der Datei angeben können. Da die Windows-Entwicklungsumgebung ihren Code auf der iSeries mit der CCSID 1252 ablegt, sollten Sie denselben Wert auch für EDTF benutzen.

Wenn Sie SEU-Fan sind und Ihre Java-Quellen in einer physischen Quellendatei auf der iSeries speichern wollen, können Sie das natürlich tun. Kopieren Sie vor dem Kompilieren Ihre so gespeicherten Dateien einfach mit dem Befehl CPYTOSTMF in das IFS. Dabei geben Sie für den Parameter STMFCODPAGE den Wert *PCASCII an, um den Quellcode in eine ASCII-Datei zu kopieren.

Festlegen der JDK-Version

Auf Ihrer iSeries können verschiedene Versionen des JDK installiert sein. Während der Installation können Sie die standardmäßig zu verwendende Version angeben. Mit dem QSH-Befehl java und der Option -version können Sie ihre JDK-Version feststellen. Dazu starten Sie die Shell von der iSeries-Befehlseingabe aus mit dem Befehl QSH. Sobald die Shell geladen ist, geben Sie den Befehl

java -version

ein, und die momentan verwendete Version wird angezeigt. Wenn Sie eine Fehlermeldung erhalten, die besagt, dass der Befehl nicht gefunden wurde, ist das JDK noch nicht installiert. Sie können die Standardversion des JDK auf verschiedene Art überschreiben: Mit dem QSH-Befehl java können Sie nicht nur die Standardversion feststellen, sondern auch angeben, welche JDK-Version verwendet werden soll. Dazu verwenden Sie die Option -D (Variable definieren) des Befehls und weisen der Eigenschaft java.version einen Wert zu:

java -D java.version=1.3.1

Dieser Wert gilt natürlich nur für die aktuelle QShell-Sitzung. Sobald Sie eine neue Shell starten, wird die JDK-Version wieder auf den urspünglichen Standardwert zurückgesetzt. Mit speziellen Property-Dateien können Sie dauerhaft gültige Standardwerte (wie z.B. java.version) auf System- und Benutzerebene festlegen. Property-Dateien müssen den Namen SystemDefault.properties haben. Die Datei mit den auf Systemebene gültigen Standardwerten muss im Verzeichnis /qibm/userdata/java400/ stehen, während die Datei mit den auf Benutzerebene gültigen Standardwerten im Home-Verzeichnis des Benutzers stehen muss (z.B. /home/brian). Nachdem Sie die Dateien erstellt haben, laden Sie sie einfach mit den gewünschten Standardwerten im Format Eigenschaft=Standardwert. Um z.B. für die JDK-Version den Standardwert 1.3.1 festzulegen, tragen Sie folgendes ein:

java.version=1.3.1

Zur Ausführungszeit fragt Java die Werte in diesen Dateien ab. Standardwerte für bestimmte Eigenschaften fragt Java in der folgenden Reihenfolge ab:

Java-Befehlszeile
Datei SystemDefault.properties auf Benutzerebene
Datei SystemDefault.properties auf Systemebene
Installations-Standardwerte

Java-Quellcode kompilieren

Bevor ein Java-Programm ausgeführt werden kann, muss es in den Java-Bytecode kompiliert werden, den die Java Virtual Machine (JVM) versteht. Eine kompilierte Datei wird Klassendatei (Class File) genannt (Dateierweiterung .class). Der QSH-Befehl zum Kompilieren von Java-Quellen ist javac. Mit dem Befehl

javac -d /home/brian/classes JavaProps.java

wird die Java-Quellendatei JavaProps.java im aktuellen Verzeichnis kompiliert und die kompilierte Klassendatei in das Verzeichnis /home/brian/classes gestelt. Die Option -d (Destination) kennzeichnet die Zielangabe. Dieses Beispiel geht davon aus, daß die Java-Quelle im aktuellen Verzeichnis steht. Das aktuelle Verzeichnis kann mit dem QSH-Befehl cd (Change Directory) gewechselt werden. Der Befehl

cd /home/brian

legt z.B. das Verzeichnis /home/brian als aktuelles Verzeichnis fest. Sie können den Befehl javac aber auch mit vollen Pfadangaben versorgen, wenn Sie das aktuelle Verzeichnis nicht wechseln wollen. Ein Beispiel:

javac -d /home/brian/classes /home/brian/JavaProps.java

Unser Java-Beispiel (JavaProps.java) in Abbildung 2 enthält Methoden, die verschiedene System-Eigenschaften abrufen. Die gesammelten Werte werden einheitlich aufbereitet und ausgedruckt. Wir erwarten nicht, daß RPG-Entwickler dieses oder irgendein anderes Programmbeispiel unserer Serie bis in alle Einzelheiten verstehen. Dieses Programm ist eigentlich nichts anderes als ein etwas höher entwickeltes „Hello World“-Programm, mit dem wir überprüfen können, ob Sie Ihre Java-Umgebung richtig aufgebaut haben.

Wir wollen jetzt die folgenden drei Schritte ausführen und dann das Programm kompilieren:

1. Überprüfen ob der Benutzer ein Home-Verzeichnis hat. 2. Überprüfen ob der Benutzer ein Verzeichnis für Klassendateien hat. 3. Setzen der Standardwerte auf Benutzerebene.

Es ist zwar nicht unbedingt erforderlich, diese Schritte jetzt auszuführen, aber diese Vorbereitungen erleichtern Ihnen später die Arbeit. Wenn OS/400 ein Benutzerprofil anlegt, wird auch ein Home-Verzeichnis für den Benutzer angelegt, das standardmäßig denselben Namen hat wie das Benutzerprofil. Dieses Home-Verzeichnis ist ein Unterverzeichnis des Verzeichnisses /home. Sie können mit dem Befehl DSPUSRPRF (Benutzerprofil anzeigen) feststellen, welches Home-Verzeichnis ein Benutzer hat, und mit dem Befehl WRKLNK (Mit Objektverbindungen arbeiten) feststellen, ob das Verzeichnis existiert. Wenn Sie z.B. überprüfen möchten, ob das Verzeichnis /home/brian existiert, geben Sie folgendes ein:

WRKLNK OBJ(‚/home/brian‘)

Wenn Sie eine Fehlermeldung („Objekt nicht gefunden“) erhalten, muß das Verzeichnis erstellt werden. Verzeichnisse können sowohl von der OS/400-Befehlseingabe als auch von der Shell aus erstellt werden. Von OS/400 aus verwenden Sie den Befehl CRTDIR (Verzeichnis erstellen):

CRTDIR DIR(‚/home/Benutzerprofil)

Von der Shell aus verwenden Sie den QSH-Befehl mkdir:

mkdir /home/Benutzerprofil

Hinweis:

In diesen beiden und in allen folgenden Beispielen ersetzen Sie bitte Benutzerprofil durch den Namen Ihres Benutzerprofils. Wenn Sie schon beim Erstellen von Verzeichnissen sind, sollten Sie auch gleich eines erstellen, in dem Sie Ihre kompilierten Java-Klassen speichern. Für unsere Übungen empfehlen wir Ihnen, ein Verzeichnis mit der Bezeichnung classes in Ihrem Home-Verzeichnis anzulegen:

CRTDIR DIR(‚/home/Benutzerprofil/classes)

Als nächstes geben Sie einen Benutzer-Standardwert für die JDK-Version ein. Dazu Dazu erstellen Sie mit dem Befehl EDTF die Datei SystemDefault.properties in Ihrem Home-Verzeichnis:

EDTF STMF(‚/home/Benutzerprofil/SystemDefault.properties‘)

Sobald die Editor-Sitzung gestartet ist, ändern Sie die CCSID der Datei auf 1252, und geben Sie die folgende Zeile ein, um den Benutzer-Standardwert für die Java-Version festzulegen:

java.version=1.3.1

Damit ist die Kompatibilität für die Beispiele unserer Serie sichergestellt. Speichern Sie die Datei, und beenden Sie den Editor. Jetzt können Sie den Quellcode für JavaProps.java (Abbildung 2) eingeben und kompilieren. Wir Speichern alle Quellen im Home-Verzeichnis des Benutzers. (Sie finden den Code für dieses Beispiel auch im Download-Bereich für Abonnenten unter www.iseriesetwork.de.) Der Umwandlungsbefehl, den Sie für dieses Beispiel in der Shell eingeben müssen, lautet:

javac verbose

      -d /home/Benutzerprofil/classes

JavaProps.java

Wenn das Programm erfolgreich umgewandelt wurde, erscheint gegen Ende der von javac ausgegebenen Nachrichten eine Meldung, die besagt, daß die Datei JavaProps.class geschrieben wurde.

Kompilierten Java-Code zur Laufzeit finden

Beim Ausführen von Java-Code muss das System in der Lage sein, die ausführbaren Java-Klassendateien zu finden. Dazu muss es den Pfad zu diesen Dateien kennen. Die Umgebungsvariable CLASSPATH dient dazu, dem System diesen Pfad mitzuteilen. Diese Variable kann auf verschiedene Art und Weise angegeben werden, wobei die von Ihnen gewählte Art einen Einfluss darauf hat, wie das System bei der Ausführung von Java-Programmen vorgeht. Üblicherweise können Sie CLASSPATH in CL, in der Shell oder in speziellen Profildateien angeben. In CL können Sie den Befehl ADDENVVAR (Umgebungsvariable hinzufügen) verwenden, um CLASSPATH auf Job- oder Systemebene anzugeben. Eine Definition auf Job-Ebene gilt für die Dauer des Jobs (oder solange, bis sie durch eine andere Definition ersetzt wird) und bezieht sich immer auf den Job, der den Befehl abgesetzt hat. Eine Definition auf Systemebene ist dagegen allgemein für alle Jobs auf dem System gültig. Wenn ein Job startet (z.B. wenn sich ein Benutzer anmeldet), wird eine Definition auf Systemebene für diesen Job zur Definition auf Job-Ebene. Mit dem Parameter LEVEL kann bei Verwendung des Befehls ADDENVVAR festgelegt werden, ob die Definition auf Job- (*JOB) oder Systemebene (*SYS) gilt. Als Standardwert wird *JOB angenommen. Ein Beispiel:

ADDENVVAR ENVVAR(CLASSPATH) +

          VALUE('IhrePfadangabe') +

          LEVEL(*JOB) +

          REPLACE(*YES)

In diesem Beispiel steht IhrePfadangabe für den Pfad zu Ihren Java-Klassendateien (z.B. /home/brian/classes). Sie können auch mehrere Pfade, durch Doppelpunkte voneinander getrennt, eingeben. Die JVM durchsucht die Pfade in der angegebenen Reihenfolge. Der Parameter REPLACE gibt an, ob ggf. eine bereits bestehende Angabe für CLASSPATH ersetzt werden soll. Neben dem Befehl ADDENVVAR können Sie auch die CL-Befehle CHGENVVAR (Umgebungsvariable ändern), RMVENVVAR (Umgebungsvariable löschen) oder WRKENVVAR (Mit Umgebungsvariablen arbeiten) verwenden. WRKENVVAR präsentiert einen Überblick über die definierten Umgebungsvariablen und dient als Befehlsschnittstelle für alle Aufgaben im Zusammenhang mit Umgebungsvariablen. Sie können CLASSPATH auch bei jedem Start der Shell angeben. Der QSH-Befehl zum Definieren des Pfades lautet

export CLASSPATH=IhrePfadangabe

wobei IhrePfadangabe wieder für den festzulegenden Pfad zu Ihren Java-Klassendateien steht. Mit speziellen Profildateien können Sie auf Benutzer- und Systemebene Standardwerte für Umgebungsvariablen (wie z.B. CLASSPATH) festlegen, die das System automatisch übernimmt, sobald die Shell gestartet wird. Die auf Benutzerebene gültige Datei muss den Namen .profile haben und im Home-Verzeichnis des Benutzers gespeichert sein. Der dem Namen vorangestellte Punkt kennzeichnet die Datei als verborgene Datei. Die auf Systemebene gültige Profildatei muss den Namen profile tragen (ohne vorangestellten Punkt) und im Verzeichnis /etc gespeichert sein. Nachdem Sie die Dateien erstellt haben, tragen Sie einfach die gewünschten Umgebungsvariablen ein. Um z.B. für CLASSPATH den Pfad /home/brian/classes vorzugeben, fügen Sie folgenden Eintrag hinzu:

export CLASSPATH=$CLASSPATH:/home/brian/classes

Beachten Sie, dass wir zwei Pfade, durch einen Doppelpunkt getrennt, eingegeben haben. Der Wert $CLASSPATH ist ein Sonderwert, der für den momentan definierten Klassenpfad steht. Wir haben diesen Eintrag hinzugefügt, um keine Konflikte mit bereits vorhandenen, z.B. vom System generierten Pfadangaben zu verursachen. Falls eine Profildatei bereits eine CLASSPATH-Angabe enthält, fügen Sie Ihren Eintrag einfach an der gewünschten Stelle in den vorhandenen Pfad ein, und verwenden Sie Doppelpunkte zum Trennen der Pfadangaben. Alle bisher vorgestellten Verfahren erfordern das Einstellen von CLASSPATH vor der Ausführung des Java-Programms. Im folgenden Abschnitt können Sie sehen, dass CLASSPATH auch beim Aufruf eines Java-Programms mit dem CL-Befehl RUNJVA (Java-Programm ausführen) oder mit dem QSH-Befehl java definiert werden kann. Die Reihenfolge, in der die Vorgaben für CLASSPATH ausgewertet werden, hängt davon ab, ob das Java-Programm mit dem CL-Befehl RUNJVA oder mit dem QSH-Befehl java aufgerufen wird. Beim Verwendung des CL-Befehls RUNJVA gilt folgende Reihenfolge:

1. Parameter CLASSPATH des Befehls RUNJVA 2. Mit dem CL-Befehl ADDENVVAR und dem Parameter LEVEL(*JOB) gesetzte Variable 3. Mit dem CL-Befehl ADDENVVAR und dem Parameter LEVEL(*SYS) gesetzte Variable

Beim Aufruf mit dem QSH-Befehl java gilt:

1. Befehlszeilenargument des QSH-Befehls java 2. Umgebungsvariable in der Profildatei auf Benutzerebene 3. Umgebungsvariable in der Profildatei auf Systemebene 4. Mit dem CL-Befehl ADDENVVAR und dem Parameter LEVEL(*JOB) gesetzte Variable 5. Mit dem CL-Befehl ADDENVVAR und dem Parameter LEVEL(*SYS) gesetzte Variable

Java-Programme ausführen

Java-Programme können entweder von CL oder von der Shell aus gestartet werden. Der CL-Befehl RUNJVA startet die Java-Shell, in der das Java-Programm läuft. Wenn der Klassenpfad korrekt festgelegt ist, können Sie unser Beispielprogramm JavaProps mit folgendem Befehl starten:

RUNJVA CLASS(JavaProps)

Ist der Klassenpfad noch nicht definiert, können Sie Ihn direkt mit dem Befehl RUNJVA angeben:

RUNJVA CLASS(JavaProps) +

       CLASSPATH('/home/brian/classes')

Sie können aber auch den QSH-Befehl java verwenden, um unser Beispielprogramm aufzurufen:

java JavaProps

Ist der Klassenpfad noch nicht definiert, können Sie die Option -classpath des QSH-Befehls java benutzen, wie das folgende Beispiel zeigt:

java -classpath /home/brian/classes JavaProps

Wenn Sie bisher alle Schritte nachvollzogen und die Klassendatei JavaProps bereits erstellt haben, können Sie sie jetzt ausführen, um eine Ausgabe wie die in Abbildung 3 gezeigte zu erhalten.

   Java Version: 1.3.1

         Vendor: IBM Corporation

      Java Home: /QIBM/ProdData/Java400/jdk13

       Encoding: ISO8859_1

     OS Version: V5R1M0

        OS Name: OS/400

OS Architecture: PowerPC

    User Region: US

      User Name: BRIAN

 User Directory: /home/brian

      Classpath: .:/home/brian/classes

   Library Path: /QSYS.LIB/QJAVA.LIB:/QSYS.LIB/QTEMP.LIB:/QSYS.LIB/BRIAN.LIB

Abbildung 3: Ausgabe des Java-Programms JavaProps

Bis zum nächsten Mal

Das genügt für den Anfang. Auch wenn Ihnen manches etwas fremd erscheint, lohnt es sich doch, etwas Zeit zu investieren. Wir empfehlen Ihnen, genau das zu tun, damit Sie auf die Aufgaben vorbereitet sind, die in den weiteren Folgen dieser Serie auf Sie zukommen. Wir werden uns mit dem Aufrufen von Java-Methoden in RPG mit JNI beschäftigen, die Arbeit mit Java-Objekten beschreiben, mehrschichtige Anwendungen erstellen, die komplexe Vorgänge vor dem Entwickler verbergen, und Stored Procedures einsetzen, um Programmobjekte von Java aus aufzurufen. Außerdem stellen wir Ihnen ein nützliches, von uns geschriebenes Tool vor, das kompilierten Java-Code untersucht und RPG-Prototypen für die enthaltenen Methoden generiert.