RFR: 8266530: HotSpot changes for JEP 306
David Holmes
david.holmes at oracle.com
Fri May 7 11:14:03 UTC 2021
On 6/05/2021 10:14 am, Joe Darcy wrote:
> On 5/5/2021 4:57 PM, forax at univ-mlv.fr wrote:
>> Given that its value 0x800 is not used on other members, it can be
>> reused to indicate something on class/field/method.
>> So we may want to recycle it
>> undefined -> defined -> undefined -> defined
>
>
> Yes; the intention of undefining it now is to allow the possibility of
> the flag position being assigned to another purpose in the future for
> later class file versions.
I don't think we can reasonably attempt to do this in the short to
medium term. The basic proposal is that ACC_STRICT becomes implied from
this point forward and javac will stop generating it. But the existing
rules for ACC_STRICT should remain as it is now technically
"deprecated". Eventually we should reject classfiles >=17 that
explicitly set ACC_STRICT. Then some time after that we could recycle
the ACC_STRICT bit value to use for another flag.
Without a period where we reject the ACC_STRICT bit I think it would be
dangerous to suddenly interpret its presence as ACC_SOMETHING_NEW.
Cheers,
David
-----
> -Joe
>
More information about the hotspot-runtime-dev
mailing list