RFE: Refactor java.util.Optional and add NonNull checks

[Oleksii Kucheruk]

Thanks Roger, Remi.

Just want to understand full picture.

For both solutions, private static final nested class and dynamic anonymous
overloading, based on dipole/boolean pattern where all methods has opposite
charge, JVM produces separate code for classes that in total has:
- >10% less commands,
- less or same amount of `invokevirtual` related to code duplication in JDK
Optional as well,
- same `invokevirtual` of Optional methods by client code,
- same value based `hashCode()` and `equals()`,
- twice shorter code execution passthrough without `ifnull`, additional `
getfield` and `goto`.

The difference is absence of final class of Optional that actually not
declare accessible constructors. The one property of value-based classes
from javadoc is potentially violated.

Is final only reason? What I missed and where to look under the hood?

I believe that an empty optional does not require `getfield`, a present
optional does not require `ifnull` checks. The decision is already made by
`Optional.of()` or `Optional.ofNullable()`.

regards, Oleksii

On Wed, Aug 23, 2023 at 9:44 PM Roger Riggs <roger.riggs at oracle.com> wrote:

> Hi,
>
> Also, Null checks in the VM are very cheap, likely cheaper than a virtual
> dispatch.
> Adding calls to requireNonNull is almost always a no-op, except for adding
> a variable name to the exception it still throws NPE. A frequently used
> class like Optional will be compiled to machine code and the number of byte
> codes is not an important metric.
>
> Regardless, Project Valhalla will be converting and optimizing Optional to
> a value class as the project matures.
>
> Thanks, Roger
>
>
> On 8/23/23 11:56 AM, Remi Forax wrote:
>
> Sorry, you can not do that.
> Optional is a value based class [1] (see the javadoc) so the class has to
> be final.
>
> And more generally, the API of a classes of OpenJDK will not change based
> on some stylistic issue, OOP or not.
>
> regards,
> Rémi Forax
>
> [1]
> https://docs.oracle.com/en/java/javase/20/docs/api/java.base/java/lang/doc-files/ValueBased.html
>
>
> ------------------------------
>
> *From: *"Oleksii Kucheruk" <iselo+openjdk at raccoons.co>
> <iselo+openjdk at raccoons.co>
> *To: *"core-libs-dev" <core-libs-dev at openjdk.org>
> <core-libs-dev at openjdk.org>
> *Sent: *Wednesday, August 23, 2023 4:43:17 PM
> *Subject: *RFE: Refactor java.util.Optional and add NonNull checks
>
> Hi there.
> I have found that `java.util.Optional` is written procedural style and has
> `ifnonnull`  checks in each method. I propose to refactor `Optional` in
> accordance to OOP-style. This will eliminates all unnecessary
> `if`-statements, removes duplications and reduces bytecode size more then
> twice.
>
> I have two solutions:
> 1. Completely dynamic that avoids single static `EMPTY` instance and
> unchecked casting of each `Optional.empty()`
> 2. Preserving original single static `EMPTY` per VM.
>
> Also there are couple methods that throws NPE due to calling methods on
> null-objects and requires to add `Objects.requireNonNull(...)`.
>
> OptionalInt, OptionalDouble, OptionalLong could be refactored same way
> even with remove of additional boolean variable `isPresent`.
>
> Since I'm new here any guidance will be helpful.
> Thank you in advance.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230824/27cc702a/attachment-0001.htm>