Nashhorn can't access module internal packages ever if they are public. So we should change the way SA works with javascript engine.
Comments
I won't be working on this issue, Yasumasa. I will unassign myself.
19-02-2019
@jgeorge Have you started to work for this issue?
I guess SA users might use various SA classes for their scripts.
So it is hard to use JSObject.
Nashorn is deprecated since JDK 11 (JEP 335). IMHO we might be able to open all SA packages to others.
Of course it is not smart, but I think SA does not need to adapt to Nashorn.
I uploaded `module-info.patch`. I created it which is based on following command:
$ find src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/ -type d | sed -e 's|src/jdk.hotspot.agent/share/classes/||g' | tr / . | sed -e 's/^.\+$/ opens \0;/g'
18-02-2019
Thanks for the clarification, Jini. I'll keep digging into the problem.
24-01-2018
Warnings like:
javax.script.ScriptException: TypeError: sapkg.runtime.VM.getVM is not a function in sa.js at line number 54
appear for every clhsdb test, but these do not affect the execution of the existing clhsdb tests (These tests don't include the javascript command tests currently). Since the warning makes it confusing while looking at the logs of the existing tests, I plan to remove it till this bug gets fixed.
23-01-2018
I believe I am seeing this issue in a number of JTReg tests. For example, on the serviceability/sa/ClhsdbFindPC.java test I get the error:
javax.script.ScriptException: TypeError: sapkg.runtime.VM.getVM is not a function in sa.js at line number 54
I believe this is caused by the issue in this bug report.
Is there any movement on this issue?
22-01-2018
Similar problems was seen in the HotSpot nightly yesterday but seems to have been caused by a different problem. JDK-8190491
01-11-2017
Sunder's comments on this below:
=================================================================
Date: Thu, 26 May 2016 11:28:43 +0530
From: Sundararajan Athijegannathan <sundararajan.athijegannathan@oracle.com>
I had discussed this problem within the nashorn team. And I had
discussed this issue with Jini as well. So, I'm CCing this email to
nashorn internal alias and India serviceability folks as well.
Yes, we have a problem with scripting SA classes.
Background: Nashorn uses dynalink library [
http://openjdk.java.net/jeps/276 ] to link invokedynamic call sites. In
particular, it uses "beans linker" of dynalink to support Java access
from scripts.
Dynalink allows only public method, field access of public classes of
exported packages only. i.e., only the packages exported to the "world"
are allowed to be accessed from scripts. Scripts are compiled and loaded
into runtime/dynamic modules [named "jdk.scripting.nashorn.scripts"].
But, dynalink, as a nashorn independent library, uses publicLookup to
resolve methods / fields and so can not allow module internal package
access.
In the non-modular world, the exported package restriction didn't
exists. That is the reason why public methods & fields of public SA
classes can be accessed from scripts. But, in the modular world, SA
packages are module internal to SA's own module [rightfully so! we don't
want SA access to the world anyway!]. So, scripts accessing SA classes
are broken in modular jdk :(
Possible fix:
Nashorn supports script-friendly wrappers on Java objects. Any object
implementing jdk.nashorn.api.scripting.JSObject [
https://docs.oracle.com/javase/8/docs/jdk/api/nashorn/jdk/nashorn/api/scripting/JSObject.html
] will be specially linked by Nashorn.
Sample:
http://hg.openjdk.java.net/jdk9/dev/nashorn/file/59d31c4e3f77/samples/jsobject.js
http://hg.openjdk.java.net/jdk9/dev/nashorn/file/59d31c4e3f77/samples/BufferArray.java
One possible fix for SA script access is that we could create JSObject
wrappers. Obviously, creating wrapper for each-n-every interesting SA
class would be too much! So, we could create reflection based wrappers
for SA classes, objects, arrays and methods. Just after creating script
engine, we could expose function to wrap a SA class/object/array/method
as a JSObject. Say, if we expose "SAType" script function that returns
a wrapper for SA class, user code can do
var VM = SAType("sun.jvm.hotspot.runtime.VM"); // this would return a
JSObject wrapper for SA class "VM"
// static method calls on VM here..
I know this is a medium sized effort - but can be done. I think we just
need 4 classes. JSObjectClassWrapper, JSObjectInstanceWrapper,
JSObjectArrayWrapper, JSObjectMethodWrapper -- all using reflection to
implement getMember, call, hasMember etc. - each wrapping a SA Java
class, Java object, Java array and a Java method respectively.
====================end Sundar's mail ========================================
Implications: The javascript interface to the hotspot serviceability agent (which includes the following commands under 'jhsdb clhsdb') will result in an "Unrecognized command" failure. jseval, jsload, class, classes, dumpclass, dumpheap, mem, sysprops, whatis
==========================================================================
15-02-2017
What is the current status of this and the implications for JDK 9 users? It is unclear why this was deferred to JDK 10.
13-02-2017
In JDK-8159806 I am getting the following error
javax.script.ScriptException: TypeError: sapkg.runtime.VM.getVM is not a function in sa.js at line number 54
javax.script.ScriptException: TypeError: sapkg.runtime.VM.getVM is not a function in sa.js at line number 54
I am not seeing this problem when using the 'images' fastdebug build. I am seeing the problem with the normal build.
You can check if the same applies here too.