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.hol...@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
