>>>> 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. -DrD-
