IBM RPG und Java: Datentypen im Vergleich – präzise Mappings, echte Migrationsrisiken und Best Practices für IBM i

1. Kurzfassung: Der wichtigste Unterschied

RPG-Datentypen sind eng mit klassischer Geschäftsdatenverarbeitung, Db2 for i, extern beschriebenen Dateien, DDS und festen Felddefinitionen verbunden. Java-Datentypen leben in einer objektorientierten, JVM-basierten Welt. Dort unterscheidet man zwischen primitiven Typen wie int, long oder double und Objekttypen wie String, BigDecimal, LocalDate, Instant oder eigenen Records.

Die größten Risiken in echten Projekten liegen bei vier Klassikern: Packed Decimal wird zu double, Timestamps werden ohne Zeitzonenbewusstsein übernommen, CCSID-Konvertierungen werden erst im Produktivsystem entdeckt und alphanumerische IDs verlieren führende Nullen. Jeder dieser Fehler ist technisch leicht erklärbar – und fachlich teuer.

2. Warum Datentypen auf IBM i so wichtig sind

Auf IBM i stecken Datentypen selten nur in lokalen Variablen. Sie sind Teil von physischen Dateien, SQL-Tabellen, DDS-Beschreibungen, extern beschriebenen Datenstrukturen, RPG-Programmen, CL-Abläufen, SQL-Prozeduren und Schnittstellen. Ein Feld ist nicht einfach „eine Zahl“, sondern möglicherweise ein Artikelbestand, ein Kundenschlüssel, ein Betrag oder ein historisches Alpha-Feld, dessen führende Nullen seit Jahren Teil des Geschäftsprozesses sind.

Wer Java-Services vor bestehende IBM-i-Daten stellt, muss deshalb zwei Sichten trennen: Was ist technisch möglich und was ist fachlich sinnvoll? Technisch kann man einen numerischen Schlüssel als long lesen. Fachlich kann das trotzdem riskant sein, wenn dieser Schlüssel in Belegen, EDI-Nachrichten oder externen APIs mit führenden Nullen auftritt.

3. RPG und Java im Direktvergleich

Die folgende Tabelle ist bewusst praxisorientiert. Sie zeigt keine absolute Speicherwahrheit für Java-Objekte, sondern beantwortet die wichtigere Frage: Welcher Java-Typ erhält die fachliche Bedeutung des RPG-Feldes am besten?

4. Zahlen: Integer, Packed, Zoned, Float

Bei Zahlen muss zuerst klar sein, welche Art von Zahl gemeint ist: exakter Dezimalwert, technische Ganzzahl, fachlicher Schlüssel oder Näherungswert. Diese Unterscheidung ist wichtiger als die reine Feldlänge.

Integer: technische Ganzzahlen

RPG kennt Integer-Varianten mit unterschiedlicher Größe. Java kennt die primitiven Typen byte, short, int und long. In moderner Java-Geschäftslogik wird für normale Zähler häufig int verwendet, für große Werte long.

Float und Double: technisch möglich, fachlich oft riskant

Fließkommazahlen sind schnell und für Messwerte, Simulationen oder technische Näherungen sinnvoll. Für kaufmännische Werte sind sie meistens die falsche Wahl.

double sum = 0.1 + 0.2;
System.out.println(sum); // typischerweise nicht exakt 0.3

BigDecimal price = new BigDecimal("0.10");
BigDecimal tax   = new BigDecimal("0.20");
System.out.println(price.add(tax)); // exakt 0.30

5. Packed Decimal und BigDecimal

Packed Decimal ist in RPG eine sehr typische Wahl für kaufmännische Werte. Java hat dafür keinen primitiven Datentyp. Die wichtigste Entsprechung ist java.math.BigDecimal.

**free

dcl-s price packed(9:2) inz(1299.95);
dcl-s quantity packed(5:0) inz(3);
dcl-s total packed(11:2);

total = price * quantity;

import java.math.BigDecimal;
import java.math.RoundingMode;

BigDecimal price = new BigDecimal("1299.95");
BigDecimal quantity = new BigDecimal("3");

BigDecimal total = price.multiply(quantity)
                        .setScale(2, RoundingMode.HALF_UP);

Die folgenden Tests sind bewusst klein gehalten. Sie sollen nicht das gesamte Fachmodell abdecken, sondern typische Migrationsannahmen absichern: Scale, führende Nullen, Zeitbezug und Unicode-Verhalten.

import static org.junit.jupiter.api.Assertions.assertEquals;
import java.math.BigDecimal;
import org.junit.jupiter.api.Test;

class DecimalMappingTest {

    @Test
    void keepsScaleForPackedAmount() {
        BigDecimal amount = new BigDecimal("9999999.99").setScale(2);

        assertEquals(new BigDecimal("9999999.99"), amount);
        assertEquals(2, amount.scale());
    }
}

6. Datum, Uhrzeit und Zeitstempel

RPG kennt eigene Datentypen für Datum, Uhrzeit und Zeitstempel. Java bietet seit Java 8 mit java.time eine moderne API. Wichtig ist: LocalDate, LocalTime, LocalDateTime, Instant und OffsetDateTime sind fachliche Typen. Sie beantworten unterschiedliche Fragen.

import java.time.Instant;
import java.time.LocalDate;
import java.time.LocalDateTime;
import java.time.OffsetDateTime;

LocalDate invoiceDate = LocalDate.of(2026, 6, 9);
LocalDateTime localBookingTime = LocalDateTime.of(2026, 6, 9, 14, 30);
Instant technicalEventTime = Instant.now();
OffsetDateTime apiTimestamp = OffsetDateTime.now();

import static org.junit.jupiter.api.Assertions.assertEquals;
import java.time.Instant;
import java.time.OffsetDateTime;
import org.junit.jupiter.api.Test;

class TimestampMappingTest {

    @Test
    void apiTimestampKeepsOffsetInformation() {
        OffsetDateTime value = OffsetDateTime.parse("2026-06-09T14:30:00+02:00");
        Instant instant = value.toInstant();

        assertEquals("2026-06-09T12:30:00Z", instant.toString());
    }
}

7. Text, String, Unicode und CCSID

Text ist in Integrationsprojekten oft gefährlicher als Zahlen. RPG- und Db2-for-i-Felder können mit unterschiedlichen CCSIDs, fester oder variabler Länge, Padding und historischen EBCDIC-Kontexten arbeiten. Java arbeitet mit String als Unicode-orientiertem Objekttyp.

String text = "tiny-tool.de 🚀";

int utf16Units = text.length();
int codePoints = text.codePointCount(0, text.length());

System.out.println("UTF-16 code units: " + utf16Units);
System.out.println("Unicode code points: " + codePoints);

import static org.junit.jupiter.api.Assertions.assertEquals;
import org.junit.jupiter.api.Test;

class CustomerNumberTest {

    @Test
    void keepsLeadingZeros() {
        CustomerNumber number = new CustomerNumber("000123");

        assertEquals("000123", number.value());
    }
}

8. Binärdaten, Pointer und Referenzen

Binärdaten sollten in Java als Binärdaten behandelt werden: byte[], ByteBuffer, InputStream oder je nach Framework geeignete Streaming-Typen. Der klassische Fehler besteht darin, Binärdaten versehentlich durch Textkonvertierung zu schicken.

Pointer sind ein anderes Thema. RPG kann mit Pointern arbeiten, Java abstrahiert Speicherzugriffe über Referenzen und Objektmodelle. Eine direkte mechanische Übersetzung ist meistens kein gutes Ziel.

9. Typische Migrationsfallen

Die folgenden Fehler sieht man in RPG-Java-Projekten besonders häufig. Sie entstehen gerade dann, wenn Teams „nur schnell“ ein Feld durchreichen wollen.

10. Value Objects und Domain-Modellierung

Java-Modernisierung ist nicht nur Typmapping. Sie ist auch die Chance, fachliche Regeln sichtbar zu machen. Ein Betrag ist nicht einfach irgendein BigDecimal. Eine Kundennummer ist nicht einfach ein String. Kleine Value Objects verhindern, dass dieselbe Validierungslogik an zehn Stellen auftaucht – oder an neun Stellen fehlt.

import java.math.BigDecimal;
import java.math.RoundingMode;

public record Money(BigDecimal amount) {

    public Money {
        if (amount == null) {
            throw new IllegalArgumentException("amount must not be null");
        }
        amount = amount.setScale(2, RoundingMode.HALF_UP);
    }

    public Money add(Money other) {
        return new Money(this.amount.add(other.amount));
    }
}

public record CustomerNumber(String value) {

    public CustomerNumber {
        if (value == null || !value.matches("\\d{6}")) {
            throw new IllegalArgumentException("customer number must have exactly 6 digits");
        }
    }
}

public enum OrderStatus {
    OPEN,
    RELEASED,
    SHIPPED,
    CANCELLED
}

11. Best Practices und Testideen

• Fachliche Bedeutung zuerst klären: Preis, Menge, Schlüssel, Status, Datum und Text sind unterschiedliche Dinge – auch wenn sie technisch ähnlich aussehen.
• Dezimalwerte konsequent behandeln: Für Geld, Preise und kaufmännische Werte in Java bevorzugt BigDecimal verwenden.
• Skalierung dokumentieren: Bei packed(9:2) ist die :2 fachlich wichtig, nicht nur Dekoration.
• Datum und Zeit sauber modellieren: LocalDate für Datum, Instant für technische Zeitpunkte, OffsetDateTime für API-Zeitpunkte mit Offset.
• CCSID und Unicode testen: Nicht nur mit ABC123, sondern mit ÄÖÜ, ß, Akzenten, Sonderzeichen und echten Produktionsbeispielen.
• IDs nicht blind numerisch machen: Wenn führende Nullen, Prüfziffern oder externe Darstellung wichtig sind, ist String oder ein Value Object oft richtiger.
• Primitive Obsession vermeiden: Wichtige Fachwerte dürfen eigene Typen oder Records bekommen.
• Mapping zentralisieren: RPG/Db2-zu-Java-Konvertierungen gehören nicht verstreut in Controller, Services und SQL-Hilfsklassen.
• Tests mit Grenzwerten bauen: Maximalwerte, Nullwerte, negative Werte, Rundungen, leere Strings, Padding, ungültige Daten und Zeitzonenfälle testen.

import static org.junit.jupiter.api.Assertions.assertEquals;
import java.math.BigDecimal;
import org.junit.jupiter.api.Test;

class MoneyTest {

    @Test
    void normalizesScaleToTwoDecimals() {
        Money money = new Money(new BigDecimal("12.3"));

        assertEquals(new BigDecimal("12.30"), money.amount());
    }

    @Test
    void addsAmountsWithStableScale() {
        Money result = new Money(new BigDecimal("0.10"))
                .add(new Money(new BigDecimal("0.20")));

        assertEquals(new BigDecimal("0.30"), result.amount());
        assertEquals(2, result.amount().scale());
    }
}

Fazit