On 7/26/19 11:51 PM, Alan Bateman wrote:
On 26/07/2019 22:12, Mandy Chung wrote:
Debug VM checks if a class is accessible to the lookup class except
if the lookup class is java.lang.Object (which was the lookup class
of publicLookup previously). WithJDK-8173978, Lookup::in has changed
and it can be used to create a new public Lookup on a different
lookup class.
A quick fix for this bug is to pass Object.class for resolution for a
Lookup object with UNCONDITIONAL mode as previously. The lookup
class and allowed modes are used to check if the resolved member is
accessible to this Lookup object. We should re-examine this area in
particular publicLookup (see JDK-8173977).
Looks okay as a quick fix, surprised it is only caught with tier5 or 6
testing.
It was a surprise that this was not caught in our tier1-3 testing. We
shall revisit and expand tier1-3 to execute certain tests such as
jdk_lang group in fastdebug mode.
I assume JDK-8173977 will need a priority boost.
It may be time to revisit this together with loader constraints
(although they are orthogonal).
Mandy
