RFR: 8215156: Deprecate the -Xfuture option
David Holmes
david.holmes at oracle.com
Thu May 23 02:04:32 UTC 2019
On 23/05/2019 11:56 am, Henry Jen wrote:
> Thanks for the quick review,
>
>> On May 22, 2019, at 6:34 PM, David Holmes <david.holmes at oracle.com> wrote:
>>
>> Hi Henry,
>>
>> On 23/05/2019 11:07 am, Henry Jen wrote:
>>> Hi,
>>> Please review a webrev[1] to deprecate the -Xfuture option per CSR-8224524[2].
>>
>> src/hotspot/share/Xusage.txt
>>
>> Ignoring the usefulness, or otherwise of this file, the entry for Xfuture should not be deleted (that happens when an option is actually removed) but just have "(deprecated)" added to it.
>>
>
> I was wondering if I should prefix (deprecated) or append to the content. It make the line over the 80 so I decided just remove it since this document is not official we don’t want to advocate that option any more.
>
> So, we have couple options,
>
>
> -Xfuture enable strictest checks, anticipating future default
> (deprecated)
> -Xrs reduce use of OS signals by Java/VM (see documentation)
I prefer option 1.
> or
>
> -Xfuture enable strictest checks (deprecated)
>
> or
>
> -Xfuture (deprecated)
> enable strictest checks, anticipating future default
>
> or keep in one line don’t mind the 80 width.
>
> Let me know which do we prefer.
>
>> ---
>>
>> In hotspot we include the version of the JDK that deprecated the option:
>>
>> "Option %s was deprecated in version %s and will likely be removed in a future release."
>>
>> Perhaps you could do the same for the launcher?
>>
>
> During the CSR discussion, we asked Dr Deprecator’s opinion and decided on
> “XXX is deprecated and may be removed in a future release.”
>
> It was suggested to change JVM message to match.
Okay.
Thanks,
David
> Cheers,
> Henry
>
>> Otherwise seems fine.
>>
>> Thanks,
>> David
>> -----
>>
>>> Cheers,
>>> Henry
>>> [1] https://cr.openjdk.java.net/~henryjen/jdk13/8215156/open/webrev/
>>> [2] https://bugs.openjdk.java.net/browse/JDK-8224524
>
More information about the core-libs-dev
mailing list