Why no public constructor for Optional in java?











up vote
19
down vote

favorite
4












Why does Optional have methods like of() and ofNullable() instead of a public constructor?










share|improve this question




















  • 3




    Because empty is a singleton for memory efficiency.
    – Minn
    Dec 2 at 11:51






  • 8




    Because how an Optional is created is an implementation detail
    – ZhekaKozlov
    Dec 2 at 11:57















up vote
19
down vote

favorite
4












Why does Optional have methods like of() and ofNullable() instead of a public constructor?










share|improve this question




















  • 3




    Because empty is a singleton for memory efficiency.
    – Minn
    Dec 2 at 11:51






  • 8




    Because how an Optional is created is an implementation detail
    – ZhekaKozlov
    Dec 2 at 11:57













up vote
19
down vote

favorite
4









up vote
19
down vote

favorite
4






4





Why does Optional have methods like of() and ofNullable() instead of a public constructor?










share|improve this question















Why does Optional have methods like of() and ofNullable() instead of a public constructor?







java java-8 optional






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Dec 2 at 14:11









Boann

36.6k1287121




36.6k1287121










asked Dec 2 at 11:48









Gopal S Akshintala

1,0331714




1,0331714








  • 3




    Because empty is a singleton for memory efficiency.
    – Minn
    Dec 2 at 11:51






  • 8




    Because how an Optional is created is an implementation detail
    – ZhekaKozlov
    Dec 2 at 11:57














  • 3




    Because empty is a singleton for memory efficiency.
    – Minn
    Dec 2 at 11:51






  • 8




    Because how an Optional is created is an implementation detail
    – ZhekaKozlov
    Dec 2 at 11:57








3




3




Because empty is a singleton for memory efficiency.
– Minn
Dec 2 at 11:51




Because empty is a singleton for memory efficiency.
– Minn
Dec 2 at 11:51




8




8




Because how an Optional is created is an implementation detail
– ZhekaKozlov
Dec 2 at 11:57




Because how an Optional is created is an implementation detail
– ZhekaKozlov
Dec 2 at 11:57












4 Answers
4






active

oldest

votes

















up vote
29
down vote



accepted










From Joshua Bloch effective Java, Chapter 2. Creating and Destroying
Objects, 1 Item:




Consider static factory methods instead of constructors




Why?




One advantage of static factory methods is that, unlike constructors,
they have names.




With static factory methods we can specify some instantiation behavior in the method definition. This makes the API easier to use and we prevent clients from calling wrong constructors.



For instance here: In Optional.ofNullable -> we allow null value be passed to instantiate the Optional, in Optional.of null value is not allowed and throw exception. We could not use the constructor here.



private Optional(T value) {
this.value = Objects.requireNonNull(value); //this throws NullPointerException
}
public static <T> Optional<T> of(T value) {
return new Optional<>(value);
}
public static <T> Optional<T> ofNullable(T value) {
return value == null ? empty() : of(value);
}


Another advantage (already mentioned):




A second advantage of static factory methods is that, unlike
constructors, they are not required to create a new object each time
they’re invoked.




In Optional, the empty value is instantiated just once, and then stored in the static field, this value is reused always when the program needs an empty value.



private static final Optional<?> EMPTY = new Optional<>(); //instantiate value when program starts

public static<T> Optional<T> empty() {
@SuppressWarnings("unchecked")
Optional<T> t = (Optional<T>) EMPTY; //return stored value when requested
return t;
}





share|improve this answer



















  • 6




    And not to forget: the names of and ofNullable do not only document the different semantics of theses two factories, they also make them even possible, as we have two methods with identical type signatures, hence need different names to declare them in the same class. Since constructors don't have names, it is impossible to declare two of them with identical argument types.
    – Holger
    Dec 2 at 22:20












  • Of course he means that on the public API. I mean, obviously you need to have constructors eventually, it can't just be an endless chain of factory methods... or can it?!
    – corsiKa
    2 days ago


















up vote
19
down vote













The reason is actually quite simple: an empty optional is a static constant to be more memory efficient. If a constructor were used, it would have to create a new instance every time for a common case.



public static<T> Optional<T> empty() {
@SuppressWarnings("unchecked")
Optional<T> t = (Optional<T>) EMPTY;
return t;
}

public static <T> Optional<T> ofNullable(T value) {
return value == null ? empty() : of(value);
}





share|improve this answer























  • Having a public constructor doesn't preclude having a static method that returns a singleton instance.
    – Chris Cooper
    2 days ago










  • I have not said that would be the case, I only answered the question.
    – Minn
    2 days ago










  • "If a constructor were used, it would have to create a new instance every time for a common case." - the way this is worded to me implies that you would have to use the constructor rather than use the factory method. Perhaps you could reword it to be clear that having a public constructor would mean people would be more likely to create duplicate empty instances?
    – Chris Cooper
    2 days ago


















up vote
10
down vote













Optional is a Value-based Class without any constructors




do not have accessible constructors, but are instead instantiated through factory methods which make no committment as to the identity of returned instances







share|improve this answer



















  • 14




    The OP knows that. He's asking why that is.
    – JB Nizet
    Dec 2 at 11:53






  • 1




    @JBNizet Do you think the OP actually asked: why value-based classes have no accessible constructors?
    – Eugen Covaci
    Dec 2 at 12:25






  • 13




    No. I think he asked why the designers of Optional chose not to add a public constructor to Optional. Answering that Optional is a value class and thus doesn't have a public constructor doesn't answer the question, IMHO.
    – JB Nizet
    Dec 2 at 12:31






  • 2




    @JBNizet: I think it does answer the question technically, but opens other questions: "What is a value class", and "What are the advantages of a value class". This answer would be better if it also contained those bigs of information.
    – Mooing Duck
    Dec 2 at 20:08


















up vote
8
down vote













Because factory methods should be favored over public constructors when the possible instantiation cases are known.

It makes the API easier to use for client classes.

Besides factory methods allow to decide whether an instance should be created at each invocation.

In the case of Optional.empty() it makes sense to cache the value as that is immutable.






share|improve this answer























    Your Answer






    StackExchange.ifUsing("editor", function () {
    StackExchange.using("externalEditor", function () {
    StackExchange.using("snippets", function () {
    StackExchange.snippets.init();
    });
    });
    }, "code-snippets");

    StackExchange.ready(function() {
    var channelOptions = {
    tags: "".split(" "),
    id: "1"
    };
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function() {
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled) {
    StackExchange.using("snippets", function() {
    createEditor();
    });
    }
    else {
    createEditor();
    }
    });

    function createEditor() {
    StackExchange.prepareEditor({
    heartbeatType: 'answer',
    convertImagesToLinks: true,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: 10,
    bindNavPrevention: true,
    postfix: "",
    imageUploader: {
    brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
    contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
    allowUrls: true
    },
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    });


    }
    });














    draft saved

    draft discarded


















    StackExchange.ready(
    function () {
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53579911%2fwhy-no-public-constructor-for-optional-in-java%23new-answer', 'question_page');
    }
    );

    Post as a guest















    Required, but never shown

























    4 Answers
    4






    active

    oldest

    votes








    4 Answers
    4






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes








    up vote
    29
    down vote



    accepted










    From Joshua Bloch effective Java, Chapter 2. Creating and Destroying
    Objects, 1 Item:




    Consider static factory methods instead of constructors




    Why?




    One advantage of static factory methods is that, unlike constructors,
    they have names.




    With static factory methods we can specify some instantiation behavior in the method definition. This makes the API easier to use and we prevent clients from calling wrong constructors.



    For instance here: In Optional.ofNullable -> we allow null value be passed to instantiate the Optional, in Optional.of null value is not allowed and throw exception. We could not use the constructor here.



    private Optional(T value) {
    this.value = Objects.requireNonNull(value); //this throws NullPointerException
    }
    public static <T> Optional<T> of(T value) {
    return new Optional<>(value);
    }
    public static <T> Optional<T> ofNullable(T value) {
    return value == null ? empty() : of(value);
    }


    Another advantage (already mentioned):




    A second advantage of static factory methods is that, unlike
    constructors, they are not required to create a new object each time
    they’re invoked.




    In Optional, the empty value is instantiated just once, and then stored in the static field, this value is reused always when the program needs an empty value.



    private static final Optional<?> EMPTY = new Optional<>(); //instantiate value when program starts

    public static<T> Optional<T> empty() {
    @SuppressWarnings("unchecked")
    Optional<T> t = (Optional<T>) EMPTY; //return stored value when requested
    return t;
    }





    share|improve this answer



















    • 6




      And not to forget: the names of and ofNullable do not only document the different semantics of theses two factories, they also make them even possible, as we have two methods with identical type signatures, hence need different names to declare them in the same class. Since constructors don't have names, it is impossible to declare two of them with identical argument types.
      – Holger
      Dec 2 at 22:20












    • Of course he means that on the public API. I mean, obviously you need to have constructors eventually, it can't just be an endless chain of factory methods... or can it?!
      – corsiKa
      2 days ago















    up vote
    29
    down vote



    accepted










    From Joshua Bloch effective Java, Chapter 2. Creating and Destroying
    Objects, 1 Item:




    Consider static factory methods instead of constructors




    Why?




    One advantage of static factory methods is that, unlike constructors,
    they have names.




    With static factory methods we can specify some instantiation behavior in the method definition. This makes the API easier to use and we prevent clients from calling wrong constructors.



    For instance here: In Optional.ofNullable -> we allow null value be passed to instantiate the Optional, in Optional.of null value is not allowed and throw exception. We could not use the constructor here.



    private Optional(T value) {
    this.value = Objects.requireNonNull(value); //this throws NullPointerException
    }
    public static <T> Optional<T> of(T value) {
    return new Optional<>(value);
    }
    public static <T> Optional<T> ofNullable(T value) {
    return value == null ? empty() : of(value);
    }


    Another advantage (already mentioned):




    A second advantage of static factory methods is that, unlike
    constructors, they are not required to create a new object each time
    they’re invoked.




    In Optional, the empty value is instantiated just once, and then stored in the static field, this value is reused always when the program needs an empty value.



    private static final Optional<?> EMPTY = new Optional<>(); //instantiate value when program starts

    public static<T> Optional<T> empty() {
    @SuppressWarnings("unchecked")
    Optional<T> t = (Optional<T>) EMPTY; //return stored value when requested
    return t;
    }





    share|improve this answer



















    • 6




      And not to forget: the names of and ofNullable do not only document the different semantics of theses two factories, they also make them even possible, as we have two methods with identical type signatures, hence need different names to declare them in the same class. Since constructors don't have names, it is impossible to declare two of them with identical argument types.
      – Holger
      Dec 2 at 22:20












    • Of course he means that on the public API. I mean, obviously you need to have constructors eventually, it can't just be an endless chain of factory methods... or can it?!
      – corsiKa
      2 days ago













    up vote
    29
    down vote



    accepted







    up vote
    29
    down vote



    accepted






    From Joshua Bloch effective Java, Chapter 2. Creating and Destroying
    Objects, 1 Item:




    Consider static factory methods instead of constructors




    Why?




    One advantage of static factory methods is that, unlike constructors,
    they have names.




    With static factory methods we can specify some instantiation behavior in the method definition. This makes the API easier to use and we prevent clients from calling wrong constructors.



    For instance here: In Optional.ofNullable -> we allow null value be passed to instantiate the Optional, in Optional.of null value is not allowed and throw exception. We could not use the constructor here.



    private Optional(T value) {
    this.value = Objects.requireNonNull(value); //this throws NullPointerException
    }
    public static <T> Optional<T> of(T value) {
    return new Optional<>(value);
    }
    public static <T> Optional<T> ofNullable(T value) {
    return value == null ? empty() : of(value);
    }


    Another advantage (already mentioned):




    A second advantage of static factory methods is that, unlike
    constructors, they are not required to create a new object each time
    they’re invoked.




    In Optional, the empty value is instantiated just once, and then stored in the static field, this value is reused always when the program needs an empty value.



    private static final Optional<?> EMPTY = new Optional<>(); //instantiate value when program starts

    public static<T> Optional<T> empty() {
    @SuppressWarnings("unchecked")
    Optional<T> t = (Optional<T>) EMPTY; //return stored value when requested
    return t;
    }





    share|improve this answer














    From Joshua Bloch effective Java, Chapter 2. Creating and Destroying
    Objects, 1 Item:




    Consider static factory methods instead of constructors




    Why?




    One advantage of static factory methods is that, unlike constructors,
    they have names.




    With static factory methods we can specify some instantiation behavior in the method definition. This makes the API easier to use and we prevent clients from calling wrong constructors.



    For instance here: In Optional.ofNullable -> we allow null value be passed to instantiate the Optional, in Optional.of null value is not allowed and throw exception. We could not use the constructor here.



    private Optional(T value) {
    this.value = Objects.requireNonNull(value); //this throws NullPointerException
    }
    public static <T> Optional<T> of(T value) {
    return new Optional<>(value);
    }
    public static <T> Optional<T> ofNullable(T value) {
    return value == null ? empty() : of(value);
    }


    Another advantage (already mentioned):




    A second advantage of static factory methods is that, unlike
    constructors, they are not required to create a new object each time
    they’re invoked.




    In Optional, the empty value is instantiated just once, and then stored in the static field, this value is reused always when the program needs an empty value.



    private static final Optional<?> EMPTY = new Optional<>(); //instantiate value when program starts

    public static<T> Optional<T> empty() {
    @SuppressWarnings("unchecked")
    Optional<T> t = (Optional<T>) EMPTY; //return stored value when requested
    return t;
    }






    share|improve this answer














    share|improve this answer



    share|improve this answer








    edited 2 days ago









    Bakudan

    13.3k84264




    13.3k84264










    answered Dec 2 at 13:21









    Stefan Repcek

    1,16211122




    1,16211122








    • 6




      And not to forget: the names of and ofNullable do not only document the different semantics of theses two factories, they also make them even possible, as we have two methods with identical type signatures, hence need different names to declare them in the same class. Since constructors don't have names, it is impossible to declare two of them with identical argument types.
      – Holger
      Dec 2 at 22:20












    • Of course he means that on the public API. I mean, obviously you need to have constructors eventually, it can't just be an endless chain of factory methods... or can it?!
      – corsiKa
      2 days ago














    • 6




      And not to forget: the names of and ofNullable do not only document the different semantics of theses two factories, they also make them even possible, as we have two methods with identical type signatures, hence need different names to declare them in the same class. Since constructors don't have names, it is impossible to declare two of them with identical argument types.
      – Holger
      Dec 2 at 22:20












    • Of course he means that on the public API. I mean, obviously you need to have constructors eventually, it can't just be an endless chain of factory methods... or can it?!
      – corsiKa
      2 days ago








    6




    6




    And not to forget: the names of and ofNullable do not only document the different semantics of theses two factories, they also make them even possible, as we have two methods with identical type signatures, hence need different names to declare them in the same class. Since constructors don't have names, it is impossible to declare two of them with identical argument types.
    – Holger
    Dec 2 at 22:20






    And not to forget: the names of and ofNullable do not only document the different semantics of theses two factories, they also make them even possible, as we have two methods with identical type signatures, hence need different names to declare them in the same class. Since constructors don't have names, it is impossible to declare two of them with identical argument types.
    – Holger
    Dec 2 at 22:20














    Of course he means that on the public API. I mean, obviously you need to have constructors eventually, it can't just be an endless chain of factory methods... or can it?!
    – corsiKa
    2 days ago




    Of course he means that on the public API. I mean, obviously you need to have constructors eventually, it can't just be an endless chain of factory methods... or can it?!
    – corsiKa
    2 days ago












    up vote
    19
    down vote













    The reason is actually quite simple: an empty optional is a static constant to be more memory efficient. If a constructor were used, it would have to create a new instance every time for a common case.



    public static<T> Optional<T> empty() {
    @SuppressWarnings("unchecked")
    Optional<T> t = (Optional<T>) EMPTY;
    return t;
    }

    public static <T> Optional<T> ofNullable(T value) {
    return value == null ? empty() : of(value);
    }





    share|improve this answer























    • Having a public constructor doesn't preclude having a static method that returns a singleton instance.
      – Chris Cooper
      2 days ago










    • I have not said that would be the case, I only answered the question.
      – Minn
      2 days ago










    • "If a constructor were used, it would have to create a new instance every time for a common case." - the way this is worded to me implies that you would have to use the constructor rather than use the factory method. Perhaps you could reword it to be clear that having a public constructor would mean people would be more likely to create duplicate empty instances?
      – Chris Cooper
      2 days ago















    up vote
    19
    down vote













    The reason is actually quite simple: an empty optional is a static constant to be more memory efficient. If a constructor were used, it would have to create a new instance every time for a common case.



    public static<T> Optional<T> empty() {
    @SuppressWarnings("unchecked")
    Optional<T> t = (Optional<T>) EMPTY;
    return t;
    }

    public static <T> Optional<T> ofNullable(T value) {
    return value == null ? empty() : of(value);
    }





    share|improve this answer























    • Having a public constructor doesn't preclude having a static method that returns a singleton instance.
      – Chris Cooper
      2 days ago










    • I have not said that would be the case, I only answered the question.
      – Minn
      2 days ago










    • "If a constructor were used, it would have to create a new instance every time for a common case." - the way this is worded to me implies that you would have to use the constructor rather than use the factory method. Perhaps you could reword it to be clear that having a public constructor would mean people would be more likely to create duplicate empty instances?
      – Chris Cooper
      2 days ago













    up vote
    19
    down vote










    up vote
    19
    down vote









    The reason is actually quite simple: an empty optional is a static constant to be more memory efficient. If a constructor were used, it would have to create a new instance every time for a common case.



    public static<T> Optional<T> empty() {
    @SuppressWarnings("unchecked")
    Optional<T> t = (Optional<T>) EMPTY;
    return t;
    }

    public static <T> Optional<T> ofNullable(T value) {
    return value == null ? empty() : of(value);
    }





    share|improve this answer














    The reason is actually quite simple: an empty optional is a static constant to be more memory efficient. If a constructor were used, it would have to create a new instance every time for a common case.



    public static<T> Optional<T> empty() {
    @SuppressWarnings("unchecked")
    Optional<T> t = (Optional<T>) EMPTY;
    return t;
    }

    public static <T> Optional<T> ofNullable(T value) {
    return value == null ? empty() : of(value);
    }






    share|improve this answer














    share|improve this answer



    share|improve this answer








    edited Dec 2 at 23:48









    Brian McCutchon

    3,36021534




    3,36021534










    answered Dec 2 at 11:54









    Minn

    61513




    61513












    • Having a public constructor doesn't preclude having a static method that returns a singleton instance.
      – Chris Cooper
      2 days ago










    • I have not said that would be the case, I only answered the question.
      – Minn
      2 days ago










    • "If a constructor were used, it would have to create a new instance every time for a common case." - the way this is worded to me implies that you would have to use the constructor rather than use the factory method. Perhaps you could reword it to be clear that having a public constructor would mean people would be more likely to create duplicate empty instances?
      – Chris Cooper
      2 days ago


















    • Having a public constructor doesn't preclude having a static method that returns a singleton instance.
      – Chris Cooper
      2 days ago










    • I have not said that would be the case, I only answered the question.
      – Minn
      2 days ago










    • "If a constructor were used, it would have to create a new instance every time for a common case." - the way this is worded to me implies that you would have to use the constructor rather than use the factory method. Perhaps you could reword it to be clear that having a public constructor would mean people would be more likely to create duplicate empty instances?
      – Chris Cooper
      2 days ago
















    Having a public constructor doesn't preclude having a static method that returns a singleton instance.
    – Chris Cooper
    2 days ago




    Having a public constructor doesn't preclude having a static method that returns a singleton instance.
    – Chris Cooper
    2 days ago












    I have not said that would be the case, I only answered the question.
    – Minn
    2 days ago




    I have not said that would be the case, I only answered the question.
    – Minn
    2 days ago












    "If a constructor were used, it would have to create a new instance every time for a common case." - the way this is worded to me implies that you would have to use the constructor rather than use the factory method. Perhaps you could reword it to be clear that having a public constructor would mean people would be more likely to create duplicate empty instances?
    – Chris Cooper
    2 days ago




    "If a constructor were used, it would have to create a new instance every time for a common case." - the way this is worded to me implies that you would have to use the constructor rather than use the factory method. Perhaps you could reword it to be clear that having a public constructor would mean people would be more likely to create duplicate empty instances?
    – Chris Cooper
    2 days ago










    up vote
    10
    down vote













    Optional is a Value-based Class without any constructors




    do not have accessible constructors, but are instead instantiated through factory methods which make no committment as to the identity of returned instances







    share|improve this answer



















    • 14




      The OP knows that. He's asking why that is.
      – JB Nizet
      Dec 2 at 11:53






    • 1




      @JBNizet Do you think the OP actually asked: why value-based classes have no accessible constructors?
      – Eugen Covaci
      Dec 2 at 12:25






    • 13




      No. I think he asked why the designers of Optional chose not to add a public constructor to Optional. Answering that Optional is a value class and thus doesn't have a public constructor doesn't answer the question, IMHO.
      – JB Nizet
      Dec 2 at 12:31






    • 2




      @JBNizet: I think it does answer the question technically, but opens other questions: "What is a value class", and "What are the advantages of a value class". This answer would be better if it also contained those bigs of information.
      – Mooing Duck
      Dec 2 at 20:08















    up vote
    10
    down vote













    Optional is a Value-based Class without any constructors




    do not have accessible constructors, but are instead instantiated through factory methods which make no committment as to the identity of returned instances







    share|improve this answer



















    • 14




      The OP knows that. He's asking why that is.
      – JB Nizet
      Dec 2 at 11:53






    • 1




      @JBNizet Do you think the OP actually asked: why value-based classes have no accessible constructors?
      – Eugen Covaci
      Dec 2 at 12:25






    • 13




      No. I think he asked why the designers of Optional chose not to add a public constructor to Optional. Answering that Optional is a value class and thus doesn't have a public constructor doesn't answer the question, IMHO.
      – JB Nizet
      Dec 2 at 12:31






    • 2




      @JBNizet: I think it does answer the question technically, but opens other questions: "What is a value class", and "What are the advantages of a value class". This answer would be better if it also contained those bigs of information.
      – Mooing Duck
      Dec 2 at 20:08













    up vote
    10
    down vote










    up vote
    10
    down vote









    Optional is a Value-based Class without any constructors




    do not have accessible constructors, but are instead instantiated through factory methods which make no committment as to the identity of returned instances







    share|improve this answer














    Optional is a Value-based Class without any constructors




    do not have accessible constructors, but are instead instantiated through factory methods which make no committment as to the identity of returned instances








    share|improve this answer














    share|improve this answer



    share|improve this answer








    edited Dec 2 at 11:56

























    answered Dec 2 at 11:51









    user7294900

    19.3k93157




    19.3k93157








    • 14




      The OP knows that. He's asking why that is.
      – JB Nizet
      Dec 2 at 11:53






    • 1




      @JBNizet Do you think the OP actually asked: why value-based classes have no accessible constructors?
      – Eugen Covaci
      Dec 2 at 12:25






    • 13




      No. I think he asked why the designers of Optional chose not to add a public constructor to Optional. Answering that Optional is a value class and thus doesn't have a public constructor doesn't answer the question, IMHO.
      – JB Nizet
      Dec 2 at 12:31






    • 2




      @JBNizet: I think it does answer the question technically, but opens other questions: "What is a value class", and "What are the advantages of a value class". This answer would be better if it also contained those bigs of information.
      – Mooing Duck
      Dec 2 at 20:08














    • 14




      The OP knows that. He's asking why that is.
      – JB Nizet
      Dec 2 at 11:53






    • 1




      @JBNizet Do you think the OP actually asked: why value-based classes have no accessible constructors?
      – Eugen Covaci
      Dec 2 at 12:25






    • 13




      No. I think he asked why the designers of Optional chose not to add a public constructor to Optional. Answering that Optional is a value class and thus doesn't have a public constructor doesn't answer the question, IMHO.
      – JB Nizet
      Dec 2 at 12:31






    • 2




      @JBNizet: I think it does answer the question technically, but opens other questions: "What is a value class", and "What are the advantages of a value class". This answer would be better if it also contained those bigs of information.
      – Mooing Duck
      Dec 2 at 20:08








    14




    14




    The OP knows that. He's asking why that is.
    – JB Nizet
    Dec 2 at 11:53




    The OP knows that. He's asking why that is.
    – JB Nizet
    Dec 2 at 11:53




    1




    1




    @JBNizet Do you think the OP actually asked: why value-based classes have no accessible constructors?
    – Eugen Covaci
    Dec 2 at 12:25




    @JBNizet Do you think the OP actually asked: why value-based classes have no accessible constructors?
    – Eugen Covaci
    Dec 2 at 12:25




    13




    13




    No. I think he asked why the designers of Optional chose not to add a public constructor to Optional. Answering that Optional is a value class and thus doesn't have a public constructor doesn't answer the question, IMHO.
    – JB Nizet
    Dec 2 at 12:31




    No. I think he asked why the designers of Optional chose not to add a public constructor to Optional. Answering that Optional is a value class and thus doesn't have a public constructor doesn't answer the question, IMHO.
    – JB Nizet
    Dec 2 at 12:31




    2




    2




    @JBNizet: I think it does answer the question technically, but opens other questions: "What is a value class", and "What are the advantages of a value class". This answer would be better if it also contained those bigs of information.
    – Mooing Duck
    Dec 2 at 20:08




    @JBNizet: I think it does answer the question technically, but opens other questions: "What is a value class", and "What are the advantages of a value class". This answer would be better if it also contained those bigs of information.
    – Mooing Duck
    Dec 2 at 20:08










    up vote
    8
    down vote













    Because factory methods should be favored over public constructors when the possible instantiation cases are known.

    It makes the API easier to use for client classes.

    Besides factory methods allow to decide whether an instance should be created at each invocation.

    In the case of Optional.empty() it makes sense to cache the value as that is immutable.






    share|improve this answer



























      up vote
      8
      down vote













      Because factory methods should be favored over public constructors when the possible instantiation cases are known.

      It makes the API easier to use for client classes.

      Besides factory methods allow to decide whether an instance should be created at each invocation.

      In the case of Optional.empty() it makes sense to cache the value as that is immutable.






      share|improve this answer

























        up vote
        8
        down vote










        up vote
        8
        down vote









        Because factory methods should be favored over public constructors when the possible instantiation cases are known.

        It makes the API easier to use for client classes.

        Besides factory methods allow to decide whether an instance should be created at each invocation.

        In the case of Optional.empty() it makes sense to cache the value as that is immutable.






        share|improve this answer














        Because factory methods should be favored over public constructors when the possible instantiation cases are known.

        It makes the API easier to use for client classes.

        Besides factory methods allow to decide whether an instance should be created at each invocation.

        In the case of Optional.empty() it makes sense to cache the value as that is immutable.







        share|improve this answer














        share|improve this answer



        share|improve this answer








        edited 2 days ago









        Bakudan

        13.3k84264




        13.3k84264










        answered Dec 2 at 11:52









        davidxxx

        61.9k55685




        61.9k55685






























            draft saved

            draft discarded




















































            Thanks for contributing an answer to Stack Overflow!


            • Please be sure to answer the question. Provide details and share your research!

            But avoid



            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.


            To learn more, see our tips on writing great answers.





            Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


            Please pay close attention to the following guidance:


            • Please be sure to answer the question. Provide details and share your research!

            But avoid



            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.


            To learn more, see our tips on writing great answers.




            draft saved


            draft discarded














            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53579911%2fwhy-no-public-constructor-for-optional-in-java%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown





















































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown

































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown







            Popular posts from this blog

            If I really need a card on my start hand, how many mulligans make sense? [duplicate]

            Alcedinidae

            Can an atomic nucleus contain both particles and antiparticles? [duplicate]