Rhino, Nashorn and V2, V3 & Java 1.8

[Rod Widdowson]

I spent today looking at this in 2 ways

1) Nashorn (JDK8) and IdP V2.

What is screwing us is that in Rhino, the ‘context’ (mechanism used to move
data from java into JavaScript) consists of the entire JavaScript namespace
and so we can say

Script = new BasicAttribute(“Scripted”)

And when we get back to java the context will contain a new variable
“Script”. In Nashorn this context is input-only and so the above line has no
effect as far as java-side is concerned.  In V3, the context is prepopulated
with attributes and so existing scripts can be made to work by just
conditionalizing the new

if (null == Script) {
   Script = new BasicAttribute(“Scripted”);
}

The attribute exists and so we do not hit the new, so all the values are
added to an object which is already in the context.

But in V2 this isn’t the case.  There is however a bit of a hack that one
can use as a fix.  If you declare a StaticDataConnector as a dependency of
the scripted attribute, and have it supply and attribute of that name, then
that attribute is available in the context and updating it works.  This is a
bit mind-bending at first, but one of the example scripts on the wiki
already does this.

So we do have a somewhat cumbersome mechanism to allow people to move a V2
installation up to JDK8.  Of course this is but part of what needs to be
done – they also need to remove the “loadPackage” commands or work around
that, plus a few other odds and sods.

2) Rhino in JDK8

On Friday, I got a strong steer to look at getting rhino available on JDK8.
The reference of note here is 

https://wiki.openjdk.java.net/display/Nashorn/Using+Rhino+JSR-223+engine+wit
h+JDK8 .  

When I looked last week I got quite despondent because some links had
rotted, but coming fresh to it today I got it to work.  I then stuffed the
requisite jars into my V2 testbed and demonstrated that with JDK8 the
scripts started working again (once I had changed the scripting language to
“rhino”).

This is all fine and well but there are a few things to note:

Firstly: this requires a js.jar from the Mozilla distribution.  Although it
exists in Maven central, the maven distribution is not referred to on the
Mozilla page.  One has to assume that this is not official, and so the
distro has to come from
https://developer.mozilla.org/en-US/docs/Mozilla/Projects/Rhino/Download_Rhi
no .  This distro of course is not signed, but it is TLS protected with a
<irony> spiffy, totally trustable, turns green </irony> EV cert

Next up: the JavaScript distro is under the MPL license
https://www.mozilla.org/MPL/ I have no expertise in reading such licenses.

This JS.jar file is then plugged into some more code that one randomly
downloads (this time via svn from java.net) and builds using ant.  This
throws up some more issues:

Obviously this is source code.  Who knows what is in it?  From the SVN logs
it (allegedly) hasn’t changed recently and I suppose you then have to do
diligence on the certificate protecting the svn repository.

Without looking at it, the automation of an ant build into an mvn build
environment feels horrid.  So if we need to do something here I guess it
becomes a separate distributable.

This source code comes with its own license:
https://java.net/projects/scripting/sources/svn/content/trunk/engines/javasc
ript/LICENSE.TXT?rev=236

“- Redistributions in binary form must reproduce the above copyright notice,

   this list of conditions and the following disclaimer in the documentation

   and/or other materials provided with the distribution.”

And that feels like a show stopper for IdP distribution.  I suppose we might
do a one-off, entirely separate distribution?  But again I have no expertise
in these things.

Last of all, since Ian did mention it, I’ll mention in passing that I saw a
brief comment on StackOverflow that it is difficult to backport Nashorn to
JDK1.7.  Someone did it at one stage, but the port has rotted and is not up
to date.

Next stages:
- I can write a page for the wiki (V2) on how to make Java 8 work with
existing scripts.
- We need to decide whether the non-technical issues are enough to stop us
proceeding on the “Rhino in JDK8” front.
- If not we need to work out what to do.

Rod