RFR 8165595: Main class should be set for nashorn modules

[Erik Joelsson]

Looks good. thanks!

/Erik


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