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