On Mon, 8 Jun 2026 17:05:46 GMT, Alan Bateman <[email protected]> wrote:
> The specification of JVMTI GetClassModifiers needs some TLC. The spec was > carried over from the equivalent function in JVMDI but doesn't really specify > that it works like Class::getModifiers and returns Java language modifiers > and not necessarily the access flags from the class file. The change in > behavior to only set ACC_IDENTITY when the class is an identity class or > array makes it a good time to re-write the spec to align with existing and > future behavior. > > A new test is added to test this function with value classes. The tests are > added to the "newer" serviceability/jvmti tree. There are some older tests > for GetClassModifiers in vmTestbase/nsk suite so there is a bit of an overlap. > > --------- > - [x] I confirm that I make this contribution in accordance with the [OpenJDK > Interim AI Policy](https://openjdk.org/legal/ai). > Chris has a concern related to the integration schedule and would prefer to > separate the Valhalla specific changes from the long-standing improvement of > the JVMTI `GetClassModifiers()` as it may impact the JDI and JDWP specs. It > feels like there has to be a way to avoid detailed the JDI and JDWP spec > changes. There are no implementation changes here and there is nothing that specifies that the JDWP ReferenceType.Modifiers command be implemented with JVMTI GetClassModifiers. That allows us to separate the concern with the JDWP and JDI specs. (BTW: At one point there were certified implementation that supported JDWP natively, no JVMTI). So I think we should create a follow-up issue to re-examine the spec of the JDWP ReferenceType.Modifiers command, and the JDI methods. Would you be okay with that? ------------- PR Comment: https://git.openjdk.org/valhalla/pull/2526#issuecomment-4673642357
