improve java.util.{List,Map} interop

[syjer]

Hi, this PR is based on #561 to improve the interoperability with java.util.List and java.util.Map.

As a main difference with #561, instead of creating 2 new wrapper, I've modified the NativeJavaObject class, as I think it's a little less disruptive and more easily reviewable.

It add some additional overhead (2 new boolean fields and some additional checks in has/get/put methods, but I would hope it's acceptable.

(Btw, I've noticed the travis build fail, but locally the tests passes)

[gbrail]

Thanks! I can see how this will be useful for people who embed Java in Rhino a lot.

Whenever I see a pattern in which we introduce a bunch of flags set in the constructor as "isThis" or "isThat", and then many methods start with "if (isThis) { do this } else if (isThat) { doThat }", I find myself asking, "would inheritance be a cleaner way to implement this?"

What if:

1. You introduced two new subclasses of NativeObject called "NativeJavaList" and "NativeJavaArray" with the necessary specializations for each
2. You modified ScriptRuntime.wrapAsJavaObject to test the class and create the appropriate form of the three subtypes.

I think this might also be handy someday because you could easily extend the pattern for other types of classes if people would like.

Would that be a painful change? I think it'd make things cleaner in the long run.

[syjer]

hi @gbrail , thank you for reviewing the PR :)

I find myself asking, "would inheritance be a cleaner way to implement this?"

Agree, I was a little bit unsure which approach would be more acceptable :).

Would that be a painful change? I think it'd make things cleaner in the long run.

not painful at all :), in fact I had the other variant in another branch (https://github.com/mozilla/rhino/compare/master...syjer:interop-java-list-map?expand=1) :). I'll take your feedback and incorporate the changes :)

[syjer]

by the way, by ScriptRuntime.wrapAsJavaObject you mean WrapFactory.wrapAsJavaObject right?

I can't find the method wrapAsJavaObject in ScriptRuntime.

[gbrail]

Yes -- that's the class. Sorry!

…

On Tue, Jun 16, 2020 at 2:20 PM Sylvain Jermini ***@***.***> wrote: by the way, by ScriptRuntime.wrapAsJavaObject you mean WrapFactory.wrapAsJavaObject right? I can't find the method wrapAsJavaObject in ScriptRuntime. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#713 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAD7I2YZC3U7HT4MNV5LP3TRW7OYNANCNFSM4N6B3BWQ> .

[syjer]

I've updated the PR following your feedback :)

The tests run successfully locally too.

[gbrail]

I think this looks great. I have two minor suggestions -- if you like them, then please give them a try, and otherwise let me know if you'd rather not!

[gbrail]

This may be over-complication but JavaScript has taught me to that anything is possible...

Is it possible that a user would use this with a map that has keys that are not strings or integers? If so, then it might aid interop with JavaScript if we iterated through the list and ensured that each key is either a string or an integer by calling ScriptRuntime.toInt32 or ScriptRuntime.toString depending on the type, and letting those methods throw a JavaScript exception if something doesn't work (for instance, if they try to use a Symbol or something).

[syjer]

This may be over-complication but JavaScript has taught me to that anything is possible...

Haha, i feel your pain ;).

Is it possible that a user would use this with a map that has keys that are not strings or integers? If so, then it might aid interop with JavaScript if we iterated through the list and ensured that each key is either a string or an integer by calling ScriptRuntime.toInt32 or ScriptRuntime.toString depending on the type, and letting those methods throw a JavaScript exception if something doesn't work (for instance, if they try to use a Symbol or something).

Ok for ensuring the type :). I'll update the PR with your feedback. Thank you for your help.

[syjer]

Actually, what about filtering out non String/Integer keys instead of converting them?

[syjer]

I've updated the PR incorporating the feedback.

./gradlew check pass as expected.

(By the way, I noticed that running it with java 11 testsrc/tests/ecma_3/Date/15.9.5.5.js and string.trim.doctest fail: it's something that should be fixed?)

[gbrail]

This looks good now. Thanks!

[syjer]

thank you for guiding me in the process 👍

[gbrail]

Yes -- whatever is happening in Java 11 with the Date tests should be fixed. It's possible that Rhino's date handling is no longer valid in Java 11, but it's a lot more possible that the particular tests makes assumptions that are no longer valid and should be replaced by a new test.

[syjer]

ok, I'll have a look at the failing tests :)