Re: RFR 8158736: Adapter class loaders can avoid creating named dynamic modules

[Marcus Lagergren]

Nice and clean!

+1

/M

> On 06 Jun 2016, at 11:38, Sundararajan Athijegannathan 
>  wrote:
> 
> Please review: http://cr.openjdk.java.net/~sundar/8158736/webrev.00/ for
> https://bugs.openjdk.java.net/browse/JDK-8158736
> 
> Nashorn creates named, dynamic modules for java adapter classes. This
> can be avoided and we can use the default, unnamed module created for
> the adapter class loader. Nashorn allows only subtyping of public,
> exported supertypes be implemented in scripts.  The only package used in
> adapter module is exported and the adapter type is public as well.
> 
> There is no need for named dynamic module - as there is nothing to
> encapsulate.  Nashorn module can still selectively export packages to
> adapter module [ so that generated adapter class can access nashorn
> internals as needed].
> 
> This avoids having to generate read-links to the modules of the
> reference types used by the adapter class - because unnamed adapter
> module has read edges to all the modules.
> 
> Thanks,
> 
> -Sundar
> 

Re: RFR 8158736: Adapter class loaders can avoid creating named dynamic modules

[Attila Szegedi]

+1. Echoing Hannes’ sentiment, it’s nice to see that extra code gone.

> On 06 Jun 2016, at 02:38, Sundararajan Athijegannathan 
>  wrote:
> 
> Please review: http://cr.openjdk.java.net/~sundar/8158736/webrev.00/ for
> https://bugs.openjdk.java.net/browse/JDK-8158736
> 
> Nashorn creates named, dynamic modules for java adapter classes. This
> can be avoided and we can use the default, unnamed module created for
> the adapter class loader. Nashorn allows only subtyping of public,
> exported supertypes be implemented in scripts.  The only package used in
> adapter module is exported and the adapter type is public as well.
> 
> There is no need for named dynamic module - as there is nothing to
> encapsulate.  Nashorn module can still selectively export packages to
> adapter module [ so that generated adapter class can access nashorn
> internals as needed].
> 
> This avoids having to generate read-links to the modules of the
> reference types used by the adapter class - because unnamed adapter
> module has read edges to all the modules.
> 
> Thanks,
> 
> -Sundar
> 

Re: RFR 8158736: Adapter class loaders can avoid creating named dynamic modules

[Sundararajan Athijegannathan]

The relevant code in jdk9-dev/nashorn repo:

createModuleTrusted method in Context.java:

http://hg.openjdk.java.net/jdk9/dev/nashorn/file/b1de131a3fed/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/Context.java

calls to these in StructureLoader.java and ScriptLoader.java:

http://hg.openjdk.java.net/jdk9/dev/nashorn/file/b1de131a3fed/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/StructureLoader.java

http://hg.openjdk.java.net/jdk9/dev/nashorn/file/b1de131a3fed/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/ScriptLoader.java

ModuleGraphManipulator.java:  of this class creates addExports
links from dynamic modules to nashorn module.

http://hg.openjdk.java.net/jdk9/dev/nashorn/file/b1de131a3fed/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/scripts/ModuleGraphManipulator.java


-Sundar

On 6/7/2016 9:25 AM, Sundararajan Athijegannathan wrote:
> No, there are still named, dynamic  modules in Nashorn.  That comment
> was specific to adapter module in nashorn. StructureLoader and
> ScriptLoaders load generated classes that require encapsulation. And so
> these loader classes do create named, dynamic modules still.
>
> -Sundar
>
>
> On 6/7/2016 12:30 AM, Jochen Theodorou wrote:
>> On 06.06.2016 11:38, Sundararajan Athijegannathan wrote:
>> [...]
>>> There is no need for named dynamic module - as there is nothing to
>>> encapsulate.  Nashorn module can still selectively export packages to
>>> adapter module [ so that generated adapter class can access nashorn
>>> internals as needed].
>> does that mean the only user of named dynamic modules is gone now?
>>
>> bye Jochen
>>

Re: RFR 8158736: Adapter class loaders can avoid creating named dynamic modules

[Sundararajan Athijegannathan]

No, there are still named, dynamic  modules in Nashorn.  That comment
was specific to adapter module in nashorn. StructureLoader and
ScriptLoaders load generated classes that require encapsulation. And so
these loader classes do create named, dynamic modules still.

-Sundar


On 6/7/2016 12:30 AM, Jochen Theodorou wrote:
> On 06.06.2016 11:38, Sundararajan Athijegannathan wrote:
> [...]
>> There is no need for named dynamic module - as there is nothing to
>> encapsulate.  Nashorn module can still selectively export packages to
>> adapter module [ so that generated adapter class can access nashorn
>> internals as needed].
>
> does that mean the only user of named dynamic modules is gone now?
>
> bye Jochen
>

Re: RFR 8158736: Adapter class loaders can avoid creating named dynamic modules

[Jochen Theodorou]

On 06.06.2016 11:38, Sundararajan Athijegannathan wrote:
[...]

There is no need for named dynamic module - as there is nothing to
encapsulate.  Nashorn module can still selectively export packages to
adapter module [ so that generated adapter class can access nashorn
internals as needed].


does that mean the only user of named dynamic modules is gone now?

bye Jochen

Re: RFR 8158736: Adapter class loaders can avoid creating named dynamic modules

[Michael Haupt]

Hi Sundar,

lower-case thumbs up!

Best,

Michael

> Am 06.06.2016 um 11:38 schrieb Sundararajan Athijegannathan 
> :
> 
> Please review: http://cr.openjdk.java.net/~sundar/8158736/webrev.00/ for
> https://bugs.openjdk.java.net/browse/JDK-8158736
> 
> Nashorn creates named, dynamic modules for java adapter classes. This
> can be avoided and we can use the default, unnamed module created for
> the adapter class loader. Nashorn allows only subtyping of public,
> exported supertypes be implemented in scripts.  The only package used in
> adapter module is exported and the adapter type is public as well.
> 
> There is no need for named dynamic module - as there is nothing to
> encapsulate.  Nashorn module can still selectively export packages to
> adapter module [ so that generated adapter class can access nashorn
> internals as needed].
> 
> This avoids having to generate read-links to the modules of the
> reference types used by the adapter class - because unnamed adapter
> module has read edges to all the modules.
> 
> 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 8158736: Adapter class loaders can avoid creating named dynamic modules

[Hannes Wallnoefer]

Looks good. Nice to see that code removed.

Hannes

Am 2016-06-06 um 11:38 schrieb Sundararajan Athijegannathan:

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

Nashorn creates named, dynamic modules for java adapter classes. This
can be avoided and we can use the default, unnamed module created for
the adapter class loader. Nashorn allows only subtyping of public,
exported supertypes be implemented in scripts.  The only package used in
adapter module is exported and the adapter type is public as well.

There is no need for named dynamic module - as there is nothing to
encapsulate.  Nashorn module can still selectively export packages to
adapter module [ so that generated adapter class can access nashorn
internals as needed].

This avoids having to generate read-links to the modules of the
reference types used by the adapter class - because unnamed adapter
module has read edges to all the modules.

Thanks,

-Sundar

RFR 8158736: Adapter class loaders can avoid creating named dynamic modules

[Sundararajan Athijegannathan]

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

Nashorn creates named, dynamic modules for java adapter classes. This
can be avoided and we can use the default, unnamed module created for
the adapter class loader. Nashorn allows only subtyping of public,
exported supertypes be implemented in scripts.  The only package used in
adapter module is exported and the adapter type is public as well.

There is no need for named dynamic module - as there is nothing to
encapsulate.  Nashorn module can still selectively export packages to
adapter module [ so that generated adapter class can access nashorn
internals as needed].

This avoids having to generate read-links to the modules of the
reference types used by the adapter class - because unnamed adapter
module has read edges to all the modules.

Thanks,

-Sundar