Re: PL/Java 1.5.1_BETA2

On 09/17/18 10:47, Christoph Berg wrote:
> Re: Chapman Flack 2018-09-17 <5B9ED559(dot)5080208(at)anastigmatix(dot)net>
>> computedPath = replacement + computedPath.slice(plen);
>> to
>> computedPath = new java.lang.String(replacement + computedPath.slice(plen));
>
> ClassCastException: sun.org.mozilla.javascript.NativeJavaObject cannot be cast to java.lang.String

I have no words. :)

One more (less intuitive) thing might be worth trying:

computedPath = String(replacement + computedPath.slice(plen));

Would you have time to try it that way? I can't make the exception
happen here, even with an Oracle jdk7 that is installed.

Correction ... I can make it happen (prior to this change) in an
icedtea-6 build installed here, with a dubious version of the
Rhino-to-JSR223 adapter jar.

And the change above to String(...) does seem to fix it (without
breaking any of the other versions I can test).

I was first guessing the issue would be the change of the bundled
JavaScript implementation from Rhino in jdk6/7 to Nashorn in jdk8.
But in both cases there is also an adapter layer so that the Java
JSR223 API is the same whether Rhino or Nashorn is underneath. And
the pre-jdk8 OpenJDK builds seem to have ended up with an older,
incomplete version of the Rhino adapter (rhino-js-engine.jar) than
what was in the Oracle builds, and it doesn't handle all of the data
type conversions as it should.

Apparently it will correctly convert a JavaScript String to a Java
String. Apparently it does *not* know what to do with a JavaScript
wrapper of an actual Java string. :) And it seems Rhino has a
clever object, this ConsString, that is an implementation detail of
a JavaScript string created efficiently by concatenation, and of
course the adapter doesn't know what to do with that either.

So using that to construct a brand new ordinary JavaScript String
seems to be the one way to get a successful conversion.

-Chap