ibm-netrexx

NetRexx & JavaFX HelloWorld

Classic

List

Threaded

18 messages Options

peter.dehouwerleeuw

NetRexx & JavaFX HelloWorld

Dear all,
As a new NetRexx user I have been reading the documentation and testing and testing.
I was very pleased with the basic results.
Then I tried using the Java API (file I/O and other classes) and also everything was working as expected.
Happy I was to have found NetRexx.

Now for the real work, I was planning to create a GUI application by using the new JavaFX 8.
I begon with a simple think like the traditional "Hello World" :

/* ===================================================== */
import javafx.application.Application;
import javafx.event.ActionEvent;
import javafx.event.EventHandler;
import javafx.scene.Group;
import javafx.scene.Scene;
import javafx.scene.control.Button;
import javafx.stage.Stage;

public class HelloWorldMainTopic extends Application {

public static void main(String[] args) {
Application.launch(args);
}

public void start(Stage primaryStage) {
primaryStage.setTitle("Hello World");
Group root = new Group();
Scene scene = new Scene(root, 300, 250);
Button btn = new Button();
btn.setLayoutX(100);
btn.setLayoutY(80);
btn.setText("Hello World");

/* ..................
btn.setOnAction(new EventHandler<ActionEvent>() {
public void handle(ActionEvent event) {
System.out.println("Hello World");
}
});
.................. */

root.getChildren().add(btn);
primaryStage.setScene(scene);
primaryStage.show();
}
}
/* ===================================================== */

Traslated into NetRexx:
/* ----------------------------------------------------- */
Import javafx.application.Application
Import javafx.event.ActionEvent
Import javafx.event.EventHandler
Import javafx.scene.Group
Import javafx.scene.Scene
Import javafx.scene.control.Button
Import javafx.stage.Stage

Class testMainTopic public extends Application

Method main(args=String[]) public static
Application.launch(args)

Method start(primaryStage = Stage) public
primaryStage.setTitle('Hello World')
root = Group()
scene1 = Scene(root,600,250)

btn = Button()
btn.setLayoutX(100)
btn.setLayoutY(80)
btn.setText("Hello World")

root.getChildren().add(btn)

primaryStage.setScene(scene1)
primaryStage.show()
/* ----------------------------------------------------- */

To the point. The JAVA example does work (with or without the extra code "btn.setOnAction")
The NetRexx example does not work.

/testMainTopic.java:24: error: no suitable method found for add(Object)
root.getChildren().add((java.lang.Object)btn);
^
method Collection.add(Node) is not applicable
(argument mismatch; Object cannot be converted to Node)
method List.add(Node) is not applicable
(argument mismatch; Object cannot be converted to Node)
Note: Some messages have been simplified; recompile with -Xdiags:verbose to get full output

If I remove the statement "root.getChildren().add(btn)", then it works (of course if just displays an empty 'stage').

> Could a friendly soul shed some light into this problem?
> Comments and suggestions are very much welcome.

--------------------------------
Besides this I have a couple of additional questions:

- If you replace all those import instructions with "Import javafx. ", then one gets:
+++ btn = Button()
+++ ^^^^^^
+++ Error: Class reference is ambiguous (more than one class matches 'Button')

- The compile process in NetRexx is being done with the JAVA option (JAVAC compiler).
If one compiles with " -Dnrx.compiler=ecj " then you get:
===== Exception running class test: java.lang.RuntimeException: Error: class sun.reflect.
NativeMethodAccessorImpl is not a subclass of javafx.application.Application =====
--- in test.main(String[]) [test.nrx:14]
15 +++ Application.launch(args)
+++ ^^^^^^

- Besides that, I have no clue on how to implement that " btn.setOnAction " section of the Java code :-(

Best regards.
_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

Jason Martin

Re: NetRexx & JavaFX HelloWorld

Without trying your code.

1) Make sure Node is not being considered as a NetRexx node.

2) Button can appear in more than one class. Example: some.class.Button, another.class.Button or 50 thousands other classes.Button

You may need to add specific import statement or use fully qualified name in code. Example: java.awt.Button

On Wed, Jul 20, 2016 at 7:29 PM, <[hidden email]> wrote:

Dear all,
As a new NetRexx user I have been reading the documentation and testing and testing.
I was very pleased with the basic results.
Then I tried using the Java API (file I/O and other classes) and also everything was working as expected.
Happy I was to have found NetRexx.

Now for the real work, I was planning to create a GUI application by using the new JavaFX 8.
I begon with a simple think like the traditional "Hello World" :

/* ===================================================== */
import javafx.application.Application;
import javafx.event.ActionEvent;
import javafx.event.EventHandler;
import javafx.scene.Group;
import javafx.scene.Scene;
import javafx.scene.control.Button;
import javafx.stage.Stage;

public class HelloWorldMainTopic extends Application {

public static void main(String[] args) {
Application.launch(args);
}

public void start(Stage primaryStage) {
primaryStage.setTitle("Hello World");
Group root = new Group();
Scene scene = new Scene(root, 300, 250);
Button btn = new Button();
btn.setLayoutX(100);
btn.setLayoutY(80);
btn.setText("Hello World");

/* ..................
btn.setOnAction(new EventHandler<ActionEvent>() {
public void handle(ActionEvent event) {
System.out.println("Hello World");
}
});
.................. */

root.getChildren().add(btn);
primaryStage.setScene(scene);
primaryStage.show();
}
}
/* ===================================================== */

Traslated into NetRexx:
/* ----------------------------------------------------- */
Import javafx.application.Application
Import javafx.event.ActionEvent
Import javafx.event.EventHandler
Import javafx.scene.Group
Import javafx.scene.Scene
Import javafx.scene.control.Button
Import javafx.stage.Stage

Class testMainTopic public extends Application

Method main(args=String[]) public static
Application.launch(args)

Method start(primaryStage = Stage) public
primaryStage.setTitle('Hello World')
root = Group()
scene1 = Scene(root,600,250)

btn = Button()
btn.setLayoutX(100)
btn.setLayoutY(80)
btn.setText("Hello World")

root.getChildren().add(btn)

primaryStage.setScene(scene1)
primaryStage.show()
/* ----------------------------------------------------- */

To the point. The JAVA example does work (with or without the extra code "btn.setOnAction")
The NetRexx example does not work.

/testMainTopic.java:24: error: no suitable method found for add(Object)
root.getChildren().add((java.lang.Object)btn);
^
method Collection.add(Node) is not applicable
(argument mismatch; Object cannot be converted to Node)
method List.add(Node) is not applicable
(argument mismatch; Object cannot be converted to Node)
Note: Some messages have been simplified; recompile with -Xdiags:verbose to get full output

If I remove the statement "root.getChildren().add(btn)", then it works (of course if just displays an empty 'stage').

> Could a friendly soul shed some light into this problem?
> Comments and suggestions are very much welcome.

--------------------------------
Besides this I have a couple of additional questions:

- If you replace all those import instructions with "Import javafx. ", then one gets:
+++ btn = Button()
+++ ^^^^^^
+++ Error: Class reference is ambiguous (more than one class matches 'Button')

- The compile process in NetRexx is being done with the JAVA option (JAVAC compiler).
If one compiles with " -Dnrx.compiler=ecj " then you get:
===== Exception running class test: java.lang.RuntimeException: Error: class sun.reflect.
NativeMethodAccessorImpl is not a subclass of javafx.application.Application =====
--- in test.main(String[]) [test.nrx:14]
15 +++ Application.launch(args)
+++ ^^^^^^

- Besides that, I have no clue on how to implement that " btn.setOnAction " section of the Java code :-(

Best regards.
_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

peter.dehouwerleeuw

Re: NetRexx & JavaFX HelloWorld

Thank you for the suggestion. I tried the fully qualified names, but still not working.
How can I be sure that Node is not being considered a NetRexx node?
Would it be possible, kindly requested, that someone actually tries to implement the below Java code in NetRexx?
To be sure that NetRexx can work with JavaFX. (newbie question :-(
Thanks beforehand for the support and best regards.

Jason Martin <[hidden email]>
Sent by: [hidden email]

2016-07-21 10:46

Please respond to
IBM Netrexx <[hidden email]>

To	IBM Netrexx <[hidden email]>,
cc
Subject	Re: [Ibm-netrexx] NetRexx & JavaFX HelloWorld

Without trying your code.
1) Make sure Node is not being considered as a NetRexx node.
2) Button can appear in more than one class. Example: some.class.Button, another.class.Button or 50 thousands other classes.Button
You may need to add specific import statement or use fully qualified name in code. Example: java.awt.Button

----------------------------------------------------------------------------------------------------
On Wed, Jul 20, 2016 at 7:29 PM, <peter.dehouwerleeuw@...> wrote:
Dear all,
As a new NetRexx user I have been reading the documentation and testing and testing.
I was very pleased with the basic results.
Then I tried using the Java API (file I/O and other classes) and also everything was working as expected.
Happy I was to have found NetRexx.

Now for the real work, I was planning to create a GUI application by using the new JavaFX 8.
I begon with a simple think like the traditional "Hello World" :

/* ===================================================== */
import javafx.application.Application;
import javafx.event.ActionEvent;
import javafx.event.EventHandler;
import javafx.scene.Group;
import javafx.scene.Scene;
import javafx.scene.control.Button;
import javafx.stage.Stage;

public class HelloWorldMainTopic extends Application {

public static void main(String[] args) {
Application.launch(args);
}

public void start(Stage primaryStage) {
primaryStage.setTitle("Hello World");
Group root = new Group();
Scene scene = new Scene(root, 300, 250);
Button btn = new Button();
btn.setLayoutX(100);
btn.setLayoutY(80);
btn.setText("Hello World");

/* ..................
btn.setOnAction(new EventHandler<ActionEvent>() {
public void handle(ActionEvent event) {
System.out.println("Hello World");
}
});
.................. */

root.getChildren().add(btn);
primaryStage.setScene(scene);
primaryStage.show();
}
}
/* ===================================================== */

Traslated into NetRexx:
/* ----------------------------------------------------- */
Import javafx.application.Application
Import javafx.event.ActionEvent
Import javafx.event.EventHandler
Import javafx.scene.Group
Import javafx.scene.Scene
Import javafx.scene.control.Button
Import javafx.stage.Stage

Class testMainTopic public extends Application

Method main(args=String[]) public static
Application.launch(args)

Method start(primaryStage = Stage) public
primaryStage.setTitle('Hello World')
root = Group()
scene1 = Scene(root,600,250)

btn = Button()
btn.setLayoutX(100)
btn.setLayoutY(80)
btn.setText("Hello World")

root.getChildren().add(btn)

primaryStage.setScene(scene1)
primaryStage.show()
/* ----------------------------------------------------- */

To the point. The JAVA example does work (with or without the extra code "btn.setOnAction")
The NetRexx example does not work.

/testMainTopic.java:24: error: no suitable method found for add(Object)
root.getChildren().add((java.lang.Object)btn);
^
method Collection.add(Node) is not applicable
(argument mismatch; Object cannot be converted to Node)
method List.add(Node) is not applicable
(argument mismatch; Object cannot be converted to Node)
Note: Some messages have been simplified; recompile with -Xdiags:verbose to get full output

If I remove the statement "root.getChildren().add(btn)", then it works (of course if just displays an empty 'stage').

> Could a friendly soul shed some light into this problem?
> Comments and suggestions are very much welcome.

--------------------------------
Besides this I have a couple of additional questions:

- If you replace all those import instructions with "Import javafx. ", then one gets:
+++ btn = Button()
+++ ^^^^^^
+++ Error: Class reference is ambiguous (more than one class matches 'Button')

- The compile process in NetRexx is being done with the JAVA option (JAVAC compiler).
If one compiles with " -Dnrx.compiler=ecj " then you get:
===== Exception running class test: java.lang.RuntimeException: Error: class sun.reflect.
NativeMethodAccessorImpl is not a subclass of javafx.application.Application =====
--- in test.main(String[]) [test.nrx:14]
15 +++ Application.launch(args)
+++ ^^^^^^

- Besides that, I have no clue on how to implement that " btn.setOnAction " section of the Java code :-(

Best regards.
_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

Dave Woodman

Re: NetRexx & JavaFX HelloWorld

In reply to this post by peter.dehouwerleeuw

Looking at the Java intermediate file, the types all seem good, in particular

javafx.scene.control.Button btn;

The issue seems to be that NetRexx compiles the

root.getChildren().add(btn)

to Java of

root.getChildren().add((java.lang.Object)btn);

and that the collection of type ObservableList returned by getChildren will not allow an Object to be added.

Changing the Java to simply

root.getChildren().add(btn);

compiles correctly, as does

root.getChildren().add((javafx.scene.Node) btn);

which is to be expected, since Node is the base type of the list.

So, the obvious thing to try in NetRexx is

root.getChildren.add(javafx.scene.Node btn)

Which compiles to

root.getChildren().add((java.lang.Object)((javafx.scene.Node)btn));

And that, of course, does not help, and does not seem sensible to me.

This is indeed a problem, but I must defer to those more knowledgable than I - I would think that explicitly casting an object should not result in a double cast, as above, but this may be desired behaviour in other cases.

How do others judge this?

rickmcguire

Re: NetRexx & JavaFX HelloWorld

The Group.getChildren() method is defined as returning ObservableList<Node>, which is a generic type. NetRexx does not yet support generics, so I'm guessing it is messing up generating the add() call because it is falling back to the base ObservalList definition rather than the defined type.

Rick

On Thu, Jul 21, 2016 at 6:11 AM, Dave Woodman <[hidden email]> wrote:

Looking at the Java intermediate file, the types all seem good, in particular

*javafx.scene.control.Button btn;*

The issue seems to be that NetRexx compiles the

*root.getChildren().add(btn)*

to Java of

*root.getChildren().add((java.lang.Object)btn);*

and that the collection of type ObservableList returned by getChildren will
not allow an Object to be added.

Changing the Java to simply

*root.getChildren().add(btn);*

compiles correctly, as does

*root.getChildren().add((javafx.scene.Node) btn); *

which is to be expected, since Node is the base type of the list.

So, the obvious thing to try in NetRexx is

*root.getChildren.add(javafx.scene.Node btn)*

Which compiles to

*root.getChildren().add((java.lang.Object)((javafx.scene.Node)btn)); *

And that, of course, does not help, and does not seem sensible to me.

This is indeed a problem, but I must defer to those more knowledgable than I
- I would think that explicitly casting an object should not result in a
double cast, as above, but this may be desired behaviour in other cases.

How do others judge this?

--
View this message in context: http://ibm-netrexx.215625.n3.nabble.com/NetRexx-JavaFX-HelloWorld-tp4027849p4027852.html
Sent from the ibm-netrexx mailing list archive at Nabble.com.

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

Dave Woodman

Re: NetRexx & JavaFX HelloWorld

The normal “workaround” is to just use an Object rather than using the generics.

In this case that does not seem to work

Dave.

From: [hidden email] [mailto:[hidden email]] On Behalf Of Rick McGuire
Sent: 21 July 2016 11:48
To: IBM Netrexx <[hidden email]>
Subject: Re: [Ibm-netrexx] NetRexx & JavaFX HelloWorld

Rick

On Thu, Jul 21, 2016 at 6:11 AM, Dave Woodman <[hidden email]> wrote:

Looking at the Java intermediate file, the types all seem good, in particular

*javafx.scene.control.Button btn;*

The issue seems to be that NetRexx compiles the

*root.getChildren().add(btn)*

to Java of

*root.getChildren().add((java.lang.Object)btn);*

and that the collection of type ObservableList returned by getChildren will
not allow an Object to be added.

Changing the Java to simply

*root.getChildren().add(btn);*

compiles correctly, as does

*root.getChildren().add((javafx.scene.Node) btn); *

which is to be expected, since Node is the base type of the list.

So, the obvious thing to try in NetRexx is

*root.getChildren.add(javafx.scene.Node btn)*

Which compiles to

*root.getChildren().add((java.lang.Object)((javafx.scene.Node)btn)); *

And that, of course, does not help, and does not seem sensible to me.

This is indeed a problem, but I must defer to those more knowledgable than I
- I would think that explicitly casting an object should not result in a
double cast, as above, but this may be desired behaviour in other cases.

How do others judge this?

--
View this message in context: http://ibm-netrexx.215625.n3.nabble.com/NetRexx-JavaFX-HelloWorld-tp4027849p4027852.html
Sent from the ibm-netrexx mailing list archive at Nabble.com.

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

rickmcguire

Re: NetRexx & JavaFX HelloWorld

On Thu, Jul 21, 2016 at 7:02 AM, Dave Woodman <[hidden email]> wrote:

The normal “workaround” is to just use an Object rather than using the generics.

In this case that does not seem to work

It's not going to work because the java compilation stage sees that the method returns ObservableList<Node> and will enforce the restriction that the added item is a Node instance. Because the NetRexx compiler inserted the cast to Object, this caused the error. The cast is odd, since it is completely unnecessary. Perhaps the compiler should be examining the type of the argument more closely to see if a cast is necessary.

Rick

Dave.
From: [hidden email] [mailto:[hidden email]] On Behalf Of Rick McGuire
Sent: 21 July 2016 11:48
To: IBM Netrexx <[hidden email]>
Subject: Re: [Ibm-netrexx] NetRexx & JavaFX HelloWorld

The Group.getChildren() method is defined as returning ObservableList<Node>, which is a generic type. NetRexx does not yet support generics, so I'm guessing it is messing up generating the add() call because it is falling back to the base ObservalList definition rather than the defined type.

Rick

On Thu, Jul 21, 2016 at 6:11 AM, Dave Woodman <[hidden email]> wrote:
Looking at the Java intermediate file, the types all seem good, in particular

*javafx.scene.control.Button btn;*

The issue seems to be that NetRexx compiles the

*root.getChildren().add(btn)*

to Java of

*root.getChildren().add((java.lang.Object)btn);*

and that the collection of type ObservableList returned by getChildren will
not allow an Object to be added.

Changing the Java to simply

*root.getChildren().add(btn);*

compiles correctly, as does

*root.getChildren().add((javafx.scene.Node) btn); *

which is to be expected, since Node is the base type of the list.

So, the obvious thing to try in NetRexx is

*root.getChildren.add(javafx.scene.Node btn)*

Which compiles to

*root.getChildren().add((java.lang.Object)((javafx.scene.Node)btn)); *

And that, of course, does not help, and does not seem sensible to me.

This is indeed a problem, but I must defer to those more knowledgable than I
- I would think that explicitly casting an object should not result in a
double cast, as above, but this may be desired behaviour in other cases.

How do others judge this?

--
View this message in context: http://ibm-netrexx.215625.n3.nabble.com/NetRexx-JavaFX-HelloWorld-tp4027849p4027852.html
Sent from the ibm-netrexx mailing list archive at Nabble.com.

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

rvjansen

Re: NetRexx & JavaFX HelloWorld

In reply to this post by Dave Woodman

My take on this would be:

import javafx.application.

import javafx.event.

import javafx.scene.

import javafx.stage.

import javafx.collections.

class testMainTopic public extends Application

  method main(args=String[]) public static

    Application.launch(args)

  method start(primaryStage = Stage) public

    primaryStage.setTitle('Hello World')

    root  = Group()

    scene1 = Scene(root,600,250)

    btn   = javafx.scene.control.Button()

    btn.setLayoutX(100)

    btn.setLayoutY(80)

    btn.setText("Hello World")

    oList = ObservableList root.getChildren()

    oList.add(javafx.scene.control.Button btn)

    primaryStage.setScene(scene1)

    primaryStage.show()

Which seems to work.

best regards,

René.

On 21 jul. 2016, at 13:02, Dave Woodman <[hidden email]> wrote:

The normal “workaround” is to just use an Object rather than using the generics.

In this case that does not seem to work

Dave.
From: [hidden email] [[hidden email]] On Behalf Of Rick McGuire
Sent: 21 July 2016 11:48
To: IBM Netrexx <[hidden email]>
Subject: Re: [Ibm-netrexx] NetRexx & JavaFX HelloWorld

The Group.getChildren() method is defined as returning ObservableList<Node>, which is a generic type. NetRexx does not yet support generics, so I'm guessing it is messing up generating the add() call because it is falling back to the base ObservalList definition rather than the defined type.

Rick

On Thu, Jul 21, 2016 at 6:11 AM, Dave Woodman <[hidden email]> wrote:
Looking at the Java intermediate file, the types all seem good, in particular

*javafx.scene.control.Button btn;*

The issue seems to be that NetRexx compiles the

*root.getChildren().add(btn)*

to Java of

*root.getChildren().add((java.lang.Object)btn);*

and that the collection of type ObservableList returned by getChildren will
not allow an Object to be added.

Changing the Java to simply

*root.getChildren().add(btn);*

compiles correctly, as does

*root.getChildren().add((javafx.scene.Node) btn); *

which is to be expected, since Node is the base type of the list.

So, the obvious thing to try in NetRexx is

*root.getChildren.add(javafx.scene.Node btn)*

Which compiles to

*root.getChildren().add((java.lang.Object)((javafx.scene.Node)btn)); *

And that, of course, does not help, and does not seem sensible to me.

This is indeed a problem, but I must defer to those more knowledgable than I
- I would think that explicitly casting an object should not result in a
double cast, as above, but this may be desired behaviour in other cases.

How do others judge this?

--
View this message in context: http://ibm-netrexx.215625.n3.nabble.com/NetRexx-JavaFX-HelloWorld-tp4027849p4027852.html
Sent from the ibm-netrexx mailing list archive at Nabble.com.

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

Dave Woodman

Re: NetRexx & JavaFX HelloWorld

In reply to this post by rickmcguire

I think we are agreeing here J

From: [hidden email] [mailto:[hidden email]] On Behalf Of Rick McGuire
Sent: 21 July 2016 12:09
To: IBM Netrexx <[hidden email]>
Subject: Re: [Ibm-netrexx] NetRexx & JavaFX HelloWorld

On Thu, Jul 21, 2016 at 7:02 AM, Dave Woodman <[hidden email]> wrote:

The normal “workaround” is to just use an Object rather than using the generics.

In this case that does not seem to work

Rick

Dave.
From: [hidden email] [mailto:[hidden email]] On Behalf Of Rick McGuire
Sent: 21 July 2016 11:48
To: IBM Netrexx <[hidden email]>
Subject: Re: [Ibm-netrexx] NetRexx & JavaFX HelloWorld

The Group.getChildren() method is defined as returning ObservableList<Node>, which is a generic type. NetRexx does not yet support generics, so I'm guessing it is messing up generating the add() call because it is falling back to the base ObservalList definition rather than the defined type.

Rick

On Thu, Jul 21, 2016 at 6:11 AM, Dave Woodman <[hidden email]> wrote:
Looking at the Java intermediate file, the types all seem good, in particular

*javafx.scene.control.Button btn;*

The issue seems to be that NetRexx compiles the

*root.getChildren().add(btn)*

to Java of

*root.getChildren().add((java.lang.Object)btn);*

and that the collection of type ObservableList returned by getChildren will
not allow an Object to be added.

Changing the Java to simply

*root.getChildren().add(btn);*

compiles correctly, as does

*root.getChildren().add((javafx.scene.Node) btn); *

which is to be expected, since Node is the base type of the list.

So, the obvious thing to try in NetRexx is

*root.getChildren.add(javafx.scene.Node btn)*

Which compiles to

*root.getChildren().add((java.lang.Object)((javafx.scene.Node)btn)); *

And that, of course, does not help, and does not seem sensible to me.

This is indeed a problem, but I must defer to those more knowledgable than I
- I would think that explicitly casting an object should not result in a
double cast, as above, but this may be desired behaviour in other cases.

How do others judge this?

--
View this message in context: http://ibm-netrexx.215625.n3.nabble.com/NetRexx-JavaFX-HelloWorld-tp4027849p4027852.html
Sent from the ibm-netrexx mailing list archive at Nabble.com.

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

Dave Woodman

Re: NetRexx & JavaFX HelloWorld

In reply to this post by rvjansen

So it does!

I am left wondering, however, if the “double cast” is legitimate. If one is performing a cast then it is an explicit overriding of an assumption made.

Should the compiler not honour that?

Dave.

From: [hidden email] [mailto:[hidden email]] On Behalf Of René Jansen
Sent: 21 July 2016 12:18
To: IBM Netrexx <[hidden email]>
Subject: Re: [Ibm-netrexx] NetRexx & JavaFX HelloWorld

My take on this would be:

import javafx.application.

import javafx.event.

import javafx.scene.

import javafx.stage.

import javafx.collections.

class testMainTopic public extends Application

method main(args=String[]) public static

Application.launch(args)

method start(primaryStage = Stage) public

primaryStage.setTitle('Hello World')

root = Group()

scene1 = Scene(root,600,250)

btn = javafx.scene.control.Button()

btn.setLayoutX(100)

btn.setLayoutY(80)

btn.setText("Hello World")

oList = ObservableList root.getChildren()

oList.add(javafx.scene.control.Button btn)

primaryStage.setScene(scene1)

primaryStage.show()

Which seems to work.

best regards,

René.

On 21 jul. 2016, at 13:02, Dave Woodman <[hidden email]> wrote:

The normal “workaround” is to just use an Object rather than using the generics.

In this case that does not seem to work

Dave.
From: [hidden email] [[hidden email]] On Behalf Of Rick McGuire
Sent: 21 July 2016 11:48
To: IBM Netrexx <[hidden email]>
Subject: Re: [Ibm-netrexx] NetRexx & JavaFX HelloWorld

The Group.getChildren() method is defined as returning ObservableList<Node>, which is a generic type. NetRexx does not yet support generics, so I'm guessing it is messing up generating the add() call because it is falling back to the base ObservalList definition rather than the defined type.

Rick

On Thu, Jul 21, 2016 at 6:11 AM, Dave Woodman <[hidden email]> wrote:
Looking at the Java intermediate file, the types all seem good, in particular

*javafx.scene.control.Button btn;*

The issue seems to be that NetRexx compiles the

*root.getChildren().add(btn)*

to Java of

*root.getChildren().add((java.lang.Object)btn);*

and that the collection of type ObservableList returned by getChildren will
not allow an Object to be added.

Changing the Java to simply

*root.getChildren().add(btn);*

compiles correctly, as does

*root.getChildren().add((javafx.scene.Node) btn); *

which is to be expected, since Node is the base type of the list.

So, the obvious thing to try in NetRexx is

*root.getChildren.add(javafx.scene.Node btn)*

Which compiles to

*root.getChildren().add((java.lang.Object)((javafx.scene.Node)btn)); *

And that, of course, does not help, and does not seem sensible to me.

This is indeed a problem, but I must defer to those more knowledgable than I
- I would think that explicitly casting an object should not result in a
double cast, as above, but this may be desired behaviour in other cases.

How do others judge this?

--
View this message in context: http://ibm-netrexx.215625.n3.nabble.com/NetRexx-JavaFX-HelloWorld-tp4027849p4027852.html
Sent from the ibm-netrexx mailing list archive at Nabble.com.

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

rvjansen

Re: NetRexx & JavaFX HelloWorld

In reply to this post by peter.dehouwerleeuw

Hi Peter,

to answer your other questions:

- If you replace all those import instructions with "Import javafx. ", then one gets:
+++ btn = Button()
+++ ^^^^^^
+++ Error: Class reference is ambiguous (more than one class matches 'Button’)

This is because during the scan of the classpath other classes were found that match this name. It would be great if we could display these but it turned out rather hard. As this mechanism is being replaced for NetRexx 5, I would suggest to do what I do: just use the correct, spelled out (‘fully qualified’) name and not waste time bothering how to figure out what the other classes might be. I gather they are from AWT or Swing in this case.

- The compile process in NetRexx is being done with the JAVA option (JAVAC compiler).
If one compiles with " -Dnrx.compiler=ecj " then you get:
===== Exception running class test: java.lang.RuntimeException: Error: class sun.reflect.
NativeMethodAccessorImpl is not a subclass of javafx.application.Application =====
--- in test.main(String[]) [test.nrx:14]
15 +++ Application.launch(args)
+++ ^^^^^^

Thank you for mentioning that, it means we might have to upgrade the packaged Eclipse batch compiler.

- Besides that, I have no clue on how to implement that " btn.setOnAction " section of the Java code :-(

I have shown below how I do it, taking your example java code. Of course, you want to do something with the event content, most of the time.

import javafx.application.

import javafx.event.

import javafx.scene.

import javafx.stage.

import javafx.collections.

class testMainTopic public extends Application

  method main(args=String[]) public static

    Application.launch(args)

  method start(primaryStage = Stage) public

    primaryStage.setTitle('Hello World')

    root  = Group()

    scene1 = Scene(root,double 600,double 250)

    btn   = javafx.scene.control.Button()

    btn.setLayoutX(double 100)

    btn.setLayoutY(double 80)

    btn.setText("Hello World")

    btn.setOnAction(testMainTopic.buttonAction())

    oList = ObservableList root.getChildren()

    oList.add(javafx.scene.control.Button btn)

    primaryStage.setScene(scene1)

    primaryStage.show()

class testMainTopic.buttonAction implements EventHandler dependent

  method handle(e=javafx.event.Event)

    say 'hello, world'

best regards,

René.

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

rvjansen

Re: NetRexx & JavaFX HelloWorld

In reply to this post by Dave Woodman

Dave,

compilers should do what we tell them to do .. except when that is wrong. In this case, I blame Java. The cast to Object was there probably from the introduction of the Collection framework, and maybe before that when we had Directory and Vector, which needed to take Object, and I seem to remember you even had to cast every argument to Object, even if that was always the defined top of the class hierarchy, and so, as Rick says, completely unnecessary. For generics, I also blame Java, which added a lot of notation for what in essence is compiler trickery with hardly any runtime code generation consequences, and still no ‘generic’ treatment like C++ can do.

Also, I am a bit allergic to calls like:

root.getChildren().add(btn);

this leaves a lot - too much - of what happens implicit and hampers understanding. It is not evident from the notation that you call something, and send another message to the result. I tend to write those out completely and on separate lines, which also helps adding something to it or tracing it with trace or a debugger. And in this case, it helps to generate the right call, precisely because you add what was left out.

There is also another type of double cast left in the generated java - when we do not specify the arguments as double, we get (double) (byte) and (double) (short) generated. I do not worry about those too much, although I also doubt that we really need them.

best regards,

René.

On 21 jul. 2016, at 13:31, Dave Woodman <[hidden email]> wrote:

So it does!

I am left wondering, however, if the “double cast” is legitimate. If one is performing a cast then it is an explicit overriding of an assumption made.

Should the compiler not honour that?

Dave.

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

peter.dehouwerleeuw

Re: NetRexx & JavaFX HelloWorld

In reply to this post by rvjansen

Mr. Jansen, thank you very much !!! (Hartelijk bedankt! :-)

Also my appreciation for all the nice people that took the time to reply to my original question. Thank you.
And now... let us continue the NetRexx study ;-)

Sincerely,
Peter

René Jansen <[hidden email]>
Sent by: [hidden email]

2016-07-21 14:33

Please respond to
IBM Netrexx <[hidden email]>

To	IBM Netrexx <[hidden email]>,
cc
Subject	Re: [Ibm-netrexx] NetRexx & JavaFX HelloWorld

Hi Peter,

to answer your other questions:

- If you replace all those import instructions with "Import javafx. ", then one gets:
+++ btn = Button()
+++ ^^^^^^
+++ Error: Class reference is ambiguous (more than one class matches 'Button’)

This is because during the scan of the classpath other classes were found that match this name. It would be great if we could display these but it turned out rather hard. As this mechanism is being replaced for NetRexx 5, I would suggest to do what I do: just use the correct, spelled out (‘fully qualified’) name and not waste time bothering how to figure out what the other classes might be. I gather they are from AWT or Swing in this case.

- The compile process in NetRexx is being done with the JAVA option (JAVAC compiler).
If one compiles with " -Dnrx.compiler=ecj " then you get:
===== Exception running class test: java.lang.RuntimeException: Error: class sun.reflect.
NativeMethodAccessorImpl is not a subclass of javafx.application.Application =====
--- in test.main(String[]) [test.nrx:14]
15 +++ Application.launch(args)
+++ ^^^^^^

Thank you for mentioning that, it means we might have to upgrade the packaged Eclipse batch compiler.

- Besides that, I have no clue on how to implement that " btn.setOnAction " section of the Java code :-(

I have shown below how I do it, taking your example java code. Of course, you want to do something with the event content, most of the time.

import javafx.application.
import javafx.event.
import javafx.scene.
import javafx.stage.
import javafx.collections.

class testMainTopic public extends Application

method main(args=String[]) public static
Application.launch(args)

method start(primaryStage = Stage) public
primaryStage.setTitle('Hello World')
root = Group()
scene1 = Scene(root,double 600,double 250)

btn = javafx.scene.control.Button()
btn.setLayoutX(double 100)
btn.setLayoutY(double 80)
btn.setText("Hello World")
btn.setOnAction(testMainTopic.buttonAction())

oList = ObservableList root.getChildren()
oList.add(javafx.scene.control.Button btn)

primaryStage.setScene(scene1)
primaryStage.show()

class testMainTopic.buttonAction implements EventHandler dependent
method handle(e=javafx.event.Event)
say 'hello, world'

best regards,

René._______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive :http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

Dave Woodman

Re: NetRexx & JavaFX HelloWorld

In reply to this post by rvjansen

Hi René,

No doubt that the root cause is historic Java. However I told the compile to generate a cast, and it generated two. Since I was overriding the type, the internal notions of type should be ignored, and the override followed I should think.

To put it another way, I said “Please don’t hold my hand at this point” and the compiler insisted on doing so. Exactly what I was asking it not to do.

I have no problem to it generating the cast to Object (for hysterical reasons) in instances when there is no other cast specified – is this unrealistic?

Dave.

From: [hidden email] [mailto:[hidden email]] On Behalf Of René Jansen
Sent: 21 July 2016 13:38
To: IBM Netrexx <[hidden email]>
Subject: Re: [Ibm-netrexx] NetRexx & JavaFX HelloWorld

Dave,

Also, I am a bit allergic to calls like:

root.getChildren().add(btn);

best regards,

René.

On 21 jul. 2016, at 13:31, Dave Woodman <[hidden email]> wrote:

So it does!

I am left wondering, however, if the “double cast” is legitimate. If one is performing a cast then it is an explicit overriding of an assumption made.

Should the compiler not honour that?

Dave.

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

rvjansen

Re: NetRexx & JavaFX HelloWorld

Hi Dave,

I think that is quite sensible - I am going to look where that cast is inserted and see if we still need to do that - and then we need to regression test with all kind of samples and JVM releases of course … and then if we don’t break important things, we might change it. And if we do, there might be still another option. This might be also something for Kermit.

best regards,

René.

On 21 jul. 2016, at 19:41, Dave Woodman <[hidden email]> wrote:

Hi René,

No doubt that the root cause is historic Java. However I told the compile to generate a cast, and it generated two. Since I was overriding the type, the internal notions of type should be ignored, and the override followed I should think.

To put it another way, I said “Please don’t hold my hand at this point” and the compiler insisted on doing so. Exactly what I was asking it not to do.

I have no problem to it generating the cast to Object (for hysterical reasons) in instances when there is no other cast specified – is this unrealistic?

Dave.

From: [hidden email] [[hidden email]] On Behalf Of René Jansen
Sent: 21 July 2016 13:38
To: IBM Netrexx <[hidden email]>
Subject: Re: [Ibm-netrexx] NetRexx & JavaFX HelloWorld

Dave,

compilers should do what we tell them to do .. except when that is wrong. In this case, I blame Java. The cast to Object was there probably from the introduction of the Collection framework, and maybe before that when we had Directory and Vector, which needed to take Object, and I seem to remember you even had to cast every argument to Object, even if that was always the defined top of the class hierarchy, and so, as Rick says, completely unnecessary. For generics, I also blame Java, which added a lot of notation for what in essence is compiler trickery with hardly any runtime code generation consequences, and still no ‘generic’ treatment like C++ can do.

Also, I am a bit allergic to calls like:

root.getChildren().add(btn);

this leaves a lot - too much - of what happens implicit and hampers understanding. It is not evident from the notation that you call something, and send another message to the result. I tend to write those out completely and on separate lines, which also helps adding something to it or tracing it with trace or a debugger. And in this case, it helps to generate the right call, precisely because you add what was left out.

There is also another type of double cast left in the generated java - when we do not specify the arguments as double, we get (double) (byte) and (double) (short) generated. I do not worry about those too much, although I also doubt that we really need them.

best regards,

René.

On 21 jul. 2016, at 13:31, Dave Woodman <[hidden email]> wrote:

So it does!

I am left wondering, however, if the “double cast” is legitimate. If one is performing a cast then it is an explicit overriding of an assumption made.

Should the compiler not honour that?

Dave.

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

billfen

Re: NetRexx & JavaFX HelloWorld

Is Kermit well enough to take on NetRexx tasks?

If so, that would be wonderful news!

On 7/21/2016 1:46 PM, René Jansen wrote:

Hi Dave,

I think that is quite sensible - I am going to look where that cast is inserted and see if we still need to do that - and then we need to regression test with all kind of samples and JVM releases of course … and then if we don’t break important things, we might change it. And if we do, there might be still another option. This might be also something for Kermit.

best regards,

René.

On 21 jul. 2016, at 19:41, Dave Woodman <[hidden email]> wrote:

Hi René,

No doubt that the root cause is historic Java. However I told the compile to generate a cast, and it generated two. Since I was overriding the type, the internal notions of type should be ignored, and the override followed I should think.

To put it another way, I said “Please don’t hold my hand at this point” and the compiler insisted on doing so. Exactly what I was asking it not to do.

I have no problem to it generating the cast to Object (for hysterical reasons) in instances when there is no other cast specified – is this unrealistic?

Dave.

From: [hidden email] [[hidden email]] On Behalf Of René Jansen
Sent: 21 July 2016 13:38
To: IBM Netrexx <[hidden email]>
Subject: Re: [Ibm-netrexx] NetRexx & JavaFX HelloWorld

Dave,

compilers should do what we tell them to do .. except when that is wrong. In this case, I blame Java. The cast to Object was there probably from the introduction of the Collection framework, and maybe before that when we had Directory and Vector, which needed to take Object, and I seem to remember you even had to cast every argument to Object, even if that was always the defined top of the class hierarchy, and so, as Rick says, completely unnecessary. For generics, I also blame Java, which added a lot of notation for what in essence is compiler trickery with hardly any runtime code generation consequences, and still no ‘generic’ treatment like C++ can do.

Also, I am a bit allergic to calls like:

root.getChildren().add(btn);

this leaves a lot - too much - of what happens implicit and hampers understanding. It is not evident from the notation that you call something, and send another message to the result. I tend to write those out completely and on separate lines, which also helps adding something to it or tracing it with trace or a debugger. And in this case, it helps to generate the right call, precisely because you add what was left out.

There is also another type of double cast left in the generated java - when we do not specify the arguments as double, we get (double) (byte) and (double) (short) generated. I do not worry about those too much, although I also doubt that we really need them.

best regards,

René.

On 21 jul. 2016, at 13:31, Dave Woodman <[hidden email]> wrote:

So it does!

I am left wondering, however, if the “double cast” is legitimate. If one is performing a cast then it is an explicit overriding of an assumption made.

Should the compiler not honour that?

Dave.

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/
_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

This email has been checked for viruses by Avast antivirus software.
www.avast.com

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

Kermit Kiser

Re: NetRexx & JavaFX HelloWorld

In reply to this post by rvjansen

I agree that NetRexx overriding an explicit cast seems irritating. But we need to examine when and why it happens. In this case, if the Java method is defined with generics, NetRexx will see the parameter as an "object" and knowing that anything can be converted to object at zero cost it tries to help that way. I am not sure we should do anything about it even if we can. Maybe we should just document the workaround?

--Kermit

On July 21, 2016 10:46:18 AM PDT, "René Jansen" <[hidden email]> wrote:

Hi Dave,

I think that is quite sensible - I am going to look where that cast is inserted and see if we still need to do that - and then we need to regression test with all kind of samples and JVM releases of course … and then if we don’t break important things, we might change it. And if we do, there might be still another option. This might be also something for Kermit.

best regards,

René.

On 21 jul. 2016, at 19:41, Dave Woodman <[hidden email]> wrote:

Hi René,

No doubt that the root cause is historic Jav! a. However I told the compile to generate a cast, and it generated two. Since I was overriding the type, the internal notions of type should be ignored, and the override followed I should think.

To put it another way, I said “Please don’t hold my hand at this point” and the compiler insisted on doing so. Exactly what I was asking it not to do.

I have no problem to it generating the cast to Object (for hysterical reasons) in instances when there is no other cast specified – is this unrealistic?

Dave.

From: [hidden email] [[hidden email]] On Behalf Of René Jansen
Sent: 21 July 2016 13:38
To: IBM Netrexx <[hidden email]>
Subject: Re: [Ibm-netrexx] NetRexx & JavaFX HelloWorld

Dave,

compilers should do what we tell them to do .. except when that is wrong. In this case, I blame Java. The cast to Object was there probably from the introduction of the Collection framework, and maybe before that when we had Directory and Vector, which needed to take Object, and I seem to remember you even had to cast every argument to Object, even if that was always the defined top of the class hierarchy, and so, as Rick says, completely unnecessary. For generics, I also blame Java, which added a lot of notation for what in esse! nce is compiler trickery with hardly any runtime code generation consequences, and still no ‘generic’ treatment like C++ can do.

Also, I am a bit allergic to calls like:

root.getChildren().add(btn);

this leaves a lot - too much - of what happens implicit and hampers understanding. It is not evident from the notation that you call something, and send another message to the result. I tend to write those out completely and on separate lines, which also helps adding something to it or tracing it with trace or a debugger. And in this case, it helps to generate the right call, precisely because you add what was left out.

There is also another type of double cast left in the generated java - when we do not speci! fy the arguments as double, we get (double) (byte) and (double) (short) generated. I do not worry about those too much, although I also doubt that we really need them.

best regards,

René.

On 21 jul. 2016, at 13:31, Dave Woodman <[hidden email]> wrote:

So it does!

I am left wondering, however, if the “double cast” is legitimate. If one is performing a cast then it is an explicit overriding of an assumption made.

Should the compiler not honour that?

Dave.

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

--
Sent from my Android device with K-9 Mail.
_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

Dave Woodman

Re: NetRexx & JavaFX HelloWorld

Hi Kermit! Good to see you here again!

In this case, the workaround is to re-write in a way that does not reflect the java from which the translation was attempted, so I am not sure that documenting it is the right thing to do. I say this because there are potentially limitless instances of similar, but not quite the same, work around. I’ll see if I can think of a generic (sic) way to document it.

To get back to the matter in hand, is not the point of a cast to allow the programmer to specify the type that should be used? If so, then the double-cast is just wrong, as I see the world. If it is not the case then it becomes nothing more than a hint, and that would, indeed, need documenting.

Dave.

From: [hidden email] [mailto:[hidden email]] On Behalf Of Kermit Kiser
Sent: 21 July 2016 20:50
To: IBM Netrexx <[hidden email]>
Subject: Re: [Ibm-netrexx] NetRexx & JavaFX HelloWorld

On July 21, 2016 10:46:18 AM PDT, "René Jansen" <[hidden email]> wrote:

Hi Dave,

I think that is quite sensible - I am going to look where that cast is inserted and see if we still need to do that - and then we need to regression test with all kind of samples and JVM releases of course … and then if we don’t break important things, we might change it. And if we do, there might be still another option. This might be also something for Kermit.

best regards,

René.

On 21 jul. 2016, at 19:41, Dave Woodman <[hidden email]> wrote:

Hi René,

No doubt that the root cause is historic Jav! a. However I told the compile to generate a cast, and it generated two. Since I was overriding the type, the internal notions of type should be ignored, and the override followed I should think.

To put it another way, I said “Please don’t hold my hand at this point” and the compiler insisted on doing so. Exactly what I was asking it not to do.

I have no problem to it generating the cast to Object (for hysterical reasons) in instances when there is no other cast specified – is this unrealistic?

Dave.

From: [hidden email] [[hidden email]] On Behalf Of René Jansen
Sent: 21 July 2016 13:38
To: IBM Netrexx <[hidden email]>
Subject: Re: [Ibm-netrexx] NetRexx & JavaFX HelloWorld

Dave,

compilers should do what we tell them to do .. except when that is wrong. In this case, I blame Java. The cast to Object was there probably from the introduction of the Collection framework, and maybe before that when we had Directory and Vector, which needed to take Object, and I seem to remember you even had to cast every argument to Object, even if that was always the defined top of the class hierarchy, and so, as Rick says, completely unnecessary. For generics, I also blame Java, which added a lot of notation for what in esse! nce is compiler trickery with hardly any runtime code generation consequences, and still no ‘generic’ treatment like C++ can do.

Also, I am a bit allergic to calls like:

root.getChildren().add(btn);

this leaves a lot - too much - of what happens implicit and hampers understanding. It is not evident from the notation that you call something, and send another message to the result. I tend to write those out completely and on separate lines, which also helps adding something to it or tracing it with trace or a debugger. And in this case, it helps to generate the right call, precisely because you add what was left out.

There is also another type of double cast left in the generated java - when we do not speci! fy the arguments as double, we get (double) (byte) and (double) (short) generated. I do not worry about those too much, although I also doubt that we really need them.

best regards,

René.

On 21 jul. 2016, at 13:31, Dave Woodman <[hidden email]> wrote:

So it does!

I am left wondering, however, if the “double cast” is legitimate. If one is performing a cast then it is an explicit overriding of an assumption made.

Should the compiler not honour that?

Dave.

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

--
Sent from my Android device with K-9 Mail.

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/