8157947: SA: Javascript engine can't access internal packages of jdk.hotspot.agent
Yasumasa Suenaga
yasuenag at gmail.com
Thu May 2 08:35:46 UTC 2019
> Would it be possible re-outline the problem and/or include the
exception that is being observed?
We can see TypeError thrown by Nashorn when we attach CLHSDB.
It means JS in jdk.hotspot.agent (sa.js) could not call
sun.jvm.hotspot.runtime.VM::getVM .
It is caused that jdk.hotspot.agent does not export to
jdk.scripting.nashorn.scripts module.
I tried to open all SA packages to everyone, it works fine [1].
IMHO it would be convenience that module API provides method(s) to open
to everyone, or --add-opens option can open modules to everyone.
Anyway, I think this issue may occur any applications that JS calls Java
world. Thus I hope this issue would be resolved in scripting API or
module system.
If so, SA should use it :-)
Thanks,
Yasumasa
[1] http://cr.openjdk.java.net/~ysuenaga/JDK-8157947/proposal/
On 2019/05/02 15:30, Alan Bateman wrote:
> On 02/05/2019 06:47, Sundararajan Athijegannathan wrote:
>> Hi Yasumasa,
>>
>> Sorry for delayed response. Your webrev looks like a good start!
>> Unfortunately, dependency on nashorn is inevitable. But there is a
>> similar (but different) object API for Graal.js. In future, someone
>> may have to do some porting work.
> This exports sun.jvm.hotspot.utilities.soql.wrapper unconditionally so
> it's adding a JDK-specific API. Would it be possible re-outline the
> problem and/or include the exception that is being observed? If
> jdk.hotspot.agent is going to export an API then it will need a lot of
> javadoc work and of course a CSR (and no guarantee that the CSR would be
> approved because we agreed in JDK 9 that jdk.hotspot.agent would be a
> supported interface).
>
> -Alan
More information about the serviceability-dev
mailing list