Backward compatibility java.util.{List,Map} interop

[tuchida]

ref. #713

var h = new java.util.HashMap();
h.put('a', 123);
h.a;  // 123.0
h.put('put', 123);
h.put; // 123.0
h.put('put', 123);
// js: "<stdin>", line 7: uncaught JavaScript runtime exception: TypeError: Cannot call property put in object {a=123.0, put=123.0}. It is not a function, it is "object".
//	at <stdin>:7

• Is it possible to have problems with code written in the past?
• Is there a how to make sure to call java.util.HashMap#put?

[tuchida]

Treating JS Object like HashMap has various problems (e.g. __proto__). I think you should consider compatibility between ES6 Map and java.util.Map.

[tuchida]

Is there a how to make sure to call java.util.HashMap#put?

var h = new java.util.HashMap();
var put = h.put;
put.call(h, 'a', 123);
h; // {a=123.0}
put.call(h, 'put', 123);
put.call(h, 'put', 456);
h; // {a=123.0, put=456.0}

[tuchida]

var a = new java.util.HashMap();
a.put('1', 123);
a['1']; // js: Java class "java.util.HashMap" has no public instance field or method named "1".

a['1']; calls public Object get(int index, Scriptable start).

rhino/src/org/mozilla/javascript/NativeJavaMap.java

Lines 56 to 60 in 5cf8b7f

	public Object get(int index, Scriptable start) {
	if (map.containsKey(Integer.valueOf(index))) {
	Context cx = Context.getContext();
	Object obj = map.get(Integer.valueOf(index));
	return cx.getWrapFactory().wrap(cx, this, obj, obj.getClass());

[tuchida]

@gbrail This issue can be critical. What do you think?

[gbrail]

This seemed like a nice convenience function, but you're right that it results in JavaScript objects that behave in strange ways, and it indeed means that things work a bit differently than they did before. Unfortunately we did a release since then, although I don't know how many people are using it. Perhaps we should add a feature flag on the Context object so that this functionality is not enabled by default.

I can see the attraction of making it possible for the JavaScript Map and Set to be made interoperable with existing Java Map and Set classes, but unfortunately the iteration semantics are very different and the result would be Map and Set objects that don't work like JavaScript Maps and Sets anyway.

[tuchida]

Thank you for looking.
For example, browser's localStorage looks like this:

localStorage.setItem('a', 1);
localStorage.a; // 1
localStorage.setItem('setItem', 1);
localStorage.setItem; // function
localStorage.setItem('1', 1);
localStorage['1']; // 1
localStorage[1]; // 1

Perhaps emulating this would be a little better.

[syjer]

Hi, as a I proposed this PR, the goal was a better compatibility with nashorn, which allow this kind of java map <-> js object behaviour. My guess would be to check how they handled this cases.

[gbrail]

They do appear to work differently: jjs> var m = new java.util.HashMap(); jjs> m.foo = 123; 123 jjs> m['foo']; 123 jjs> m.get('foo'); 123 jjs> m.put('get', 2); null jjs> m.get; 2 jjs> m.get('get'); 2 js> var m = new java.util.HashMap(); js> m.foo = 123; 123 js> m['foo']; 123.0 js> m.get('foo'); 123.0 js> m.put('get', 2); null js> m.get; 2.0 js> m.get('get'); js: uncaught JavaScript runtime exception: TypeError: Cannot call property get in object {foo=123.0, get=2.0}. It is not a function, it is "object". Nashorn seems to either have some special handling of function properties versus non-function properties, or something. At this point I'd prefer if we opened an issue to track what the differences are and thought about what to change,

…

On Thu, Jan 7, 2021 at 7:22 PM Sylvain Jermini ***@***.***> wrote: Hi, as a I proposed this PR, the goal was a better compatibility with nashorn, which allow this kind of java map <-> js object behaviour. My guess would be to check how they handled this cases. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#820 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAD7I25DN3AJ6AOLW4NDTRLSYZ26RANCNFSM4VU7BYPQ> .

[tuchida]

Nashorn:

// $ jjs -v
// nashorn 1.8.0_275
var h = new java.util.HashMap();
h.put; // [jdk.internal.dynalink.beans.SimpleDynamicMethod Object java.util.HashMap.put(Object,Object)]
h.put('put', 1);
h.put('put', 2);   // OK
(h.put)('a', 2);  // OK
var put = h.put;
put('a', 2); // <shell>:1 TypeError: put is not a function
(0, h.put)('a', 2);  // <shell>:1 TypeError: 0 ,> h.put is not a function

Rhino:

(function() {
  eval("var x = 1;");
  (0, eval)("var x = 2;");
  print(x); // 1
}());
print(x); // 2

https://github.com/tc39/test262/blob/041da54c02ae7d17edb8c134ab7691c4f643bafe/test/language/eval-code/indirect/var-env-var-non-strict.js
Is it feasible with Icode_CALLSPECIAL?

[tuchida]

var h = new java.util.HashMap();
h.put(new String('abc'), 1);
h.put(new String('abc'), 2);
JSON.stringify(Object.keys(h)); // ["abc","abc"]

[tuchida]

ref. #839

[tuchida]

ref. #836
It is now disabled.
Probably the problem occurs only with NativeJavaMap, and NativeJavaList is not a problem since it only accesses numbers.