A disclaimer or two for Optional

[Zakharov, Vladimir]

I too think the idea of ValueBased is fine.

Regarding a possible warning, isn’t it similar in spirit to the compiler warning about overriding equals() without overriding hashCode()? If so, why not leave it as a feature request for javac?

The Goldman Sachs Group, Inc. All rights reserved.
See http://www.gs.com/disclaimer/global_email for important risk disclosures, conflicts of interest and other terms and conditions relating to this e-mail and your reliance on information contained in it.  This message may contain confidential or privileged information.  If you are not the intended recipient, please advise us immediately and delete this message.  See http://www.gs.com/disclaimer/email for further information on confidentiality and the risks of non-secure electronic communication.  If you cannot access these links, please notify us by reply message and we will send the contents to you.

From: lambda-libs-spec-experts-bounces at openjdk.java.net [mailto:lambda-libs-spec-experts-bounces at openjdk.java.net] On Behalf Of Brian Goetz
Sent: Sunday, December 01, 2013 12:23 AM
To: Joe Bowbeer
Cc: lambda-libs-spec-experts at openjdk.java.net
Subject: Re: A disclaimer or two for Optional



I'm just pointing out that this is a serious warning in the javadoc that certainly qualifies for javac integration as well (right?).
No, wrong.

This is like saying that library code can't have invariants that the compiler cannot enforce.

The compiler is not in the business of detecting every possible violation of every possible classes spec.  Nor has this disclaimer of what value-based means remotely risen to the level of language feature.