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