FWD » Core Development » Conversion Tools

using Progress.Lang.Object.
using Progress.Lang.ParameterList.

routine-level on error undo, throw.

class Test:

    define temp-table ttKeyField no-undo field f1 as char field f2 as char.
    define dataset dsKeyField for ttKeyField.

    method public void FetchList(output dataset-handle dsOut):
        def var exts as Test extent 1.
        CallFetchListOnComponent(exts[1], exts[1], "a", "b", output dataset-handle dsOut by-reference).
    end method.

    method private void CallFetchListOnComponent(p1 as Test, p2 as Object, p3 as character, p4 as character, output dataset-handle dsOut):
        // no-op
    end method.

    method private void CallFetchListOnComponent(p1 as Test, p2 as Object, dataset dsKeyField, p4 as logical, output dataset-handle dsOut):
        // no-op
    end method.

end class.

This causes:

     [java] Caused by: java.lang.NullPointerException: Cannot invoke "java.lang.Class.isAssignableFrom(java.lang.Class)" because "calleeType" is null
     [java]     at com.goldencode.p2j.uast.FuzzyMethodLookup.isWideningTypeMatch(FuzzyMethodLookup.java:829)
     [java]     at com.goldencode.p2j.uast.FuzzyMethodLookup.lambda$fuzzyMethodLookup$12(FuzzyMethodLookup.java:386)
     [java]     at java.base/java.util.function.Predicate.lambda$negate$1(Predicate.java:80)
     [java]     at java.base/java.util.Collection.removeIf(Collection.java:576)
     [java]     at com.goldencode.p2j.uast.FuzzyMethodLookup.fuzzyMethodLookup(FuzzyMethodLookup.java:424)
     [java]     at com.goldencode.p2j.uast.ClassDefinition.lookupMethodWorker(ClassDefinition.java:3883)
     [java]     at com.goldencode.p2j.uast.ClassDefinition.annotateMethodCall(ClassDefinition.java:2128)
     [java]     at com.goldencode.p2j.uast.SymbolResolver.annotateObjectMethod(SymbolResolver.java:5070)
     [java]     ... 30 more

I added Serban and Constantin as watchers as they made changes to FuzzyMethodLookup recently. I think the bug is related to the use of extent variables (i.e. exts¹) as arguments for an overloaded method.
This is a blocker for converting the POC of a customer with latest trunk - I suspect this is a regression considering 7156e didn't show such issue.

My change seems to be too old to not be included in 7156e, so I suspect it is a later change.

                   | ** -#- -I- --Date-- ---------------------------------------Description----------------------------------------
                   | ** 001 CA  20230928 Initial version. 
14769.1.9  ca@gold | **     CA  20231007 Arguments for direct method calls which can't be emitted as direct java calls (as they 
                   | **                  are considered 'dynamic poly') must be wrapped in a 'polyArg' to check the type.
14934.1.1  sb@gold | ** 002 SB  20231218 Changed isWideningTypeMatch so that for callee type 'object' the function always
                   | **                  returns true. For type 'object' the caller's type can always be matched to a wider type.
15832.1.8  ca@gold | ** 003 CA  20250319 A method from a super-class can have the same name as current class, so calls to this kind
                   | **                  of methods must not be resolved as a constructor for the current class.
15888.1.19 ca@gold | ** 004 CA  20250425 An unknown '?' literal can not match a BUFFER parameter.
16239.1.1  ca@gold | ** 005 CA  20250909 Fixes for direct java access, when passing arguments the result for a Java call or field,
                   | **                  or a 4GL call with a Java return type.
14769.1.3  ca@gold | */

Alex, the fix is this:

=== modified file 'src/com/goldencode/p2j/uast/FuzzyMethodLookup.java'
--- old/src/com/goldencode/p2j/uast/FuzzyMethodLookup.java      2025-09-09 07:00:38 +0000
+++ new/src/com/goldencode/p2j/uast/FuzzyMethodLookup.java      2025-11-21 13:22:29 +0000
@@ -826,7 +826,7 @@
          return true;
       }

-      if (calleeType.isAssignableFrom(callerType))
+      if (calleeType != null && calleeType.isAssignableFrom(callerType))
       {
          incrementer.run();
          return true;
@@ -839,11 +839,14 @@
          incrementer.run();
          return true;
       }
-      compatible = JavaClassDefinition.getNearMatches(calleeType);
-      if (compatible.contains(callerType))
+      if (calleeType != null)
       {
-         incrementer.run();
-         return true;
+         compatible = JavaClassDefinition.getNearMatches(calleeType);
+         if (compatible.contains(callerType))
+         {
+            incrementer.run();
+            return true;
+         }
       }

       return false;

The problem is from #10496.

Alexandru, I think the first condition needs also to be:

      if (calleeType != null && 
          calleeType.isAssignableFrom(callerType) &&
          !(calleeType == java.lang.Object.class && callerType == object.class))
      {
         // never match Java Object to legacy object!
         incrementer.run();
         return true;
      }

I'm testing this now with a customer's project. I've documented in #10946-33

In #10946-34 you mentioned that there is more to this fix. Can we get all of that in 10912a or do we plan to merge 9457a to trunk soon so we have this pending?
FYI, the patch in #10912-4 is currently enough for me to run the POC and is not Urgent. It is just that trunk has this regression in it and may pop-up at a customer sooner rather than later.

The change is in 10912a rev 16311. I think this can be merged to trunk.