RFR(S) 8158338: Nashorn's ScriptLoader split delegation has to adjusted

[Sundararajan Athijegannathan]

Please review http://cr.openjdk.java.net/~sundar/8158338/webrev.00/ for
https://bugs.openjdk.java.net/browse/JDK-8158338

Thanks,

-Sundar

Re: "not an object"

[Sundararajan Athijegannathan]

Hi,

Java objects are treated "as is" in nashorn. i.e., Nashorn uses
wrapperless Java object access.  So, Java objects are *not* ECMAScript
objects. Dynamic property addition, prototype manipulation etc. won't
work on Java objects.

But, you can create a helper ECMAScript object whose properties are
bound to the properties of a Java object. You can use
Object.bindProperties extension for this  [
https://wiki.openjdk.java.net/display/Nashorn/Nashorn+extensions#Nashornextensions-Object.bindProperties
]

Example:

var props = java.lang.System.properties;
var obj = Object.bindProperties({}, props); // create a new script
object and bind it's properties to that of Java object

Object.getOwnPropertyNames(obj).forEach(function(val) { print(val) });


Note that Java Maps are treated as 'special' in that keys can be used as
properties. [
https://wiki.openjdk.java.net/display/Nashorn/Nashorn+extensions#Nashornextensions-JavaMapkeysasproperties
]
That also could be used to provide script friendly return object from
your Java code.

Hope this helps,
-Sundar

On 6/1/2016 1:53 AM, yikes aroni wrote:
> So from a javascript function i call a java method that returns a java
> object. What gets returned is not a simple bean. It has properties and
> methods on it.
>
> var xxx = MyJavaClass.getMeSomething();
>
> The *typeof* xxx is "object" according to Nashorn. However, when i try to
> do things with it -- as if it were a Javascript object -- I get the message
>
> TypeError: testSample is not an Object
>
> Is there something specific i need to do to be able to manipulate xxx as a
> javascript object? For example, I want to be able to add properties and
> functions to it
>
> xxx['someProp'] = 3.14;
> xxx['someFn'] = function() {
>  print('hello!');
> }
>
> I want to be able to get stuff from it
>
> Object.getOwnPropertyNames(xxx).forEach(function(val) { print(val) });
>
> Stuff like that... but i can't because it's not seen as a native JS
> "object"
>
> thanks. I hope i am clear.

"not an object"

[yikes aroni]

So from a javascript function i call a java method that returns a java
object. What gets returned is not a simple bean. It has properties and
methods on it.

var xxx = MyJavaClass.getMeSomething();

The *typeof* xxx is "object" according to Nashorn. However, when i try to
do things with it -- as if it were a Javascript object -- I get the message

TypeError: testSample is not an Object

Is there something specific i need to do to be able to manipulate xxx as a
javascript object? For example, I want to be able to add properties and
functions to it

xxx['someProp'] = 3.14;
xxx['someFn'] = function() {
 print('hello!');
}

I want to be able to get stuff from it

Object.getOwnPropertyNames(xxx).forEach(function(val) { print(val) });

Stuff like that... but i can't because it's not seen as a native JS
"object"

thanks. I hope i am clear.

Re: RFR 8158250: nashorn ant javadoc targets are broken

[Michael Haupt]

Hi Sundar,

lower-case thumbs up!

Best,

Michael

> Am 31.05.2016 um 17:00 schrieb Sundararajan Athijegannathan 
> :
> 
> Please review  http://cr.openjdk.java.net/~sundar/8158250/webrev.00/ for
> https://bugs.openjdk.java.net/browse/JDK-8158250
> 
> Thanks,
> 
> -Sundar
> 

-- 

 
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany

ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 
München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 
3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
  Oracle is committed to developing 
practices and products that help protect the environment

Re: RFR 8158250: nashorn ant javadoc targets are broken

[Hannes Wallnoefer]

Looks good!

Am 2016-05-31 um 17:00 schrieb Sundararajan Athijegannathan:

Please review  http://cr.openjdk.java.net/~sundar/8158250/webrev.00/ for
https://bugs.openjdk.java.net/browse/JDK-8158250

Thanks,

-Sundar

RFR 8158250: nashorn ant javadoc targets are broken

[Sundararajan Athijegannathan]

Please review  http://cr.openjdk.java.net/~sundar/8158250/webrev.00/ for
https://bugs.openjdk.java.net/browse/JDK-8158250

Thanks,

-Sundar

Re: RFR 8158131: Nashorn should not use jdk.internal.module.Modules API

[Hannes Wallnoefer]

+1 for the incremental changes in the last iteration.

Hannes

Am 2016-05-31 um 09:17 schrieb Sundararajan Athijegannathan:

Sorry, I have updated nashorn webrev again:

http://cr.openjdk.java.net/~sundar/8158131/nashorn/webrev.02/

Incremental changes:

* Missed "nashornModule" name in JavaAdapterClassLoader.java. Fixed it
to use all caps name
* AccessController.doPrivileged call in Context.createModuleTrusted.
Earlier I had used an acc. context with "getClassLoader" and
"createClassLoader" permissions.
But, Layer.defineModules call requires just "getClassLoader" permission.
Reduced acc. context accordingly.

-Sundar

On 5/30/2016 4:13 PM, Sundararajan Athijegannathan wrote:

Updated nashorn webrev:
http://cr.openjdk.java.net/~sundar/8158131/nashorn/webrev.01/

* Added @link in ModuleGraphManipulator.java's javadoc

* Using Context.class.getModule() in all places where nashorn module is
needed

* Using  all caps names for static final variables  - nashornModule,
javaBaseModule, myModule  in generated

-Sundar


On 5/30/2016 2:50 PM, Sundararajan Athijegannathan wrote:

Hi,

Inline replies below.


On 5/30/2016 2:16 PM, Michael Haupt wrote:

Hi Sundar,

lower-case thumbs up for both the jdk and nashorn changes, with remarks:

== ModuleGraphManipulator.java ==

* please add a @see or @link to the place where the bytes are read and
code is dynamically generated, or used, and vice versa.


Will do.


== JavaAdapterBytecodeGenerator.java ==
  
+private static final Module nashornModule =

JavaAdapterBytecodeGenerator.class.getModule();

This borders on the emerging discipline of Jigsaw idioms and patterns
... assuming this class moves, at some point in the future, to another
(internal?) module. This will itch. How about having one central
authority saying "I represent the Nashorn module", rather than
implicitly assuming the class at hand will be in that module forever?
One line below, Object.class.getModule() looks like a waterproof
representative for the java.base module.

hmm..  if this class moves out of nashorn , many things will break
anyway! i.e., this has to be in nashorn (because of security assumptions
for eg). I could use Context class perhaps..


+private static byte[] MODULES_READ_ADDER_BYRES;

If it cannot be final, how about @Stable? It would help, if not in
terms of performance, so at least to document that this is an array
that will be populated *once* and never change thereafter.


hmm.. @Stable would bring another internal API dependency to nashorn.
Would like to avoid another internal API dependency to nashorn.


+// private static final Module myModule;
+{
+FieldVisitor fv = cw.visitField(ACC_PRIVATE | ACC_FINAL |
ACC_STATIC,
+"myModule", "Ljava/lang/reflect/Module;", null, null);
+fv.visitEnd();
+}

Suggestion: adhere to Java coding style even in generated code and
spell this as MY_MODULE.

Will fix that.

Thanks,
-Sundar


Best,

Michael


Am 30.05.2016 um 10:24 schrieb Sundararajan Athijegannathan
mailto:sundararajan.athijegannat...@oracle.com>>:

Please review http://cr.openjdk.java.net/~sundar/8158131/
 for
https://bugs.openjdk.java.net/browse/JDK-8158131

This code cleanup is to avoid Nashorn's use of JDK internal class
jdk.internal.module.Modules.

With this change, nashorn uses java.lang.reflect.Layer public API to
create single Module layers as needed.  And nashorn generates/loads code
into appropriate modules (which calls java.lang.reflect.Module.addReads,
.addExports public APIs) to add module export/read edges as needed.

-Sundar


--

Oracle 
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467
Potsdam, Germany

ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25,
D-80992 München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering
163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
Green Oracle    Oracle is committed
to developing practices and products that help protect the environment

Re: RFR 8158131: Nashorn should not use jdk.internal.module.Modules API

[Hannes Wallnoefer]

Sorry for the slow review, I needed some explanation from Sundar about 
the difficulties of dynamic module creation, cross-layer read edges etc.


With that knowledge +1 for this change.

Hannes

Am 2016-05-30 um 19:55 schrieb Alan Bateman:

On 30/05/2016 11:43, Sundararajan Athijegannathan wrote:

Updated nashorn webrev:
http://cr.openjdk.java.net/~sundar/8158131/nashorn/webrev.01/

* Added @link in ModuleGraphManipulator.java's javadoc

* Using Context.class.getModule() in all places where nashorn module is
needed

* Using  all caps names for static final variables  - nashornModule,
javaBaseModule, myModule  in generated


I looked over the changes and good to see it using the API to create 
dynamic modules. I assume folks familiar with the Nashorn code will do 
the detailed review.


-Alan

Re: RFR 8158131: Nashorn should not use jdk.internal.module.Modules API

[Sundararajan Athijegannathan]

Sorry, I have updated nashorn webrev again:

http://cr.openjdk.java.net/~sundar/8158131/nashorn/webrev.02/

Incremental changes:

* Missed "nashornModule" name in JavaAdapterClassLoader.java. Fixed it
to use all caps name
* AccessController.doPrivileged call in Context.createModuleTrusted.
Earlier I had used an acc. context with "getClassLoader" and
"createClassLoader" permissions.
But, Layer.defineModules call requires just "getClassLoader" permission.
Reduced acc. context accordingly.

-Sundar

On 5/30/2016 4:13 PM, Sundararajan Athijegannathan wrote:
> Updated nashorn webrev:
> http://cr.openjdk.java.net/~sundar/8158131/nashorn/webrev.01/
>
> * Added @link in ModuleGraphManipulator.java's javadoc
>
> * Using Context.class.getModule() in all places where nashorn module is
> needed
>
> * Using  all caps names for static final variables  - nashornModule,
> javaBaseModule, myModule  in generated
>
> -Sundar
>
>
> On 5/30/2016 2:50 PM, Sundararajan Athijegannathan wrote:
>> Hi,
>>
>> Inline replies below.
>>
>>
>> On 5/30/2016 2:16 PM, Michael Haupt wrote:
>>> Hi Sundar,
>>>
>>> lower-case thumbs up for both the jdk and nashorn changes, with remarks:
>>>
>>> == ModuleGraphManipulator.java ==
>>>
>>> * please add a @see or @link to the place where the bytes are read and
>>> code is dynamically generated, or used, and vice versa.
>>>
>> Will do.
>>
>>> == JavaAdapterBytecodeGenerator.java ==
>>>  
>>> +private static final Module nashornModule =
>>> JavaAdapterBytecodeGenerator.class.getModule();
>>>
>>> This borders on the emerging discipline of Jigsaw idioms and patterns
>>> ... assuming this class moves, at some point in the future, to another
>>> (internal?) module. This will itch. How about having one central
>>> authority saying "I represent the Nashorn module", rather than
>>> implicitly assuming the class at hand will be in that module forever?
>>> One line below, Object.class.getModule() looks like a waterproof
>>> representative for the java.base module.
>> hmm..  if this class moves out of nashorn , many things will break
>> anyway! i.e., this has to be in nashorn (because of security assumptions
>> for eg). I could use Context class perhaps..
>>
>>> +private static byte[] MODULES_READ_ADDER_BYRES;
>>>
>>> If it cannot be final, how about @Stable? It would help, if not in
>>> terms of performance, so at least to document that this is an array
>>> that will be populated *once* and never change thereafter.
>>>
>> hmm.. @Stable would bring another internal API dependency to nashorn.
>> Would like to avoid another internal API dependency to nashorn.
>>
>>> +// private static final Module myModule;
>>> +{
>>> +FieldVisitor fv = cw.visitField(ACC_PRIVATE | ACC_FINAL |
>>> ACC_STATIC,
>>> +"myModule", "Ljava/lang/reflect/Module;", null, null);
>>> +fv.visitEnd();
>>> +}
>>>
>>> Suggestion: adhere to Java coding style even in generated code and
>>> spell this as MY_MODULE.
>> Will fix that.
>>
>> Thanks,
>> -Sundar
>>
>>> Best,
>>>
>>> Michael
>>>
 Am 30.05.2016 um 10:24 schrieb Sundararajan Athijegannathan
 >>> >:

 Please review http://cr.openjdk.java.net/~sundar/8158131/
  for
 https://bugs.openjdk.java.net/browse/JDK-8158131

 This code cleanup is to avoid Nashorn's use of JDK internal class
 jdk.internal.module.Modules.

 With this change, nashorn uses java.lang.reflect.Layer public API to
 create single Module layers as needed.  And nashorn generates/loads code
 into appropriate modules (which calls java.lang.reflect.Module.addReads,
 .addExports public APIs) to add module export/read edges as needed.

 -Sundar

>>> -- 
>>>
>>> Oracle 
>>> Dr. Michael Haupt | Principal Member of Technical Staff
>>> Phone: +49 331 200 7277 | Fax: +49 331 200 7561
>>> Oracle Java Platform Group | LangTools Team | Nashorn
>>> Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467
>>> Potsdam, Germany
>>>
>>> ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25,
>>> D-80992 München
>>> Registergericht: Amtsgericht München, HRA 95603
>>>
>>> Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering
>>> 163/167, 3543 AS Utrecht, Niederlande
>>> Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
>>> Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
>>> Green Oracle  Oracle is committed
>>> to developing practices and products that help protect the environment
>>>
>>>