[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-nashorn-dev
Subject:    Re: Rhino shell compatibility
From:       "David P. Caldwell" <david () code ! davidpcaldwell ! com>
Date:       2014-05-14 1:15:15
Message-ID: CABBxOKkrA+gNn-R6-DtV+DreHZrEddLBjGbEnyQTppiqG2yAHQ () mail ! gmail ! com
[Download RAW message or body]

I guess my view is that since mozilla_compat.js is intended to ease
transition, the JavaAdapter cover, for example, should also provide
the less strict form; this wouldn't harm the preferred Java.extend
target for migration, which could continue to use the stricter form.

Similarly, readFile and readUrl wouldn't be hard to implement; I
implemented each of them (poorly, but sufficiently) in perhaps 5-7
lines of code.

Maybe there are sound reasons to exclude these (particularly if there
are technical reasons I don't understand that would make the
JavaAdapter defaults difficult), but my view would be, why not provide
the smoothest possible glide path when providing a compatibility layer
that is explicitly for that purpose?

-- David P. Caldwell
http://www.davidpcaldwell.com/

On Mon, May 12, 2014 at 11:58 PM, A. Sundararajan
<sundararajan.athijegannathan@oracle.com> wrote:
> Hi,
>
> mozilla_compat.js provides only few things for transition -- not every Rhino
> shell extension is supported by that. Only a subset of "non-shell" rhino
> extensions are supported. JavaAdapter in mozilla_compat.js is a cover over
> nashorn's own Java.extend. Java.extend, Java.type - are stricter in that
> errors/exceptions are preferred compared to silently returning
> false/providing empty method etc.
>
> Thanks
> -Sundar
>
>
> On Monday 12 May 2014 09:57 PM, David P. Caldwell wrote:
>>
>> I don't know how much compatibility is the goal, and I may be doing
>> something wrong, but it looks like (running JDK 1.8.0_05) there are
>> three incompatibilities between the Rhino shell and the
>> mozilla_compat.js implementation provided with Nashorn.
>>
>> There may be reasons for these incompatibilities. But just in case
>> there are not,
>>
>> 1. readFile appears to be absent,
>> 2. readUrl appears to be absent,
>> 3. The JavaAdapter implementation no longer appears to silently
>> provide delegate methods that return null; instead the default
>> implementation throws UnsupportedOperationException.
>>
>> Obviously I know how to work around these differences, but they cause
>> some software to need modification to run under Nashorn even with the
>> compatibility layer.
>>
>> Thoughts?
>>
>> -- David P. Caldwell
>> http://www.davidpcaldwell.com/
>
>
[prev in list] [next in list] [prev in thread] [next in thread]