Multiple entry points requirement

[David M. Lloyd]

Sorry for the mis-send.  I was just going to suggest that alternatively 
to adding complexity to an already complex system, the wrapper 
script/program could simply pass in an argument to determine which 
program to run.

On 06/28/2011 08:07 PM, Mandy Chung wrote:
> I think the multiple entry points should be added to the requirement.
>
> There are several tools in the JDK that would be best if they can be
> packaged in a single module with multiple entry points. For example,
> jps, jstat, jstack, jmap, etc are the JDK command-line tools that are in
> tools.jar and each has its own entry point. Each of the tool has only
> one or few classes and they are diagnosability tools that make sense to
> be packaged and installed together. The JDK would benefit from the
> multiple entry points to avoid unnecessary fine-grained modules.
>
> Mandy
>
> On 6/29/11 2:10 AM, Alex Buckley wrote:
>> I recall discussion of different entrypoints when a module is used in
>> different contexts, e.g. applet v. command-line launcher.
>>
>> However, the Java Module System requirements don't say anything about
>> this, so I stuck with a solitary, unqualified 'class ...' construct in
>> the module declaration. The closest "context-aware" requirement is
>> that a module "can be used both as a JAR on the class path and
>> installed as a module in a module library".
>>
>> Alex
>>
>> On 6/28/2011 10:41 AM, Roger Riggs wrote:
>>> Hi,
>>>
>>> Thanks for the writeup of jigsaw modules.
>>>
>>> This is more of a comment on the module compilation unit grammar
>>> and the choice of keywords and semantics.
>>> http://openjdk.java.net/projects/jigsaw/doc/topics/grammar.html
>>>
>>> The "class" keyword in the module-info.java sticks out as an awkward
>>> usage.
>>> There are plenty of classes in the module. The significance the class
>>> is that it is a/the main class. The keyword should identify the usage
>>> of the class.
>>> "main" would be more meaningful and intuitive.
>>>
>>> The "class" keyword is being overloaded. While it identifies a main
>>> class it is
>>> also being used to indicate module is the root of the static context for
>>> the module as a whole and the class name is not relevant to that
>>> function.
>>>
>>> A separate keyword defining the module as requiring a static context
>>> would clearer to separate the semantics of the entry point from the
>>> "classloader"
>>> behavior.
>>>
>>> Can a module, like a jar file could contain multiple classes with
>>> main methods?
>>> In current usage, for jar files, the main class can be given on the
>>> command line
>>> allowing multiple applications to share the overhead of packaging.
>>> Having a solitary entry point may result in extra overhead because
>>> each application
>>> must be in a separate module.
>>>
>>> Roger
>


-- 
- DML