> On Jul 12, 2016, at 6:13 AM, Paul Benedict <[email protected]> wrote: > > Alan, I wish I found this before I responded to you, but, anyway, here you > go: > > https://bugs.openjdk.java.net/browse/JDK-8160698 > "java --dry-run should not cause main class be initialized” >
Yes this has been fixed. Mandy > Cheers, > Paul > > On Mon, Jul 11, 2016 at 5:09 PM, Paul Benedict <[email protected]> wrote: > >> So I just tested "--dry-run" and I see it does load the class. My >> apologies. I was following the commit trail but somehow the loading of the >> class escaped me. I swore at one point it wasn't loading, but my error, >> nevertheless. >> >> Was there any debate on this issue? The problem I currently see with >> loading the class is you're still allowing static initializers to run. I >> don't see a purpose in loading the class here because you're potentially >> allowing user code to execute and causing side-effects in the JVM. If the >> purpose of JDK-8159596 is to test the resolving of the >> configuration/options, I don't see how the current behavior is therefore >> desired. To take an analogy, the Maven Release Plugin has a "dry run" >> feature to test an install. It actually doesn't do an install. But someone >> can make the argument (and I am) that Java's --dry-run is not actually dry. >> It's really just a "--no-main" but user code can still run. >> >> Cheers, >> Paul >> >> On Mon, Jul 11, 2016 at 4:39 PM, Alan Bateman <[email protected]> >> wrote: >> >>> On 11/07/2016 22:01, Paul Benedict wrote: >>> >>> The current help of --dry-run is this: >>>> "create VM but do not execute main method" >>>> >>>> But I think it's pretty important to note that the class is also not even >>>> loaded. >>>> >>> The main class should be loaded. The original intention was that it do >>> everything except invoke the main method. >>> >>> -Alan >>> >> >>
