RFR: jdk10: 8169646: Remove launcher's -d32/-d64 option
Kumar Srinivasan
kumar.x.srinivasan at oracle.com
Mon May 8 14:27:19 UTC 2017
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 ?
>
> > 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.
>>
More information about the core-libs-dev
mailing list