FWD » Core Development » Base Language

Are you compiling with Java 8 or Java 17?

Constantin Asofiei wrote:

Are you compiling with Java 8 or Java 17?

Java 17.

openjdk 17.0.14 2025-01-21
OpenJDK Runtime Environment (build 17.0.14+7-Ubuntu-124.04)
OpenJDK 64-Bit Server VM (build 17.0.14+7-Ubuntu-124.04, mixed mode, sharing)

OK, well, your signature at the function definitions matches the argument's. define the argument obj as progress.lang.class, not progress.lang.object.

Quick question, when converting extent variables given as arguments what is the node that is generally taken into account, the variable definition or the function definition?
I want to take into account how fixing this issue might affect existing functionality.

Normally those definitions should be the same or else there would be a compilation error. But it is much more complicated with objects, because while they could have a certain type, they could be compatible if for example they implement the same interface or inherit the same class.

Besides this, the example shows that a instance of a class that inherits another class (like progress.lang.object) can even be replaced with one of its parents and not with children like any other normal programming languages (except JavaScript and Python which are dynamically typed). In other words it should not be possible to pass a instance of a class to a function that expects one of a another class for the case when the class expected is a child of the class given yet progress allows this (at least for the object class).

Quick question, when converting extent variables given as arguments what is the node that is generally taken into account, the variable definition or the function definition?

You can create some tests with integer[] vs decimal[]. I don't have a quick answer, but what I know is that the argument and parameter type must match depending on the mode (INPUT/OUTPUT/INPUT-OUTPUT). So, for OUTPUT, the argument's type needs to be wider than the parameter's type (as the argument will be written).

• OUTPUT means the argument's type is wider than the parameter's type (so arg can be progress.lang.object while parameter progress.lang.class)
• for INPUT means the argument's type is narrower than the parameter's type (so arg can be progress.lang.class while parameter progress.lang.object)
• for INPUT-OUTPUT, they must match exactly AFAIK.

Ok so, I tried examples with integer[] and decimal[] but the converted code won't compile. That is because of the wrap function but that's another problem that doesn't have to do with this task.

I tried writing another simple example with a class that inherits another and it looks like the converted code has the same problem:

DEFINE VARIABLE b AS CLASS task.ClsB EXTENT 3.

FUNCTION func RETURNS INTEGER (OUTPUT out AS task.ClsA EXTENT 3):
END FUNCTION.

func(OUTPUT b).

@LegacySignature(type = Type.MAIN, name = "task/play.p")
   public void execute()
   {
      externalProcedure(Play.this, new Block((Body) () -> 
      {
         func(new OutputExtentParameter<object<? extends com.goldencode.testcases.task.ClsB>>()
         {
            public object<? extends com.goldencode.testcases.task.ClsB>[] getVariable()
            {
               return b;
            }

            public void setVariable(final object<? extends com.goldencode.testcases.task.ClsB>[] newRef)
            {
               b = newRef;
            }
         });
      }));
   }

I assume that the correct version would be this:

@LegacySignature(type = Type.MAIN, name = "task/play.p")
   public void execute()
   {
      externalProcedure(Play.this, new Block((Body) () -> 
      {
         func(new OutputExtentParameter<object<? extends com.goldencode.testcases.task.ClsA>>()
         {
            public object<? extends com.goldencode.testcases.task.ClsA>[] getVariable()
            {
               return (object<? extends ClsA>[]) b;
            }

            public void setVariable(final object<? extends com.goldencode.testcases.task.ClsA>[] newRef)
            {
               b = newRef;
            }
         });
      }));
   }

The conversion is done at convert/output_parameter.rules around line 138.

In annotations/output_parameter.rules, save an additional outputExtentObjectType annotation (from the target parameter definition, like object<? extends ...>). From there, in convert/output_parameter.rules, if outputExtentType starts with object<, and it does not match the outputExtentObjectType annotation, then use a different template - see java_templates.tpl, like output_extent_var_expr.

Committed rev. 15858 on branch 9877a. This version resolves the initial issue but I'm not sure it converts correctly in all cases.
For example:

DEFINE VARIABLE b AS CLASS task.ClsB EXTENT 3.

FUNCTION func RETURNS INTEGER (OUTPUT out AS task.ClsA EXTENT 3):
END FUNCTION.

func(OUTPUT b).

public class Play
{
   @LegacySignature(type = Type.VARIABLE, extent = 3, name = "b")
   object<? extends com.goldencode.testcases.task.ClsB>[] b = UndoableFactory.objectExtent(3, com.goldencode.testcases.task.ClsB.class);

   /**
    * External procedure (converted to Java from the 4GL source code
    * in task/play.p).
    */
   @LegacySignature(type = Type.MAIN, name = "task/play.p")
   public void execute()
   {
      externalProcedure(Play.this, new Block((Body) () -> 
      {
         func(new OutputExtentParameter<object<? extends com.goldencode.testcases.task.ClsA>>()
         {
            public object<? extends com.goldencode.testcases.task.ClsA>[] getVariable()
            {
               return (object[]) b;
            }

            public void setVariable(final object<? extends com.goldencode.testcases.task.ClsA>[] newRef)
            {
               b = newRef;
            }
         });
      }));
   }

   @LegacySignature(type = Type.FUNCTION, name = "func", returns = "INTEGER", parameters = 
   {
      @LegacyParameter(name = "out", type = "OBJECT", extent = 3, qualified = "task.clsa", mode = "OUTPUT")
   })
   public integer func(final OutputExtentParameter<object<? extends com.goldencode.testcases.task.ClsA>> extout)
   {
      object<? extends com.goldencode.testcases.task.ClsA>[] out = TypeFactory.initOutput(extout, 3);

      return function(this, "func", integer.class, new Block());
   }
}

Is the cast to object[] correct? Or should it be object<? extends ClsA>[]?

Paul Bodale wrote:

Is the cast to object[] correct? Or should it be object<? extends ClsA>[]?

Does it compile in Java 8 (and Java 17) if you manually change to object<? extends ClsA>[] ?

I've looked at the branch and the approach is good; the only note: if you look at the function def AST, there will be a typelist annotation - get the type from there. See annotations.xml line 794 for an example how is used.

Also, please test with OO method calls, too.

Constantin Asofiei wrote:

Paul Bodale wrote:

Is the cast to object[] correct? Or should it be object<? extends ClsA>[]?

Does it compile in Java 8 (and Java 17) if you manually change to object<? extends ClsA>[] ?

I tried both tests (the one with the custom classes and the one with progress.lang.Object/Class) with the modification on both java 17 and java 8 and they compile and run except for the problem described below.

I've looked at the branch and the approach is good; the only note: if you look at the function def AST, there will be a typelist annotation - get the type from there. See annotations.xml line 794 for an example how is used.

I need to have the parameter ast because I'm using the "full-java-class" annotation to build the bounding for the object wildcard. This is also how the outputExtentType annotation is created. But I've noticed a problem with this, if the function returns an extent then the first child won't be the LPARENS like I expect. Is there maybe a function in common-progress.rules that can help with this?

Constantin Asofiei wrote:

Also, please test with OO method calls, too.

I wrote a batch of tests and after some problems I managed to get them converted and compiled successfully.

• I believe this is a known issue but one of the problems were because I didn't qualify the argument given to the function call as being OUTPUT. This resulted in wrong conversion.
• Another problem I had was that the rule I wrote was supposed to accommodate method calls too. I added a function in common-progress.rules called get_param_ast to be able to retrieve the corresponding parameter of a function or a method call.
• The tests I wrote include the cases for integer/decimal as well as coverage for some known issues I had. There seems to be a problem with the behavior of BDT extents given as output arguments for method calls. It looks like the variables don't get updated and stay the same as before the function call.
• There are 2 simple cases where calling a function that expects a integer extent with a decimal extent doesn't work because of the wrap function but this is not part of this task.

Other than the exceptions related to BDT variables/parameters mentioned, the tests convert correctly and are passing successfully.

I tested with both java 8 and java 17 and in both cases the project compiles and runs.

I committed rev. 15861 with the clean and complete fix and added history entries.

Standing by for review 😄

Paul, just one question: get_param_ast - this is supposed to find a PARAMETER node under LPARENS of the method/function definition, right? I ask because for calls, the arguments are not parented in a PARAMETER node, so the argument index is the param_index annotation, not indexPos.

Constantin Asofiei wrote:

Paul, just one question: get_param_ast - this is supposed to find a PARAMETER node under LPARENS of the method/function definition, right?

Yes.

I ask because for calls, the arguments are not parented in a PARAMETER node, so the argument index is the param_index annotation, not indexPos.

I used the param_index annotation when calling the function from annotations/output_parameters.rules. The arguments of the get_param_ast are the function/method node (which is the parent in our case) and the index of the parameter which is retrieved via #(int) getNoteLong("param_index").

Perhaps I used indexPos in a older revision and realized the mistake after. The latest revision is 15861 .

Committed rev. 15873 on branch 9877a which fixes the issue where the code would convert to the text ${rettype}.

Took me a little to reproduce the error, it was because of a mistake in the rule introduced by the previous commit.

Please merge 9877a to trunk now.