Class instantiation

[Robert Hanson]

Zhou Renjian or Udo,

Zhou Renjian, I have not heard from you in a long time. I hope you are well and in good spirits about J2S and still actively engaged in it. I realize you must have all sorts of other things that are at least important for you these days. I can never thank you enough for this contribution.

Can we discuss class instantiation and construction? Would you be interested in a Skype session with Udo and me? I have now got the PhET applets working in JavaScript, but it took some serious tricks, partially because I know I am working with an older version of the compiler. I know j2sSwingJS.js  has diverged substantially from j2slib.js, so I do not want to presume that what I saw there is still an issue with j2slib. Still, I am interested in making sure I am doing this right, and there are things I don't understand. Some questions for you:

- I don't see why it is important for the compiler to split off the "prepareFields" business from the rest of the initialization. This is not what Java does. Why does J2S do it?

- Can you tell me if j2slib functions properly in cases where there are multiple abstract superclasses, some of which need to prepare fields? I had some problem with that and ended up handling it by forcing a default constructor in all classses that have fields to prepare. Maybe this is the simplest solution. Not sure.

- Is there a reason c$ is global? This caused a problem when a static definition used "new" to create an object, and in that object's constructor another class was loaded by reflection, thus changing c$ prior to returning. Wouldn't it be simpler to use a var c$ instead of a global c$, passing  that as a variable to the Clazz.pu$h method? What am I missing? I do see in your latest version you are doing some additional local save/restore of that variable, but I don't think that really solves the problem. At least not for these PhET applets.

I have not implemented your changes from June, partially because I was so busy with my research group, partially because I am still using Eclipse Juno, and I think  that was for Kepler or Luna, I can't remember. But I did look it over, and I have it installed now in Eclipse Mars.2 finally, so I can test that. I see that you implemented a new method, thisConstructor. I understand what that is there to address -- that "this()" must only access methods in its class, not the subclass. I solved the problem it addresses with just a few lines of code in what I am now calling j2sSwingJS.js using makeConstructor(), so I think if I do implement the latest compiler, I will just replace "thisConstructor" with "makeConstructor" using an Ant task.

One thing you may be interested in is that I have a decent solution to the signature problem. Like your solution, it still does not address numeric (int, float, decimal) overloading. It uses the fact that you can assign a field to the anonymous delegate function itself. So that means that once the correct method is found, it can be saved in the caller function to the delegate being run, and it never has to be found or checked again. This radically reduced the time in processing signatures and seems to work perfectly.

I also saw you addressing the explicit casting of class for objects, not just null. This is certainly interesting, and I don't have any other suggestion about that, but I am a bit concerned that it will reduce the performance considerably because it is creating new objects with every call to the function, and it seems to me it is doing it more often than it needs to. So I'm also not sure I want to implement that. Right now these PhET applets are at the limit for barely functional, and so I have to be very careful not to introduce anything that slows it done in a general sense.

Hoping this is the start of a conversation,

Bob

ps - The first flakes of snow fell today here in Minnesota, and a cold wind is blowing. Winter is coming.... "around the corner" we say.

If you would like, I can submit more GitHub bug reports.

Bob

[Zhou Renjian]

Hi Bob,

I have to say that the recent month is a really busy month for me. One of our product's active users drops sharply totally beside our expectation. We are working day and night trying to get it fixed.

What you mentioned are big questions for J2S. I need more time to pick up those designs and thoughts, and make them clear. But not in next one or two weeks, I think.

Just make some simple inline replies now (see below). Later when I have more time, I will give more detailed replies.

Regards,
Zhou Renjian

On Sat, Nov 19, 2016 at 2:13 PM, Robert Hanson <han...@stolaf.edu> wrote:

Zhou Renjian or Udo,

Zhou Renjian, I have not heard from you in a long time. I hope you are well and in good spirits about J2S and still actively engaged in it. I realize you must have all sorts of other things that are at least important for you these days. I can never thank you enough for this contribution.

Can we discuss class instantiation and construction? Would you be interested in a Skype session with Udo and me? I have now got the PhET applets working in JavaScript, but it took some serious tricks, partially because I know I am working with an older version of the compiler. I know j2sSwingJS.js  has diverged substantially from j2slib.js, so I do not want to presume that what I saw there is still an issue with j2slib. Still, I am interested in making sure I am doing this right, and there are things I don't understand. Some questions for you: 

- I don't see why it is important for the compiler to split off the "prepareFields" business from the rest of the initialization. This is not what Java does. Why does J2S do it?

- Can you tell me if j2slib functions properly in cases where there are multiple abstract superclasses, some of which need to prepare fields? I had some problem with that and ended up handling it by forcing a default constructor in all classses that have fields to prepare. Maybe this is the simplest solution. Not sure.

I am not sure now. Later I may review existed sources and tests to get more details.

 

- Is there a reason c$ is global? This caused a problem when a static definition used "new" to create an object, and in that object's constructor another class was loaded by reflection, thus changing c$ prior to returning. Wouldn't it be simpler to use a var c$ instead of a global c$, passing  that as a variable to the Clazz.pu$h method? What am I missing? I do see in your latest version you are doing some additional local save/restore of that variable, but I don't think that really solves the problem. At least not for these PhET applets.

In very early version of Java2Script compiler, I introduce global variable of c$. Not quite sure it is still necessary or not for latest implementation. I remembered that I tried to reduce global variables in j2slib in June/July this year. But not sure c$ still exists or not.

 

I have not implemented your changes from June, partially because I was so busy with my research group, partially because I am still using Eclipse Juno, and I think  that was for Kepler or Luna, I can't remember. But I did look it over, and I have it installed now in Eclipse Mars.2 finally, so I can test that. I see that you implemented a new method, thisConstructor. I understand what that is there to address -- that "this()" must only access methods in its class, not the subclass. I solved the problem it addresses with just a few lines of code in what I am now calling j2sSwingJS.js using makeConstructor(), so I think if I do implement the latest compiler, I will just replace "thisConstructor" with "makeConstructor" using an Ant task.

To migrate latest update back to early versions of Eclipse can be done by comparing sources of project net.sf.j2s.core between different branches for Eclipse versions. Ya, it needs time to verify everything.

 

One thing you may be interested in is that I have a decent solution to the signature problem. Like your solution, it still does not address numeric (int, float, decimal) overloading. It uses the fact that you can assign a field to the anonymous delegate function itself. So that means that once the correct method is found, it can be saved in the caller function to the delegate being run, and it never has to be found or checked again. This radically reduced the time in processing signatures and seems to work perfectly.

I also saw you addressing the explicit casting of class for objects, not just null. This is certainly interesting, and I don't have any other suggestion about that, but I am a bit concerned that it will reduce the performance considerably because it is creating new objects with every call to the function, and it seems to me it is doing it more often than it needs to. So I'm also not sure I want to implement that. Right now these PhET applets are at the limit for barely functional, and so I have to be very careful not to introduce anything that slows it done in a general sense.

Later after I fixing the casting objects problem, I am thinking about fixing  numeric (int, float, decimal) overloading in similar way. I know the performance problem after casting objects fixes. More tests and more optimizations may help performance improvements. Need more works on this problem.

Hoping this is the start of a conversation,

Bob

ps - The first flakes of snow fell today here in Minnesota, and a cold wind is blowing. Winter is coming.... "around the corner" we say.

If you would like, I can submit more GitHub bug reports.

Bob

--
You received this message because you are subscribed to the Google Groups "Java2Script" group.
To unsubscribe from this group and stop receiving emails from it, send an email to java2script+unsubscribe@googlegroups.com.
To post to this group, send email to java2...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/java2script/CAF_YUvVVG4twcTS5_yBLKuCZ3CKwAJhVt-HQVV8Zn74W0CC6SA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Robert Hanson]

Class casting: Understood. Would it be possible to supply a compiler flag that would consider the recent changes involving casting objects as "experimental" or, alternatively, to allow me to turn those off? I would like to move up to Mars if possible.

Pre-4.5 versions: I probably will not explore the issues with creating the J2S compiler, although it sounds like that is not terribly difficult. I wish I had more time to explore that. 

Signatures: My solution to this, which does significantly reduce the time spent in searching and executing methods, is as follows. This is done in my version of j2slib, which I call j2sSwingJS.js. <https://sourceforge.net/p/swingjs/code/HEAD/tree/trunk/jsmoljs/j2sSwingJS.js> I realize this is a huge diversion from j2slib, but I think perhaps what I did there could be of help:

1) For constructors in particular it is extremely efficient. Once a superCall is made to a superconstructor once, the link is set, and there is no further checking. This is possible because there can be only one superCall from any given constructor. What I do in that case is to attach the target constructor method to the argument.callee.caller, and then, if that is present, simply call that function for any subsequent call.

2) For general methods, one cannot be sure that there is only one variation of signature from a given method, so that method will not work. Instead, for each such method, we attach a Hashtable that, given a specific signature, ties to a specific method. So at least we don't have to go through the whole search process every time, and there is a small subset of "known" methods that will be called. The overhead is simply the creation of the signature for checking in a Hashtable.

This still does not take care of the issue of casting which I had in PhET:

  xxx.doThis( (Class1) whatever);

  xxx.doThis( (Class2) whatever);

But perhaps, if you were to limit those Clazz.castObjectAs(....) calls to only cases where they are explicitly use by the programmer in Java, that would be taken care of as well.

I would love to work with you on this.

Bob

To view this discussion on the web visit https://groups.google.com/d/msgid/java2script/CAEqDfKmTrKXA7cwLAkvrcZ6g0YwVwc0qGJS7VHGRRO2Kpq083A%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Robert M. Hanson
Larson-Anderson Professor of Chemistry
St. Olaf College
Northfield, MN
http://www.stolaf.edu/people/hansonr


If nature does not answer first what we want,
it is better to take what answer we get.

-- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900

[Robert Hanson]

c$ as a local variable works just fine. No need for that to be a global. In fact, I think there would be a way to implement it as a "var" that completely removed the need for Clazz.pu$h and Clazz.p0p. But I did not go that far; I just wrapped the JavaScript in anonymous functions:

(function() { var c;
....
})();

and changed Clazz.pu$h() to Clazz.pu$h(c$)

Working perfectly.

Bob

On Tue, Nov 22, 2016 at 4:00 PM, Robert Hanson <han...@stolaf.edu> wrote:

 

- Is there a reason c$ is global? This caused a problem when a static definition used "new" to create an object, and in that object's constructor another class was loaded by reflection, thus changing c$ prior to returning. Wouldn't it be simpler to use a var c$ instead of a global c$, passing  that as a variable to the Clazz.pu$h method? What am I missing? I do see in your latest version you are doing some additional local save/restore of that variable, but I don't think that really solves the problem. At least not for these PhET applets.

In very early version of Java2Script compiler, I introduce global variable of c$. Not quite sure it is still necessary or not for latest implementation. I remembered that I tried to reduce global variables in j2slib in June/July this year. But not sure c$ still exists or not.