[lworld] RFR: 8373202: [lworld] ObjectReference.equals should follow == semantics for value objects [v5]

[Chris Plummer]

On Thu, 22 Jan 2026 21:50:27 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> Updated implementation of ObjectReference.equals and ObjectReference.hashCode to comply the spec for value objects.
>> Added the test for value object ctor debugging, the test verifies the behaviour is expected.
>> There is an issue with instance filter, it till be fixed separately (it's not yet clear how it would be better to fix it)
>> 
>> testing: tier1..4, hs-tier5-svc
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   feedback

src/jdk.jdi/share/classes/com/sun/tools/jdi/VirtualMachineImpl.java line 838:

> 836:     }
> 837: 
> 838:     public boolean supportsValueClasses() {

What happens if not running in preview mode? Value classes are not supported in that case, but as implemented this API will say they are supported, leading to isValueClass() looking at modifiers in a way that is not compatible when value classes are not supported.

JDI didn't really run into this type of problem with virtual thread support. It did modify a couple of new public APIs with:

    @PreviewFeature(feature = PreviewFeature.Feature.VIRTUAL_THREADS)

However, I don't see how that helps us here. It seems we need to query the debug agent to find out if value classes are supported. There's no good way to do that. Is there any way for JDI to somewhat detect that value class support is supported (preview mode is enabled).

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/1834#discussion_r2719402224