<div dir="ltr"><div dir="ltr"><div>Thanks Roger, Remi.</div><div><br></div><div>Just want to understand full picture.</div><div> </div><div>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:</div><div>- >10% less commands,</div><div>- less or same amount of `invokevirtual` related to code duplication in JDK Optional as well,</div><div>- same `invokevirtual` of Optional methods by client code,</div><div>- same value based `hashCode()` and `equals()`,</div><div>- twice shorter code execution passthrough without `ifnull`, additional `<span style="font-variant-ligatures:no-common-ligatures;color:rgb(0,0,0);font-family:Menlo;font-size:11px">getfield`</span> and `goto`.</div><div><br></div><div>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.</div><div><div><br></div><div>Is final only reason? What I missed and where to look under the hood?</div></div><div><br></div><div><div>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()`.</div><div><br></div></div><div>regards, Oleksii</div></div><div dir="ltr"><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Aug 23, 2023 at 9:44 PM Roger Riggs <<a href="mailto:roger.riggs@oracle.com" target="_blank">roger.riggs@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

  
  <div>
    Hi,<br>
    <br>
    Also, Null checks in the VM are very cheap, likely cheaper than a
    virtual dispatch.<br>
    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.<br>
    <br>
    Regardless, Project Valhalla will be converting and optimizing
    Optional to a value class as the project matures.<br>
    <br>
    Thanks, Roger<br>
    <br>
    <br>
    <div>On 8/23/23 11:56 AM, Remi Forax wrote:<br>
    </div>
    <blockquote type="cite">
      
      <div style="font-family:arial,helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
        <div>Sorry, you can not do that.</div>
        <div>Optional is a value based class [1] (see the javadoc) so
          the class has to be final.<br>
        </div>
        <div><br>
        </div>
        <div>And more generally, the API of a classes of OpenJDK will
          not change based on some stylistic issue, OOP or not. <br>
        </div>
        <div><br>
        </div>
        <div>regards,<br>
        </div>
        <div>Rémi Forax<br>
        </div>
        <div><br>
        </div>
        <div>[1]
<a href="https://docs.oracle.com/en/java/javase/20/docs/api/java.base/java/lang/doc-files/ValueBased.html" target="_blank">https://docs.oracle.com/en/java/javase/20/docs/api/java.base/java/lang/doc-files/ValueBased.html</a><br>
        </div>
        <div><br>
        </div>
        <div><br>
        </div>
        <hr id="m_6221270110130973272m_4671643928234183696m_6444779605791983672zwchr">
        <div>
          <blockquote style="border-left:2px solid rgb(16,16,255);margin-left:5px;padding-left:5px;color:rgb(0,0,0);font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt"><b>From:
            </b>"Oleksii Kucheruk" <a href="mailto:iselo+openjdk@raccoons.co" target="_blank"><iselo+openjdk@raccoons.co></a><br>
            <b>To: </b>"core-libs-dev"
            <a href="mailto:core-libs-dev@openjdk.org" target="_blank"><core-libs-dev@openjdk.org></a><br>
            <b>Sent: </b>Wednesday, August 23, 2023 4:43:17 PM<br>
            <b>Subject: </b>RFE: Refactor java.util.Optional and add
            NonNull checks<br>
          </blockquote>
        </div>
        <div>
          <blockquote style="border-left:2px solid rgb(16,16,255);margin-left:5px;padding-left:5px;color:rgb(0,0,0);font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt">
            <div dir="ltr">Hi there.
              <div>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.</div>
              <br>
              <div>I have two solutions:</div>
              <div>1. Completely dynamic that avoids single static
                `EMPTY` instance and unchecked casting of each
                `Optional.empty()`</div>
              <div>2. Preserving original single static `EMPTY` per VM.</div>
              <br>
              <div>Also there are couple methods that throws NPE due
                to calling methods on null-objects and requires to add
                `Objects.requireNonNull(...)`.</div>
              <br>
              <div>OptionalInt, OptionalDouble, OptionalLong could be
                refactored same way even with remove of additional
                boolean variable `isPresent`.</div>
              <br>
              <div>Since I'm new here any guidance will be helpful.</div>
              <div>Thank you in advance.</div>
            </div>
            <br>
          </blockquote>
        </div>
      </div>
    </blockquote>
    <br>
  </div>

</blockquote></div></div>
</div>