Why should Java 8 s Optional not be used in arguments

Question

I ve read on many Web sites Optional should be used as a return type only  and not used in method arguments   I m struggling to find a logical reason why   For example I have a piece of logic which has 2 optional parameters   Therefore I think it would make sense to write my method signature like this  solution 1    public int calculateSomething Optional lt String gt  p1  Optional lt BigDecimal gt  p2          my logic     Many web pages specify Optional should not be used as method arguments  With this in mind  I could use the following method signature and add a clear Javadoc comment to specify that the arguments may be null  hoping future maintainers will read the Javadoc and therefore always carry out null checks prior to using the arguments  solution 2    public int calculateSomething String p1  BigDecimal p2           my logic     Alternatively I could replace my method with four public methods to provide a nicer interface and make it more obvious p1 and p2 are optional  solution 3    public int calculateSomething         calculateSomething null  null      public int calculateSomething String p1        calculateSomething p1  null      public int calculateSomething BigDecimal p2        calculateSomething null  p2      public int calculateSomething String p1  BigDecimal p2           my logic     Now I try writing the code of the class which invokes this piece of logic for each approach   I first retrieve the two input parameters from another object which returns Optionals and then  I invoke calculateSomething   Therefore  if solution 1 is used the calling code would look like this   Optional lt String gt  p1   otherObject getP1    Optional lt BigInteger gt  p2   otherObject getP2    int result   myObject calculateSomething p1  p2     if solution 2 is used  the calling code would look like this   Optional lt String gt  p1   otherObject getP1    Optional lt BigInteger gt  p2   otherObject getP2    int result   myObject calculateSomething p1 orElse null   p2 orElse null      if solution 3 is applied  I could use the code above or I could use the following  but it s significantly more code    Optional lt String gt  p1   otherObject getP1    Optional lt BigInteger gt  p2   otherObject getP2    int result  if  p1 isPresent          if  p2 isPresent              result   myObject calculateSomething p1  p2         else           result   myObject calculateSomething p1           else       if  p2 isPresent              result   myObject calculateSomething p2         else           result   myObject calculateSomething              So my question is  Why is it considered bad practice to use Optionals as method arguments  see solution 1    It looks like the most readable solution to me and makes it most obvious that the parameters could be empty null to future maintainers    I m aware the designers of Optional intended it to only be used as a return type  but I can t find any logical reasons not to use it in this scenario

User · Answer

I believe the reson of being is you have to first check whether or not Optional is null itself and then try to evaluate value it wraps  Too many unnecessary validations

User · Answer

This advice is a variant of the  be as unspecific as possible regarding inputs and as specific as possible regarding outputs  rule of thumb   Usually if you have a method that takes a plain non-null value  you can map it over the Optional  so the plain version is strictly more unspecific regarding inputs  However there are a bunch of possible reasons why you would want to require an Optional argument nonetheless    you want your function to be used in conjunction with another API that returns an Optional Your function should return something other than an empty Optional if the given value is empty You think Optional is so awesome that whoever uses your API should be required to learn about it  -

User · Answer

Let s make something perfectly clear  in other languages  there is no general recommendation against the use of a Maybe type as a field type  a constructor parameter type  a method parameter type  or a function parameter type  So if you  quot shouldn t quot  use Optional as a parameter type in Java  the reason is specific to Optional  to Java  or to both  Reasoning that might apply to other Maybe types  or other languages  is probably not valid here  Per Brian Goetz    W e did have a clear intention when adding  Optional   and it was not to be a general purpose Maybe type  as much as many people would have liked us to do so  Our intention was to provide a limited mechanism for library method return types where there needed to be a clear way to represent  quot no result quot   and using null for such was overwhelmingly likely to cause errors  For example  you probably should never use it for something that returns an array of results  or a list of results  instead return an empty array or list  You should almost never use it as a field of something or a method parameter   So the answer is specific to Optional  it isn t  quot a general purpose Maybe type quot   as such  it is limited  and it may be limited in ways that limit its usefulness as a field type or a parameter type  That said  in practice  I ve rarely found using Optional as a field type or a parameter type to be an issue  If Optional  despite its limitations  works as a parameter type or a field type for your use case  use it

User · Answer

First of all  if you re using method 3  you can replace those last 14 lines of code with this   int result   myObject calculateSomething p1 orElse null   p2 orElse null     The four variations you wrote are convenience methods  You should only use them when they re more convenient  That s also the best approach  That way  the API is very clear which members are necessary and which aren t  If you don t want to write four methods  you can clarify things by how you name your parameters    public int calculateSomething String p1OrNull  BigDecimal p2OrNull   This way  it s clear that null values are allowed   Your use of p1 orElse null  illustrates how verbose our code gets when using Optional  which is part of why I avoid it  Optional was written for functional programming  Streams need it  Your methods should probably never return Optional unless it s necessary to use them in functional programming  There are methods  like Optional flatMap   method  that requires a reference to a function that returns Optional  Here s its signature   public  lt U gt  Optional lt U gt  flatMap Function lt   super T    extends Optional lt   extends U gt  gt  mapper   So that s usually the only good reason for writing a method that returns Optional  But even there  it can be avoided  You can pass a getter that doesn t return Optional to a method like flatMap    by wrapping it in a another method that converts the function to the right type  The wrapper method looks like this   public static  lt T  U gt  Function lt   super T  Optional lt U gt  gt  optFun Function lt T  U gt  function        return t - gt  Optional ofNullable function apply t        So suppose you have a getter like this  String getName    You can t pass it to flatMap like this    opt flatMap Widget  getName     Won t work   But you can pass it like this   opt flatMap optFun Widget  getName      Works great   Outside of functional programming  Optionals should be avoided    Brian Goetz said it best when he said this   The reason Optional was added to Java is because this   return Arrays asList enclosingInfo getEnclosingClass   getDeclaredMethods         stream        filter m - gt  Objects equals m getName    enclosingInfo getName         filter m - gt   Arrays equals m getParameterTypes    parameterClasses        filter m - gt  Objects equals m getReturnType    returnType        findFirst        getOrThrow    - gt  new InternalError          is cleaner than this   Method matching       Arrays asList enclosingInfo getEnclosingClass   getDeclaredMethods         stream        filter m - gt  Objects equals m getName    enclosingInfo getName         filter m - gt   Arrays equals m getParameterTypes    parameterClasses        filter m - gt  Objects equals m getReturnType    returnType        getFirst    if  matching    null    throw new InternalError  Enclosing method not found    return matching

User · Answer

Oh  those coding styles are to be taken with a bit of salt       Passing an Optional result to another method  without any semantic analysis  leaving that to the method  is quite alright   -  Using Optional parameters causing conditional logic inside the methods is literally contra-productive   -  Needing to pack an argument in an Optional  is suboptimal for the compiler  and does an unnecessary wrapping   -  In comparison to nullable parameters Optional is more costly   -  The risk of someone passing the Optional as null in actual parameters   In general  Optional unifies two states  which have to be unraveled  Hence better suited for result than input  for the complexity of the data flow

User · Answer

There are almost no good reasons for not using Optional as parameters   The arguments against this rely on arguments from authority  see Brian Goetz - his argument is we can t enforce non null optionals  or that the Optional arguments may be null  essentially the same argument    Of course  any reference in Java can be null  we need to encourage rules being enforced by the compiler  not programmers memory  which is problematic and does not scale      Functional programming languages encourage Optional parameters   One of the best ways of using this is to have multiple optional parameters and using liftM2 to use a function assuming the parameters are not empty and returning an optional  see http   www functionaljava org javadoc 4 4 functionaljava fj data Option html liftM2-fj F-    Java 8 has unfortunately implemented a very limited library supporting optional   As Java programmers we should only be using null to interact with legacy libraries

User · Answer

Maybe I will provoke a bunch of down-votes and negative comments  but    I cannot stand  Disclaimer  what I write below is not really an answer to the original question  but rather my thoughts on the topic  And the only source for it is my thoughts and my experience  with Java and other languages   First let s check  why would anyone like to use Optional at all  For me the reason is simple  unlike other languages java does not have built-in capability to define variable  or type  as nullable or not  All  quot object quot -variables are nullable and all primitive-types are not  For the sake of simplicity let t not consider primitive types in further discussion  so I will claim simply that all variables are nullable  Why would one need to declare variables as nullable non-nullable  Well  the reason for me is  explicit is always better  than implicit  Besides having explicit decoration  e g  annotation or type  could help static analyzer  or compiler  to catch some null-pointer related issues  Many people argue in the comments above  that functions do not need to have nullable arguments  Instead overloads should be used  But such statement is only good in a school-book  In real life there are different situations  Consider class  which represents settings of some system  or personal data of some user  or in fact any composite data-structure  which contains lots of fields - many of those with repeated types  and some of the fields are mandatory while others are optional  In such cases inheritance constructor overloads do not really help  Random example  Let s say  we need to collect data about people  But some people don t want to provide all the data  And of course this is POD  so basically type with value-semantics  so I want it to be more or less immutable  no setters   class PersonalData       private final String name     mandatory     private final int age     mandatory     private final Address homeAddress     optional     private final PhoneNumber phoneNumber     optional  Dedicated class to handle constraints     private final BigDecimal income     optional             further fields         How many constructor-  or factory-  overloads do we need to handle all cases        without nullable arguments  If I am not mistaken  8  And what if we have more optional        fields                 So  IMO discussion above shows  that even though mostly we can survive without nullable arguments  but sometimes it is not really feasible  Now we come to the problem  if some of the arguments are nullable and others are not  how do we know  which one  Approach 1  All arguments are nullable  according to java standrd  except primitive types   So we check all of them  Result  code explodes with checks  which are mostly unneeded  because as we discussed above almost all of the time we can go ahead with nullable variables  and only in some rare cases  quot nullables quot  are needed  Approach 2  Use documentation and or comments to describe  which arguments fields are nullable and which not  Result  It does not really work  People are lazy to write and read the docs  Besides lately the trend is  that we should avoid writing documentation in favor of making the code itself self-describing  Besides all the reasoning about modifying the code and forgeting to modify the documentation is still valid  Approach 3   Nullable  NonNull etc    I personally find them to be nice  But there are certain disadvantages    e g  they are only respected by external tools  not the compiler   the worst of which is that they are not standard  which means  that 1  I would need to add external dependency to my project to benefit from them  and 2  The way they are treated by different systems are not uniform  As far as I know  they were voted out of official Java standard  and I don t know if there are any plans to try again   Approach 4  Optional lt  gt   The disadvantages are already mentioned in other comments  the worst of which is  IMO  performance penalty  Also it adds a bit of boilerplate  even thoough I personally find  use of Optional empty   and Optional of   to be not so bad  The advantages are obvious   It is part of the Java standard  It makes obvious to the reader of the code  or to the user of API   that these arguments may be null  Moreover  it forces both  user of the API and developer of the method to aknolage this fact by explicitly wrapping unwrapping the values  which is not the case  when annotations like  Nullable etc  are used    So in my point  there is no black-and-white in regard of any methodology including this one  I personally ended up with the following guidelines and conventions  which are still not strict rules    Inside my own code all the variables must be not-null  but probably Optional lt  gt    If I have a method with one or two optional arguments I try to redesign it using overloads  inheritance etc  If I cannot find the solution in reasonable time  I start thinking  if the performance is critical  i e  if there are millions of the objects to be processed   Usually it is not the case  If not  I use Optional as argument types and or field types   There are still grey areas  where these conventions do not work   We need high performance  e g  processing of huge amounts of data  so that total execution time is very large  or situations when throughput is critical   In this cases performance penalty introduced by Optional may be really unwanted  We are on the boundary of the code  which we write ourselves  e g   we read from the DB  Rest Endpoint  parse file etc  Or we just use some external libraries  which do not follow our conventions  so again  we should be careful     By the way  the last two cases can also be the source of need in the optional fields arguments  I e  when the structure of the data is not developed by ourselves  but is imposed by some external interfaces  db-schemas etc    At the end  I think  that one should think about the problem  which is being solved  and try to find the appropriate tools  If Optional lt  gt  is appropriate  then I see no reason not to use it  Edit  Approach 5  I used this one recently  when I could not use Optional  The idea is simply to use naming convention for method arguments and class variables  I used  quot maybe quot -prefix  so that if e g   quot url quot  argument is nullable  then it becomes maybeUrl  The advantage is that it slightly improves understandability of the intent  and does not have disadvantages of other approaches  like external dependencies or performance penalty   But there are also drawbacks  like  there is no tooling to support this convention  your IDE will not show you any warning  if you access  quot maybe quot -variable without first checking it   Another problem is that it only helps  when applied consistently by all people working on the project

User · Answer

My take is that Optional should be a Monad and these are not conceivable in Java   In functional programming you deal with pure and higher order functions that take and compose their arguments only based on their  business domain type   Composing functions that feed on  or whose computation should be reported to  the real-world  so called side effects  requires the application of functions that take care of automatically unpacking the values out of the monads representing the outside world  State  Configuration  Futures  Maybe  Either  Writer  etc      this is called lifting  You can think of it as a kind of separation of concerns   Mixing these two levels of abstraction doesn t facilitate legibility so you re better off just avoiding it

User · Answer

Accepting Optional as parameters causes unnecessary wrapping at caller level   For example in the case of   public int calculateSomething Optional lt String gt  p1  Optional lt BigDecimal gt  p2      Suppose you have two not-null strings  ie  returned from some other method    String p1    p1    String p2    p2     You re forced to wrap them in Optional even if you know they are not Empty   This get even worse when you have to compose with other  mappable  structures  ie  Eithers   Either lt Error  String gt  value   compute   right   map  s  - gt  calculateSomething   lt  here you have to wrap the parameter in a Optional even if you know it s a    string  gt       ref      methods shouldn t expect Option as parameters  this is almost always a   code smell that indicated a leakage of control flow from the caller to   the callee  it should be responsibility of the caller to check the   content of an Option   ref  https   github com teamdigitale digital-citizenship-functions pull 148 discussion r170862749

User · Answer

Another reason to be carefully when pass an Optional as parameter is that a method should do one thing    If you pass an Optional param you could favor do more than one thing  it could be similar to pass a boolean param   public void method Optional lt MyClass gt  param         if param isPresent                 do something        else              do some other

User · Answer

This is because we have different requirements to an API user and an API developer    A developer is responsible for providing a precise specification and a correct implementation  Therefore if the developer is already aware that an argument is optional the implementation must deal with it correctly  whether it being a null or an Optional  The API should be as simple as possible to the user  and null is the simplest   On the other hand  the result is passed from the API developer to the user  However the specification is complete and verbose  there is still a chance that the user is either unaware of it or just lazy to deal with it  In this case  the Optional result forces the user to write some extra code to deal with a possible empty result

User · Answer

One more approach  what you can do is      get your optionals first Optional lt String gt  p1   otherObject getP1    Optional lt BigInteger gt  p2   otherObject getP2        bind values to a function Supplier lt Integer gt  calculatedValueSupplier      - gt       your logic here using both optional as state    Once you have built a function supplier in this case  you will be able to pass this around as any other variable and would be able to call it using  calculatedValueSupplier apply      The idea here being whether you have got optional value or not will be internal detail of your function and will not be in parameter  Thinking functions when thinking about optional as parameter is actually very useful technique that I have found   As to your question whether you should actually do it or not is based on your preference  but as others said it makes your API ugly to say the least

User · Answer

Check out the JavaDoc in JDK10  https   docs oracle com javase 10 docs api java util Optional html  an API note is added      API Note    Optional is primarily intended for use as a method return type where there is a clear need to represent  no result   and where using null is likely to cause errors

User · Answer

This seems a bit silly to me  but the only reason I can think of is that object arguments in method parameters already are optional in a way - they can be null  Therefore forcing someone to take an existing object and wrap it in an optional is sort of pointless    That being said  chaining methods together that take return optionals is a reasonable thing to do  e g  Maybe monad

User · Answer

At first  I also preferred to pass Optionals as parameter  but if you switch from an API-Designer perspective to a API-User perspective  you see the disadvantages    For your example  where each parameter is optional  I would suggest to change the calculation method into an own class like follows    Optional lt String gt  p1   otherObject getP1    Optional lt BigInteger gt  p2   otherObject getP2     MyCalculator mc   new MyCalculator    p1 map mc  setP1   p2 map mc  setP2   int result   mc calculate

User · Answer

I think that is because you usually write your functions to manipulate data  and then lift it to Optional using map and similar functions  This adds the default Optional behavior to it  Of course  there might be cases  when it is necessary to write your own auxilary function that works on Optional

User · Answer

I know that this question is more about opinion rather than hard facts  But I recently moved from being a  net developer to a java one  so I have only recently joined the Optional party  Also  I d prefer to state this as a comment  but since my point level does not allow me to comment  I am forced to put this as an answer instead   What I have been doing  which has served me well as a rule of thumb  Is to use Optionals for return types  and only use Optionals as parameters  if I require both the value of the Optional  and weather or not the Optional had a value within the method   If I only care about the value  I check isPresent before calling the method  if I have some kind of logging or different logic within the method that depends on if the value exists  then I will happily pass in the Optional

User · Answer

The pattern with Optional is for one to avoid returning null   It s still perfectly possible to pass in null to a method   While these aren t really official yet  you can use JSR-308 style annotations to indicate whether or not you accept null values into the function   Note that you d have to have the right tooling to actually identify it  and it d provide more of a static check than an enforceable runtime policy  but it would help   public int calculateSomething  NotNull final String p1   NotNull final String p2

User · Answer

Optionals aren t designed for this purpose  as explained nicely by Brian Goetz   You can always use  Nullable to denote that a method argument can be null  Using an optional does not really enable you to write your method logic more neatly

User · Answer

The best post I ve seen on the topic was written by Daniel Olszewski      Although it might be tempting to consider Optional for not mandatory method parameters  such a solution pale in comparison with other possible alternatives  To illustrate the problem  examine the following constructor declaration   public SystemMessage String title  String content  Optional lt Attachment gt  attachment           assigning field values         At first glance it may look as a right design decision  After all  we   explicitly marked the attachment parameter as optional  However  as   for calling the constructor  client code can become a little bit   clumsy   SystemMessage withoutAttachment   new SystemMessage  title    content   Optional empty     Attachment attachment   new Attachment    SystemMessage withAttachment   new SystemMessage  title    content   Optional ofNullable attachment          Instead of providing clarity  the factory methods of the Optional   class only distract the reader  Note there   s only one optional   parameter  but imagine having two or three  Uncle Bob definitely   wouldn   t be proud of such code       When a method can accept optional parameters  it   s preferable to adopt the well-proven approach and design such case using method   overloading  In the example of the SystemMessage class  declaring   two separate constructors are superior to using Optional   public SystemMessage String title  String content        this title  content  null      public SystemMessage String title  String content  Attachment attachment           assigning field values         That change makes client code much simpler and easier to read   SystemMessage withoutAttachment   new SystemMessage  title    content    Attachment attachment   new Attachment    SystemMessage withAttachment   new SystemMessage  title    content   attachment

[java] Why should Java 8's Optional not be used in arguments

Examples related to java

Examples related to java-8

Examples related to optional