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

Kumar Srinivasan kumar.x.srinivasan at oracle.COM
Tue Jan 17 16:30:52 PST 2012


Hi Joe,

> Kumar,
>
> What is the general plan on getting this functionality into JDK 8 as 
> well as 7uX?

Good question, I am hoping someone on this forum can answer about the 
timetable
and also the merge into 7uX and jdk8. I am hoping when it is ready to be 
merge into
8, we will have to lay this out in a more sensible way.

Kumar

>
> Like Anthony, I'm a bit concerned about the code duplications, 
> although generally the changes look good.
>
> -Joe
>
> On 1/17/2012 8:35 AM, Kumar Srinivasan wrote:
>> 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
>>>>>
>>>>>
>>>>>
>>>>
>>




More information about the jdk7u-dev mailing list