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