[7ux-osx] Please review: 7124089: launcher refactoring (original) (raw)

Anthony Petrov anthony.petrov at oracle.com
Tue Jan 17 11:24:12 PST 2012

On 1/17/2012 8:35 PM, Kumar Srinivasan wrote:

src/share/bin/java.c

987 } else if (IsMacOSX() && JLIStrCmp(arg, "-XstartOnFirstThread") == 0) { 988 ProcessSpecialArg(arg); 989 } else if (IsMacOSX() && JLIStrCCmp(arg, "-Xdock:") == 0) { 990 ProcessSpecialArg(arg); If we don't have those runtime checks then Windows, Linux and Solaris will accept those flags without a fuss, so what should the behavior be ?

I just thought that instead of the run-time conditional this could somehow be folded into a compile-type kind of check. This could be an #ifdef, or at the end of this chained if{}else{} block we could have something like:

} else if (ProcessPlatformArg(arg)) { } else if (RemovableOption...

and then have the ProcessPlatformArg() be defined in java_md.c.

Was a specification (ccc) filed for these flags ? Will this be documented in the help section ? though X flags are unsupported, in the past we have documented them, both in the man pages as well as "java -X", if these will be left undocumented should we take the vm approach and mark it -XX ?

These flags are commonly recognized since Apple has introduced them ages ago, so developers expect these flags to work. I think it makes sense to document their usage.

Generally, the fix looks good. Lots of #ifdef MACOSX looked very confusing before. However, I feel uncomfortable with having so much code duplicated between src/solaris/bin/javamd.c and src/macosx/bin/javamd.c. This seems to increase launcher code maintenance cost. Is there any possibility to fold the code up in a common source file that is shared between solaris/linux and macosx, and only define really specific parts of the code in separate files? The simplest way to accomplish this would be to leave exactly one #ifdef MACOSX in the shared file and #include a platform specific part there. Or we could tweak the make files to compile an additional file. Yes it is a lot more readable, and yes it increases duplication , but we already have some duplication between windows and unix. Since this is platform specific code, and 7uX will go into maintenance mode, the exposure will be limited.

Ah, I didn't realize that this fix isn't going to be ported to JDK 8. In this case I guess I'm fine with this. But in JDK 8 we should certainly think of something more maintainable and less duplicating. BTW, adding comments to both java_md.c's for macosx and solaris stating that lots of the code is duplicated between the two would be great.

-- best regards, Anthony

However, for jdk8 we need a hierarchical structure, as I heard some noise about restructuring the platform code, at that time it will be a good idea to coalesce these things, and remove the LDLIBRARYPATH cloaking in solaris/javamd.c which is not relevant to MacOSX.

Also, the major part of the JVMInit() function is identical on all three platforms - solaris/linux, macosx, and windows. It makes sense to define a function containing that code in the java.c and call it by platform-specific JVMInit() implementations where needed. Yes this can be done, I will look into it. Kumar -- best regards, Anthony On 1/17/2012 7:33 AM, Kumar Srinivasan wrote: oops missed setting the subject line to 7ux-osx.

Kumar

Hi,

Please review the launcher refactoring work, the webrev is here: http://cr.openjdk.java.net/~ksrini/7124089/webrev.0/ Notes: 1. Moves the majority of the launcher code into platform specific directories/files, removed redundant conditionals. 2. The solaris/linux code co-exists together as before. 3. On MacOSX, "java -client" will launch the server VM, for compatibility reasons, and dual mode is left in the macosx's javamd.c, this will enable experiments with universal libraries, quite easily. Also the mac ergonomics will always return server. Testing: Tested splash screen on all platforms and launcher regression tests. Thanks Kumar

More information about the macosx-port-dev mailing list