IBM RPG vs. Java on IBM i – Terminology, Concepts, and Where Each One Fits

Is an IBM i library the same thing as a schema? Is a job comparable to a thread? And when should RPG stay in the center of the architecture — while Java handles the edges?

1. Quick take: RPG vs. Java on IBM i

RPG and Java are often discussed as if one of them has to win. That framing is tempting, but it is usually too simplistic. RPG is deeply rooted in IBM i. It is close to traditional business logic, batch processing, 5250 applications, and Db2 for i data structures. Java is strongest where cross-platform architecture, APIs, web applications, frameworks, integration, and distributed systems matter.

Modern RPG — especially ILE RPG in free-form or fully free-form style — is far more readable and modular than old fixed-column RPG code. Java, on the other hand, brings a huge ecosystem: build tools, frameworks, testing libraries, REST stacks, observability tooling, cloud integration, and a broad developer talent pool.

2. AS/400, System i, IBM i — getting the names right first

Many people still say “AS/400.” In day-to-day conversation, they often mean a modern IBM i environment running on IBM Power. Historically, though, that is not the same thing. The AS/400 family was introduced in 1988. Later branding included iSeries and System i. Today, the operating system is IBM i, running on IBM Power servers.

This is not just a branding detail. When someone says “the AS/400,” they might mean the hardware, the operating system, a 5250 UI, an RPG application, Db2 for i, or simply “that old business system in the basement.” For technical decisions, that is too vague. Better distinctions are:

• IBM i for the operating system.
• IBM Power or Power servers for the hardware platform.
• Db2 for i for the integrated relational database.
• RPG / ILE RPG for the programming language and its modern modular environment.
• 5250 for the classic terminal-oriented user interface.

3. RPG and Java: two languages, two mental models

RPG grew out of commercial data processing. Its early world was shaped by reports, records, files, and structured business workflows. That history is exactly why RPG still fits many core business processes so well: orders, customers, inventory, invoices, shipments, settlements, end-of-day jobs, and exception handling.

Java arrived with a different promise: a language and runtime that could run across platforms. In enterprise systems, Java became powerful through the JVM, server-side frameworks, broad library support, tooling, and a massive community.

The interesting part is that both languages can be relevant on IBM i. IBM i supports Java through IBM Technology for Java and current JDK options. At the same time, RPG remains central for many IBM i business applications because it often contains decades of carefully refined domain logic.

4. Terminology: translating IBM i concepts without flattening them

Many IBM i terms do not translate cleanly into Java, Linux, or cloud terminology. A library is not just a folder. A job is not just a thread. A logical file can resemble an index, a view, or an access path depending on the context. That is why a careful terminology map is more useful than a one-word translation table.

5. Database thinking: physical files, SQL tables, and Db2 for i

Db2 for i is integrated into IBM i. That makes the platform different from environments where the database server, operating system, and application layer are separate products. On IBM i, traditional record-level access and SQL access can work with related or even the same business data — but they may expose different assumptions.

A beginner-friendly comparison such as “physical file equals SQL table” and “logical file equals index or view” can be useful for orientation. But for serious work, it needs nuance. A physical file can often be treated like a table. A SQL table is also a database object. But DDS definitions, members, access paths, naming conventions, journaling, constraints, and historical design choices can all matter.

Java teams sometimes underestimate how much business behavior is hidden in data structures, DDS descriptions, triggers, programs, job environments, library lists, and nightly processes. Classic IBM i teams sometimes underestimate the value of explicit API contracts, automated tests, structured logging, and repeatable deployment pipelines. Both blind spots are expensive.

6. Runtime model: jobs, programs, threads, and services

An IBM i job carries a lot of context: user profile, job description, library list, activation groups, messages, job log, environment, and resources. That is why “job equals thread” is not a safe comparison.

For integration architectures, this level is critical. Java can call RPG programs, read data through JDBC, publish REST endpoints, or run as a separate service layer next to IBM i. But every integration must respect IBM i runtime realities: library lists, authorities, CCSIDs, locks, commitment control, message handling, and response-time expectations.

7. Mini code comparison: same business question, different shape

Here is a deliberately small example. The business question is simple: read the revenue for a customer and return or display it. In RPG, the code often sits close to Db2 for i and the existing business process. In Java, the design often emphasizes repositories, services, tests, and object boundaries.

**FREE
ctl-opt dftactgrp(*no) option(*srcstmt:*nodebugio);

dcl-s customerNo packed(7:0) inz(4711);
dcl-s amount     packed(11:2) inz(0);

exec sql
  select coalesce(sum(order_total), 0)
    into :amount
    from orders
   where customer_no = :customerNo;

dsply ('Revenue: ' + %char(amount));

*inlr = *on;
return;

import java.math.BigDecimal;

public class CustomerRevenueService {
    private final OrderRepository orders;

    public CustomerRevenueService(OrderRepository orders) {
        this.orders = orders;
    }

    public BigDecimal revenueForCustomer(int customerNo) {
        return orders.sumOrderTotalByCustomerNo(customerNo);
    }
}

This is intentionally compact. In real applications, the RPG side might be part of existing programs, service programs, or stored procedures. The Java side would usually include tests, dependency injection, logging, exception handling, transaction boundaries, and an API layer. The point is not that one version is better. The point is that each one organizes responsibility differently.

8. Use cases: when RPG is the better fit, and when Java is

The best choice rarely depends on the language alone. It depends on the target architecture, operational risk, data model, integration needs, team skills, and expected lifetime of the application.

9. Modernization: complementing often beats replacing

Modernization does not automatically mean migration. A healthy IBM i modernization roadmap may look like this:

• Split older RPG programs into clearer modules and service programs.
• Move fixed-format source gradually toward more readable free-form RPG where appropriate.
• Document SQL access, the data model, transaction boundaries, and hidden dependencies.
• Expose proven RPG business logic through defined interfaces.
• Build new APIs, web interfaces, and integration layers with Java or another suitable modern stack.
• Add tests, logging, monitoring, and repeatable deployment pipelines.

A rewrite can be justified when the current application is well understood, technically constrained, too hard to maintain, or strategically misaligned. But a rewrite is not a modernization strategy by itself. IBM i systems often contain tiny details with enormous business impact: exception handling, data fixes, operational timing, locking behavior, batch order, special customer rules, and edge cases nobody wants to rediscover in production.

10. A decision matrix for real-world projects

For real projects, a plain decision matrix beats gut feeling. It is not glamorous, but it keeps architecture discussions honest.

Good IBM i modernization respects the platform while opening it where that creates business value. That is the sweet spot: do not cling to the old just because it is familiar, but do not rebuild everything just because a newer stack sounds more fashionable.

11. Conclusion

The old comparison “RPG is legacy, Java is the future” is too cheap. A better version is this: RPG is often the business memory of the organization. Java is often the bridge to modern architecture. Teams that understand both can modernize IBM i landscapes with far less risk.

Sources