Rhino, Nashorn and V2, V3 & Java 1.8

[Cantor, Scott]

On 7/22/14, 8:48 AM, "Rod Widdowson" <rdw at steadingsoftware.com> wrote:

>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

So, in V2 we didn't prepopulate the object? That was what I thought.

>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.

I didn't recall that the data connectors actually exposed IdPAttribute
objects, I was thinking something else was used internally. There's always
been this odd disconnect between the data connector outputs and attribute
definition outputs in my mind.

>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.

Something, though.

There's also the possibility of making V2 do what V3 does and have it
create the object, right? Or does that break scripts?

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

MPL is a bit like LGPL, but more liberal in that its virality only applies
to the actual files that contain MPL source. Using a self-contained/built
library under MPL in a larger work does not affect the licensing of the
larger work. So it's fine.

>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.

We'd probably want to at least peruse it.

>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.

Or at least that we'd build it, upload it, and likely never touch it again
since I'm sure they won't.

>This source code comes with its own license:
>https://java.net/projects/scripting/sources/svn/content/trunk/engines/java
>sc
>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.

No, that's standard language. That's the modern BSD language, not the
"advertising clause" language. The difference is that it just means you
attribute them in the "documentation", meaning your copyright/attribution
file. We already do that for many things. The bad language says that
runtime invocation of your code requires the credit.

In other words, I think this is probably viable, particularly since it
isn't "active" by default and is designed as a bridge for people.

-- Scott