Object REXX and Java 17: Resolving Overloaded Methods with Primitive Arguments

When integrating Object REXX with Java 17 via jinit, method dispatch for overloaded Java methods accepting primitive types creates a boundary. REXX variables are untyped, so passing a numeric literal to a method expecting int or double does not communicate the required Java type to the dispatcher. Documented behavior indicates explicit wrapper instantiation or type coercion is necessary, but the boundary between REXX coercion rules and Java overload resolution remains a design concern.

Version assumptions add complexity. OpenObject REXX 5.0+ supports Java 17 classpaths natively, while legacy distributions constrained to Java 8 may encounter module-path loading failures. This split raises questions about whether primitive mapping behavior is consistent across REXX-Java combinations or whether dispatcher logic changed between Java 8 and 17 runtimes.

For developers calling overloaded Java APIs from execs, the practical uncertainty is how to ensure deterministic overload selection when REXX passes untyped values. Without clear rules, the same exec may resolve to different signatures depending on REXX version, Java version, or the presence of String versus StringBuilder parameters.

Does Object REXX 5.0+ on Java 17 require explicit wrapper classes for primitive arguments in all overloaded contexts, or does native coercion cover int and double reliably? Are checked Java exceptions thrown during primitive-argument dispatch consistently converted to REXX RuntimeException, or does trap behavior vary by distribution? How should execs avoid ambiguous overload resolution when a Java class exposes both String and StringBuilder variants alongside primitive overloads?