RFR: jdk10: 8169646: Remove launcher's -d32/-d64 option

[David Holmes]

Hi Kumar,

On 9/05/2017 12:27 AM, Kumar Srinivasan wrote:
>
> Hi David,
>
>> Hi Kumar,
>>
>> On 7/05/2017 1:21 AM, Kumar Srinivasan wrote:
>>> Hello,
>>>
>>> Please review the changes to remove the java launcher's data model
>>> options  -d32/-d64, these options existed to support Solaris dual-mode
>>> operation, however for uniformity, these options were accepted by other
>>> platforms as well.  These options are  now obsolete, and deprecated in
>>> jdk9,and are now being removed.
>>>
>>> Webrev: http://cr.openjdk.java.net/~ksrini/8169646/webrev.0
>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8169646
>>
>> This seems okay in itself, though I'm curious why you made the
>> launcher/jli responsible for treating -d32/-d64 as invalid options
>> instead of just passing them through to the VM to let it reject them
>> as it does any other non-existent option eg:
>
> I mulled over this for sometime, and felt that since the launcher
> supported these options before, it should give a better/reasonable
> error message than the VM does. I am undecided. What do you think ?

I think all invalid options should be treated the same. We had the 
deprecation phase for providing custom feedback - now we're just 
rejecting them outright.

Cheers,
David

>>
>>  > java -foo -version
>> Unrecognized option: -foo
>> Error: Could not create the Java Virtual Machine.
>> Error: A fatal exception has occurred. Program will exit.
>>
>> I also see some pre-existing messiness you might want to tidy up while
>> you're in the area :)
>
> OMG Pre-existing conditions. ;)
>
>>
>> src/java.base/macosx/native/libjli/java_md_macosx.c
>>
>> 378     JLI_Snprintf(jvmcfg, so_jvmcfg, "%s%slib%s%s%sjvm.cfg",
>> 379                  jrepath, FILESEP, FILESEP,  "", "");
>>
>> The last two %s should just be removed instead of passing empty strings.
>>
>>  422     } else {
>>  423         /*
>>  424          * macosx client library is built thin, i386 only.
>>  425          * 64 bit client requests must load server library
>>  426          */
>>  427         const char *jvmtypeUsed = "server";
>>  428         JLI_Snprintf(jvmpath, jvmpathsize, "%s/lib/%s/" JVM_DLL,
>> jrepath, jvmtypeUsed);
>>  429     }
>>
>> I don't think we have ever had 32-bit client on OSX! So this whole
>> clause seems strange. That aside you can just hardwire %s/lib/server
>> instead of using the jvmTypeUsed variable.
>
> +1, I think we did support 32-bit for sometime, in the early days of
> MacOSX.
>
>
>>
>> ---
>>
>> src/java.base/unix/native/libjli/java_md_solinux.c
>>
>>  323     JLI_Snprintf(jvmcfg, so_jvmcfg, "%s%slib%s%sjvm.cfg",
>>  324             jrepath, FILESEP, FILESEP, FILESEP);
>>
>> Another strange version of this code - only 4 %s this time, but
>> adjacent FILESEP. :) I'm assuming this is from when <arch> was removed.
> Urk.
>
> Ok I will revisit the above, good catches!, and prepare
> another changeset.
>
> Kumar
>
>
>>
>> Thanks,
>> David
>>
>>> Thanks
>>> Kumar
>>>
>>> PS: Thanks to David Holmes and Igor Ignatyev the -d32/-d64 flags have
>>> been
>>> purged from internal test suites.
>>>
>