ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <>
Subject Re: supporting graal.js
Date Tue, 28 Jul 2020 20:05:28 GMT
On 2020-07-19, Jaikiran Pai wrote:

> I have one suggestion/question related to this - instead of this
> property, we can perhaps just enable full Nashorn compatibility using
> the "polyglot.js.nashorn-compat" property set to true? The reason I say
> this is, the property name itself describes its nature unlike the
> "allowAllAccess" property. I think we should enable full Nashorn
> compatibility because IMO the whole goal of switching the GraalJS script
> engine implementation is to allow existing Nashorn based scripts to work
> fine.

At work I've been involved in a Nashorn to Graal.js migration lately[1]
and we needed to enable full compatibility there as well. Even then it
is not a drop-in replacement. If people try to use <script> in
multithreaded environments, this may be problematic.

Enabling full compatibility is probably desirable for people migrating
their Nashorn scripts. People starting from scratch may not need this
and would be fine with "just" enabling host access (so they can use
Ant's objects).

I've toyed with the idea of making <script> more configurable so one can
set properties as needed but not tried to do that in code, yet.

> I think what we should do additionally, irrespective of the property
> that we set, is starting Java 15, log a WARN message which states that
> the "javascript" script type no longer has a script engine shipped in
> the JDK and hence we are internally using GraalJS as a short term option
> and perhaps in the long run these "javascript" based scripts will no
> longer be supported unless a specific engine is made available in the
> classpath by the user?

Actually I wasn't planning to include graal.js with the Ant
distribution. I haven't even verified whether the license would be
compatible, yet. OK, I just did. I believe graalvm.regex is required and
distributed as GPLv2 so we couldn't inlclude that.

We certainly need to document how to add Graal.js. Logging a specific
error if the language is javascript and we don't find a ScriptEngine in
Java 15+ probably is a good idea.

> Having said that, it's interesting that a compiled script in GraalJS
> takes more time to run than a non-compiled script. Perhaps something to
> check later and report if necessary.

I believe the compiled script itself hasn't been slower, just not so
much faster that it would catch up the time spent on compiling before
the first run.


[1] in particular

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message