On Tue, 23 Feb 2021 16:46:06 GMT, Andrey Turbanov <github.com+741251+turban...@openjdk.org> wrote:
> There are 2 separate reads of fields. First can return non-null value, while > second still can get null Can this really happen? If this `version` field has been updated, its value is definitely no longer `null`. And before the second field read the field is always set to a non-null value on the current thread. I fail to understand why the second read can still yield a null given the fact that the current thread has updated it to a non-null value and other threads may have updated it to a non-null value. >> src/java.base/share/classes/java/lang/Runtime.java line 824: >> >>> 822: VersionProps.pre(), VersionProps.build(), >>> 823: VersionProps.optional()); >>> 824: version = v; >> >> Can't this just be `return version = new Version(...` than reassigning to a >> local variable for no good? > > It's matter of style. I've seen both styles are acceptable in JDK codebase. I > personally prefer placing assigning each variable into separate lines. Doesn't using `return version = new Version(...` allow one local variable to be effectively final and save two aload/astore opcodes? Guess jvm optimizes it ------------- PR: https://git.openjdk.java.net/jdk/pull/2691
