A disclaimer or two for Optional

[Howard Lovatt]

Unfortunately I think that once Optional is introduced as a reference type
it will be used like all the other reference types, e.g. null will mean not
assigned. This is not unreasonable for programmers to do this because it is
exactly what Java does when initialising fields.

When (and I hope sooner rather than latter) Java gets value types it will
be necessary to come up with some mechanism to cope with this, e.g.
optional (note lower case) gets auto boxed to Optional (note upper case)
and the stream API is changed to return optional (which won't be a problem
because Stream never returns a null Optional). It would be nice if the
programmer when defining a value type could specify a companion reference
type that could be auto boxed to and could perhaps automatically gain the
same methods.

On Wednesday, October 23, 2013, Joe Bowbeer wrote:

> Does the paragraph below from Rose's blog list everything that shouldn't be
> done to an Optional?
>
> A value-safe expression may not be the subject of a value-unsafe operation.
> >  In particular, it cannot be synchronized on, nor can it be compared with
> > the “==” operator, not even with a null or with another value-safe type.
>
>
> Comparing an Optional with null would be pretty funny.  For other potential
> value types, such as Boolean and Integer, comparing with null is,
> unfortunately, a somewhat common idiom: null means "not assigned".
>
> --Joe
>
>
> On Sun, Oct 20, 2013 at 10:40 AM, Remi Forax <forax at univ-mlv.fr<javascript:;>>
> wrote:
>
> > On 10/20/2013 07:01 PM, Joe Bowbeer wrote:
> >
> >>
> >> The Integer.valueOf definition is useful to Java programmers developing
> >> for contained devices, and library writers trying to eek out
> performance.
> >> (These Java programmers are not idiots. They are us.)
> >>
> >>
> > Sorry but we are all idiots when we start to think about performance
> > because we focus only on the current data, the current program, the
> current
> > VM, the current OS, the current hardware and all of these things change
> > faster than our own vision of the world.
> > Anyway, that's not the issue here. The real issue is that this part of
> the
> > Java spec is overspecified as Josh said.
> >
> >
> >  It creates a safe zone for equals, much like the specification that
> >> string constants are ==.
> >>
> >>
> > again String constantification is not free, VMs use a global shared
> > dictionary.
> >
> >
> >  Changing Integer values is a Java 10 order of change.
> >>
> >>
> > yes, maybe, start to warn now, and change in 10, or just give up with
> > Integers has Brian said.
> >
> >
> >  I'm fine with carving a spot for Optional evolution, but it is going to
> >> be challenging to document in a way that is not misunderstood.
> >>
> >>
> > yes, it's challenging.
> > Rémi
> >
> >  On Oct 20, 2013 9:47 AM, "Remi Forax" <forax at univ-mlv.fr <javascript:;><mailto:
> >> forax at univ-mlv.fr <javascript:;>>> wrote:
> >>
> >>     On 10/20/2013 06:09 PM, Brian Goetz wrote:
> >>
> >>         Right, which is why Integer is likely too far polluted to be
> >>         rescued. But, wouldn't it have been better if we could enforce
> >>         that no one depended on it in the first place?  Wouldn't it be
> >>         a shame for Optional to join it in the "hopelessly polluted by
> >>         identity" department?
> >>
> >>
> >>     JLS 5.1.7 is what is what is usually called a premature
> optimization.
> >>     IMO the only sane choice is to just remove the wording about
> >>     caching and performance and pretend that it has never existed.
> >>
> >>     Rémi
> >>
> >>
> >>         On 10/20/2013 12:08 PM, Joe Bowbeer wrote:
> >>
> >>             Remi: Integer.valueOf is defined to return singletons for
> >>             a range of
> >>             values near zero, and new instances in other cases. Java
> >>             programmers
> >>             understand what this means, and their code sometimes
> >>             depends on it.
> >>
> >>             On Oct 20, 2013 5:52 AM, "Remi Forax" <forax at univ-mlv.fr<javascript:;>
> >>             <mailto:forax at univ-mlv.fr <javascript:;>>
> >>             <mailto:forax at univ-mlv.fr <javascript:;> <mailto:
> forax at univ-mlv.fr <javascript:;>>>> wrote:
> >>
> >>                 On 10/20/2013 03:32 AM, Joshua Bloch wrote:
> >>
> >>                     Brian,
> >>
> >>
> >>                     On Sat, Oct 19, 2013 at 3:17 PM, Brian Goetz
> >>                     <brian.goetz at oracle.com <javascript:;>
> >>             <mailto:brian.goetz at oracle.com <javascript:;>**>
> >>             <mailto:brian.goetz at oracle.com <javascript:;>
> >>             <mailto:brian.goetz at oracle.com <javascript:;>**>>
> >>                     <mailto:brian.goetz at oracle.com <javascript:;>
> >>             <mailto:brian.goetz at oracle.com <javascript:;>**>
> >>                     <mailto:brian.goetz at oracle.com <javascript:;>
> >>             <mailto:brian.goetz at oracle.com**>>__>> wrote:
> >>
> >>                          OK, here's some of the background you may be
> >>             missing.
> >>
> >>                          "A future version of Java" will almost
> >>             certainly have
> >>                     support for
> >>                          "value types", "user-defined primitives",
> >>             "identity-less
> >>                          aggregates", "structs", or whatever you would
> >>             like to call
> >>                     them.
> >>                           Without making promises or projections or
> >>             even going into anTy
> >>                          details, this is high on the priority list,
> >>             and some nontrivial
> >>                          analysis has already been done on what it
> >>             might look like
> >>                     and what
> >>                          the migration compatibility concerns would be.
> >>
> >>
> >>                     That's great because, frankly, Java's type system
> >>             is way too
> >>                     simple.  I'm glad you guys are investigating ways
> >>             to make it
> >>                     more complex, and to provide additional ways to do
> >>             things that
> >>                     people are already doing. This will keep Java
> >>             programmers on
> >>                     their toes, which, frankly, is just what they need.
> >>
> >>                     Josh
> >>
> >>
> >>                 Hi Josh,
> >>
> >>                 It's a consequence of the introduction of
> >>             auto-boxing/unboxing.
> >>                 When you call Integer.valueOf() you explicitly say
> >>             that you don't
> >>                 care about the identity of the returned object, only
> >>             the wrapped
> >>                 value is important.
> >>                 As you know, you can not predict the result of
> >>             Integer.valueOf(x) ==
> >>                 Integer.valueOf(x), which means that == on Integer is
> >>             meaningless.
> >>
> >>                 Currently, the code that try to remove boxing in the
> >>             VM is full of
> >>                 special cases because the semantics of boxing is not
> >>             the same for
> >>                 each wrappers (and is also partially specified in each
> >>



-- 
  -- Howard.