From Vladimir.Zakharov at gs.com  Sun Dec  1 21:18:15 2013
From: Vladimir.Zakharov at gs.com (Zakharov, Vladimir)
Date: Mon, 2 Dec 2013 00:18:15 -0500
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: <CC083D55BC84324BAD626880FD266983173A388871@GSCMAMP02EX.firmwide.corp.gs.com>

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.




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

From spullara at gmail.com  Sun Dec  1 21:29:01 2013
From: spullara at gmail.com (Sam Pullara)
Date: Sun, 1 Dec 2013 21:29:01 -0800
Subject: Closing the Stream returned from BufferedReader.lines()
In-Reply-To: <CACuKZqFRL6aF=G-uFfG90EN50iasiB72C_EF5S_VmF2VRM4LsA@mail.gmail.com>
References: <CACuKZqFRL6aF=G-uFfG90EN50iasiB72C_EF5S_VmF2VRM4LsA@mail.gmail.com>
Message-ID: <60A36212-717E-42B4-B86F-87DFD479936E@gmail.com>

This must be a bug, right? Isn't this the reason we added AutoCloseable to streams?

Sam

On Dec 1, 2013, at 7:03 PM, Zhong Yu <zhong.j.yu at gmail.com> wrote:

> In this code
> 
>        BufferedReader br = ...;
>        Stream<String> stream = br.lines();
>        stream.close();  // does not close `br`
> 
> `stream.close()` does not trigger `br.close()`. I for one find that
> rather counter-intuitive. Can you guys explain the design choice? When
> should a Stream forward close() to its source and when should it not?
> 
> see http://stackoverflow.com/questions/20319417
> 
> Zhong Yu
> 


From brian.goetz at oracle.com  Tue Dec  3 14:33:45 2013
From: brian.goetz at oracle.com (Brian Goetz)
Date: Tue, 03 Dec 2013 17:33:45 -0500
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: <529E5C49.6040500@oracle.com>

Draft of final proposed spec at:
   http://cr.openjdk.java.net/~mduigou/JDK-8028816/0/webrev/

On 11/26/2013 4:35 PM, Brian Goetz 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>
>

From forax at univ-mlv.fr  Sat Dec  7 08:57:20 2013
From: forax at univ-mlv.fr (Remi Forax)
Date: Sat, 07 Dec 2013 17:57:20 +0100
Subject: Collectors.groupingBy(classifier, downstream) signatue is not correct
Message-ID: <52A35370.7000300@univ-mlv.fr>

This is something, I have discovered with Paul during Devoxx,
that I had forgotten until one of my student stubble on the very same 
issue Wednesday,
it's not a big issue, it's just something annoying.

Collectors.groupingBy that takes another collector as downstream 
collector is typed like this:
public static <T, K, A, D>
     Collector<T, ?, Map<K, D>> groupingBy(Function<? super T, ? extends 
K> classifier,
                                           Collector<? super T, A, D> 
downstream) {
         ...
     }

here declaring A is useless because it is used only to type downstream.

This is annoying because another rule of Java,
when you specify implicitly a type argument for a type variable,
you cannot use '?' even if the type variable appears in place where '?' 
is allowed.
So the compiler is able to capture a wildcard to a type varaible but
a user can not do the same thing explicitly.

My student was trying to understand why the compiler was not compiling 
its code (hint: he fails to check the spelling first) and to isolate the 
issue, he was trying to explicitly specify the type argument.

I think the signature of groupBy (the one that takes a downstream)
should be
   public static <T, K, D>
     Collector<T, ?, Map<K, D>> groupingBy(Function<? super T, ? extends 
K> classifier,
                                           Collector<? super T, ?, D> 
downstream) {
         ...
     }

(the declaration of A is removed and A is replaced by '?')

cheers,
R?mi


From brian.goetz at oracle.com  Sat Dec  7 09:27:06 2013
From: brian.goetz at oracle.com (Brian Goetz)
Date: Sat, 07 Dec 2013 12:27:06 -0500
Subject: Collectors.groupingBy(classifier, downstream) signatue is not
	correct
In-Reply-To: <52A35370.7000300@univ-mlv.fr>
References: <52A35370.7000300@univ-mlv.fr>
Message-ID: <52A35A6A.70008@oracle.com>

Yes, the two would be basically identical from a client perspective, 
since the only appearance of A is in a type argument of Collector.  I 
think I may even have written it that way originally!  And I think what 
pushed me into doing it this way is that if the Collector's A argument 
is a wildcard, then the whole rest of the implementation can't use A 
either, but instead would have to use ? or Object.  For example:

         Supplier<A> downstreamSupplier = downstream.supplier();
         BiConsumer<A, ? super T> downstreamAccumulator = 
downstream.accumulator();
         BiConsumer<Map<K, A>, T> accumulator = (m, t) -> {
             K key = Objects.requireNonNull(classifier.apply(t), 
"element cannot be mapped to a null key");
             A container = m.computeIfAbsent(key, k -> 
downstreamSupplier.get());
             downstreamAccumulator.accept(container, t);
         };
        ...

Being able to use A here in the implementation makes it more readable 
and enables more type checking.  And "A" shows up a lot in this code.


On 12/7/2013 11:57 AM, Remi Forax wrote:
> This is something, I have discovered with Paul during Devoxx,
> that I had forgotten until one of my student stubble on the very same
> issue Wednesday,
> it's not a big issue, it's just something annoying.
>
> Collectors.groupingBy that takes another collector as downstream
> collector is typed like this:
> public static <T, K, A, D>
>      Collector<T, ?, Map<K, D>> groupingBy(Function<? super T, ? extends
> K> classifier,
>                                            Collector<? super T, A, D>
> downstream) {
>          ...
>      }
>
> here declaring A is useless because it is used only to type downstream.
>
> This is annoying because another rule of Java,
> when you specify implicitly a type argument for a type variable,
> you cannot use '?' even if the type variable appears in place where '?'
> is allowed.
> So the compiler is able to capture a wildcard to a type varaible but
> a user can not do the same thing explicitly.
>
> My student was trying to understand why the compiler was not compiling
> its code (hint: he fails to check the spelling first) and to isolate the
> issue, he was trying to explicitly specify the type argument.
>
> I think the signature of groupBy (the one that takes a downstream)
> should be
>    public static <T, K, D>
>      Collector<T, ?, Map<K, D>> groupingBy(Function<? super T, ? extends
> K> classifier,
>                                            Collector<? super T, ?, D>
> downstream) {
>          ...
>      }
>
> (the declaration of A is removed and A is replaced by '?')
>
> cheers,
> R?mi
>

From paul.sandoz at oracle.com  Tue Dec 17 00:42:39 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 17 Dec 2013 09:42:39 +0100
Subject: Stream + BaseStream
In-Reply-To: <CAPs6150T5V3SVmVTOBzKddiks7MgXo_dLw39ttFJ1HhzzyFW0Q@mail.gmail.com>
References: <CAPs6150T5V3SVmVTOBzKddiks7MgXo_dLw39ttFJ1HhzzyFW0Q@mail.gmail.com>
Message-ID: <CAEA6DAA-89C0-4911-B155-C87E03810830@oracle.com>


On Dec 16, 2013, at 11:23 PM, Kasper Nielsen <kasperni at gmail.com> wrote:

> Hi,
> 
> IntStream/LongStream/DoubleStream all override
> 
> sequential(), parallel(), unordered(), ... from BaseStream.
> 
> However Stream does not override this methods

It does:

  public interface Stream<T> extends BaseStream<T, Stream<T>>


> so you have to cast the
> stream if you are you a using a non-parameterized stream, as in:
> Stream s = *null*;
> s = (Stream) s.unordered();
> 

Because a raw-typed Stream is used, and therefore a raw type for BaseStream, the compiler cannot infer S and has to resort to using the upper bound, BaseStream:

  public interface BaseStream<T, S extends BaseStream<T, S>>

Using a raw type for Stream will also have other consequences for type inference when chaining operations. I have seen a number of examples highlighting issues (posted to various lists) that were in part broken because a raw type for Stream was used. I would recommend avoiding such use if at all possible.

Paul.


From paul.sandoz at oracle.com  Tue Dec 17 00:47:47 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 17 Dec 2013 09:47:47 +0100
Subject: Int/Long/DoubleSummaryStatistics and serialization
In-Reply-To: <CAPs6151=0wG8+aDDs7vWoO8a2d34ULHkMtQQtxyrs2nWksF+_w@mail.gmail.com>
References: <CAPs6151=0wG8+aDDs7vWoO8a2d34ULHkMtQQtxyrs2nWksF+_w@mail.gmail.com>
Message-ID: <80D07C92-7E85-455B-B488-DB0A3B513B0B@oracle.com>


On Dec 16, 2013, at 11:09 PM, Kasper Nielsen <kasperni at gmail.com> wrote:

> Hi,
> 
> I'm trying to send a IntSummaryStatistics across a network.
> However it is basically impossible because IntSummaryStatistics
> is neither Serializable nor provides a IntSummaryStatistics(count, sum,
> min, max) constructor.
> 
> It would be really helpful if IntSummaryStatistics (and friends) could
> a) provide a IntSummaryStatistics(count, sum, min, max) constructor.
> b) implement Serializable
> 

Noted, thanks. Unlikely to be fixed for 8.

Paul.

From paul.sandoz at oracle.com  Tue Dec 17 03:34:07 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 17 Dec 2013 12:34:07 +0100
Subject: Stream + BaseStream
In-Reply-To: <CAPs61508afyK2=HKzaBwWcq4GVLoThVGcE5A9cqjU6rVwuKshQ@mail.gmail.com>
References: <CAPs6150T5V3SVmVTOBzKddiks7MgXo_dLw39ttFJ1HhzzyFW0Q@mail.gmail.com>
	<CAEA6DAA-89C0-4911-B155-C87E03810830@oracle.com>
	<CAPs61508afyK2=HKzaBwWcq4GVLoThVGcE5A9cqjU6rVwuKshQ@mail.gmail.com>
Message-ID: <B34ED63E-A99E-4A6F-B10B-515BA8D386E5@oracle.com>

On Dec 17, 2013, at 11:41 AM, Kasper Nielsen <kasperni at gmail.com> wrote:
> Sorry didn't make myself clear.
> 

Ah, i see now, thanks. Yes, that could improve things, but still one may run into issues when chaining operations.

I am partly inclined to leave things as they are since it makes it more difficult to use Stream as a raw type :-) although that does seem a little mean.

Paul.

> What I was hinting at, was covariant overrides of onClose(), parallel(),
> sequential(), unordered() in Stream such as
> 
> Stream.java
> 
>    /** {@inheritDoc} */
> 
>    Stream<T> unordered();
> 
>    /** {@inheritDoc} */
> 
>    Stream<T> parallel();
> .....
>