8169001: Remove launcher's built-in ergonomics (original) (raw)

David DeHaven david.dehaven at oracle.com
Wed Nov 9 18:13:05 UTC 2016

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 ! constcpwildcard, constjavaw, 0); Can you clarify this change with ! constcpwildcard, constjavaw, 0 /* unused */); To clarify: -159 constcpwildcard, constjavaw, constergoclass); +159 constcpwildcard, constjavaw, 0); JLILaunch is an internal entry point, this is primarily used in main.c, and this is called by JDK's tool launchers which sets "NEVERACTASSERVER", 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-

More information about the core-libs-dev mailing list