Is there really anything the breaks using the Boolean constant here? JDK uses Boolean for this use case, and in fact considering that method, I'm curious whether we should deprecate this class at the same time? https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/util/Collections.html#newSetFromMap(java.util.Map)

i move this one to NB 27 too.

Is there really anything the breaks using the Boolean constant here?

Boxed type constructors are deprecated for-removal. At some point, they will be gone, see parent issue.

I wouldn't deprecate the class without also rewriting a big part of its usages (as proof of concept) and it is used across the code base. Some modules produce a few thousands compiler warnings already, it would be good to try to reduce that number first before adding more.

Changing the constant here should be harmless since it never leaves the collection - it is a internal marker.

Is there really anything the breaks using the Boolean constant here?

Boxed type constructors are deprecated for-removal. At some point, they will be gone, see parent issue.

I'm aware of the constructor deprecation. The Boolean.TRUE constant is not deprecated.

not sure if a shared constant can be used here. would have to check what other instances can hit that code path

Well, the above linked JDK implementation uses it, anyway.

Point taken on deprecation without rewriting all the usages! It's useful to look at where we have overlap with later JDK APIs, but also no point in changing things without reason.

i am thinking about changing it into:

    private static final Object PRESENT = new Object();

since this looks less mysterious, otherwise it makes the impression the value or type is relevant to anything.

I was right the first time - https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/Collections.java#L5961 I think using Boolean.TRUE is quite a common pattern for this.

now I remember why I didn't change it to an Object instance.

by using a boolean array as value, it becomes consistent with existing usage. The JDK example is nicer since it uses it as payload and compares with null, this is a slightly different implementation - it compares with the marker object and therefore has element-type-mismatch compiler warning suppression across the file.

edit: WeakSet is public API, we should probably deprecate it anyway while taking the hit of the additional compiler warnings across the project
edit2: also assuming I can trust the find usages feature, nothing uses the resize(int) method of this custom collection, this simplifies migration.

will close this and replace it with a PR which deprecates WeakSet + refactors all usages to JDK equivalents

closing in favor of #8411