[7ux-osx] Please review: 7124089: launcher refactoring

[Kumar Srinivasan]

Hi Anthony,

>
> src/share/bin/java.c
>>  987         } else if (IsMacOSX() && JLI_StrCmp(arg, 
>> "-XstartOnFirstThread") == 0) {
>>  988             ProcessSpecialArg(arg);
>>  989         } else if (IsMacOSX() && JLI_StrCCmp(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 ?

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 ?
>
>> 1595     if (IsMacOSX()) {

I can make this platform specific.


>
> 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/java_md.c and 
> src/macosx/bin/java_md.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.

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 LD_LIBRARY_PATH cloaking in solaris/java_md.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 java_md.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
>>>
>>>
>>>
>>