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

Kumar Srinivasan kumar.x.srinivasan at oracle.COM
Tue Jan 17 20:25:32 PST 2012


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

Yes I have addressed this in my repo, all runtime and compile time checks in
java.c  are history :).

Will send a completed webrev after I am done with this.

Thanks
Kumar

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



More information about the macosx-port-dev mailing list