Details

    • Subcomponent:
    • Understanding:
      Fix Understood

      Description

      Optional.get() is an "attractive nuisance" and is too tempting for programmers, leading to frequent errors. People don't expect a getter to throw an exception. A replacement API for Optional.get() with equivalent semantics should be added. The specification for Optional.get() should direct readers to the new API. However, Optional.get() shouldn't be deprecated just yet; deprecation is covered by the follow-on issue JDK-8160606.

      The current proposal for replacement is a no-arg Optional.orElseThrow(). This fits well within the family of or-else methods, and it's closely related to orElseThrow(exSupplier), as if providing a NoSuchElementException supplier as a default.

        Issue Links

          Activity

          smarks Stuart Marks created issue -
          smarks Stuart Marks made changes -
          Field Original Value New Value
          Status New [ 10000 ] Open [ 1 ]
          smarks Stuart Marks made changes -
          Parent JDK-8065614 [ 4756830 ]
          Issue Type Enhancement [ 7 ] Sub-task [ 5 ]
          smarks Stuart Marks made changes -
          Summary deprecate Optional.get() and add an equivalent replacement deprecate Optional.get() and replace it with Optional.getWhenPresent()
          smarks Stuart Marks made changes -
          Description Optional.get() is an "attractive nuisance" and is too tempting for programmers, leading to frequent errors. It should be deprecated and replaced with a more descriptively named method that has the same semantics. Optional.get() is an "attractive nuisance" and is too tempting for programmers, leading to frequent errors. It should be deprecated and replaced with a more descriptively named method that has the same semantics.

          The current proposal for replacement is Optional.getWhenPresent(). This name reinforces the assumption the caller is making, namely that the value is present. Alternatives such as Optional.getOrThrow() are confusing since the other "or-throw" methods take an exception supplier, and this one does not.
          smarks Stuart Marks made changes -
          Labels api-grab-bag api-grab-bag noreg-jck
          smarks Stuart Marks made changes -
          Link This issue relates to JDK-8157055 [ JDK-8157055 ]
          smarks Stuart Marks made changes -
          Link This issue relates to JDK-8160606 [ JDK-8160606 ]
          smarks Stuart Marks made changes -
          Description Optional.get() is an "attractive nuisance" and is too tempting for programmers, leading to frequent errors. It should be deprecated and replaced with a more descriptively named method that has the same semantics.

          The current proposal for replacement is Optional.getWhenPresent(). This name reinforces the assumption the caller is making, namely that the value is present. Alternatives such as Optional.getOrThrow() are confusing since the other "or-throw" methods take an exception supplier, and this one does not.
          Optional.get() is an "attractive nuisance" and is too tempting for programmers, leading to frequent errors. It should be deprecated and replaced with a more descriptively named method that has the same semantics.

          The current proposal for replacement is Optional.getWhenPresent(). This name reinforces the assumption the caller is making, namely that the value is present. Alternatives include getOrThrow(), orElseThrow(), and possibly uncheckedGet(). Something like Optional.getOrThrow() may be confusing since the other "or-throw" methods take an exception supplier while this one does not.
          smarks Stuart Marks made changes -
          Summary deprecate Optional.get() and replace it with Optional.getWhenPresent() add replacement for Optional.get()
          smarks Stuart Marks made changes -
          Description Optional.get() is an "attractive nuisance" and is too tempting for programmers, leading to frequent errors. It should be deprecated and replaced with a more descriptively named method that has the same semantics.

          The current proposal for replacement is Optional.getWhenPresent(). This name reinforces the assumption the caller is making, namely that the value is present. Alternatives include getOrThrow(), orElseThrow(), and possibly uncheckedGet(). Something like Optional.getOrThrow() may be confusing since the other "or-throw" methods take an exception supplier while this one does not.
          Optional.get() is an "attractive nuisance" and is too tempting for programmers, leading to frequent errors. A replacement API for Optional.get() with equivalent semantics should be added. The specification for Optional.get() should direct readers to the new API. However, Optional.get() shouldn't be deprecated just yet, because it would create too many deprecation warnings. Deprecation should be handled by the follow-on issue JDK-8160606.

          The current proposal for replacement is Optional.getWhenPresent(). This name reinforces the assumption the caller is making, namely that the value is present. Alternatives include getOrThrow(), orElseThrow(), and possibly uncheckedGet(). Something like Optional.getOrThrow() may be confusing since the other "or-throw" methods take an exception supplier while this one does not.
          bchristi Brent Christian made changes -
          Labels api-grab-bag noreg-jck api-grab-bag jep-277 noreg-jck
          smarks Stuart Marks made changes -
          smarks Stuart Marks made changes -
          smarks Stuart Marks made changes -
          Priority P4 [ 4 ] P3 [ 3 ]
          smarks Stuart Marks made changes -
          Fix Version/s tbd_major [ 11972 ]
          smarks Stuart Marks made changes -
          Summary add replacement for Optional.get() (opt) add replacement for Optional.get()
          smarks Stuart Marks made changes -
          Summary (opt) add replacement for Optional.get() (opt) add no-arg orElseThrow() as preferred alternative to get()
          Hide
          smarks Stuart Marks added a comment - - edited
          A previous proposal for replacement is Optional.getWhenPresent(). This name reinforces the assumption the caller is making, namely that the value is present. However, the "when" seemed to connote time, not the notion of definiteness, misleading people into thinking that it did something like blocking until a value was present. Alternatives include getOrThrow() and orElseThrow().

          Previous review thread of proposal that included deprecation of Optional.get():

              http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-April/040484.html
          Show
          smarks Stuart Marks added a comment - - edited A previous proposal for replacement is Optional.getWhenPresent(). This name reinforces the assumption the caller is making, namely that the value is present. However, the "when" seemed to connote time, not the notion of definiteness, misleading people into thinking that it did something like blocking until a value was present. Alternatives include getOrThrow() and orElseThrow(). Previous review thread of proposal that included deprecation of Optional.get():      http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-April/040484.html
          smarks Stuart Marks made changes -
          Description Optional.get() is an "attractive nuisance" and is too tempting for programmers, leading to frequent errors. A replacement API for Optional.get() with equivalent semantics should be added. The specification for Optional.get() should direct readers to the new API. However, Optional.get() shouldn't be deprecated just yet, because it would create too many deprecation warnings. Deprecation should be handled by the follow-on issue JDK-8160606.

          The current proposal for replacement is Optional.getWhenPresent(). This name reinforces the assumption the caller is making, namely that the value is present. Alternatives include getOrThrow(), orElseThrow(), and possibly uncheckedGet(). Something like Optional.getOrThrow() may be confusing since the other "or-throw" methods take an exception supplier while this one does not.
          Optional.get() is an "attractive nuisance" and is too tempting for programmers, leading to frequent errors. A replacement API for Optional.get() with equivalent semantics should be added. The specification for Optional.get() should direct readers to the new API. However, Optional.get() shouldn't be deprecated just yet, because it would create too many deprecation warnings. Deprecation should be handled by the follow-on issue JDK-8160606.

          The current proposal for replacement is a no-arg Optional.orElseThrow(). This fits well within the family of or-else methods, and it's closely related to orElseThrow(exSupplier), as if providing a NoSuchElementException supplier as a default.
          smarks Stuart Marks made changes -
          Description Optional.get() is an "attractive nuisance" and is too tempting for programmers, leading to frequent errors. A replacement API for Optional.get() with equivalent semantics should be added. The specification for Optional.get() should direct readers to the new API. However, Optional.get() shouldn't be deprecated just yet, because it would create too many deprecation warnings. Deprecation should be handled by the follow-on issue JDK-8160606.

          The current proposal for replacement is a no-arg Optional.orElseThrow(). This fits well within the family of or-else methods, and it's closely related to orElseThrow(exSupplier), as if providing a NoSuchElementException supplier as a default.
          Optional.get() is an "attractive nuisance" and is too tempting for programmers, leading to frequent errors. People don't expect a getter to throw an exception. A replacement API for Optional.get() with equivalent semantics should be added. The specification for Optional.get() should direct readers to the new API. However, Optional.get() shouldn't be deprecated just yet, because it would create too many deprecation warnings. Deprecation should be handled by the follow-on issue JDK-8160606.

          The current proposal for replacement is a no-arg Optional.orElseThrow(). This fits well within the family of or-else methods, and it's closely related to orElseThrow(exSupplier), as if providing a NoSuchElementException supplier as a default.
          smarks Stuart Marks made changes -
          Description Optional.get() is an "attractive nuisance" and is too tempting for programmers, leading to frequent errors. People don't expect a getter to throw an exception. A replacement API for Optional.get() with equivalent semantics should be added. The specification for Optional.get() should direct readers to the new API. However, Optional.get() shouldn't be deprecated just yet, because it would create too many deprecation warnings. Deprecation should be handled by the follow-on issue JDK-8160606.

          The current proposal for replacement is a no-arg Optional.orElseThrow(). This fits well within the family of or-else methods, and it's closely related to orElseThrow(exSupplier), as if providing a NoSuchElementException supplier as a default.
          Optional.get() is an "attractive nuisance" and is too tempting for programmers, leading to frequent errors. People don't expect a getter to throw an exception. A replacement API for Optional.get() with equivalent semantics should be added. The specification for Optional.get() should direct readers to the new API. However, Optional.get() shouldn't be deprecated just yet; deprecation is covered by the follow-on issue JDK-8160606.

          The current proposal for replacement is a no-arg Optional.orElseThrow(). This fits well within the family of or-else methods, and it's closely related to orElseThrow(exSupplier), as if providing a NoSuchElementException supplier as a default.
          smarks Stuart Marks made changes -
          Status Open [ 1 ] In Progress [ 3 ]
          Understanding Fix Understood [ 10001 ]
          Hide
          smarks Stuart Marks added a comment -
          Show
          smarks Stuart Marks added a comment - Review thread of updated proposal: http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-December/050465.html
          smarks Stuart Marks made changes -
          Fix Version/s 10 [ 16302 ]
          Fix Version/s tbd_major [ 11972 ]
          smarks Stuart Marks made changes -
          Link This issue csr for JDK-8193280 [ JDK-8193280 ]

            People

            • Assignee:
              smarks Stuart Marks
              Reporter:
              smarks Stuart Marks
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated: