> On Nov 9, 2016, at 10:13 AM, David DeHaven <david.deha...@oracle.com> wrote: > > >>>>> Please review the fix for: >>>>> https://bugs.openjdk.java.net/browse/JDK-8169001 >>>>> >>>>> Webrev at: >>>>> http://cr.openjdk.java.net/~ksrini/8169001/webrev.00/ >>>> >>>> Overall this looks like a complete eradication of the launcher >>>> ergonomics. A few specific comments: >>>> >>>> src/java.base/share/native/launcher/main.c >>>> >>>> ! const_cpwildcard, const_javaw, 0); >>>> >>>> Can you clarify this change with >>>> >>>> ! const_cpwildcard, const_javaw, 0 /* unused */); >>> >>> To clarify: >>> >>> -159 const_cpwildcard, const_javaw, const_ergo_class); >>> +159 const_cpwildcard, const_javaw, 0); >>> >>> >>> JLI_Launch is an *internal* entry point, this is primarily used in main.c, >>> and this is called by JDK's tool launchers which sets >>> "NEVER_ACT_AS_SERVER", >>> also this entry point is used by the java packager and deployment, I >>> have cc'ed >>> Chris Bensen and David DeHaven, my take is not to change the signature now. >>> Chris, David ? > > We (deploy) pass 0 for ergo policy, so we're fine as long as the signature > doesn't change. > > I would appreciate if we could leave the signature alone as that would > require us to support both forms at least until Java 12. It's easy to adapt > to changing signatures in Java, but not native as we'll get the same function > pointer regardless of what the function arguments are. Sending an improperly > set up stack frame to a function can cause Very Bad Things(tm) to happen. > While it may work on one system, purely by virtue of the fact that it's the > last argument in the list, there's no guarantee it will behave properly for > future compilers or even different optimization levels. > > And just so I don't appear entirely selfish here, you'll also impact anyone > using JLI_Launch in third party software. Since jli.h is included in the JDK > it really should be viewed as external API, or at least externally accessible.
As long as the signature doesn’t change the Java Packager will be fine. If there is a signature change I’d suggest changing the name of the method especially if it happens during a minor release so there is some way the Java Packager’s launcher can determine what to call. Chris
