On Mon, 5 May 2025 13:41:22 GMT, Per Minborg <pminb...@openjdk.org> wrote:
> This sketch shows how "Stable Updaters" can be used to create stable
> computations of `@Stable` fields. Only one updater is needed per class,
> similar to `AtomicIntegerFieldUpdater`.
src/java.base/share/classes/java/lang/reflect/Method.java line 105:
> 103: public int applyAsInt(Method method) {
> 104: return
> method.getDeclaringClass().getName().hashCode() ^ method.getName()
> 105: .hashCode();
Suggestion:
return method.getDeclaringClass().getName().hashCode()
^ method.getName().hashCode();
code indentation alignment
src/java.base/share/classes/jdk/internal/lang/stable/StableFieldUpdater.java
line 330:
> 328: throw illegalField("non final fields", field);
> 329: }
> 330: sun.reflect.misc.ReflectUtil.ensureMemberAccess(
Why not use import here but use the full path?
src/java.base/share/classes/jdk/internal/lang/stable/StableFieldUpdater.java
line 350:
> 348: }
> 349: final Field[] fields = holderType.getDeclaredFields();
> 350: for (Field f : fields) {
Suggestion:
for (Field f : holderType.getDeclaredFields()) {
The local variable fields is only used once and can be simplified
test/jdk/java/lang/StableValue/StableFieldUpdaterExampleTest.java line 132:
> 130: Objects.equals(this.bar, that.bar) &&
> 131: Objects.equals(this.baz, that.baz);
> 132: }
Suggestion:
public boolean equals(Object o) {
return o instanceof Foo that
&& Objects.equals(this.bar, that.bar)
&& Objects.equals(this.baz, that.baz);
}
In most cases in JDK code, the operator `&&` is placed in front.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/25040#discussion_r2075244737
PR Review Comment: https://git.openjdk.org/jdk/pull/25040#discussion_r2075229805
PR Review Comment: https://git.openjdk.org/jdk/pull/25040#discussion_r2075234183
PR Review Comment: https://git.openjdk.org/jdk/pull/25040#discussion_r2075239678
