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

[David Holmes]

On 18/01/2012 2:35 AM, Kumar Srinivasan wrote:
>> 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 ?

I think it should be possible to invoke a platform-specific argument 
parsing function to complement the shared options. Though for 7u leaving 
this ifdef'd to MACOSX should be fine.

> 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 ?

-XX should be reserved for VM flags

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

In both the JDK and VM we have, in my opinion, reached the limits of how 
we handle multiple platforms without introducing (even more) excessive 
duplication. The main distinguishing factor for native code is "Windows 
or not-Windows", with some further distinctions arising in a few 
specific areas. To address that we need to refactor along those lines of 
difference. Unfortunately each time we add a new platform (OS or CPU) to 
the existing structure, we make that refactoring job in the future 
considerably more difficult and larger.

David
-----

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