Scripts written not interoperable between Nashorn and GraalVM

Started by Manj75, June 25, 2021, 10:43:03 AM

Previous topic - Next topic

Manj75

I've written scripts that use the Swing components based on Herve's generate_view script and then progressed on to using SWT widgets based on the JFaceConfigDialog script, which only works using the GraalVM JS engine.

The issue I encountered through much wasted time was that my previous scripts that used Swing components started to throw NullPointerException (no line of code was given in the exception stack). Thinking that I had broken it somehow I debugged it to javax.swing.JButton method setVerticalTextPosition, so not my code, which was bizarre.

This prompted me to try the generate_view script and to my surprise that too threw a NullPointerException, at which point I deduced that the Swing based scripts will not run in GraalVM, which was proven correct after I switched back to Nashorn ES6 the scripts started working. Problem is my other scripts that now use SWT won't run in Nashorn, so, I will have to remember which JS Engine to use when running the scripts and this is not great user experience, especially for the client users that I'm prompting this to.

Is this a known issue/feature and is there anything that can be done to get better interoperability?

Worst case scenario is that I update all my scripts to use a single chosen JS engine, but if I want to use other community scripts I have no control over what UI SDK they'll use :(

Phil Beauvoir

#1
>  the JFaceConfigDialog script, which only works using the GraalVM JS engine.

It does work using Nashorn ES6.

> The issue I encountered through much wasted time

You wouldn't believe the time I've "wasted" just getting Archi and its plug-ins to work because of impossible issues.

> and this is not great user experience, especially for the client users that I'm prompting this to.

And some users' sense of entitlement is not a great experience for me, either.

There are differences between Nashorn and GraalVM and I've tried to make clear that GraalVM is experimental in jArchi. Some differences I've managed to workaround (different handling of Map type objects, for example) but if there are other differences then they'll have to be documented and investigated to see where the issue lies.

In this case there are problems when using Swing and its event handlers in an SWT based client (Archi) with GraalVM. I don't know why that is. This is where jArchi users can help, because it's all open source.

Edit - this is something to do with multi-threaded access between AWT, Swing, SWT and GraalVM. Like this https://github.com/oracle/graaljs/issues/59

Edit 2 - the NPE can be fixed at lines 440-441 with:

okButton.setVerticalTextPosition(Packages.javax.swing.SwingConstants.CENTER);
okButton.setHorizontalTextPosition(Packages.javax.swing.SwingConstants.CENTER);


But it won't solve the threading issue to do with java.awt.event.ActionListener and SWT threading in Graal.
If you value and use Archi, please consider making a donation!
Ask your ArchiMate related questions to the ArchiMate Community's Discussion Board.

Manj75

Thanks Phil,

You're right the JFaceConfigDialog does work in Nashorn ES6, however my simple DocumentAppendDialog based on it throws a class cast exception, but works unchanged in GraalVM.  Is this something you've come across?  I'll just have to debug further to pinpoint and try to resolve.

java.lang.ClassCastException: Cannot cast jdk.nashorn.internal.runtime.Undefined to org.eclipse.swt.widgets.Control

Btw - my comments was in way negative, I was just hoping there was a way to harmonise so all scripts work with one engine as having switch in the preferences to run a particular script is not ideal, but understand that it is an option.


Jean-Baptiste Sarrodie

Hi,

My 2 cents:

jArchi is not meant to support these use cases. They are indeed possible because underlying engines make it possible to use the whole JVM, but they are not supported and are "at your own risk".

If a script relies on a specific engine, then it can easily test which engine is used at runtime by using the (documented) $.process.engine variable.

Regards,

JB
If you value and use Archi, please consider making a donation!
Ask your ArchiMate related questions to the ArchiMate Community's Discussion Board.

Phil Beauvoir

My findings show that  the NPE in Herve's script can be fixed at lines 440-441 with:

okButton.setVerticalTextPosition(Packages.javax.swing.SwingConstants.CENTER);
okButton.setHorizontalTextPosition(Packages.javax.swing.SwingConstants.CENTER);


But it won't solve the threading issues to do with java.awt.event.ActionListener and SWT threading in GraalVM. Perhaps someone might investigate that problem.
If you value and use Archi, please consider making a donation!
Ask your ArchiMate related questions to the ArchiMate Community's Discussion Board.

Manj75

This is great  :)

Phil - I've made your suggested change to my script and the NPE is resolved and the dialog appears, however due to the threading issue the dialog Ok and Cancel buttons don't respond. So I'll keep an eye out here for any further updates on a resolution from anyone.

JB - getting the JS engine from the running script will help to at least carry out a check and provide a user-friendly message to set the correct engine.

Thanks