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.ri...@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+open...@raccoons.co> > <iselo+open...@raccoons.co> > *To: *"core-libs-dev" <core-libs-dev@openjdk.org> > <core-libs-dev@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. > > >
