Both options are hacks :( Personally I'm not comfortable with either
option.
JSObject wrapper suggested in the bug is not impossible to do.
VM.getVM() would the "initial object" -- a JSObject impl. that walks
through objects is possible. JSObject impls. can cache fields/methods
reflectively and invoke those as needed. If SA class is needed, we can
add JSClassObject impl. (which would a JSObject impl. that'd support
static method/field access).
-Sundar
On 12/04/19, 7:35 PM, Yasumasa Suenaga wrote:
Hi all,
I saw the message when I attached CLHSDB to target VM as below:
----
javax.script.ScriptException: TypeError: sapkg.runtime.VM.getVM is not
a function in sa.js at line number 54
Warning! JS Engine can't start, some commands will not be available.
----
It has been reported as JDK-8157947.
It is caused that jdk.hotspot.agent module is not exported to
nashorn dynamic module.
The comment in JDK-8157947 says that it will be fixed if we implement
JSObject, but I think it is difficult because we cannot know
what classes in SA are used in user scripts.
So I think two approaches for this issue:
1. Open all packages in module-info in jdk.hotspot.agent
I filed suggested fix to JBS, but it is not smart...
2. Open all packages in JSJavaScriptEngine::<clinit>
Opens all packages to Module.EVERYONE_MODULE.
But EVERYONE_MODULE is private field, so we need to access
from JNI code.
http://cr.openjdk.java.net/~ysuenaga/JDK-8157947/proposal/
This change has passed serviceability/sa jtreg tests.
Both ideas is hackish, but I prefer to 2. to fix it.
If 2. is accepted I will push it to submit repo and send review request.
What do you think?
Thanks,
Yasumasa
