Why no public constructor for Optional in java?












30














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 '18 at 11:51






  • 8




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
















30














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 '18 at 11:51






  • 8




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














30












30








30


6





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 constructor java-8 optional






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Dec 14 '18 at 11:49









Andrew Tobilko

26k104284




26k104284










asked Dec 2 '18 at 11:48









Gopal S Akshintala

1,0881815




1,0881815








  • 3




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






  • 8




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














  • 3




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






  • 8




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








3




3




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




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




8




8




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




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












4 Answers
4






active

oldest

votes


















37














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



















  • 7




    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 '18 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
    Dec 3 '18 at 4:04



















20














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
    Dec 3 '18 at 9:07










  • I have not said that would be the case, I only answered the question.
    – Minn
    Dec 3 '18 at 9:10










  • "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
    Dec 3 '18 at 10:01



















9














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 '18 at 11:53






  • 1




    @JBNizet Do you think the OP actually asked: why value-based classes have no accessible constructors?
    – user10639668
    Dec 2 '18 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 '18 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 '18 at 20:08



















9














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',
    autoActivateHeartbeat: false,
    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









    37














    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



















    • 7




      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 '18 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
      Dec 3 '18 at 4:04
















    37














    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



















    • 7




      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 '18 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
      Dec 3 '18 at 4:04














    37












    37








    37






    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 Dec 3 '18 at 8:38









    Bakudan

    13.4k84264




    13.4k84264










    answered Dec 2 '18 at 13:21









    Stefan Repcek

    1,34211122




    1,34211122








    • 7




      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 '18 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
      Dec 3 '18 at 4:04














    • 7




      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 '18 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
      Dec 3 '18 at 4:04








    7




    7




    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 '18 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 '18 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
    Dec 3 '18 at 4:04




    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
    Dec 3 '18 at 4:04













    20














    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
      Dec 3 '18 at 9:07










    • I have not said that would be the case, I only answered the question.
      – Minn
      Dec 3 '18 at 9:10










    • "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
      Dec 3 '18 at 10:01
















    20














    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
      Dec 3 '18 at 9:07










    • I have not said that would be the case, I only answered the question.
      – Minn
      Dec 3 '18 at 9:10










    • "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
      Dec 3 '18 at 10:01














    20












    20








    20






    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 '18 at 23:48









    Brian McCutchon

    3,43421534




    3,43421534










    answered Dec 2 '18 at 11:54









    Minn

    676115




    676115












    • Having a public constructor doesn't preclude having a static method that returns a singleton instance.
      – Chris Cooper
      Dec 3 '18 at 9:07










    • I have not said that would be the case, I only answered the question.
      – Minn
      Dec 3 '18 at 9:10










    • "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
      Dec 3 '18 at 10:01


















    • Having a public constructor doesn't preclude having a static method that returns a singleton instance.
      – Chris Cooper
      Dec 3 '18 at 9:07










    • I have not said that would be the case, I only answered the question.
      – Minn
      Dec 3 '18 at 9:10










    • "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
      Dec 3 '18 at 10:01
















    Having a public constructor doesn't preclude having a static method that returns a singleton instance.
    – Chris Cooper
    Dec 3 '18 at 9:07




    Having a public constructor doesn't preclude having a static method that returns a singleton instance.
    – Chris Cooper
    Dec 3 '18 at 9:07












    I have not said that would be the case, I only answered the question.
    – Minn
    Dec 3 '18 at 9:10




    I have not said that would be the case, I only answered the question.
    – Minn
    Dec 3 '18 at 9:10












    "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
    Dec 3 '18 at 10:01




    "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
    Dec 3 '18 at 10:01











    9














    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 '18 at 11:53






    • 1




      @JBNizet Do you think the OP actually asked: why value-based classes have no accessible constructors?
      – user10639668
      Dec 2 '18 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 '18 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 '18 at 20:08
















    9














    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 '18 at 11:53






    • 1




      @JBNizet Do you think the OP actually asked: why value-based classes have no accessible constructors?
      – user10639668
      Dec 2 '18 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 '18 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 '18 at 20:08














    9












    9








    9






    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 '18 at 11:56

























    answered Dec 2 '18 at 11:51









    user7294900

    20.6k103258




    20.6k103258








    • 14




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






    • 1




      @JBNizet Do you think the OP actually asked: why value-based classes have no accessible constructors?
      – user10639668
      Dec 2 '18 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 '18 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 '18 at 20:08














    • 14




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






    • 1




      @JBNizet Do you think the OP actually asked: why value-based classes have no accessible constructors?
      – user10639668
      Dec 2 '18 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 '18 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 '18 at 20:08








    14




    14




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




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




    1




    1




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




    @JBNizet Do you think the OP actually asked: why value-based classes have no accessible constructors?
    – user10639668
    Dec 2 '18 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 '18 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 '18 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 '18 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 '18 at 20:08











    9














    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




























      9














      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


























        9












        9








        9






        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 Dec 3 '18 at 8:39









        Bakudan

        13.4k84264




        13.4k84264










        answered Dec 2 '18 at 11:52









        davidxxx

        63.5k56093




        63.5k56093






























            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

            AnyDesk - Fatal Program Failure

            How to calibrate 16:9 built-in touch-screen to a 4:3 resolution?

            QoS: MAC-Priority for clients behind a repeater