Review request: JDK-8159596 Add java --dry-run

[Peter Levart]

Hi,


On 07/02/2016 10:01 AM, David Holmes wrote:
> On 2/07/2016 1:17 AM, Mandy Chung wrote:
>>
>>> On Jul 1, 2016, at 12:48 AM, David Holmes <david.holmes at oracle.com> 
>>> wrote:
>>>
>>> Okay so back to my original statement - if all this does is ensure 
>>> the main class is found does it really carry its weight as a new 
>>> argument?
>>>
>>
>> Are you suggesting for java —-dry-run to run <clinit> or not to load 
>> main class?  Are you thinking that if the main class can’t be found 
>> or no main entry point, launching it will fail anyway and why bother?
>
> The difference between -version and --dry-run is only the locating of 
> the main class, which will be an obvious failure without --dry-run. It 
> just doesn't seem to carry its weight as a new command-line arg. I had 
> assumed the loading and/or initialization was needed to ensure the 
> module system was all configured correctly, but based on what you have 
> said that seems not to be the case.
>
> David
>
>> Mandy
>>

What about extending the behavior of -version option so that when it is 
specified together with other startup options like -mp, -m, -cp, 
MainClass, ... it would behave just like --dry-run has been designed to 
work? Would such combinations of options be hard to 
parse/detect/validate ? For example, what to do if someone specifies 
-version in combination with -mp, -addmods, but no -m ? Would we still 
try to resolve the modules and print the version or fail and with what? 
Specifying just -mp by itself currently prints usage help. Having an 
explicit --dry-run option at least does not have those dilemmas and 
defines the behavior explicitly when some startup options are missing - 
the same behavior as without --dry-run.

In order to put more weight into --dry-run, I suggest extending its 
behavior to report to the stdout, the result of resolving the modules 
when successfull. For example:


module app {
    requires lib;
    uses my.lib.Service;
    exports my.app;
}

module lib {
    exports my.lib;
}

module service {
   requires lib;
   provides my.lib.Service with my.service.ServiceImpl;
}


java --dry-run -mp modules -m app/my.app.Main

Resolved modules (Legend: * root module, -- requires, -= requires 
public, -> uses, -< provides)

* app
   +-- java.base
   |   +-> java.lang.System$LoggerFinder
   |   +-> java.net.ContentHandlerFactory
   |   |   \-< java.desktop (sun.awt.www.content.MultimediaContentHandlers)
   |   |       +-- java.base ...
   |   |       +-= java.datatransfer
   |   |       |   +-- java.base ...
   |   |       |   \-> sun.datatransfer.DesktopDatatransferService
   |   |       |       \-< java.desktop 
(sun.awt.datatransfer.DesktopDatatransferServiceImpl) ...
   |   |       +-- java.prefs
   |   |       |   +-- java.base ...
   |   |       |   +-- java.xml
   |   |       |   |   +-- java.base ...
   |   |       |   |   +-> javax.xml.datatype.DatatypeFactory
   |   |       |   |   +-> javax.xml.parsers.DocumentBuilderFactory
   |   |       |   |   +-> javax.xml.parsers.SAXParserFactory
   |   |       |   |   +-> javax.xml.stream.XMLEventFactory
   |   |       |   |   +-> javax.xml.stream.XMLInputFactory
   |   |       |   |   +-> javax.xml.stream.XMLOutputFactory
   |   |       |   |   +-> javax.xml.transform.TransformerFactory
   |   |       |   |   +-> javax.xml.validation.SchemaFactory
   |   |       |   |   +-> javax.xml.xpath.XPathFactory
   |   |       |   |   \-> org.xml.sax.XMLReader
   |   |       |   \-> java.util.prefs.PreferencesFactory
   |   |       +-= java.xml ...
...
...
...
   +-- lib
   |   \-- java.base ...
   \-> my.lib.Service
       \-< service (my.service.ServiceImpl)
           +-- java.base ...
           \-- lib ...


Here's a prototype:

http://cr.openjdk.java.net/~plevart/jdk9-dev/java-dry-run/webrev.01/


I did it using just public API. What I was missing is a way to find out 
what the root modules are. Currently this uses the following algorithm:

- start with a set of all resolved modules in the Layer (the boot layer)
- remove from the set all modules that any module requires.
- remove from the set all modules that provide service that any module uses
- what's left are root modules.

The problem with this approach is that if a real "root" module provides 
some service that is used by some resolved module, it will not be 
considered as root module by this algorithm.

The information about root modules is lost when Layer is resolved. If 
this information was kept at least in the ModuleReference, then the 
algorithm would be trivial and always correct:

http://cr.openjdk.java.net/~plevart/jdk9-dev/java-dry-run/webrev.02/




Regards, Peter