RFR 8165595: Main class should be set for nashorn modules

Erik Joelsson erik.joelsson at oracle.com
Thu Sep 8 09:23:27 UTC 2016

Looks good. thanks!


On 2016-09-08 10:58, Sundararajan Athijegannathan wrote:
> Thanks. I'm going ahead with updated webrev :
> http://cr.openjdk.java.net/~sundar/8165595/webrev.02/
> Only change is the whitespace removal as suggested.
> Thanks,
> -Sundar
> On 9/7/2016 6:18 PM, Erik Joelsson wrote:
>> Hello,
>> I cannot think of a more suitable place to put this right now. So far
>> we have not had a need for module specific configuration for jmod
>> creation. If this need grows, we might need to think of something.
>> (sort of related, I have been thinking of ways to move all the java
>> compilation details in CompileJavaModules.gmk to module specific files
>> as well)
>> I'm happy with the patch as long as you reduce the indentation to 2
>> spaces which we use for logical indents in the build system files. See
>> http://openjdk.java.net/groups/build/doc/code-conventions.html for
>> details.
>> /Erik
>> On 2016-09-07 14:38, Alan Bateman wrote:
>>> On 07/09/2016 13:27, Sundararajan Athijegannathan wrote:
>>>> jjs does not yet support module related options. So, user modules can
>>>> not be scripted directly with jjs as of now. Only way is to use to
>>>> launcher with -mp along with -m for jjs main class. With the change,
>>>> only module name needs to be specified.
>>>> Also, jjs tool is not shipped for embedded platforms (compact1). But,
>>>> jdk.nashorn.tools.Shell (used to be the jjs main in jdk8u) is compact1
>>>> compliant. So user can use
>>>>       java -m jdk.scripting.nashorn
>>>> on embedded platforms [and use functionality reduced jjs there]
>>>> Yes, I tried to see if I can get it per-module config from somewhere -
>>>> but couldn't. I'm open to suggestions on how to do that in the current
>>>> scheme.
>>> Is there an issue tracking the update to `jjs`?
>>> Also I think you should wait to hear from Erik as to where to put
>>> this in the build. The concern with CreateJMods.gmk is that isn't not
>>> going to scale once we eventually get to sorting out the issues with
>>> modules that have entry points.
>>> -Alan

More information about the build-dev mailing list