From forax at univ-mlv.fr  Sat Nov 16 06:00:26 2013
From: forax at univ-mlv.fr (Remi Forax)
Date: Sat, 16 Nov 2013 15:00:26 +0100
Subject: An ad-hoc polymorphism way to create a stream
Message-ID: <52877A7A.1050504@univ-mlv.fr>

During Devoxx Belgium, after the talk of Brian and Jose Paumard, there was an interesting discussion among some Java8 early adopters about the fact that in the API there no xommon way to get a Stream for anything that is conceptually a collection.

I propose to introduce the following new methods on Stream:

   /**
    * Returns a sequential|Stream|  with the iterable as its source.
    *
    * @param T the type of stream elements.
    * @param iterable the iterable used as source of the stream.
    * @return a sequential stream.
    */
   public static <T> Stream<T> from(Iterable<T> iterable) {
       return StreamSupport.stream(iterable.spliterator(), false);
   }

   /**
    * Returns a sequential|Stream|  with the collection as its source.
    *
    * @param T the type of stream elements.
    * @param collection the collection used as source of the stream.
    * @return a sequential stream.
    */
   public static <T> Stream<T> from(Collection<T> collection) {
       return collection.stream();
   }

   /**
    * Returns a sequential|Stream|  with the array as its source.
    *
    * @param T the type of stream elements.
    * @param array the array used as source of the stream.
    * @return a sequential stream.
    */
   public static <T> Stream<T> from(T[] array) {
       return Stream.of(array);
   }

These methods are like the of() methods but of() overloads deal with values while from() deal with collections.

This also re-introduce a way to get a stream from an unknown Iterable that was removed from Iterable
because we want implementation of Iterable to be able to return Stream of primitives.
  
I know that this is late in the game, but I think that given these methods just delegates to existing methods,
it will be better to introduce them in Java8 than in Java9.

cheers,
R?mi
  


From forax at univ-mlv.fr  Wed Nov 20 14:54:56 2013
From: forax at univ-mlv.fr (Remi Forax)
Date: Wed, 20 Nov 2013 23:54:56 +0100
Subject: Map.Entry.setValue as a default method
Message-ID: <528D3DC0.4000508@univ-mlv.fr>

A good question of one of my student,
why Iterator.remove() is a default method that throws UOE in 8 but 
Map.Entry.setValue() is not a default method with the same semantics.

regards,
R?mi


From mike.duigou at oracle.com  Wed Nov 20 15:07:51 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Wed, 20 Nov 2013 15:07:51 -0800
Subject: Map.Entry.setValue as a default method
In-Reply-To: <528D3DC0.4000508@univ-mlv.fr>
References: <528D3DC0.4000508@univ-mlv.fr>
Message-ID: <771E070D-6E5B-42B2-80B0-80CAA2FBFBC8@oracle.com>

It could still be added in a future rev. setValue was less compelling and obviously correct than Iterator.remove(). I had a version of Map.Entry earlier on which provided provided setValue() along defaults for the required implementations of hashCode() and equals(). The spec for these later two methods is part of the API so defaults seemed appropriate. We essentially didn't implement them to avoid scope creep--none of these were strictly necessary for our other goals. For Iterator.remove() we could get immediate benefit.

Mike

On Nov 20 2013, at 14:54 , Remi Forax <forax at univ-mlv.fr> wrote:

> A good question of one of my student,
> why Iterator.remove() is a default method that throws UOE in 8 but Map.Entry.setValue() is not a default method with the same semantics.
> 
> regards,
> R?mi
> 


From forax at univ-mlv.fr  Wed Nov 20 16:31:22 2013
From: forax at univ-mlv.fr (Remi Forax)
Date: Thu, 21 Nov 2013 01:31:22 +0100
Subject: Map.Entry.setValue as a default method
In-Reply-To: <771E070D-6E5B-42B2-80B0-80CAA2FBFBC8@oracle.com>
References: <528D3DC0.4000508@univ-mlv.fr>
	<771E070D-6E5B-42B2-80B0-80CAA2FBFBC8@oracle.com>
Message-ID: <528D545A.8020109@univ-mlv.fr>

Hi mike,

On 11/21/2013 12:07 AM, Mike Duigou wrote:
> It could still be added in a future rev.

yes, I've post that here as a remainder for the future generation :)

>   setValue was less compelling and obviously correct than Iterator.remove(). I had a version of Map.Entry earlier on which provided provided setValue() along defaults for the required implementations of hashCode() and equals(). The spec for these later two methods is part of the API so defaults seemed appropriate.

Totally appropriate because a lot of people forget to implement them 
when implementing Map.Entry,
3 or 4 years back, hibernate collections had that issue, by example.

But while you can declare a default hashCode and equals, it will not 
work because the implementation of Object.hashCode and Object.equals 
will always be preferred to the default methods by the VM, this is how 
default methods are specified. Not something I'm very proud.

>   We essentially didn't implement them to avoid scope creep--none of these were strictly necessary for our other goals. For Iterator.remove() we could get immediate benefit.
>
> Mike

R?mi


>
> On Nov 20 2013, at 14:54 , Remi Forax <forax at univ-mlv.fr> wrote:
>
>> A good question of one of my student,
>> why Iterator.remove() is a default method that throws UOE in 8 but Map.Entry.setValue() is not a default method with the same semantics.
>>
>> regards,
>> R?mi
>>


From mike.duigou at oracle.com  Wed Nov 20 16:38:35 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Wed, 20 Nov 2013 16:38:35 -0800
Subject: Map.Entry.setValue as a default method
In-Reply-To: <528D545A.8020109@univ-mlv.fr>
References: <528D3DC0.4000508@univ-mlv.fr>
	<771E070D-6E5B-42B2-80B0-80CAA2FBFBC8@oracle.com>
	<528D545A.8020109@univ-mlv.fr>
Message-ID: <F7D7D194-3469-445C-BB53-934BC55B205B@oracle.com>


On Nov 20 2013, at 16:31 , Remi Forax <forax at univ-mlv.fr> wrote:

> Hi mike,
> 
> On 11/21/2013 12:07 AM, Mike Duigou wrote:
>> It could still be added in a future rev.
> 
> yes, I've post that here as a remainder for the future generation :)
> 
>>  setValue was less compelling and obviously correct than Iterator.remove(). I had a version of Map.Entry earlier on which provided provided setValue() along defaults for the required implementations of hashCode() and equals(). The spec for these later two methods is part of the API so defaults seemed appropriate.
> 
> Totally appropriate because a lot of people forget to implement them when implementing Map.Entry,
> 3 or 4 years back, hibernate collections had that issue, by example.
> 
> But while you can declare a default hashCode and equals, it will not work because the implementation of Object.hashCode and Object.equals will always be preferred to the default methods by the VM, this is how default methods are specified. Not something I'm very proud.

Ah, yes. It had worked for a while but then that decision was made.

> 
>>  We essentially didn't implement them to avoid scope creep--none of these were strictly necessary for our other goals. For Iterator.remove() we could get immediate benefit.
>> 
>> Mike
> 
> R?mi
> 
> 
>> 
>> On Nov 20 2013, at 14:54 , Remi Forax <forax at univ-mlv.fr> wrote:
>> 
>>> A good question of one of my student,
>>> why Iterator.remove() is a default method that throws UOE in 8 but Map.Entry.setValue() is not a default method with the same semantics.
>>> 
>>> regards,
>>> R?mi
>>> 
> 


From john.r.rose at oracle.com  Wed Nov 20 17:08:50 2013
From: john.r.rose at oracle.com (John Rose)
Date: Wed, 20 Nov 2013 17:08:50 -0800
Subject: Map.Entry.setValue as a default method
In-Reply-To: <528D545A.8020109@univ-mlv.fr>
References: <528D3DC0.4000508@univ-mlv.fr>
	<771E070D-6E5B-42B2-80B0-80CAA2FBFBC8@oracle.com>
	<528D545A.8020109@univ-mlv.fr>
Message-ID: <F6F6A391-CFE5-4FF8-984C-DAB7CBDDB4D3@oracle.com>

On Nov 20, 2013, at 4:31 PM, Remi Forax <forax at univ-mlv.fr> wrote:

> But while you can declare a default hashCode and equals, it will not work because the implementation of Object.hashCode and Object.equals will always be preferred to the default methods by the VM, this is how default methods are specified. Not something I'm very proud.

Next question:  What's the best practice for declaring reusable code for exactly those restricted methods (hashCode/equals, toString)?  Because of the irregularity with Object, the opt-in isn't by default, but there should still be a convention for supplying the code as a "would-be default method".

Maybe one of:
  interface KoolReusablePair {
    default boolean defaultEquals(Object x) { ... }
    static int hashCode(KoolReusablePair self) { ... }
    ...
  }

  class KoolImpl implements KoolReusablePair {
    @Override //manual opt-in:
    public boolean equals(Object x) { return KoolReusablePair.super.defaultEquals(x); }
    @Override //manual opt-in:
    public int hashCode() { return KoolReusablePair.hashCode(this); }
    ...
  }

? John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/lambda-libs-spec-experts/attachments/20131120/ba3ee215/attachment.html 

From forax at univ-mlv.fr  Thu Nov 21 06:56:20 2013
From: forax at univ-mlv.fr (Remi Forax)
Date: Thu, 21 Nov 2013 15:56:20 +0100
Subject: Map.Entry.setValue as a default method
In-Reply-To: <F6F6A391-CFE5-4FF8-984C-DAB7CBDDB4D3@oracle.com>
References: <528D3DC0.4000508@univ-mlv.fr>
	<771E070D-6E5B-42B2-80B0-80CAA2FBFBC8@oracle.com>
	<528D545A.8020109@univ-mlv.fr>
	<F6F6A391-CFE5-4FF8-984C-DAB7CBDDB4D3@oracle.com>
Message-ID: <528E1F14.2020001@univ-mlv.fr>

On 11/21/2013 02:08 AM, John Rose wrote:
> On Nov 20, 2013, at 4:31 PM, Remi Forax <forax at univ-mlv.fr 
> <mailto:forax at univ-mlv.fr>> wrote:
>
>> But while you can declare a default hashCode and equals, it will not 
>> work because the implementation of Object.hashCode and Object.equals 
>> will always be preferred to the default methods by the VM, this is 
>> how default methods are specified. Not something I'm very proud.
>
> Next question:  What's the best practice for declaring reusable code 
> for exactly those restricted methods (hashCode/equals, toString)? 
>  Because of the irregularity with Object, the opt-in isn't by default, 
> but there should still be a convention for supplying the code as a 
> "would-be default method".
>
> Maybe one of:
>   interface KoolReusablePair {
>     default boolean defaultEquals(Object x) { ... }
>     static int hashCode(KoolReusablePair self) { ... }
>     ...
>   }
>
>   class KoolImpl implements KoolReusablePair {
>     @Override //manual opt-in:
>     public boolean equals(Object x) { return 
> KoolReusablePair.super.defaultEquals(x); }
>     @Override //manual opt-in:
>     public int hashCode() { return KoolReusablePair.hashCode(this); }
>     ...
>   }
>
> ? John

The plumber in me think that a static method unlike a default method 
will not pollute the itable.

regards,
R?mi


From brian.goetz at oracle.com  Fri Nov 22 13:05:44 2013
From: brian.goetz at oracle.com (Brian Goetz)
Date: Fri, 22 Nov 2013 16:05:44 -0500
Subject: A disclaimer or two for Optional
In-Reply-To: <5262CC71.3020606@cs.oswego.edu>
References: <5262CC71.3020606@cs.oswego.edu>
Message-ID: <528FC728.2080108@oracle.com>

OK, trying to wrap this loose end up...

Doug's suggestion was:

>      /**
>       * Returns an {@code Optional} with the specified present non-null
> value.
> adding...
> * The returned instance need not be unique. Thus the results of
> * comparing two instances using @code{==}, or using one as the
> * argument for a @code{synchronized} block are arbitrary and should
> * be avoided.
>       *
>       * @param <T> the class of the value
>       * @param value the value to be present, which must be non-null
>       * @return an {@code Optional} with the value present
>       * @throws NullPointerException if value is null
>       */
>      public static <T> Optional<T> of(T value) {
>          return new Optional<>(value);
>      }
>

Joe suggested "more carrot, less stick", promising benefits for 
following the rules rather than threatened punishment for not doing so. 
  Though not sure what carrot to offer without explaning the whole story.

Perhaps generalizing:

... the use of value-unsafe operations, including comparing ... should 
be avoided.

(which begs the question, what is "value-unsafe" :(

From forax at univ-mlv.fr  Sat Nov 23 03:17:53 2013
From: forax at univ-mlv.fr (Remi Forax)
Date: Sat, 23 Nov 2013 12:17:53 +0100
Subject: @FunctionalInterface implications
In-Reply-To: <529005B0.5080307@oracle.com>
References: <CAMaYbv+oeWCuDo6cFbRChy5AtEa9P+aUss+wcJdC3FO7pbtbvQ@mail.gmail.com>
	<529005B0.5080307@oracle.com>
Message-ID: <52908EE1.4070903@univ-mlv.fr>

On 11/23/2013 02:32 AM, Brian Goetz wrote:
> Function is extended by BinaryOperator, also a functional interface,
> which specializes its type parameters.  I think that's a fine pattern.

Brian,
I don't want to restart the thread about the naming of UnaryOperator and 
BinaryOperator,
but  BinaryOperator is a BiFunction not a Function, UnaryOperator is a 
Function.

BTW I've recently discover something weird, Function.identity() should 
return a UnaryOperator<T> and not a Function<T,T> which can be seen as 
an hint of the fact that having two interfaces for something so similar 
is not a good idea.

I think we have missed a point when we have discussed about naming, the 
real question is why UnaryOperator and BinaryOperator exist, from now, 
they does not seem to worth their weight (naming, specialization, etc) ?

R?mi

>
> More generally, its perfectly fine for an interface to extend a
> functional interface but not itself be a functional interface.  See
> Node.Builder inside the Stream package, for example.
>
> On 11/22/2013 7:50 PM, Richard Warburton wrote:
>> Hi,
>>
>> If the intent of an interface marked with @FunctionalInterface is to be
>> used as such then should it ever be extended by another interface?
>>
>> I appreciate there are probably enough complex interactions that generating
>> a compile error if this happens would be too restrictive but what about
>> 'morally' or as a guideline?
>>
>> regards,
>>
>>     Richard Warburton
>>
>>     http://insightfullogic.com
>>     @RichardWarburto <http://twitter.com/richardwarburto>
>>


From joe.bowbeer at gmail.com  Sat Nov 23 09:45:10 2013
From: joe.bowbeer at gmail.com (Joe Bowbeer)
Date: Sat, 23 Nov 2013 09:45:10 -0800
Subject: A disclaimer or two for Optional
In-Reply-To: <528FC728.2080108@oracle.com>
References: <5262CC71.3020606@cs.oswego.edu>
	<528FC728.2080108@oracle.com>
Message-ID: <CAHzJPEoH5BgOwunJQL3Grme0M-5Y-=GZzVu2HcgRsHMFEF8a+w@mail.gmail.com>

Value-unsafe is a poor term but at least it makes it clear that this is a
new thing, for Java. (And I can google for value-unsafe operations.)

Warning that legal constructs today might fail in arbitrary ways in the
future is not a message that Java programmers have ever received, and I
would avoid crossing that line here. It is better to describe what uses
will allow more performant implementations in the future. In that respect,
the best sentence would explain the optimal ways to use Optional.  I think
it's ok to use the term value type.

On Friday, November 22, 2013, Brian Goetz wrote:

> OK, trying to wrap this loose end up...
>
> Doug's suggestion was:
>
>       /**
>>       * Returns an {@code Optional} with the specified present non-null
>> value.
>> adding...
>> * The returned instance need not be unique. Thus the results of
>> * comparing two instances using @code{==}, or using one as the
>> * argument for a @code{synchronized} block are arbitrary and should
>> * be avoided.
>>       *
>>       * @param <T> the class of the value
>>       * @param value the value to be present, which must be non-null
>>       * @return an {@code Optional} with the value present
>>       * @throws NullPointerException if value is null
>>       */
>>      public static <T> Optional<T> of(T value) {
>>          return new Optional<>(value);
>>      }
>>
>>
> Joe suggested "more carrot, less stick", promising benefits for following
> the rules rather than threatened punishment for not doing so.  Though not
> sure what carrot to offer without explaning the whole story.
>
> Perhaps generalizing:
>
> ... the use of value-unsafe operations, including comparing ... should be
> avoided.
>
> (which begs the question, what is "value-unsafe" :(
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/lambda-libs-spec-experts/attachments/20131123/b06111e1/attachment.html 

From brian.goetz at oracle.com  Mon Nov 25 16:41:49 2013
From: brian.goetz at oracle.com (Brian Goetz)
Date: Mon, 25 Nov 2013 19:41:49 -0500
Subject: @FunctionalInterface and Javadoc
Message-ID: <5293EE4D.6010905@oracle.com>

A long time ago, we agreed that the Javadoc for a functional interface 
should say something like "This is a functional interface."  This is 
done using a structural analysis of the interface, just as when used as 
the target of a lambda.

Later in time, we arrived at @FunctionalInterface, which is optional to 
use.  It is closest in spirit to @Override, since:
  - It captures design intent
  - It enlists the compiler's aid in catching violations of such intent; 
an @FI-marked method that is not a functional interface will merit a 
compile error.

It has recently been pointed out that perhaps we should adjust the 
Javadoc generation, to trigger off of @FI rather than structurally, 
since there are functional interfaces in the JDK that are not marked @FI 
(deliberately) but which still bear the "This is a functional interface" 
blurb.




From brian.goetz at oracle.com  Tue Nov 26 13:35:34 2013
From: brian.goetz at oracle.com (Brian Goetz)
Date: Tue, 26 Nov 2013 16:35:34 -0500
Subject: A disclaimer or two for Optional
In-Reply-To: <5262CC71.3020606@cs.oswego.edu>
References: <5262CC71.3020606@cs.oswego.edu>
Message-ID: <52951426.6030700@oracle.com>

OK, after several iterations with Doug and JohnR, I think we have a 
winner.

Then Optional would have a disclaimer:

  * <p>This is a <a 
href="../package-summary.html#ValueBased">value-based</a>
  * class; use of identity-sensitive operations on instances of {@code 
Optional}
  * may have unpredictable effects and should be avoided.
  *

pointing to (which lives in some suitable place, probably a .html file 
java/lang/doc-files):


<h2><a name="ValueBased">Value-based classes</a></h2>

Some classes, such as <code>java.util.Optional</code> and
<code>java.time.LocalDateTime</code>, are <em>value-based</em>. 
Instances of a
value-based class:
<ul>
     <li>are immutable (though may contain references to mutable 
objects);</li>
     <li>have value-based implementations of <code>equals</code>,
         <code>hashCode</code>, and <code>toString</code>, which are 
computed
         solely from the instance's state and not on its identity or the 
state
         of any other object;</li>
     <li>make no use of identity-sensitive operations such as reference
         equality between instances, identity hash code of instances, or
         synchronization on an instances's intrinsic lock;</li>
     <li>are considered equal solely based on 
<code>Object.equals()</code>, not
         based on reference equality (<code>==</code>);</li>
     <li>are not instantiated through accessible constructors, but instead
         through factory methods which make no committment as to the 
identity
         of returned instances;</li>
     <li>are <em>freely substitutable</em> when equal, meaning that 
interchanging
         any two instances <code>x</code> and <code>y</code> that are equal
         according to <code>Object.equals()</code> in any computation or 
method
         invocation should produce no visible change in behavior.
         </li>
</ul>

<p>A program may produce unpredictable results if it attempts to 
distinguish two
references to equal values of a value-based class, whether directly via 
reference
equality or indirectly via an appeal to synchronization, identity hashing,
serialization, or any other identity-sensitive mechanism.  Use of
identity-sensitive operations on instances of value-based classes may have
unpredictable effects and should be avoided.</p>


From joe.bowbeer at gmail.com  Wed Nov 27 16:43:04 2013
From: joe.bowbeer at gmail.com (Joe Bowbeer)
Date: Wed, 27 Nov 2013 16:43:04 -0800
Subject: A disclaimer or two for Optional
In-Reply-To: <52951426.6030700@oracle.com>
References: <5262CC71.3020606@cs.oswego.edu>
	<52951426.6030700@oracle.com>
Message-ID: <CAHzJPEo4uSVm512j+TR0r-M6oO-QpvZ635V6bQqzh5Pq+gjBqg@mail.gmail.com>

I approve. It seems definitive.

It is also scary. Will javac emit these warnings?
On Nov 26, 2013 1:36 PM, "Brian Goetz" <brian.goetz at oracle.com> wrote:

> OK, after several iterations with Doug and JohnR, I think we have a winner.
>
> Then Optional would have a disclaimer:
>
>  * <p>This is a <a href="../package-summary.html#
> ValueBased">value-based</a>
>  * class; use of identity-sensitive operations on instances of {@code
> Optional}
>  * may have unpredictable effects and should be avoided.
>  *
>
> pointing to (which lives in some suitable place, probably a .html file
> java/lang/doc-files):
>
>
> <h2><a name="ValueBased">Value-based classes</a></h2>
>
> Some classes, such as <code>java.util.Optional</code> and
> <code>java.time.LocalDateTime</code>, are <em>value-based</em>. Instances
> of a
> value-based class:
> <ul>
>     <li>are immutable (though may contain references to mutable
> objects);</li>
>     <li>have value-based implementations of <code>equals</code>,
>         <code>hashCode</code>, and <code>toString</code>, which are
> computed
>         solely from the instance's state and not on its identity or the
> state
>         of any other object;</li>
>     <li>make no use of identity-sensitive operations such as reference
>         equality between instances, identity hash code of instances, or
>         synchronization on an instances's intrinsic lock;</li>
>     <li>are considered equal solely based on <code>Object.equals()</code>,
> not
>         based on reference equality (<code>==</code>);</li>
>     <li>are not instantiated through accessible constructors, but instead
>         through factory methods which make no committment as to the
> identity
>         of returned instances;</li>
>     <li>are <em>freely substitutable</em> when equal, meaning that
> interchanging
>         any two instances <code>x</code> and <code>y</code> that are equal
>         according to <code>Object.equals()</code> in any computation or
> method
>         invocation should produce no visible change in behavior.
>         </li>
> </ul>
>
> <p>A program may produce unpredictable results if it attempts to
> distinguish two
> references to equal values of a value-based class, whether directly via
> reference
> equality or indirectly via an appeal to synchronization, identity hashing,
> serialization, or any other identity-sensitive mechanism.  Use of
> identity-sensitive operations on instances of value-based classes may have
> unpredictable effects and should be avoided.</p>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/lambda-libs-spec-experts/attachments/20131127/6ce79b2e/attachment.html 

From forax at univ-mlv.fr  Wed Nov 27 16:59:11 2013
From: forax at univ-mlv.fr (Remi Forax)
Date: Thu, 28 Nov 2013 01:59:11 +0100
Subject: A disclaimer or two for Optional
In-Reply-To: <CAHzJPEo4uSVm512j+TR0r-M6oO-QpvZ635V6bQqzh5Pq+gjBqg@mail.gmail.com>
References: <5262CC71.3020606@cs.oswego.edu> <52951426.6030700@oracle.com>
	<CAHzJPEo4uSVm512j+TR0r-M6oO-QpvZ635V6bQqzh5Pq+gjBqg@mail.gmail.com>
Message-ID: <5296955F.9070507@univ-mlv.fr>

On 11/28/2013 01:43 AM, Joe Bowbeer wrote:
>
> I approve. It seems definitive.
>

fine for me too.

R?mi


From brian.goetz at oracle.com  Sat Nov 30 08:27:23 2013
From: brian.goetz at oracle.com (Brian Goetz)
Date: Sat, 30 Nov 2013 11:27:23 -0500
Subject: A disclaimer or two for Optional
In-Reply-To: <CAHzJPEo4uSVm512j+TR0r-M6oO-QpvZ635V6bQqzh5Pq+gjBqg@mail.gmail.com>
References: <5262CC71.3020606@cs.oswego.edu> <52951426.6030700@oracle.com>
	<CAHzJPEo4uSVm512j+TR0r-M6oO-QpvZ635V6bQqzh5Pq+gjBqg@mail.gmail.com>
Message-ID: <22CAB85E-C0CB-44DD-993C-3C717DE3A34C@oracle.com>

No javac interaction for now. 

Sent from my iPhone

On Nov 27, 2013, at 7:43 PM, Joe Bowbeer <joe.bowbeer at gmail.com> wrote:

> I approve. It seems definitive.
> 
> It is also scary. Will javac emit these warnings?
> 
> On Nov 26, 2013 1:36 PM, "Brian Goetz" <brian.goetz at oracle.com> wrote:
>> OK, after several iterations with Doug and JohnR, I think we have a winner.
>> 
>> Then Optional would have a disclaimer:
>> 
>>  * <p>This is a <a href="../package-summary.html#ValueBased">value-based</a>
>>  * class; use of identity-sensitive operations on instances of {@code Optional}
>>  * may have unpredictable effects and should be avoided.
>>  *
>> 
>> pointing to (which lives in some suitable place, probably a .html file java/lang/doc-files):
>> 
>> 
>> <h2><a name="ValueBased">Value-based classes</a></h2>
>> 
>> Some classes, such as <code>java.util.Optional</code> and
>> <code>java.time.LocalDateTime</code>, are <em>value-based</em>. Instances of a
>> value-based class:
>> <ul>
>>     <li>are immutable (though may contain references to mutable objects);</li>
>>     <li>have value-based implementations of <code>equals</code>,
>>         <code>hashCode</code>, and <code>toString</code>, which are computed
>>         solely from the instance's state and not on its identity or the state
>>         of any other object;</li>
>>     <li>make no use of identity-sensitive operations such as reference
>>         equality between instances, identity hash code of instances, or
>>         synchronization on an instances's intrinsic lock;</li>
>>     <li>are considered equal solely based on <code>Object.equals()</code>, not
>>         based on reference equality (<code>==</code>);</li>
>>     <li>are not instantiated through accessible constructors, but instead
>>         through factory methods which make no committment as to the identity
>>         of returned instances;</li>
>>     <li>are <em>freely substitutable</em> when equal, meaning that interchanging
>>         any two instances <code>x</code> and <code>y</code> that are equal
>>         according to <code>Object.equals()</code> in any computation or method
>>         invocation should produce no visible change in behavior.
>>         </li>
>> </ul>
>> 
>> <p>A program may produce unpredictable results if it attempts to distinguish two
>> references to equal values of a value-based class, whether directly via reference
>> equality or indirectly via an appeal to synchronization, identity hashing,
>> serialization, or any other identity-sensitive mechanism.  Use of
>> identity-sensitive operations on instances of value-based classes may have
>> unpredictable effects and should be avoided.</p>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/lambda-libs-spec-experts/attachments/20131130/2a4089de/attachment.html 

From joe.bowbeer at gmail.com  Sat Nov 30 08:43:22 2013
From: joe.bowbeer at gmail.com (Joe Bowbeer)
Date: Sat, 30 Nov 2013 08:43:22 -0800
Subject: A disclaimer or two for Optional
In-Reply-To: <22CAB85E-C0CB-44DD-993C-3C717DE3A34C@oracle.com>
References: <5262CC71.3020606@cs.oswego.edu> <52951426.6030700@oracle.com>
	<CAHzJPEo4uSVm512j+TR0r-M6oO-QpvZ635V6bQqzh5Pq+gjBqg@mail.gmail.com>
	<22CAB85E-C0CB-44DD-993C-3C717DE3A34C@oracle.com>
Message-ID: <CAHzJPEpa+hR_7+F1a-uOwbhiGSW9rGXig4fD++zWZcg-1q4nuA@mail.gmail.com>

I want javac to warn about any code that may have unpredictable results.
This is even more important if the unpredictable results may not manifest
immediately.

On Saturday, November 30, 2013, Brian Goetz wrote:

> No javac interaction for now.
>
> Sent from my iPhone
>
> On Nov 27, 2013, at 7:43 PM, Joe Bowbeer <joe.bowbeer at gmail.com<javascript:_e({}, 'cvml', 'joe.bowbeer at gmail.com');>>
> wrote:
>
> I approve. It seems definitive.
>
> It is also scary. Will javac emit these warnings?
> On Nov 26, 2013 1:36 PM, "Brian Goetz" <brian.goetz at oracle.com<javascript:_e({}, 'cvml', 'brian.goetz at oracle.com');>>
> wrote:
>
>> OK, after several iterations with Doug and JohnR, I think we have a
>> winner.
>>
>> Then Optional would have a disclaimer:
>>
>>  * <p>This is a <a href="../package-summary.html#
>> ValueBased">value-based</a>
>>  * class; use of identity-sensitive operations on instances of {@code
>> Optional}
>>  * may have unpredictable effects and should be avoided.
>>  *
>>
>> pointing to (which lives in some suitable place, probably a .html file
>> java/lang/doc-files):
>>
>>
>> <h2><a name="ValueBased">Value-based classes</a></h2>
>>
>> Some classes, such as <code>java.util.Optional</code> and
>> <code>java.time.LocalDateTime</code>, are <em>value-based</em>.
>> Instances of a
>> value-based class:
>> <ul>
>>     <li>are immutable (though may contain references to mutable
>> objects);</li>
>>     <li>have value-based implementations of <code>equals</code>,
>>         <code>hashCode</code>, and <code>toString</code>, which are
>> computed
>>         solely from the instance's state and not on its identity or the
>> state
>>         of any other object;</li>
>>     <li>make no use of identity-sensitive operations such as reference
>>         equality between instances, identity hash code of instances, or
>>         synchronization on an instances's intrinsic lock;</li>
>>     <li>are considered equal solely based on
>> <code>Object.equals()</code>, not
>>         based on reference equality (<code>==</code>);</li>
>>     <li>are not instantiated through accessible constructors, but instead
>>         through factory methods which make no committment as to the
>> identity
>>         of returned instances;</li>
>>     <li>are <em>freely substitutable</em> when equal, meaning that
>> interchanging
>>         any two instances <code>x</code> and <code>y</code> that are equal
>>         according to <code>Object.equals()</code> in any computation or
>> method
>>         invocation should produce no visible change in behavior.
>>         </li>
>> </ul>
>>
>> <p>A program may produce unpredictable results if it attempts to
>> distinguish two
>> references to equal values of a value-based class, whether directly via
>> reference
>> equality or indirectly via an appeal to synchronization, identity hashing,
>> serialization, or any other identity-sensitive mechanism.  Use of
>> identity-sensitive operations on instances of value-based classes may have
>> unpredictable effects and should be avoided.</p>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/lambda-libs-spec-experts/attachments/20131130/269f2a0f/attachment.html 

From tim at peierls.net  Sat Nov 30 08:44:03 2013
From: tim at peierls.net (Tim Peierls)
Date: Sat, 30 Nov 2013 11:44:03 -0500
Subject: A disclaimer or two for Optional
In-Reply-To: <22CAB85E-C0CB-44DD-993C-3C717DE3A34C@oracle.com>
References: <5262CC71.3020606@cs.oswego.edu> <52951426.6030700@oracle.com>
	<CAHzJPEo4uSVm512j+TR0r-M6oO-QpvZ635V6bQqzh5Pq+gjBqg@mail.gmail.com>
	<22CAB85E-C0CB-44DD-993C-3C717DE3A34C@oracle.com>
Message-ID: <CA+F8eeRw6Y-JqKv4zFgPXg_mjOaokQ4ATiQe5OmhfX_LnzdCdA@mail.gmail.com>

Whoops, I never responded to the latest proposal. I think it's fine, just
what I was hoping for when I wrote, earlier in this thread:

I think a better way to prepare folks for such a language change would be
> to create a separate section in an overview or package doc that describes
> valueish types and what you shouldn't do with them, perhaps mentioning the
> possibility of a language change that would make such misuse entirely
> broken, and add links from the class comment for all such types to this
> section.


Glad there's no mention of language change. And "value-based" is certainly
better than "valueish". :-)

--tim


On Nov 26, 2013 1:36 PM, "Brian Goetz" <brian.goetz at oracle.com> wrote:
>
> OK, after several iterations with Doug and JohnR, I think we have a winner.
>
>>
> Then Optional would have a disclaimer:
>
>>
>  * <p>This is a <a href="../package-summary.html#
> ValueBased">value-based</a>
>
>  * class; use of identity-sensitive operations on instances of {@code
> Optional}
>
>  * may have unpredictable effects and should be avoided.
>
>  *
>
>>
> pointing to (which lives in some suitable place, probably a .html file
> java/lang/doc-files):
>
>>
>
> <h2><a name="ValueBased">Value-based classes</a></h2>
>
>>
> Some classes, such as <code>java.util.Optional</code> and
>
> <code>java.time.LocalDateTime</code>, are <em>value-based</em>. Instances
> of a
>
> value-based class:
>
> <ul>
>
>     <li>are immutable (though may contain references to mutable
> objects);</li>
>
>     <li>have value-based implementations of <code>equals</code>,
>
>         <code>hashCode</code>, and <code>toString</code>, which are
> computed
>
>         solely from the instance's state and not on its identity or the
> state
>
>         of any other object;</li>
>
>     <li>make no use of identity-sensitive operations such as reference
>
>         equality between instances, identity hash code of instances, or
>
>         synchronization on an instances's intrinsic lock;</li>
>
>     <li>are considered equal solely based on <code>Object.equals()</code>,
> not
>
>         based on reference equality (<code>==</code>);</li>
>
>     <li>are not instantiated through accessible constructors, but instead
>
>         through factory methods which make no committment as to the
> identity
>
>         of returned instances;</li>
>
>     <li>are <em>freely substitutable</em> when equal, meaning that
> interchanging
>
>         any two instances <code>x</code> and <code>y</code> that are equal
>
>         according to <code>Object.equals()</code> in any computation or
> method
>
>         invocation should produce no visible change in behavior.
>
>         </li>
>
> </ul>
>
>>
> <p>A program may produce unpredictable results if it attempts to
> distinguish two
>
> references to equal values of a value-based class, whether directly via
> reference
>
> equality or indirectly via an appeal to synchronization, identity hashing,
>
> serialization, or any other identity-sensitive mechanism.  Use of
>
> identity-sensitive operations on instances of value-based classes may have
>
> unpredictable effects and should be avoided.</p>
>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/lambda-libs-spec-experts/attachments/20131130/861f22d6/attachment-0001.html 

From tim at peierls.net  Sat Nov 30 09:30:35 2013
From: tim at peierls.net (Tim Peierls)
Date: Sat, 30 Nov 2013 12:30:35 -0500
Subject: A disclaimer or two for Optional
In-Reply-To: <CAHzJPEpa+hR_7+F1a-uOwbhiGSW9rGXig4fD++zWZcg-1q4nuA@mail.gmail.com>
References: <5262CC71.3020606@cs.oswego.edu> <52951426.6030700@oracle.com>
	<CAHzJPEo4uSVm512j+TR0r-M6oO-QpvZ635V6bQqzh5Pq+gjBqg@mail.gmail.com>
	<22CAB85E-C0CB-44DD-993C-3C717DE3A34C@oracle.com>
	<CAHzJPEpa+hR_7+F1a-uOwbhiGSW9rGXig4fD++zWZcg-1q4nuA@mail.gmail.com>
Message-ID: <CA+F8eeQ-KR-hGgBfGP8sMM5ju09iRZPrX3sbnFCj7Z=fwQVqMw@mail.gmail.com>

Ideally, yes, but doubtless getting this into javac now would mean an
enormous delay, leaving an unpleasant choice between having only the doc
warnings now -- with better javac messages left for the future -- and
pushing everything into the distant future. (*Pace* Brian, for whom it
cannot be expressed as a choice.)

Can't FindBugs be a stopgap measure here? If one ignores the docs now and
refuses to (or can't) recompile after a future release that has javac
messages for value-based rules violations, then one should at least run
FindBugs on your class files. (Such violations *are* amenable to FindBugs
detection, aren't they?)

--tim


On Sat, Nov 30, 2013 at 11:43 AM, Joe Bowbeer <joe.bowbeer at gmail.com> wrote:

> I want javac to warn about any code that may have unpredictable results.
> This is even more important if the unpredictable results may not manifest
> immediately.
>
>
> On Saturday, November 30, 2013, Brian Goetz wrote:
>
>> No javac interaction for now.
>>
>> Sent from my iPhone
>>
>> On Nov 27, 2013, at 7:43 PM, Joe Bowbeer <joe.bowbeer at gmail.com> wrote:
>>
>> I approve. It seems definitive.
>>
>> It is also scary. Will javac emit these warnings?
>> On Nov 26, 2013 1:36 PM, "Brian Goetz" <brian.goetz at oracle.com> wrote:
>>
>>> OK, after several iterations with Doug and JohnR, I think we have a
>>> winner.
>>>
>>> Then Optional would have a disclaimer:
>>>
>>>  * <p>This is a <a href="../package-summary.html#
>>> ValueBased">value-based</a>
>>>  * class; use of identity-sensitive operations on instances of {@code
>>> Optional}
>>>  * may have unpredictable effects and should be avoided.
>>>  *
>>>
>>> pointing to (which lives in some suitable place, probably a .html file
>>> java/lang/doc-files):
>>>
>>>
>>> <h2><a name="ValueBased">Value-based classes</a></h2>
>>>
>>> Some classes, such as <code>java.util.Optional</code> and
>>> <code>java.time.LocalDateTime</code>, are <em>value-based</em>.
>>> Instances of a
>>> value-based class:
>>> <ul>
>>>     <li>are immutable (though may contain references to mutable
>>> objects);</li>
>>>     <li>have value-based implementations of <code>equals</code>,
>>>         <code>hashCode</code>, and <code>toString</code>, which are
>>> computed
>>>         solely from the instance's state and not on its identity or the
>>> state
>>>         of any other object;</li>
>>>     <li>make no use of identity-sensitive operations such as reference
>>>         equality between instances, identity hash code of instances, or
>>>         synchronization on an instances's intrinsic lock;</li>
>>>     <li>are considered equal solely based on
>>> <code>Object.equals()</code>, not
>>>         based on reference equality (<code>==</code>);</li>
>>>     <li>are not instantiated through accessible constructors, but instead
>>>         through factory methods which make no committment as to the
>>> identity
>>>         of returned instances;</li>
>>>     <li>are <em>freely substitutable</em> when equal, meaning that
>>> interchanging
>>>         any two instances <code>x</code> and <code>y</code> that are
>>> equal
>>>         according to <code>Object.equals()</code> in any computation or
>>> method
>>>         invocation should produce no visible change in behavior.
>>>         </li>
>>> </ul>
>>>
>>> <p>A program may produce unpredictable results if it attempts to
>>> distinguish two
>>> references to equal values of a value-based class, whether directly via
>>> reference
>>> equality or indirectly via an appeal to synchronization, identity
>>> hashing,
>>> serialization, or any other identity-sensitive mechanism.  Use of
>>> identity-sensitive operations on instances of value-based classes may
>>> have
>>> unpredictable effects and should be avoided.</p>
>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/lambda-libs-spec-experts/attachments/20131130/ad1260f2/attachment.html 

From joe.bowbeer at gmail.com  Sat Nov 30 10:34:27 2013
From: joe.bowbeer at gmail.com (Joe Bowbeer)
Date: Sat, 30 Nov 2013 10:34:27 -0800
Subject: A disclaimer or two for Optional
In-Reply-To: <CA+F8eeQ-KR-hGgBfGP8sMM5ju09iRZPrX3sbnFCj7Z=fwQVqMw@mail.gmail.com>
References: <5262CC71.3020606@cs.oswego.edu> <52951426.6030700@oracle.com>
	<CAHzJPEo4uSVm512j+TR0r-M6oO-QpvZ635V6bQqzh5Pq+gjBqg@mail.gmail.com>
	<22CAB85E-C0CB-44DD-993C-3C717DE3A34C@oracle.com>
	<CAHzJPEpa+hR_7+F1a-uOwbhiGSW9rGXig4fD++zWZcg-1q4nuA@mail.gmail.com>
	<CA+F8eeQ-KR-hGgBfGP8sMM5ju09iRZPrX3sbnFCj7Z=fwQVqMw@mail.gmail.com>
Message-ID: <CAHzJPEorCU1GuDP6GE6t6SUDjddVRZUg7r8=h48r+MjcLmGspg@mail.gmail.com>

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

Otherwise, it feels more like one of those tiny-print end-user agreements.

I would like this warning to be more visible, if possible. Adding a warning
to javac is the best way to force support in findbugs and IDEs.

So, file a feature request for javac integration?
On Nov 30, 2013 9:30 AM, "Tim Peierls" <tim at peierls.net> wrote:

> Ideally, yes, but doubtless getting this into javac now would mean an
> enormous delay, leaving an unpleasant choice between having only the doc
> warnings now -- with better javac messages left for the future -- and
> pushing everything into the distant future. (*Pace* Brian, for whom it
> cannot be expressed as a choice.)
>
> Can't FindBugs be a stopgap measure here? If one ignores the docs now and
> refuses to (or can't) recompile after a future release that has javac
> messages for value-based rules violations, then one should at least run
> FindBugs on your class files. (Such violations *are* amenable to FindBugs
> detection, aren't they?)
>
> --tim
>
>
> On Sat, Nov 30, 2013 at 11:43 AM, Joe Bowbeer <joe.bowbeer at gmail.com>wrote:
>
>> I want javac to warn about any code that may have unpredictable results.
>> This is even more important if the unpredictable results may not manifest
>> immediately.
>>
>>
>> On Saturday, November 30, 2013, Brian Goetz wrote:
>>
>>> No javac interaction for now.
>>>
>>> Sent from my iPhone
>>>
>>> On Nov 27, 2013, at 7:43 PM, Joe Bowbeer <joe.bowbeer at gmail.com> wrote:
>>>
>>> I approve. It seems definitive.
>>>
>>> It is also scary. Will javac emit these warnings?
>>> On Nov 26, 2013 1:36 PM, "Brian Goetz" <brian.goetz at oracle.com> wrote:
>>>
>>>> OK, after several iterations with Doug and JohnR, I think we have a
>>>> winner.
>>>>
>>>> Then Optional would have a disclaimer:
>>>>
>>>>  * <p>This is a <a href="../package-summary.html#
>>>> ValueBased">value-based</a>
>>>>  * class; use of identity-sensitive operations on instances of {@code
>>>> Optional}
>>>>  * may have unpredictable effects and should be avoided.
>>>>  *
>>>>
>>>> pointing to (which lives in some suitable place, probably a .html file
>>>> java/lang/doc-files):
>>>>
>>>>
>>>> <h2><a name="ValueBased">Value-based classes</a></h2>
>>>>
>>>> Some classes, such as <code>java.util.Optional</code> and
>>>> <code>java.time.LocalDateTime</code>, are <em>value-based</em>.
>>>> Instances of a
>>>> value-based class:
>>>> <ul>
>>>>     <li>are immutable (though may contain references to mutable
>>>> objects);</li>
>>>>     <li>have value-based implementations of <code>equals</code>,
>>>>         <code>hashCode</code>, and <code>toString</code>, which are
>>>> computed
>>>>         solely from the instance's state and not on its identity or the
>>>> state
>>>>         of any other object;</li>
>>>>     <li>make no use of identity-sensitive operations such as reference
>>>>         equality between instances, identity hash code of instances, or
>>>>         synchronization on an instances's intrinsic lock;</li>
>>>>     <li>are considered equal solely based on
>>>> <code>Object.equals()</code>, not
>>>>         based on reference equality (<code>==</code>);</li>
>>>>     <li>are not instantiated through accessible constructors, but
>>>> instead
>>>>         through factory methods which make no committment as to the
>>>> identity
>>>>         of returned instances;</li>
>>>>     <li>are <em>freely substitutable</em> when equal, meaning that
>>>> interchanging
>>>>         any two instances <code>x</code> and <code>y</code> that are
>>>> equal
>>>>         according to <code>Object.equals()</code> in any computation or
>>>> method
>>>>         invocation should produce no visible change in behavior.
>>>>         </li>
>>>> </ul>
>>>>
>>>> <p>A program may produce unpredictable results if it attempts to
>>>> distinguish two
>>>> references to equal values of a value-based class, whether directly via
>>>> reference
>>>> equality or indirectly via an appeal to synchronization, identity
>>>> hashing,
>>>> serialization, or any other identity-sensitive mechanism.  Use of
>>>> identity-sensitive operations on instances of value-based classes may
>>>> have
>>>> unpredictable effects and should be avoided.</p>
>>>>
>>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/lambda-libs-spec-experts/attachments/20131130/355b8f72/attachment.html 

From brian.goetz at oracle.com  Sat Nov 30 21:12:57 2013
From: brian.goetz at oracle.com (Brian Goetz)
Date: Sun, 1 Dec 2013 00:12:57 -0500
Subject: A disclaimer or two for Optional
In-Reply-To: <CAHzJPEpa+hR_7+F1a-uOwbhiGSW9rGXig4fD++zWZcg-1q4nuA@mail.gmail.com>
References: <5262CC71.3020606@cs.oswego.edu> <52951426.6030700@oracle.com>
	<CAHzJPEo4uSVm512j+TR0r-M6oO-QpvZ635V6bQqzh5Pq+gjBqg@mail.gmail.com>
	<22CAB85E-C0CB-44DD-993C-3C717DE3A34C@oracle.com>
	<CAHzJPEpa+hR_7+F1a-uOwbhiGSW9rGXig4fD++zWZcg-1q4nuA@mail.gmail.com>
Message-ID: <F4863524-4787-49EE-AA72-68FBDBD9B095@oracle.com>

This is a nice goal, except that it's patently unreasonable :). It is not possible for the compiler to understand and enforce every library-based invariant.  



Sent from my iPad

On Nov 30, 2013, at 11:43 AM, Joe Bowbeer <joe.bowbeer at gmail.com> wrote:

> I want javac to warn about any code that may have unpredictable results. This is even more important if the unpredictable results may not manifest immediately.
> 
> On Saturday, November 30, 2013, Brian Goetz wrote:
>> No javac interaction for now. 
>> 
>> Sent from my iPhone
>> 
>> On Nov 27, 2013, at 7:43 PM, Joe Bowbeer <joe.bowbeer at gmail.com> wrote:
>> 
>>> I approve. It seems definitive.
>>> 
>>> It is also scary. Will javac emit these warnings?
>>> 
>>> On Nov 26, 2013 1:36 PM, "Brian Goetz" <brian.goetz at oracle.com> wrote:
>>>> OK, after several iterations with Doug and JohnR, I think we have a winner.
>>>> 
>>>> Then Optional would have a disclaimer:
>>>> 
>>>>  * <p>This is a <a href="../package-summary.html#ValueBased">value-based</a>
>>>>  * class; use of identity-sensitive operations on instances of {@code Optional}
>>>>  * may have unpredictable effects and should be avoided.
>>>>  *
>>>> 
>>>> pointing to (which lives in some suitable place, probably a .html file java/lang/doc-files):
>>>> 
>>>> 
>>>> <h2><a name="ValueBased">Value-based classes</a></h2>
>>>> 
>>>> Some classes, such as <code>java.util.Optional</code> and
>>>> <code>java.time.LocalDateTime</code>, are <em>value-based</em>. Instances of a
>>>> value-based class:
>>>> <ul>
>>>>     <li>are immutable (though may contain references to mutable objects);</li>
>>>>     <li>have value-based implementations of <code>equals</code>,
>>>>         <code>hashCode</code>, and <code>toString</code>, which are computed
>>>>         solely from the instance's state and not on its identity or the state
>>>>         of any other object;</li>
>>>>     <li>make no use of identity-sensitive operations such as reference
>>>>         equality between instances, identity hash code of instances, or
>>>>         synchronization on an instances's intrinsic lock;</li>
>>>>     <li>are considered equal solely based on <code>Object.equals()</code>, not
>>>>         based on reference equality (<code>==</code>);</li>
>>>>     <li>are not instantiated through accessible constructors, but instead
>>>>         through factory methods which make no committment as to the identity
>>>>         of returned instances;</li>
>>>>     <li>are <em>freely substitutable</em> when equal, meaning that interchanging
>>>>         any two instances <code>x</code> and <code>y</code> that are equal
>>>>         according to <code>Object.equals()</code> in any computation or method
>>>>         invocation should produce no visible change in behavior.
>>>>         </li>
>>>> </ul>
>>>> 
>>>> <p>A program may produce unpredictable results if it attempts to distinguish two
>>>> references to equal values of a value-based class, whether directly via reference
>>>> equality or indirectly via an appeal to synchronization, identity hashing,
>>>> serialization, or any other identity-sensitive mechanism.  Use of
>>>> identity-sensitive operations on instances of value-based classes may have
>>>> unpredictable effects and should be avoided.</p>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/lambda-libs-spec-experts/attachments/20131201/bd36f913/attachment.html 

From brian.goetz at oracle.com  Sat Nov 30 21:23:21 2013
From: brian.goetz at oracle.com (Brian Goetz)
Date: Sun, 1 Dec 2013 00:23:21 -0500
Subject: A disclaimer or two for Optional
In-Reply-To: <CAHzJPEorCU1GuDP6GE6t6SUDjddVRZUg7r8=h48r+MjcLmGspg@mail.gmail.com>
References: <5262CC71.3020606@cs.oswego.edu> <52951426.6030700@oracle.com>
	<CAHzJPEo4uSVm512j+TR0r-M6oO-QpvZ635V6bQqzh5Pq+gjBqg@mail.gmail.com>
	<22CAB85E-C0CB-44DD-993C-3C717DE3A34C@oracle.com>
	<CAHzJPEpa+hR_7+F1a-uOwbhiGSW9rGXig4fD++zWZcg-1q4nuA@mail.gmail.com>
	<CA+F8eeQ-KR-hGgBfGP8sMM5ju09iRZPrX3sbnFCj7Z=fwQVqMw@mail.gmail.com>
	<CAHzJPEorCU1GuDP6GE6t6SUDjddVRZUg7r8=h48r+MjcLmGspg@mail.gmail.com>
Message-ID: <863F6A4B-D30A-4094-A32C-D0A21CD96185@oracle.com>


> 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.  


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/lambda-libs-spec-experts/attachments/20131201/c11be6d7/attachment.html 

From joe.bowbeer at gmail.com  Sat Nov 30 21:28:58 2013
From: joe.bowbeer at gmail.com (Joe Bowbeer)
Date: Sat, 30 Nov 2013 21:28:58 -0800
Subject: A disclaimer or two for Optional
In-Reply-To: <863F6A4B-D30A-4094-A32C-D0A21CD96185@oracle.com>
References: <5262CC71.3020606@cs.oswego.edu> <52951426.6030700@oracle.com>
	<CAHzJPEo4uSVm512j+TR0r-M6oO-QpvZ635V6bQqzh5Pq+gjBqg@mail.gmail.com>
	<22CAB85E-C0CB-44DD-993C-3C717DE3A34C@oracle.com>
	<CAHzJPEpa+hR_7+F1a-uOwbhiGSW9rGXig4fD++zWZcg-1q4nuA@mail.gmail.com>
	<CA+F8eeQ-KR-hGgBfGP8sMM5ju09iRZPrX3sbnFCj7Z=fwQVqMw@mail.gmail.com>
	<CAHzJPEorCU1GuDP6GE6t6SUDjddVRZUg7r8=h48r+MjcLmGspg@mail.gmail.com>
	<863F6A4B-D30A-4094-A32C-D0A21CD96185@oracle.com>
Message-ID: <CAHzJPEq8J_0yS3FxOV26+orNi9CU-STngNPgfwaCkG0RpKTcZQ@mail.gmail.com>

Is there something about this case that prohibits compiler warnings?

> It is not possible for the compiler to understand and enforce every
library-based invariant.

The compiler emits a lot of warnings about dubious code that should be
avoided.  Why wouldn't you want the compiler to warn about this one?  (It
seems like you're claiming that the compiler shouldn't warn about this.)

This is a case where the ill-advised code seemingly works, and for all
practical purposes it works.  And yet it should be avoided because in Java
9 it will no longer work.  Shouldn't the compiler warn about that if/when
it can?


On Sat, Nov 30, 2013 at 9:23 PM, Brian Goetz <brian.goetz at oracle.com> wrote:

>
> 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.
>
>
>
>>>>>
>>>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/lambda-libs-spec-experts/attachments/20131130/93dd1933/attachment.html 

From brian.goetz at oracle.com  Sat Nov 30 21:52:21 2013
From: brian.goetz at oracle.com (Brian Goetz)
Date: Sun, 1 Dec 2013 00:52:21 -0500
Subject: A disclaimer or two for Optional
In-Reply-To: <CAHzJPEq8J_0yS3FxOV26+orNi9CU-STngNPgfwaCkG0RpKTcZQ@mail.gmail.com>
References: <5262CC71.3020606@cs.oswego.edu> <52951426.6030700@oracle.com>
	<CAHzJPEo4uSVm512j+TR0r-M6oO-QpvZ635V6bQqzh5Pq+gjBqg@mail.gmail.com>
	<22CAB85E-C0CB-44DD-993C-3C717DE3A34C@oracle.com>
	<CAHzJPEpa+hR_7+F1a-uOwbhiGSW9rGXig4fD++zWZcg-1q4nuA@mail.gmail.com>
	<CA+F8eeQ-KR-hGgBfGP8sMM5ju09iRZPrX3sbnFCj7Z=fwQVqMw@mail.gmail.com>
	<CAHzJPEorCU1GuDP6GE6t6SUDjddVRZUg7r8=h48r+MjcLmGspg@mail.gmail.com>
	<863F6A4B-D30A-4094-A32C-D0A21CD96185@oracle.com>
	<CAHzJPEq8J_0yS3FxOV26+orNi9CU-STngNPgfwaCkG0RpKTcZQ@mail.gmail.com>
Message-ID: <C2D2614E-6F77-4E6A-9FE8-66BF3B96B887@oracle.com>

There is certainly something about the current date that prohibits any consideration of further language work at this time...



Sent from my iPad

On Dec 1, 2013, at 12:28 AM, Joe Bowbeer <joe.bowbeer at gmail.com> wrote:

> Is there something about this case that prohibits compiler warnings?
> 
> > It is not possible for the compiler to understand and enforce every library-based invariant.
> 
> The compiler emits a lot of warnings about dubious code that should be avoided.  Why wouldn't you want the compiler to warn about this one?  (It seems like you're claiming that the compiler shouldn't warn about this.)
> 
> This is a case where the ill-advised code seemingly works, and for all practical purposes it works.  And yet it should be avoided because in Java 9 it will no longer work.  Shouldn't the compiler warn about that if/when it can?
> 
> 
> On Sat, Nov 30, 2013 at 9:23 PM, Brian Goetz <brian.goetz at oracle.com> wrote:
>> 
>>> 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.  
>> 
>> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/lambda-libs-spec-experts/attachments/20131201/4718fc0a/attachment-0001.html