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: <clinit> 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
>>