From scolebourne at joda.org  Fri Feb  1 06:30:48 2013
From: scolebourne at joda.org (Stephen Colebourne)
Date: Fri, 1 Feb 2013 14:30:48 +0000
Subject: Error using static interface methods
Message-ID: <CACzrW9CykhqBwD=OVCpOWWMtcwGy_OxvZZ8LsTeB8C-RUpc7Qg@mail.gmail.com>

This morning I pulled and rebuilt configure/build/images NEWBUILD from
the repos in http://hg.openjdk.java.net/threeten/threeten which were
synced last night by Roger Riggs. Note the non mainline repo.

The static interface methods compile fine, but I'm unable to call them
without a verify error:

java.lang.VerifyError: Illegal type at constant pool entry 4 in class
tck.java.time.chrono.TCKChronoLocalDate
Exception Details:
  Location:
    tck/java/time/chrono/TCKChronoLocalDate.factory_from_TemporalAccessor()V
@8: invokestatic
  Reason:
    Constant pool index 4 is invalid
  Bytecode:
    0000000: bb00 0259 2ab7 0003 b800 044c 2b11 07dc
    0000010: 1006 101e b800 05b8 0006 b1

another example:

java.lang.VerifyError: Illegal type at constant pool entry 2 in class
tck.java.time.chrono.TCKChronoLocalDate
Exception Details:
  Location:
    tck/java/time/chrono/TCKChronoLocalDate.factory_from_TemporalAccessor_null()V
@1: invokestatic
  Reason:
    Constant pool index 2 is invalid
  Bytecode:
    0000000: 01b8 0002 57b1


It could be that the hotspot/langtools has a mismatch somewhere in
http://hg.openjdk.java.net/threeten/threeten.

Any thoughts?
Stephen

From georgiy.rakov at oracle.com  Fri Feb  1 06:43:04 2013
From: georgiy.rakov at oracle.com (Georgiy Rakov)
Date: Fri, 01 Feb 2013 18:43:04 +0400
Subject: sum return type for primitive streams
Message-ID: <510BD478.2000401@oracle.com>

Hello,

IntStream sum method return type is a primitive while the return type of 
min, max, average is Optional...:

         default long sum() {
             return collect(Collectors.intSumAsLong()).sum();
         }

         default OptionalInt min() {
             return reduce(Math::min);
         }

         default OptionalInt max() {
             return reduce(Math::max);
         }

         default OptionalDouble average() {
             return collect(Collectors.intCountAndSumAsLong()).mean();
         }

Could you please tell if it's a bug or expected behavior. If it's 
expected behavior could you please clarify why it is because from the 
first glance OptionalLong should be the return type for sum method.

The same is true for DoubleStream and LongStream.

Thank you, Georgiy.

From ali.ebrahimi1781 at gmail.com  Fri Feb  1 06:54:32 2013
From: ali.ebrahimi1781 at gmail.com (Ali Ebrahimi)
Date: Fri, 1 Feb 2013 19:24:32 +0430
Subject: Error using static interface methods
In-Reply-To: <CACzrW9CykhqBwD=OVCpOWWMtcwGy_OxvZZ8LsTeB8C-RUpc7Qg@mail.gmail.com>
References: <CACzrW9CykhqBwD=OVCpOWWMtcwGy_OxvZZ8LsTeB8C-RUpc7Qg@mail.gmail.com>
Message-ID: <CAA0cW5DeMheTuCffxib366U5gbG0+5CmM_afsfNoOZuLiGMFYQ@mail.gmail.com>

Hi,
verifier does not fully support static interface methods yet. for
workaround try this :
-Xverify:none

Ali

On Fri, Feb 1, 2013 at 7:00 PM, Stephen Colebourne <scolebourne at joda.org>wrote:

> This morning I pulled and rebuilt configure/build/images NEWBUILD from
> the repos in http://hg.openjdk.java.net/threeten/threeten which were
> synced last night by Roger Riggs. Note the non mainline repo.
>
> The static interface methods compile fine, but I'm unable to call them
> without a verify error:
>
> java.lang.VerifyError: Illegal type at constant pool entry 4 in class
> tck.java.time.chrono.TCKChronoLocalDate
> Exception Details:
>   Location:
>
> tck/java/time/chrono/TCKChronoLocalDate.factory_from_TemporalAccessor()V
> @8: invokestatic
>   Reason:
>     Constant pool index 4 is invalid
>   Bytecode:
>     0000000: bb00 0259 2ab7 0003 b800 044c 2b11 07dc
>     0000010: 1006 101e b800 05b8 0006 b1
>
> another example:
>
> java.lang.VerifyError: Illegal type at constant pool entry 2 in class
> tck.java.time.chrono.TCKChronoLocalDate
> Exception Details:
>   Location:
>
> tck/java/time/chrono/TCKChronoLocalDate.factory_from_TemporalAccessor_null()V
> @1: invokestatic
>   Reason:
>     Constant pool index 2 is invalid
>   Bytecode:
>     0000000: 01b8 0002 57b1
>
>
> It could be that the hotspot/langtools has a mismatch somewhere in
> http://hg.openjdk.java.net/threeten/threeten.
>
> Any thoughts?
> Stephen
>
>

From brian.goetz at oracle.com  Fri Feb  1 07:07:35 2013
From: brian.goetz at oracle.com (Brian Goetz)
Date: Fri, 01 Feb 2013 10:07:35 -0500
Subject: sum return type for primitive streams
In-Reply-To: <510BD478.2000401@oracle.com>
References: <510BD478.2000401@oracle.com>
Message-ID: <510BDA37.1000702@oracle.com>

That is correct behavior.

The integers form a monoid under +, whose identity is zero.  Therefore, 
there is a sensible result value when there are no elements to sum.

The min/max operations on integers, on the other hand, have no sensible 
identity value.  If we picked one (e.g., have min() return 
Integer.MAX_VALUE), we would be unable to distinguish between the result 
of min'ing no elements and min'ing a list that happened to contain only 
that distinguished value.  (This is the problem that Map.get() has -- 
when you get null, you don't know whether there's no mapping or the key 
is mapped to null.)

There were some who suggested we do this anyway.  There were others who 
suggested we force the user to pass in their "poison" value to min/max. 
  In the end, we use Optional where we must, and avoid Optional where we 
can.

On 2/1/2013 9:43 AM, Georgiy Rakov wrote:
> Hello,
>
> IntStream sum method return type is a primitive while the return type of
> min, max, average is Optional...:
>
>           default long sum() {
>               return collect(Collectors.intSumAsLong()).sum();
>           }
>
>           default OptionalInt min() {
>               return reduce(Math::min);
>           }
>
>           default OptionalInt max() {
>               return reduce(Math::max);
>           }
>
>           default OptionalDouble average() {
>               return collect(Collectors.intCountAndSumAsLong()).mean();
>           }
>
> Could you please tell if it's a bug or expected behavior. If it's
> expected behavior could you please clarify why it is because from the
> first glance OptionalLong should be the return type for sum method.
>
> The same is true for DoubleStream and LongStream.
>
> Thank you, Georgiy.
>

From kevinb at google.com  Fri Feb  1 07:09:06 2013
From: kevinb at google.com (Kevin Bourrillion)
Date: Fri, 1 Feb 2013 07:09:06 -0800
Subject: sum return type for primitive streams
In-Reply-To: <510BD478.2000401@oracle.com>
References: <510BD478.2000401@oracle.com>
Message-ID: <CAGKkBkv9PTL82cxAXXKRSM_hwwC+Q6PwbvV3KszqL8zXxQTLOg@mail.gmail.com>

The sum of no values is mathematically well-defined (zero); the others are
not.


On Fri, Feb 1, 2013 at 6:43 AM, Georgiy Rakov <georgiy.rakov at oracle.com>wrote:

> Hello,
>
> IntStream sum method return type is a primitive while the return type of
> min, max, average is Optional...:
>
>          default long sum() {
>              return collect(Collectors.intSumAsLong()).sum();
>          }
>
>          default OptionalInt min() {
>              return reduce(Math::min);
>          }
>
>          default OptionalInt max() {
>              return reduce(Math::max);
>          }
>
>          default OptionalDouble average() {
>              return collect(Collectors.intCountAndSumAsLong()).mean();
>          }
>
> Could you please tell if it's a bug or expected behavior. If it's
> expected behavior could you please clarify why it is because from the
> first glance OptionalLong should be the return type for sum method.
>
> The same is true for DoubleStream and LongStream.
>
> Thank you, Georgiy.
>
>


-- 
Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com

From luc.duponcheel at gmail.com  Fri Feb  1 07:14:28 2013
From: luc.duponcheel at gmail.com (Luc Duponcheel)
Date: Fri, 1 Feb 2013 16:14:28 +0100
Subject: No subject
Message-ID: <CADO5TNt5XvcirQTQBUi2uMi+bOdo8LT3CoVcF0Bk5yNKaCdGVg@mail.gmail.com>

Hello,

I have a (hopefully) very simple question about spliterators

consider something like

  Spliterator<Integer> spliterator =
   // ... make a spliterator

  spliterator.forEach(integer ->
    new Integer(integer.intValue() + 1)
   );

does the foreach method "just work"
(I mean: will it try to split)

or do I somehow have to invoke the trySplit() method myself

thx

Luc

-- 
   __~O
  -\ <,
(*)/ (*)

reality goes far beyond imagination

From brian.goetz at oracle.com  Fri Feb  1 07:33:51 2013
From: brian.goetz at oracle.com (Brian Goetz)
Date: Fri, 01 Feb 2013 10:33:51 -0500
Subject: 
In-Reply-To: <CADO5TNt5XvcirQTQBUi2uMi+bOdo8LT3CoVcF0Bk5yNKaCdGVg@mail.gmail.com>
References: <CADO5TNt5XvcirQTQBUi2uMi+bOdo8LT3CoVcF0Bk5yNKaCdGVg@mail.gmail.com>
Message-ID: <510BE05F.4090209@oracle.com>

It "just works", but it doesn't try to split ;)

Spliterator is NOT a parallel execution framework.  It is the low-level 
adapter type that lets an arbitrary data structure (array, List, 
whatever) feed data into a parallel execution framework.  Think of it as 
the parallel analogue of Iterator, but the framework has to decide when 
to split.

Spliterator is not meant for most devs to use; only for developers of 
library-based aggregates.  EVeryone else will do:

   list.parallelStream().forEach(...)

and get what you are looking for.

On 2/1/2013 10:14 AM, Luc Duponcheel wrote:
> Hello,
>
> I have a (hopefully) very simple question about spliterators
>
> consider something like
>
>    Spliterator<Integer> spliterator =
>     // ... make a spliterator
>
>    spliterator.forEach(integer ->
>      new Integer(integer.intValue() + 1)
>     );
>
> does the foreach method "just work"
> (I mean: will it try to split)
>
> or do I somehow have to invoke the trySplit() method myself
>
> thx
>
> Luc
>

From scolebourne at joda.org  Fri Feb  1 07:38:16 2013
From: scolebourne at joda.org (Stephen Colebourne)
Date: Fri, 1 Feb 2013 15:38:16 +0000
Subject: Error using static interface methods
In-Reply-To: <CAA0cW5DeMheTuCffxib366U5gbG0+5CmM_afsfNoOZuLiGMFYQ@mail.gmail.com>
References: <CACzrW9CykhqBwD=OVCpOWWMtcwGy_OxvZZ8LsTeB8C-RUpc7Qg@mail.gmail.com>
	<CAA0cW5DeMheTuCffxib366U5gbG0+5CmM_afsfNoOZuLiGMFYQ@mail.gmail.com>
Message-ID: <CACzrW9C8m+HdVhtHMzB+f6Qk=zsxDmzdO83-CzNyvfPNkn-75w@mail.gmail.com>

OK thanks
Stephen

On 1 February 2013 14:54, Ali Ebrahimi <ali.ebrahimi1781 at gmail.com> wrote:
> Hi,
> verifier does not fully support static interface methods yet. for workaround
> try this :
> -Xverify:none
>
> Ali
>
>
> On Fri, Feb 1, 2013 at 7:00 PM, Stephen Colebourne <scolebourne at joda.org>
> wrote:
>>
>> This morning I pulled and rebuilt configure/build/images NEWBUILD from
>> the repos in http://hg.openjdk.java.net/threeten/threeten which were
>> synced last night by Roger Riggs. Note the non mainline repo.
>>
>> The static interface methods compile fine, but I'm unable to call them
>> without a verify error:
>>
>> java.lang.VerifyError: Illegal type at constant pool entry 4 in class
>> tck.java.time.chrono.TCKChronoLocalDate
>> Exception Details:
>>   Location:
>>
>> tck/java/time/chrono/TCKChronoLocalDate.factory_from_TemporalAccessor()V
>> @8: invokestatic
>>   Reason:
>>     Constant pool index 4 is invalid
>>   Bytecode:
>>     0000000: bb00 0259 2ab7 0003 b800 044c 2b11 07dc
>>     0000010: 1006 101e b800 05b8 0006 b1
>>
>> another example:
>>
>> java.lang.VerifyError: Illegal type at constant pool entry 2 in class
>> tck.java.time.chrono.TCKChronoLocalDate
>> Exception Details:
>>   Location:
>>
>> tck/java/time/chrono/TCKChronoLocalDate.factory_from_TemporalAccessor_null()V
>> @1: invokestatic
>>   Reason:
>>     Constant pool index 2 is invalid
>>   Bytecode:
>>     0000000: 01b8 0002 57b1
>>
>>
>> It could be that the hotspot/langtools has a mismatch somewhere in
>> http://hg.openjdk.java.net/threeten/threeten.
>>
>> Any thoughts?
>> Stephen
>>
>

From alahijani at gmail.com  Fri Feb  1 08:00:08 2013
From: alahijani at gmail.com (Ali Lahijani)
Date: Fri, 1 Feb 2013 19:30:08 +0330
Subject: sum return type for primitive streams
In-Reply-To: <510BDA37.1000702@oracle.com>
References: <510BD478.2000401@oracle.com>
	<510BDA37.1000702@oracle.com>
Message-ID: <CACygQvkD_t_k_KrGZ+ZCGSRg_1f8xRYxvWviVtSsjAGgqbfX+w@mail.gmail.com>

On Fri, Feb 1, 2013 at 6:37 PM, Brian Goetz <brian.goetz at oracle.com> wrote:

> That is correct behavior.
>
> The integers form a monoid under +, whose identity is zero.  Therefore,
> there is a sensible result value when there are no elements to sum.
>
> The min/max operations on integers, on the other hand, have no sensible
> identity value.


Sorry to bring it up again, but integers also form a monoid under min, max.
With Integer.MIN_VALUE and Integer.MAX_VALUE being the obvious identities.

Actually much better: they form a semi-lattice (a commutative and
idempotent monoid).
And the two operations are dual to each other, so they even form a
commutative lattice.


> If we picked one (e.g., have min() return
> Integer.MAX_VALUE), we would be unable to distinguish between the result
> of min'ing no elements and min'ing a list that happened to contain only
> that distinguished value.  (This is the problem that Map.get() has --
> when you get null, you don't know whether there's no mapping or the key
> is mapped to null.)
>

This is absolutely no different from sum (at least in principle).
We are unable to distinguish between the result of summing no elements and
summing a list that happened to contain only zeros.

Contrast this with average() which is not defined on an empty list because
that would involve division by zero.

There were some who suggested we do this anyway.  There were others who
> suggested we force the user to pass in their "poison" value to min/max.
>   In the end, we use Optional where we must, and avoid Optional where we
> can.
>
> On 2/1/2013 9:43 AM, Georgiy Rakov wrote:
> > Hello,
> >
> > IntStream sum method return type is a primitive while the return type of
> > min, max, average is Optional...:
> >
> >           default long sum() {
> >               return collect(Collectors.intSumAsLong()).sum();
> >           }
> >
> >           default OptionalInt min() {
> >               return reduce(Math::min);
> >           }
> >
> >           default OptionalInt max() {
> >               return reduce(Math::max);
> >           }
> >
> >           default OptionalDouble average() {
> >               return collect(Collectors.intCountAndSumAsLong()).mean();
> >           }
> >
> > Could you please tell if it's a bug or expected behavior. If it's
> > expected behavior could you please clarify why it is because from the
> > first glance OptionalLong should be the return type for sum method.
> >
> > The same is true for DoubleStream and LongStream.
> >
> > Thank you, Georgiy.
> >
>
>
Best
Ali

From peter.levart at gmail.com  Fri Feb  1 08:07:10 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Fri, 01 Feb 2013 17:07:10 +0100
Subject: sum return type for primitive streams
In-Reply-To: <510BD478.2000401@oracle.com>
References: <510BD478.2000401@oracle.com>
Message-ID: <510BE82E.1070505@gmail.com>

On 02/01/2013 03:43 PM, Georgiy Rakov wrote:
> Hello,
>
> IntStream sum method return type is a primitive while the return type of
> min, max, average is Optional...:
>
>           default long sum() {
>               return collect(Collectors.intSumAsLong()).sum();
>           }
>
>           default OptionalInt min() {
>               return reduce(Math::min);
>           }
>
>           default OptionalInt max() {
>               return reduce(Math::max);
>           }
>
>           default OptionalDouble average() {
>               return collect(Collectors.intCountAndSumAsLong()).mean();
>           }
>
> Could you please tell if it's a bug or expected behavior. If it's
> expected behavior could you please clarify why it is because from the
> first glance OptionalLong should be the return type for sum method.
>
> The same is true for DoubleStream and LongStream.
Hi Georgiy,

http://en.wikipedia.org/wiki/Empty_sum

According to above, even the return type of average() could be double 
(not OptionalDouble)...

Regards, Peter

>
> Thank you, Georgiy.
>


From luc.duponcheel at gmail.com  Fri Feb  1 08:22:58 2013
From: luc.duponcheel at gmail.com (Luc Duponcheel)
Date: Fri, 1 Feb 2013 17:22:58 +0100
Subject: 
In-Reply-To: <510BE05F.4090209@oracle.com>
References: <CADO5TNt5XvcirQTQBUi2uMi+bOdo8LT3CoVcF0Bk5yNKaCdGVg@mail.gmail.com>
	<510BE05F.4090209@oracle.com>
Message-ID: <CADO5TNtFA4TsNAu0t=4Jtowk=hS7_a+G5orJX21p1hGB9MZS8A@mail.gmail.com>

thanks so much

it is always a bit tricky to know which methods are for
app developers and which ones are for lib developers

I worked with the parallel stream alternative already
( but was intrigued by the spliterator as well :-) )

Luc


On Fri, Feb 1, 2013 at 4:33 PM, Brian Goetz <brian.goetz at oracle.com> wrote:

> It "just works", but it doesn't try to split ;)
>
> Spliterator is NOT a parallel execution framework.  It is the low-level
> adapter type that lets an arbitrary data structure (array, List, whatever)
> feed data into a parallel execution framework.  Think of it as the parallel
> analogue of Iterator, but the framework has to decide when to split.
>
> Spliterator is not meant for most devs to use; only for developers of
> library-based aggregates.  EVeryone else will do:
>
>   list.parallelStream().forEach(**...)
>
> and get what you are looking for.
>
>
> On 2/1/2013 10:14 AM, Luc Duponcheel wrote:
>
>> Hello,
>>
>> I have a (hopefully) very simple question about spliterators
>>
>> consider something like
>>
>>    Spliterator<Integer> spliterator =
>>     // ... make a spliterator
>>
>>    spliterator.forEach(integer ->
>>      new Integer(integer.intValue() + 1)
>>     );
>>
>> does the foreach method "just work"
>> (I mean: will it try to split)
>>
>> or do I somehow have to invoke the trySplit() method myself
>>
>> thx
>>
>> Luc
>>
>>


-- 
   __~O
  -\ <,
(*)/ (*)

reality goes far beyond imagination

From brian.goetz at oracle.com  Fri Feb  1 08:48:41 2013
From: brian.goetz at oracle.com (Brian Goetz)
Date: Fri, 01 Feb 2013 11:48:41 -0500
Subject: sum return type for primitive streams
In-Reply-To: <CACygQvkD_t_k_KrGZ+ZCGSRg_1f8xRYxvWviVtSsjAGgqbfX+w@mail.gmail.com>
References: <510BD478.2000401@oracle.com> <510BDA37.1000702@oracle.com>
	<CACygQvkD_t_k_KrGZ+ZCGSRg_1f8xRYxvWviVtSsjAGgqbfX+w@mail.gmail.com>
Message-ID: <510BF1E9.7090403@oracle.com>

> Sorry to bring it up again, but integers also form a monoid under min, max.
> With Integer.MIN_VALUE and Integer.MAX_VALUE being the obvious identities.

And what about longs?  Having the same operation with different 
identities for coincident sets is pretty confusing.

> This is absolutely no different from sum (at least in principle).
> We are unable to distinguish between the result of summing no elements
> and summing a list that happened to contain only zeros.

Except that the sum of no elements can reasonably be considered to be 
zero, so the ambiguity is largely academic.  The minimum value of an 
empty set is NOT Integer.MAX_VALUE under any reasonable view of reality.

From brian.goetz at oracle.com  Fri Feb  1 08:50:19 2013
From: brian.goetz at oracle.com (Brian Goetz)
Date: Fri, 01 Feb 2013 11:50:19 -0500
Subject: 
In-Reply-To: <CADO5TNtFA4TsNAu0t=4Jtowk=hS7_a+G5orJX21p1hGB9MZS8A@mail.gmail.com>
References: <CADO5TNt5XvcirQTQBUi2uMi+bOdo8LT3CoVcF0Bk5yNKaCdGVg@mail.gmail.com>
	<510BE05F.4090209@oracle.com>
	<CADO5TNtFA4TsNAu0t=4Jtowk=hS7_a+G5orJX21p1hGB9MZS8A@mail.gmail.com>
Message-ID: <510BF24B.80809@oracle.com>

Spliterator is cool because it means all you have to do to be a source 
for parallel streams -- thereby getting all the benefits of 
filter/map/reduce/etc -- is provide a Spliterator, and the library does 
the rest.

If you cannot come up with a Spliterator, we can convert an Iterator to 
a Spliterator, and even extract *some* parallelism.  Obviously not as 
much as a well-tuned spliterator that produces exact binary splits, but 
still better than nothing.



On 2/1/2013 11:22 AM, Luc Duponcheel wrote:
> thanks so much
>
> it is always a bit tricky to know which methods are for
> app developers and which ones are for lib developers
>
> I worked with the parallel stream alternative already
> ( but was intrigued by the spliterator as well :-) )
>
> Luc
>
>
> On Fri, Feb 1, 2013 at 4:33 PM, Brian Goetz <brian.goetz at oracle.com
> <mailto:brian.goetz at oracle.com>> wrote:
>
>     It "just works", but it doesn't try to split ;)
>
>     Spliterator is NOT a parallel execution framework.  It is the
>     low-level adapter type that lets an arbitrary data structure (array,
>     List, whatever) feed data into a parallel execution framework.
>       Think of it as the parallel analogue of Iterator, but the
>     framework has to decide when to split.
>
>     Spliterator is not meant for most devs to use; only for developers
>     of library-based aggregates.  EVeryone else will do:
>
>        list.parallelStream().forEach(__...)
>
>     and get what you are looking for.
>
>
>     On 2/1/2013 10:14 AM, Luc Duponcheel wrote:
>
>         Hello,
>
>         I have a (hopefully) very simple question about spliterators
>
>         consider something like
>
>             Spliterator<Integer> spliterator =
>              // ... make a spliterator
>
>             spliterator.forEach(integer ->
>               new Integer(integer.intValue() + 1)
>              );
>
>         does the foreach method "just work"
>         (I mean: will it try to split)
>
>         or do I somehow have to invoke the trySplit() method myself
>
>         thx
>
>         Luc
>
>
>
>
> --
>     __~O
>    -\ <,
> (*)/ (*)
>
> reality goes far beyond imagination

From alahijani at gmail.com  Fri Feb  1 09:23:55 2013
From: alahijani at gmail.com (Ali Lahijani)
Date: Fri, 1 Feb 2013 20:53:55 +0330
Subject: sum return type for primitive streams
In-Reply-To: <510BF1E9.7090403@oracle.com>
References: <510BD478.2000401@oracle.com> <510BDA37.1000702@oracle.com>
	<CACygQvkD_t_k_KrGZ+ZCGSRg_1f8xRYxvWviVtSsjAGgqbfX+w@mail.gmail.com>
	<510BF1E9.7090403@oracle.com>
Message-ID: <CACygQvkX2uNUAk6dn-GZ1eOUdajmFBSpvMPgiKpjF-kBSUCY9A@mail.gmail.com>

On Fri, Feb 1, 2013 at 8:18 PM, Brian Goetz <brian.goetz at oracle.com> wrote:

> Sorry to bring it up again, but integers also form a monoid under min, max.
>> With Integer.MIN_VALUE and Integer.MAX_VALUE being the obvious identities.
>>
>
> And what about longs?  Having the same operation with different identities
> for coincident sets is pretty confusing.


You're right, we usually view int and long as approximations of
mathematical integers, which have no top/bottom elements. So main/max on
pure infinite integers (BigIntegers) do not have an identity.

One could argue that when you are using an IntStream or LongStream instead
of a Steam<BigIntegers>, you have already decided that you only need a
finite subset of mathematical integers, so you should be prepared to see
MIN_VALUE and MAX_VALUE used as positive/negative infinity. But I don't see
that argument persuading anyone.

So, in such an imperfect world, I guess there is no better answer for this
question.

Best

From maurizio.cimadamore at oracle.com  Fri Feb  1 09:23:38 2013
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Fri, 01 Feb 2013 17:23:38 +0000
Subject: hg: lambda/lambda/langtools: Merge graph and legacy inference engines
Message-ID: <20130201172343.76B0E4775F@hg.openjdk.java.net>

Changeset: 6a304c200a29
Author:    mcimadamore
Date:      2013-02-01 17:23 +0000
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/6a304c200a29

Merge graph and legacy inference engines

! src/share/classes/com/sun/tools/javac/code/Source.java
! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/Check.java
! src/share/classes/com/sun/tools/javac/comp/DeferredAttr.java
- src/share/classes/com/sun/tools/javac/comp/GraphInfer.java
! src/share/classes/com/sun/tools/javac/comp/Infer.java
- src/share/classes/com/sun/tools/javac/comp/InferFactory.java
- src/share/classes/com/sun/tools/javac/comp/LegacyInfer.java
! src/share/classes/com/sun/tools/javac/comp/Resolve.java
! test/tools/javac/lambda/TargetType20.java
- test/tools/javac/lambda/TargetType20.out
! test/tools/javac/lambda/TargetType50.java
- test/tools/javac/lambda/TargetType50.out
! test/tools/javac/lambda/TargetType56.java


From brian.goetz at oracle.com  Fri Feb  1 09:27:41 2013
From: brian.goetz at oracle.com (Brian Goetz)
Date: Fri, 01 Feb 2013 12:27:41 -0500
Subject: sum return type for primitive streams
In-Reply-To: <CACygQvkX2uNUAk6dn-GZ1eOUdajmFBSpvMPgiKpjF-kBSUCY9A@mail.gmail.com>
References: <510BD478.2000401@oracle.com> <510BDA37.1000702@oracle.com>
	<CACygQvkD_t_k_KrGZ+ZCGSRg_1f8xRYxvWviVtSsjAGgqbfX+w@mail.gmail.com>
	<510BF1E9.7090403@oracle.com>
	<CACygQvkX2uNUAk6dn-GZ1eOUdajmFBSpvMPgiKpjF-kBSUCY9A@mail.gmail.com>
Message-ID: <510BFB0D.1010000@oracle.com>

Yep, that basically "sums" up the thought process we went through. 
There's no perfect answer, but this seems the least surprising.

On 2/1/2013 12:23 PM, Ali Lahijani wrote:
>
> On Fri, Feb 1, 2013 at 8:18 PM, Brian Goetz <brian.goetz at oracle.com
> <mailto:brian.goetz at oracle.com>> wrote:
>
>         Sorry to bring it up again, but integers also form a monoid
>         under min, max.
>         With Integer.MIN_VALUE and Integer.MAX_VALUE being the obvious
>         identities.
>
>
>     And what about longs?  Having the same operation with different
>     identities for coincident sets is pretty confusing.
>
>
> You're right, we usually view int and long as approximations of
> mathematical integers, which have no top/bottom elements. So main/max on
> pure infinite integers (BigIntegers) do not have an identity.
>
> One could argue that when you are using an IntStream or LongStream
> instead of a Steam<BigIntegers>, you have already decided that you only
> need a finite subset of mathematical integers, so you should be prepared
> to see MIN_VALUE and MAX_VALUE used as positive/negative infinity. But I
> don't see that argument persuading anyone.
>
> So, in such an imperfect world, I guess there is no better answer for
> this question.
>
> Best

From henry.jen at oracle.com  Fri Feb  1 15:44:08 2013
From: henry.jen at oracle.com (Henry Jen)
Date: Fri, 01 Feb 2013 15:44:08 -0800
Subject: experience trying out lambda-8-b74
In-Reply-To: <510633DE.9060001@gmail.com>
References: <51053A5A.24195.AAF1F6@v.a.ammodytes.googlemail.com>
	<5105762A.8040002@oracle.com>
	<E61425C5-6E01-49C3-B149-151D2A3B81F3@wonderly.org>
	<CC95D104-28E2-42DE-B1A4-DD02BAD67F38@oracle.com>
	<510633DE.9060001@gmail.com>
Message-ID: <510C5348.8020107@oracle.com>

On 01/28/2013 12:16 AM, Peter Levart wrote:
> On 01/28/2013 12:06 AM, Henry Jen wrote:
>>
>> http://cr.openjdk.java.net/~henryjen/lambda/nio.5/webrev/
>>
> Hi Henry,
> 
> I can imagine that many times a single block of code would be
> responsible for constructing a Path stream (possibly enclosed into a
> try-with-resources construct) and consuming it's results, so having to
> deal with the duality of IOException/UncheckedIOException is a
> complication for a user in my opinion. Wouldn't it be better also for
> the stream-factory methods to throw UncheckedIOException and for
> CloseableStream.close() to also throw UncheckedIOException (that means,
> only inheriting from AutoCloseable, not Closeable and co-variant-ly
> redefining the throws declaration):
> 
> public interface CloseableStream<T> extends Stream<T>, AutoCloseable {
>     @Override
>     void close() throws UncheckedIOException;
> }
> 

Hi Peter,

Sorry for the late reply, I want to let the idea sink a little bit.

After couple days, I am slightly prefer not to change it because,

1) The CloseableStream-factory method throws IOException reminds use of
try-with-resource better than an unchecked exception.

2) As factory methods throwing IOException, developer is dealing with
duality already.

3) If the close method throws UncheckedIOException as the stream
handling, the suppressing of exceptions will be more confusing. Should
developer look into cause IOException or the UncheckedIOException?

4) When the implementation is a Closeable, the wrapping of IOException
into an UncheckedIOException doesn't do any good except overhead in case
developer want to deal with it. On the other hand, a IOException handler
is probably in place as the factory methods throws IOException.

Does it make sense?

I updated the webrev to have some test coverage for exception handling,
it's painful as always, but the duality is not what bothers me.

http://cr.openjdk.java.net/~henryjen/lambda/nio.6/webrev/

Cheers,
Henry


From peter.levart at gmail.com  Fri Feb  1 21:38:17 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Sat, 02 Feb 2013 06:38:17 +0100
Subject: experience trying out lambda-8-b74
In-Reply-To: <510C5348.8020107@oracle.com>
References: <51053A5A.24195.AAF1F6@v.a.ammodytes.googlemail.com>
	<5105762A.8040002@oracle.com>
	<E61425C5-6E01-49C3-B149-151D2A3B81F3@wonderly.org>
	<CC95D104-28E2-42DE-B1A4-DD02BAD67F38@oracle.com>
	<510633DE.9060001@gmail.com> <510C5348.8020107@oracle.com>
Message-ID: <510CA649.5050000@gmail.com>


On 02/02/2013 12:44 AM, Henry Jen wrote:
> On 01/28/2013 12:16 AM, Peter Levart wrote:
>> On 01/28/2013 12:06 AM, Henry Jen wrote:
>>> http://cr.openjdk.java.net/~henryjen/lambda/nio.5/webrev/
>>>
>> Hi Henry,
>>
>> I can imagine that many times a single block of code would be
>> responsible for constructing a Path stream (possibly enclosed into a
>> try-with-resources construct) and consuming it's results, so having to
>> deal with the duality of IOException/UncheckedIOException is a
>> complication for a user in my opinion. Wouldn't it be better also for
>> the stream-factory methods to throw UncheckedIOException and for
>> CloseableStream.close() to also throw UncheckedIOException (that means,
>> only inheriting from AutoCloseable, not Closeable and co-variant-ly
>> redefining the throws declaration):
>>
>> public interface CloseableStream<T> extends Stream<T>, AutoCloseable {
>>      @Override
>>      void close() throws UncheckedIOException;
>> }
>>
> Hi Peter,

Hi Henry,

> Sorry for the late reply, I want to let the idea sink a little bit.
>
> After couple days, I am slightly prefer not to change it because,
>
> 1) The CloseableStream-factory method throws IOException reminds use of
> try-with-resource better than an unchecked exception.

The *Closeable*Stream method return type name also reminds of that ;-)

> 2) As factory methods throwing IOException, developer is dealing with
> duality already.

He is dealing with duality already *if* the factory methods are throwing 
IOException. If they are throwing UncheckedIOException, he is not 
dealing with duality.

> 3) If the close method throws UncheckedIOException as the stream
> handling, the suppressing of exceptions will be more confusing. Should
> developer look into cause IOException or the UncheckedIOException?

Do you think a programmer might want to handle different subtypes of 
IOException differently? If that is the case, the javadoc should 
document all the possible situations. And what about different subtypes 
of IOException wrapped by UncheckedIOException while consuming the 
stream? If the programmer already bothers to unwrap the unchecked 
exception to do the cause analisys, then this same handler would be good 
also for dealing with exceptions thrown in factory methods and 
CloseableStream.close(). The streams API is a higher-lever wrapper over 
the java.nio.file.DirectoryStream API and it is already wrapping the 
lower-level IOException with UncheckedIOException when consuming the 
CloseableStream. I think it should do it consistently. By doing it 
consistently, it simplifies correct exception handling logic in *all* 
situations.

> 4) When the implementation is a Closeable, the wrapping of IOException
> into an UncheckedIOException doesn't do any good except overhead in case
> developer want to deal with it. On the other hand, a IOException handler
> is probably in place as the factory methods throws IOException.

It is probably in place *if* the factory methods are throwing 
IOException. If they are throwing UncheckedIOException, then such 
handler is not there. The question is whether the UncheckedIOException 
handler is in place too. If I look in one of your tests:

  148         public void testWalk() {
  149                 try(CloseableStream<Path> s = Files.walk(testFolder)) {
  150                         Object[] actual = s.sorted(Comparators.naturalOrder()).toArray();
  151                         assertEquals(actual, all);
  152                 } catch (IOException ioe) {
  153                         fail("Unexpected IOException");
  154                 }
  155         }


You haven't bothered to handle the UncheckedIOException (because the 
test would fail anyway if it was thrown). But I'm afraid that average 
programmer will walk away from similar codes with false sense of 
confidence that he handled all exceptional situations when he put the 
checked exception handler in place. I think that being consistent and 
throwing UncheckedIOException everywhere would actually have greater 
probability for average programmer to not miss the handling of 
exceptional situations while consuming the stream - at least all 
exceptional situations would be handled or not handled equally.

Regards, Peter

> Does it make sense?
>
> I updated the webrev to have some test coverage for exception handling,
> it's painful as always, but the duality is not what bothers me.
>
> http://cr.openjdk.java.net/~henryjen/lambda/nio.6/webrev/
>
> Cheers,
> Henry
>


From paul.sandoz at oracle.com  Sat Feb  2 04:14:45 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Sat, 2 Feb 2013 13:14:45 +0100
Subject: experience trying out lambda-8-b74
In-Reply-To: <5105762A.8040002@oracle.com>
References: <51053A5A.24195.AAF1F6@v.a.ammodytes.googlemail.com>
	<5105762A.8040002@oracle.com>
Message-ID: <E8BC1E78-BB9C-486B-83AF-DE07BFCA265F@oracle.com>

On Jan 27, 2013, at 7:47 PM, Brian Goetz <brian.goetz at Oracle.COM> wrote:
> That said, its interesting that you see different parallelization by 
> adding the intermediate collect() stage.  This may well be a bug, we'll 
> look into that.
> 

The wrapping spliterator (that encapsulates the source spliterator of one element and the explode op) is not very smart. 

We could use the same spliterator from iterator trick to extract some parallelism by further wrapping the wrapping the dumb wrapping spliterator. However, at the moment i am not quite sure of the exact rules when to apply this trick.

Paul.

From zhong.j.yu at gmail.com  Sat Feb  2 09:06:31 2013
From: zhong.j.yu at gmail.com (Zhong Yu)
Date: Sat, 2 Feb 2013 11:06:31 -0600
Subject: experience trying out lambda-8-b74
In-Reply-To: <510CA649.5050000@gmail.com>
References: <51053A5A.24195.AAF1F6@v.a.ammodytes.googlemail.com>
	<5105762A.8040002@oracle.com>
	<E61425C5-6E01-49C3-B149-151D2A3B81F3@wonderly.org>
	<CC95D104-28E2-42DE-B1A4-DD02BAD67F38@oracle.com>
	<510633DE.9060001@gmail.com> <510C5348.8020107@oracle.com>
	<510CA649.5050000@gmail.com>
Message-ID: <CACuKZqEWJKBxUh0=j8krP47f=UOZcTB6dREJuhdj0H7L4pYfTg@mail.gmail.com>

Also, what about other checked exceptions? If I make a stream based on
JDBC ResultSet, how do I handle SQLExceptions? Should I create a
proprietary UncheckedSQLException? Should multiple libraries each
provide their own version of UncheckedXxxExceptions for every
XxxException? We'll be in this hell for some years to come before the
language gives a better device.

Meanwhile, why not provide a generic wrapper exception whose explicit
and sole purpose is to wrap another checked exception? I know the idea
is trivia, but why not?

The Wrapper can provide convenience methods like

    class Wrapper extends RuntimeException

        // if cause is E1, throw cause; otherwise throw wrapper.
        <E1> RuntimeException rethrow(Class<E1> type) throws E1, Wrapper

so we can

    catch(Wrapper w)
        throw w.rethrow(IOException.class, SQLException.class);

or to handle causes inline

    catch(Wrapper w)
        w.on(IOException.class, e->{ handle e; })
           .on(SQLException.class, e->{ handle e; });

    <Ei, Eo> Wrapper on(Class<Ei> type, ExceptionHandler<Ei,Eo>) throws Eo;

    interface ExceptionHandler<Ei,Eo>
        void handle(Ei e) throws Eo;

obviously not elegant, but at least give us something of the sort that
can alleviate the pain in the short term.

Zhong Yu


On Fri, Feb 1, 2013 at 11:38 PM, Peter Levart <peter.levart at gmail.com> wrote:
>
> On 02/02/2013 12:44 AM, Henry Jen wrote:
>> On 01/28/2013 12:16 AM, Peter Levart wrote:
>>> On 01/28/2013 12:06 AM, Henry Jen wrote:
>>>> http://cr.openjdk.java.net/~henryjen/lambda/nio.5/webrev/
>>>>
>>> Hi Henry,
>>>
>>> I can imagine that many times a single block of code would be
>>> responsible for constructing a Path stream (possibly enclosed into a
>>> try-with-resources construct) and consuming it's results, so having to
>>> deal with the duality of IOException/UncheckedIOException is a
>>> complication for a user in my opinion. Wouldn't it be better also for
>>> the stream-factory methods to throw UncheckedIOException and for
>>> CloseableStream.close() to also throw UncheckedIOException (that means,
>>> only inheriting from AutoCloseable, not Closeable and co-variant-ly
>>> redefining the throws declaration):
>>>
>>> public interface CloseableStream<T> extends Stream<T>, AutoCloseable {
>>>      @Override
>>>      void close() throws UncheckedIOException;
>>> }
>>>
>> Hi Peter,
>
> Hi Henry,
>
>> Sorry for the late reply, I want to let the idea sink a little bit.
>>
>> After couple days, I am slightly prefer not to change it because,
>>
>> 1) The CloseableStream-factory method throws IOException reminds use of
>> try-with-resource better than an unchecked exception.
>
> The *Closeable*Stream method return type name also reminds of that ;-)
>
>> 2) As factory methods throwing IOException, developer is dealing with
>> duality already.
>
> He is dealing with duality already *if* the factory methods are throwing
> IOException. If they are throwing UncheckedIOException, he is not
> dealing with duality.
>
>> 3) If the close method throws UncheckedIOException as the stream
>> handling, the suppressing of exceptions will be more confusing. Should
>> developer look into cause IOException or the UncheckedIOException?
>
> Do you think a programmer might want to handle different subtypes of
> IOException differently? If that is the case, the javadoc should
> document all the possible situations. And what about different subtypes
> of IOException wrapped by UncheckedIOException while consuming the
> stream? If the programmer already bothers to unwrap the unchecked
> exception to do the cause analisys, then this same handler would be good
> also for dealing with exceptions thrown in factory methods and
> CloseableStream.close(). The streams API is a higher-lever wrapper over
> the java.nio.file.DirectoryStream API and it is already wrapping the
> lower-level IOException with UncheckedIOException when consuming the
> CloseableStream. I think it should do it consistently. By doing it
> consistently, it simplifies correct exception handling logic in *all*
> situations.
>
>> 4) When the implementation is a Closeable, the wrapping of IOException
>> into an UncheckedIOException doesn't do any good except overhead in case
>> developer want to deal with it. On the other hand, a IOException handler
>> is probably in place as the factory methods throws IOException.
>
> It is probably in place *if* the factory methods are throwing
> IOException. If they are throwing UncheckedIOException, then such
> handler is not there. The question is whether the UncheckedIOException
> handler is in place too. If I look in one of your tests:
>
>   148         public void testWalk() {
>   149                 try(CloseableStream<Path> s = Files.walk(testFolder)) {
>   150                         Object[] actual = s.sorted(Comparators.naturalOrder()).toArray();
>   151                         assertEquals(actual, all);
>   152                 } catch (IOException ioe) {
>   153                         fail("Unexpected IOException");
>   154                 }
>   155         }
>
>
> You haven't bothered to handle the UncheckedIOException (because the
> test would fail anyway if it was thrown). But I'm afraid that average
> programmer will walk away from similar codes with false sense of
> confidence that he handled all exceptional situations when he put the
> checked exception handler in place. I think that being consistent and
> throwing UncheckedIOException everywhere would actually have greater
> probability for average programmer to not miss the handling of
> exceptional situations while consuming the stream - at least all
> exceptional situations would be handled or not handled equally.
>
> Regards, Peter
>
>> Does it make sense?
>>
>> I updated the webrev to have some test coverage for exception handling,
>> it's painful as always, but the duality is not what bothers me.
>>
>> http://cr.openjdk.java.net/~henryjen/lambda/nio.6/webrev/
>>
>> Cheers,
>> Henry
>>
>
>

From robert.field at oracle.com  Sat Feb  2 10:33:49 2013
From: robert.field at oracle.com (robert.field at oracle.com)
Date: Sat, 02 Feb 2013 18:33:49 +0000
Subject: hg: lambda/lambda/langtools: Real fix for 80005632: synthethic flag
	on lambda method prevented it from being seen as enclosing
	method of inner class on 'make images'
Message-ID: <20130202183352.4DA34477AD@hg.openjdk.java.net>

Changeset: 5d728c6d8d85
Author:    rfield
Date:      2013-02-02 10:33 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/5d728c6d8d85

Real fix for 80005632: synthethic flag on lambda method prevented it from being seen as enclosing method of inner class on 'make images'
Follow on fixes for 8005653: external type variable references (including as class type parameters) on fields in class nested in lambda
and NPE in this context.
Full 'make images' now succeeds with java/util/stream/*Pipeline fully reverted from the work-arounds to 80005632 and 8005653.

! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java
! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java
! src/share/classes/com/sun/tools/javac/util/Names.java
+ test/tools/javac/lambda/LambdaInnerTypeVarArgs.java


From mike.duigou at oracle.com  Sat Feb  2 12:31:25 2013
From: mike.duigou at oracle.com (mike.duigou at oracle.com)
Date: Sat, 02 Feb 2013 20:31:25 +0000
Subject: hg: lambda/lambda/jdk: 3 new changesets
Message-ID: <20130202203214.39E1B477B3@hg.openjdk.java.net>

Changeset: e04eaaef10ab
Author:    ksrini
Date:      2013-02-01 22:12 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/e04eaaef10ab

8003549: (pack200) assertion errors when processing lambda class files with IMethods
Summary: add more check for opcode, sketch provided by jrose
Reviewed-by: jrose

! src/share/classes/com/sun/java/util/jar/pack/Attribute.java
! src/share/classes/com/sun/java/util/jar/pack/ClassReader.java
! src/share/classes/com/sun/java/util/jar/pack/ConstantPool.java
! src/share/classes/com/sun/java/util/jar/pack/Instruction.java
! src/share/classes/com/sun/java/util/jar/pack/PackageWriter.java
! src/share/classes/com/sun/java/util/jar/pack/PackerImpl.java
! src/share/classes/com/sun/java/util/jar/pack/PropMap.java
! src/share/classes/com/sun/java/util/jar/pack/Utils.java
! test/ProblemList.txt
+ test/tools/pack200/InstructionTests.java
! test/tools/pack200/pack200-verifier/src/xmlkit/ClassReader.java

Changeset: 10dac341696d
Author:    ksrini
Date:      2013-02-01 22:18 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/10dac341696d

8007428: [launcher] add tools/launcher/FXLauncherTest.java to ProblemList.txt
Reviewed-by: mchung

! test/ProblemList.txt

Changeset: 9d5bfcde7287
Author:    ksrini
Date:      2013-02-02 12:08 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/9d5bfcde7287

8007135: tools/launcher/VersionCheck.java failing with new tool jabswitch
Reviewed-by: ksrini, mduigou
Contributed-by: ragini.prasad at oracle.com

! test/tools/launcher/VersionCheck.java


From boaznahum at gmail.com  Sat Feb  2 12:35:46 2013
From: boaznahum at gmail.com (Boaz Nahum)
Date: Sat, 2 Feb 2013 22:35:46 +0200
Subject: Grouping stream elements by their position - how to handle tail of
	stream ?
Message-ID: <CAB_DFWaUEv8jAo6Ok58d7EthS6gZubSvr8rbXxGoEVLVAmjeug@mail.gmail.com>

Hi.

I looking in Stream interface for a way to convert a stream of
   {  t1, t2, .. Tn }
to
   { {t1,t2}, ... {Tn-1, Tn} }
or
   { {t1,t2}, ... {Tn, null}}

Lets assume {t1, t2} are aggeraget by Pair<T,T>



So I tried to use explode:

*        Stream<Integer> si = Arrays.asList(1, 2, 3, 4, 5).stream();

        Stream<Pair<Integer, Integer>> spi = si.sequential().explode(new
BiConsumer<Stream.Downstream<Pair<Integer, Integer>>, Integer>() {

            Integer firstValue;

            @Override
            public void accept(Stream.Downstream<Pair<Integer, Integer>>
pairDownstream, Integer v) {

                if (firstValue == null) {
                    firstValue = v;
                } else {

                    pairDownstream.send(new Pair<>(firstValue, v));
                    firstValue = null;

                }
            }

        });
*

But I didn't find a way to add the tail of input stream {.., 5} to the new
stream { ,,, {5, null}}.

Of-course this only simplified example of more general problem I have.

Thanks
Boaz

From latsama at gmail.com  Sat Feb  2 12:59:28 2013
From: latsama at gmail.com (Lattie)
Date: Sat, 2 Feb 2013 12:59:28 -0800
Subject: Grouping stream elements by their position - how to handle tail
	of stream ?
In-Reply-To: <CAB_DFWaUEv8jAo6Ok58d7EthS6gZubSvr8rbXxGoEVLVAmjeug@mail.gmail.com>
References: <CAB_DFWaUEv8jAo6Ok58d7EthS6gZubSvr8rbXxGoEVLVAmjeug@mail.gmail.com>
Message-ID: <CAKJVG8aN1=H4OX7j65m0EK7FuGc7U8s-UMyn1eQ0rWybqpO9JA@mail.gmail.com>

Boaz,

I just wanted to validate your request as I ran into *exactly* the
same issue yesterday.

I think that explode ought to call some sort of finalizer method at
end of stream to accommodate those BiBlocks which are stateful.

Also, I'm not sure if 'explode' is the best name as I find I am using
it more generally to transform a stream of X into a stream of Y, where
Y may require 1 or more X's as inputs.  (I didn't find any other
method that enabled that type of transformation.  Please feel free to
educate me :)






On Sat, Feb 2, 2013 at 12:35 PM, Boaz Nahum <boaznahum at gmail.com> wrote:
> Hi.
>
> I looking in Stream interface for a way to convert a stream of
>    {  t1, t2, .. Tn }
> to
>    { {t1,t2}, ... {Tn-1, Tn} }
> or
>    { {t1,t2}, ... {Tn, null}}
>
> Lets assume {t1, t2} are aggeraget by Pair<T,T>
>
>
>
> So I tried to use explode:
>
> *        Stream<Integer> si = Arrays.asList(1, 2, 3, 4, 5).stream();
>
>         Stream<Pair<Integer, Integer>> spi = si.sequential().explode(new
> BiConsumer<Stream.Downstream<Pair<Integer, Integer>>, Integer>() {
>
>             Integer firstValue;
>
>             @Override
>             public void accept(Stream.Downstream<Pair<Integer, Integer>>
> pairDownstream, Integer v) {
>
>                 if (firstValue == null) {
>                     firstValue = v;
>                 } else {
>
>                     pairDownstream.send(new Pair<>(firstValue, v));
>                     firstValue = null;
>
>                 }
>             }
>
>         });
> *
>
> But I didn't find a way to add the tail of input stream {.., 5} to the new
> stream { ,,, {5, null}}.
>
> Of-course this only simplified example of more general problem I have.
>
> Thanks
> Boaz
>

From brian.goetz at oracle.com  Sat Feb  2 13:55:13 2013
From: brian.goetz at oracle.com (Brian Goetz)
Date: Sat, 02 Feb 2013 16:55:13 -0500
Subject: Grouping stream elements by their position - how to handle tail
	of stream ?
In-Reply-To: <CAB_DFWaUEv8jAo6Ok58d7EthS6gZubSvr8rbXxGoEVLVAmjeug@mail.gmail.com>
References: <CAB_DFWaUEv8jAo6Ok58d7EthS6gZubSvr8rbXxGoEVLVAmjeug@mail.gmail.com>
Message-ID: <510D8B41.6040109@oracle.com>

The glass is half full, or half empty, depending on your disposition.

While its trivial to write a version of explode() that remembers the 
last element seen, and either emits nothing or a pair (you have a little 
fixup at the end to deal with, but that's easy too, just annoying), once 
you start writing such stateful lambdas, you are tying yourself to 
sequential execution in a very error-prone way.  The type system can't 
record this assumption, so when someone helpfully later adds a 
.parallel() somewhere, your code will silently turn to sewage.  So, 
don't ever do this.

Too see why the obvious algorithm is sequential only, consider a 
decomposition of a data source with a spliterator.  In most cases, we 
don't necessarily know the even-ness or odd-ness of the sum of sizes of 
all prior splits.  Which means we don't know whether the first element 
of any given split is the left element of some pair or the right element 
of some pair.

You might say: I don't care about parallelism, I only care about 
sequential.

To which we'd respond: fine, but we're not really interested in 
distorting the model to encourage that.  The Stream API is designed 
around operations that can be equally well performed in serial or 
parallel.  There are no "serial only" operations supported, and that was 
an explicit design choice.  Passing state-holding lambdas to these 
methods is likely to be a spec violation.  We can't enforce it, any more 
than we can enforce the lack of data races, but bear in mind that if you 
do this, you're writing broken code, and asking for trouble.

Now, that said, here's a parallel algorithm you can implement with 
collect(), though you may find the performance overhead too offensive. 
Basically, for each chunk of the input t1..tn, you compute two possible 
answers:

p0 = (t1,t2), t3,t4), ..., maybe leftover tn
p1 = t1, (t2, t3), (t4, t5), ... maybe leftover tn

then you combine these pairs chunks in the mostly obvious way (observe 
that p0 has trailing element = !(p1 has trailing element)).  Then when 
you get to the top of the tree, you take the one that doesn't have an 
orphaned initial element, and toss the other.  Basically you're doing 2x 
work for each input element, but it parallelizes fairly cleanly.

Such an algorithm is ideally suited to collect(), because a Collector is 
a representation of a catamorphism, which the above transformation is. 
Because the combination logic is associative, it parallelizes cleanly 
without needing any nasty stateful lambdas.

When we expose the Op APIs and you can write your own 
decomposition-aware operations, you'll have another option: write a 
StatefulOp.  This won't be an option for 8, but once we do, its easy 
enough, and it will let you avoid the extra overhead by creating a 
custom operation.

So, to sum up:
  - If you're looking for a one-liner, you'll be disappointed;
  - If you convince yourself "I would never need parallelism here" and 
write the obvious unsafe stateful lambda, please write your manager a 
letter first explaining how your incompetence is putting the reliability 
of his product in jeopardy;
  - If you're willing to write the above collector, you'll likely be 
happy enough with the result.


On 2/2/2013 3:35 PM, Boaz Nahum wrote:
> Hi.
>
> I looking in Stream interface for a way to convert a stream of
>     {  t1, t2, .. Tn }
> to
>     { {t1,t2}, ... {Tn-1, Tn} }
> or
>     { {t1,t2}, ... {Tn, null}}
>
> Lets assume {t1, t2} are aggeraget by Pair<T,T>
>
>
>
> So I tried to use explode:
>
> *        Stream<Integer> si = Arrays.asList(1, 2, 3, 4, 5).stream();
>
>          Stream<Pair<Integer, Integer>> spi = si.sequential().explode(new
> BiConsumer<Stream.Downstream<Pair<Integer, Integer>>, Integer>() {
>
>              Integer firstValue;
>
>              @Override
>              public void accept(Stream.Downstream<Pair<Integer, Integer>>
> pairDownstream, Integer v) {
>
>                  if (firstValue == null) {
>                      firstValue = v;
>                  } else {
>
>                      pairDownstream.send(new Pair<>(firstValue, v));
>                      firstValue = null;
>
>                  }
>              }
>
>          });
> *
>
> But I didn't find a way to add the tail of input stream {.., 5} to the new
> stream { ,,, {5, null}}.
>
> Of-course this only simplified example of more general problem I have.
>
> Thanks
> Boaz
>

From zhong.j.yu at gmail.com  Sat Feb  2 15:52:06 2013
From: zhong.j.yu at gmail.com (Zhong Yu)
Date: Sat, 2 Feb 2013 17:52:06 -0600
Subject: Grouping stream elements by their position - how to handle tail
	of stream ?
In-Reply-To: <CAKJVG8aN1=H4OX7j65m0EK7FuGc7U8s-UMyn1eQ0rWybqpO9JA@mail.gmail.com>
References: <CAB_DFWaUEv8jAo6Ok58d7EthS6gZubSvr8rbXxGoEVLVAmjeug@mail.gmail.com>
	<CAKJVG8aN1=H4OX7j65m0EK7FuGc7U8s-UMyn1eQ0rWybqpO9JA@mail.gmail.com>
Message-ID: <CACuKZqEqJhE7u6RpX9akgo-geJSviULA0O+L+YNT63abD_3fxg@mail.gmail.com>

On Sat, Feb 2, 2013 at 2:59 PM, Lattie <latsama at gmail.com> wrote:
> Boaz,
>
> I just wanted to validate your request as I ran into *exactly* the
> same issue yesterday.
>
> I think that explode ought to call some sort of finalizer method at
> end of stream to accommodate those BiBlocks which are stateful.
>
> Also, I'm not sure if 'explode' is the best name as I find I am using
> it more generally to transform a stream of X into a stream of Y, where
> Y may require 1 or more X's as inputs.  (I didn't find any other
> method that enabled that type of transformation.  Please feel free to
> educate me :)

I also wanted this. It's kind of like a lexer that turns a char stream
into a token stream; an EOF event needs to be raised and handled.

However, it is inherently sequential, which Stream doesn't want to
support, even though it is teasingly named *stream*. Someone will
invent other models like Sequence - fortunately the only reason we
didn't have these things is the syntax of anonymous class, which is
now solved by lambda expression.

Zhong Yu

>
>
>
>
>
>
> On Sat, Feb 2, 2013 at 12:35 PM, Boaz Nahum <boaznahum at gmail.com> wrote:
>> Hi.
>>
>> I looking in Stream interface for a way to convert a stream of
>>    {  t1, t2, .. Tn }
>> to
>>    { {t1,t2}, ... {Tn-1, Tn} }
>> or
>>    { {t1,t2}, ... {Tn, null}}
>>
>> Lets assume {t1, t2} are aggeraget by Pair<T,T>
>>
>>
>>
>> So I tried to use explode:
>>
>> *        Stream<Integer> si = Arrays.asList(1, 2, 3, 4, 5).stream();
>>
>>         Stream<Pair<Integer, Integer>> spi = si.sequential().explode(new
>> BiConsumer<Stream.Downstream<Pair<Integer, Integer>>, Integer>() {
>>
>>             Integer firstValue;
>>
>>             @Override
>>             public void accept(Stream.Downstream<Pair<Integer, Integer>>
>> pairDownstream, Integer v) {
>>
>>                 if (firstValue == null) {
>>                     firstValue = v;
>>                 } else {
>>
>>                     pairDownstream.send(new Pair<>(firstValue, v));
>>                     firstValue = null;
>>
>>                 }
>>             }
>>
>>         });
>> *
>>
>> But I didn't find a way to add the tail of input stream {.., 5} to the new
>> stream { ,,, {5, null}}.
>>
>> Of-course this only simplified example of more general problem I have.
>>
>> Thanks
>> Boaz
>>
>

From latsama at gmail.com  Sat Feb  2 16:49:53 2013
From: latsama at gmail.com (Lattie)
Date: Sat, 2 Feb 2013 16:49:53 -0800
Subject: Grouping stream elements by their position - how to handle tail
	of stream ?
In-Reply-To: <510D8B41.6040109@oracle.com>
References: <CAB_DFWaUEv8jAo6Ok58d7EthS6gZubSvr8rbXxGoEVLVAmjeug@mail.gmail.com>
	<510D8B41.6040109@oracle.com>
Message-ID: <CAKJVG8Z3R4ax-ySsuGEPhptjjx6_frnhak3HksfqsHnnT3ZEMA@mail.gmail.com>

>Now, that said, here's a parallel algorithm you can implement with
>collect(), though you may find the performance overhead too offensive.
>Basically, for each chunk of the input t1..tn, you compute two possible
>answers:
>
>p0 = (t1,t2), (t3,t4), ..., maybe leftover tn

This is what I want... the ability to compute p0.  I was not able to
figure out how to use collect() to do this though, and so I went down
the road of explode() with a stateful lambda... can someone point me
to any tutorial or info on how to properly use collect()?

TIA


On Sat, Feb 2, 2013 at 1:55 PM, Brian Goetz <brian.goetz at oracle.com> wrote:
> The glass is half full, or half empty, depending on your disposition.
>
> While its trivial to write a version of explode() that remembers the
> last element seen, and either emits nothing or a pair (you have a little
> fixup at the end to deal with, but that's easy too, just annoying), once
> you start writing such stateful lambdas, you are tying yourself to
> sequential execution in a very error-prone way.  The type system can't
> record this assumption, so when someone helpfully later adds a
> .parallel() somewhere, your code will silently turn to sewage.  So,
> don't ever do this.
>
> Too see why the obvious algorithm is sequential only, consider a
> decomposition of a data source with a spliterator.  In most cases, we
> don't necessarily know the even-ness or odd-ness of the sum of sizes of
> all prior splits.  Which means we don't know whether the first element
> of any given split is the left element of some pair or the right element
> of some pair.
>
> You might say: I don't care about parallelism, I only care about
> sequential.
>
> To which we'd respond: fine, but we're not really interested in
> distorting the model to encourage that.  The Stream API is designed
> around operations that can be equally well performed in serial or
> parallel.  There are no "serial only" operations supported, and that was
> an explicit design choice.  Passing state-holding lambdas to these
> methods is likely to be a spec violation.  We can't enforce it, any more
> than we can enforce the lack of data races, but bear in mind that if you
> do this, you're writing broken code, and asking for trouble.
>
> Now, that said, here's a parallel algorithm you can implement with
> collect(), though you may find the performance overhead too offensive.
> Basically, for each chunk of the input t1..tn, you compute two possible
> answers:
>
> p0 = (t1,t2), t3,t4), ..., maybe leftover tn
> p1 = t1, (t2, t3), (t4, t5), ... maybe leftover tn
>
> then you combine these pairs chunks in the mostly obvious way (observe
> that p0 has trailing element = !(p1 has trailing element)).  Then when
> you get to the top of the tree, you take the one that doesn't have an
> orphaned initial element, and toss the other.  Basically you're doing 2x
> work for each input element, but it parallelizes fairly cleanly.
>
> Such an algorithm is ideally suited to collect(), because a Collector is
> a representation of a catamorphism, which the above transformation is.
> Because the combination logic is associative, it parallelizes cleanly
> without needing any nasty stateful lambdas.
>
> When we expose the Op APIs and you can write your own
> decomposition-aware operations, you'll have another option: write a
> StatefulOp.  This won't be an option for 8, but once we do, its easy
> enough, and it will let you avoid the extra overhead by creating a
> custom operation.
>
> So, to sum up:
>   - If you're looking for a one-liner, you'll be disappointed;
>   - If you convince yourself "I would never need parallelism here" and
> write the obvious unsafe stateful lambda, please write your manager a
> letter first explaining how your incompetence is putting the reliability
> of his product in jeopardy;
>   - If you're willing to write the above collector, you'll likely be
> happy enough with the result.
>
>
> On 2/2/2013 3:35 PM, Boaz Nahum wrote:
>> Hi.
>>
>> I looking in Stream interface for a way to convert a stream of
>>     {  t1, t2, .. Tn }
>> to
>>     { {t1,t2}, ... {Tn-1, Tn} }
>> or
>>     { {t1,t2}, ... {Tn, null}}
>>
>> Lets assume {t1, t2} are aggeraget by Pair<T,T>
>>
>>
>>
>> So I tried to use explode:
>>
>> *        Stream<Integer> si = Arrays.asList(1, 2, 3, 4, 5).stream();
>>
>>          Stream<Pair<Integer, Integer>> spi = si.sequential().explode(new
>> BiConsumer<Stream.Downstream<Pair<Integer, Integer>>, Integer>() {
>>
>>              Integer firstValue;
>>
>>              @Override
>>              public void accept(Stream.Downstream<Pair<Integer, Integer>>
>> pairDownstream, Integer v) {
>>
>>                  if (firstValue == null) {
>>                      firstValue = v;
>>                  } else {
>>
>>                      pairDownstream.send(new Pair<>(firstValue, v));
>>                      firstValue = null;
>>
>>                  }
>>              }
>>
>>          });
>> *
>>
>> But I didn't find a way to add the tail of input stream {.., 5} to the new
>> stream { ,,, {5, null}}.
>>
>> Of-course this only simplified example of more general problem I have.
>>
>> Thanks
>> Boaz
>>
>

From brian.goetz at oracle.com  Sat Feb  2 20:04:01 2013
From: brian.goetz at oracle.com (Brian Goetz)
Date: Sat, 02 Feb 2013 23:04:01 -0500
Subject: Grouping stream elements by their position - how to handle tail
	of stream ?
In-Reply-To: <CAKJVG8Z3R4ax-ySsuGEPhptjjx6_frnhak3HksfqsHnnT3ZEMA@mail.gmail.com>
References: <CAB_DFWaUEv8jAo6Ok58d7EthS6gZubSvr8rbXxGoEVLVAmjeug@mail.gmail.com>
	<510D8B41.6040109@oracle.com>
	<CAKJVG8Z3R4ax-ySsuGEPhptjjx6_frnhak3HksfqsHnnT3ZEMA@mail.gmail.com>
Message-ID: <510DE1B1.3030904@oracle.com>

Look at the implementations in Collectors for a hint.  Obviously we owe 
some significant documentation, which unfortunately lags the code by too 
much.  But a Collector is basically a mutable foldl/inject; you provide 
a way to create a new mutable container, a way to add a single element 
to it, and a way to combine two mutable containers.  The framework 
decomposes the source, creates a bunch of little containers at the 
leaves, and them goes up the tree, merging.

Dumping the elements into an ArrayList maps easily to Collector:

  collect(ArrayList::new, ArrayList::add, ArrayList::addAll)

This parallelizes, as we can collect each chunk into a list, and then 
merge the lists up the tree with addAll.

The "how do I get the last element" problem goes away, since your data 
structure can explicitly maintain the state of whether the chunk ends 
with a balanced pair or an extra.

But, you need to calculate BOTH p0 and p1 for each chunk (except maybe 
the left-spine chunks), because you don't know until the end which will 
have the right parity.

On 2/2/2013 7:49 PM, Lattie wrote:
>> Now, that said, here's a parallel algorithm you can implement with
>> collect(), though you may find the performance overhead too offensive.
>> Basically, for each chunk of the input t1..tn, you compute two possible
>> answers:
>>
>> p0 = (t1,t2), (t3,t4), ..., maybe leftover tn
>
> This is what I want... the ability to compute p0.  I was not able to
> figure out how to use collect() to do this though, and so I went down
> the road of explode() with a stateful lambda... can someone point me
> to any tutorial or info on how to properly use collect()?
>
> TIA
>
>
> On Sat, Feb 2, 2013 at 1:55 PM, Brian Goetz <brian.goetz at oracle.com> wrote:
>> The glass is half full, or half empty, depending on your disposition.
>>
>> While its trivial to write a version of explode() that remembers the
>> last element seen, and either emits nothing or a pair (you have a little
>> fixup at the end to deal with, but that's easy too, just annoying), once
>> you start writing such stateful lambdas, you are tying yourself to
>> sequential execution in a very error-prone way.  The type system can't
>> record this assumption, so when someone helpfully later adds a
>> .parallel() somewhere, your code will silently turn to sewage.  So,
>> don't ever do this.
>>
>> Too see why the obvious algorithm is sequential only, consider a
>> decomposition of a data source with a spliterator.  In most cases, we
>> don't necessarily know the even-ness or odd-ness of the sum of sizes of
>> all prior splits.  Which means we don't know whether the first element
>> of any given split is the left element of some pair or the right element
>> of some pair.
>>
>> You might say: I don't care about parallelism, I only care about
>> sequential.
>>
>> To which we'd respond: fine, but we're not really interested in
>> distorting the model to encourage that.  The Stream API is designed
>> around operations that can be equally well performed in serial or
>> parallel.  There are no "serial only" operations supported, and that was
>> an explicit design choice.  Passing state-holding lambdas to these
>> methods is likely to be a spec violation.  We can't enforce it, any more
>> than we can enforce the lack of data races, but bear in mind that if you
>> do this, you're writing broken code, and asking for trouble.
>>
>> Now, that said, here's a parallel algorithm you can implement with
>> collect(), though you may find the performance overhead too offensive.
>> Basically, for each chunk of the input t1..tn, you compute two possible
>> answers:
>>
>> p0 = (t1,t2), t3,t4), ..., maybe leftover tn
>> p1 = t1, (t2, t3), (t4, t5), ... maybe leftover tn
>>
>> then you combine these pairs chunks in the mostly obvious way (observe
>> that p0 has trailing element = !(p1 has trailing element)).  Then when
>> you get to the top of the tree, you take the one that doesn't have an
>> orphaned initial element, and toss the other.  Basically you're doing 2x
>> work for each input element, but it parallelizes fairly cleanly.
>>
>> Such an algorithm is ideally suited to collect(), because a Collector is
>> a representation of a catamorphism, which the above transformation is.
>> Because the combination logic is associative, it parallelizes cleanly
>> without needing any nasty stateful lambdas.
>>
>> When we expose the Op APIs and you can write your own
>> decomposition-aware operations, you'll have another option: write a
>> StatefulOp.  This won't be an option for 8, but once we do, its easy
>> enough, and it will let you avoid the extra overhead by creating a
>> custom operation.
>>
>> So, to sum up:
>>    - If you're looking for a one-liner, you'll be disappointed;
>>    - If you convince yourself "I would never need parallelism here" and
>> write the obvious unsafe stateful lambda, please write your manager a
>> letter first explaining how your incompetence is putting the reliability
>> of his product in jeopardy;
>>    - If you're willing to write the above collector, you'll likely be
>> happy enough with the result.
>>
>>
>> On 2/2/2013 3:35 PM, Boaz Nahum wrote:
>>> Hi.
>>>
>>> I looking in Stream interface for a way to convert a stream of
>>>      {  t1, t2, .. Tn }
>>> to
>>>      { {t1,t2}, ... {Tn-1, Tn} }
>>> or
>>>      { {t1,t2}, ... {Tn, null}}
>>>
>>> Lets assume {t1, t2} are aggeraget by Pair<T,T>
>>>
>>>
>>>
>>> So I tried to use explode:
>>>
>>> *        Stream<Integer> si = Arrays.asList(1, 2, 3, 4, 5).stream();
>>>
>>>           Stream<Pair<Integer, Integer>> spi = si.sequential().explode(new
>>> BiConsumer<Stream.Downstream<Pair<Integer, Integer>>, Integer>() {
>>>
>>>               Integer firstValue;
>>>
>>>               @Override
>>>               public void accept(Stream.Downstream<Pair<Integer, Integer>>
>>> pairDownstream, Integer v) {
>>>
>>>                   if (firstValue == null) {
>>>                       firstValue = v;
>>>                   } else {
>>>
>>>                       pairDownstream.send(new Pair<>(firstValue, v));
>>>                       firstValue = null;
>>>
>>>                   }
>>>               }
>>>
>>>           });
>>> *
>>>
>>> But I didn't find a way to add the tail of input stream {.., 5} to the new
>>> stream { ,,, {5, null}}.
>>>
>>> Of-course this only simplified example of more general problem I have.
>>>
>>> Thanks
>>> Boaz
>>>
>>

From boaznahum at gmail.com  Sat Feb  2 23:38:04 2013
From: boaznahum at gmail.com (Boaz Nahum)
Date: Sun, 3 Feb 2013 09:38:04 +0200
Subject: Grouping stream elements by their position - how to handle tail
	of stream ?
In-Reply-To: <510D8B41.6040109@oracle.com>
References: <CAB_DFWaUEv8jAo6Ok58d7EthS6gZubSvr8rbXxGoEVLVAmjeug@mail.gmail.com>
	<510D8B41.6040109@oracle.com>
Message-ID: <CAB_DFWbpff5NHuwpVeOfYT9KHh8a-uk4hGiRV0ic1OS2JHtZ5g@mail.gmail.com>

Hi Brian.

> The glass is half full, or half empty, depending on your disposition.
I know my English is quite poor. My question was a real - not a criticism.
Juts trying to learn.

I gave up paralism - that why I called sequential before explode

>>   si.sequential().explode

> you have a little fixup at the end to deal with, but that's easy too,
just annoying
I didn't find a way to to it with explode (unless my explode is last in the
chain, then it easy). As some else mention in case of sequential stream a
'finalize' method will do the trick.

As you suggested, I will look at Collectors.

Thanks.
Boaz



On Sat, Feb 2, 2013 at 11:55 PM, Brian Goetz <brian.goetz at oracle.com> wrote:

> The glass is half full, or half empty, depending on your disposition.
>
> While its trivial to write a version of explode() that remembers the last
> element seen, and either emits nothing or a pair (you have a little fixup
> at the end to deal with, but that's easy too, just annoying), once you
> start writing such stateful lambdas, you are tying yourself to sequential
> execution in a very error-prone way.  The type system can't record this
> assumption, so when someone helpfully later adds a .parallel() somewhere,
> your code will silently turn to sewage.  So, don't ever do this.
>
> Too see why the obvious algorithm is sequential only, consider a
> decomposition of a data source with a spliterator.  In most cases, we don't
> necessarily know the even-ness or odd-ness of the sum of sizes of all prior
> splits.  Which means we don't know whether the first element of any given
> split is the left element of some pair or the right element of some pair.
>
> You might say: I don't care about parallelism, I only care about
> sequential.
>
> To which we'd respond: fine, but we're not really interested in distorting
> the model to encourage that.  The Stream API is designed around operations
> that can be equally well performed in serial or parallel.  There are no
> "serial only" operations supported, and that was an explicit design choice.
>  Passing state-holding lambdas to these methods is likely to be a spec
> violation.  We can't enforce it, any more than we can enforce the lack of
> data races, but bear in mind that if you do this, you're writing broken
> code, and asking for trouble.
>
> Now, that said, here's a parallel algorithm you can implement with
> collect(), though you may find the performance overhead too offensive.
> Basically, for each chunk of the input t1..tn, you compute two possible
> answers:
>
> p0 = (t1,t2), t3,t4), ..., maybe leftover tn
> p1 = t1, (t2, t3), (t4, t5), ... maybe leftover tn
>
> then you combine these pairs chunks in the mostly obvious way (observe
> that p0 has trailing element = !(p1 has trailing element)).  Then when you
> get to the top of the tree, you take the one that doesn't have an orphaned
> initial element, and toss the other.  Basically you're doing 2x work for
> each input element, but it parallelizes fairly cleanly.
>
> Such an algorithm is ideally suited to collect(), because a Collector is a
> representation of a catamorphism, which the above transformation is.
> Because the combination logic is associative, it parallelizes cleanly
> without needing any nasty stateful lambdas.
>
> When we expose the Op APIs and you can write your own decomposition-aware
> operations, you'll have another option: write a StatefulOp.  This won't be
> an option for 8, but once we do, its easy enough, and it will let you avoid
> the extra overhead by creating a custom operation.
>
> So, to sum up:
>  - If you're looking for a one-liner, you'll be disappointed;
>  - If you convince yourself "I would never need parallelism here" and
> write the obvious unsafe stateful lambda, please write your manager a
> letter first explaining how your incompetence is putting the reliability of
> his product in jeopardy;
>  - If you're willing to write the above collector, you'll likely be happy
> enough with the result.
>
>
>
> On 2/2/2013 3:35 PM, Boaz Nahum wrote:
>
>> Hi.
>>
>> I looking in Stream interface for a way to convert a stream of
>>     {  t1, t2, .. Tn }
>> to
>>     { {t1,t2}, ... {Tn-1, Tn} }
>> or
>>     { {t1,t2}, ... {Tn, null}}
>>
>> Lets assume {t1, t2} are aggeraget by Pair<T,T>
>>
>>
>>
>> So I tried to use explode:
>>
>> *        Stream<Integer> si = Arrays.asList(1, 2, 3, 4, 5).stream();
>>
>>
>>          Stream<Pair<Integer, Integer>> spi = si.sequential().explode(new
>> BiConsumer<Stream.Downstream<**Pair<Integer, Integer>>, Integer>() {
>>
>>              Integer firstValue;
>>
>>              @Override
>>              public void accept(Stream.Downstream<Pair<**Integer,
>> Integer>>
>> pairDownstream, Integer v) {
>>
>>                  if (firstValue == null) {
>>                      firstValue = v;
>>                  } else {
>>
>>                      pairDownstream.send(new Pair<>(firstValue, v));
>>                      firstValue = null;
>>
>>                  }
>>              }
>>
>>          });
>> *
>>
>> But I didn't find a way to add the tail of input stream {.., 5} to the new
>> stream { ,,, {5, null}}.
>>
>> Of-course this only simplified example of more general problem I have.
>>
>> Thanks
>> Boaz
>>
>>

From guenter.jantzen at gmx.de  Sun Feb  3 08:14:14 2013
From: guenter.jantzen at gmx.de (=?ISO-8859-1?Q?G=FCnter?= Jantzen)
Date: Sun, 03 Feb 2013 17:14:14 +0100
Subject: Grouping stream elements by their position - how to handle
	tail of stream ?
In-Reply-To: <510DE1B1.3030904@oracle.com>
References: <CAB_DFWaUEv8jAo6Ok58d7EthS6gZubSvr8rbXxGoEVLVAmjeug@mail.gmail.com>
	<510D8B41.6040109@oracle.com>
	<CAKJVG8Z3R4ax-ySsuGEPhptjjx6_frnhak3HksfqsHnnT3ZEMA@mail.gmail.com>
	<510DE1B1.3030904@oracle.com>
Message-ID: <1359908054.1812.36.camel@Lieschen3>

Hello together,

I am happy that we will receive very powerful tools in Java 8, but
the involved concepts from functional programming and category theory
("catamorphism") are not quite easy to grasp. So, looking in the sources
is a good advice, but sometimes still very puzzling.

It is quite helpful to receive a src.zip together with the weekly
binaries. But it would be even more helpful to receive a test.zip
containing the actual tests, too.

The tests contain not only a lot of examples, which are a good starting
point to play around. They have the extra benefit to be *working*
examples. A real benefit, because searching in the internet points
mostly to examples which are not very interesting or out to date.
(BTW very helpful and always up to date are these oneliners:
https://github.com/aruld/java-oneliners) 
 
So for all of us, who don't build their own java, test sources
included in the weekly binary distribution could be really helpful.

Best regards and thanks for all this beauty work!
G?nter 

Am Samstag, den 02.02.2013, 23:04 -0500 schrieb Brian Goetz:
> Look at the implementations in Collectors for a hint.  Obviously we owe 
> some significant documentation, which unfortunately lags the code by too 
> much.  


From brian.goetz at oracle.com  Sun Feb  3 08:47:37 2013
From: brian.goetz at oracle.com (brian.goetz at oracle.com)
Date: Sun, 03 Feb 2013 16:47:37 +0000
Subject: hg: lambda/lambda/jdk: Revert workarounds (using inner classes
	instead of lambdas) for 80005632
Message-ID: <20130203164817.787C2477BF@hg.openjdk.java.net>

Changeset: 1b8b4bf3f0a2
Author:    briangoetz
Date:      2013-02-03 11:47 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/1b8b4bf3f0a2

Revert workarounds (using inner classes instead of lambdas) for 80005632

! src/share/classes/java/util/stream/DoublePipeline.java
! src/share/classes/java/util/stream/IntPipeline.java
! src/share/classes/java/util/stream/LongPipeline.java
! src/share/classes/java/util/stream/ReferencePipeline.java


From brian.goetz at oracle.com  Sun Feb  3 09:12:58 2013
From: brian.goetz at oracle.com (brian.goetz at oracle.com)
Date: Sun, 03 Feb 2013 17:12:58 +0000
Subject: hg: lambda/lambda/jdk: More witness elimination,
	enabled by a311c0821e90
Message-ID: <20130203171311.18DED477C0@hg.openjdk.java.net>

Changeset: e572f1bdcf0b
Author:    briangoetz
Date:      2013-02-03 12:12 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/e572f1bdcf0b

More witness elimination, enabled by a311c0821e90

! src/share/classes/java/util/stream/Collectors.java
! src/share/classes/java/util/stream/ConcurrentCollectors.java
! test-ng/tests/org/openjdk/tests/java/util/stream/TabulatorsTest.java


From aruld at acm.org  Sun Feb  3 13:56:45 2013
From: aruld at acm.org (Arul Dhesiaseelan)
Date: Sun, 3 Feb 2013 11:56:45 -1000
Subject: Custom stream extensions
Message-ID: <CAKEXrxnaBjkst6tO0rt_zgWSn1uQH=bHTGRHSTuCXTqPGcLzjw@mail.gmail.com>

I was able to add extensions to my custom list implementation in earlier
builds.

  public MyStream<E> stream() {
    return new MyReferencePipeline<>(() -> Arrays.spliterator((E[])
this.toArray(), 0, this.size()), StreamOpFlag.IS_SIZED |
StreamOpFlag.IS_ORDERED);
  }


Now that, ReferencePipeline is made package local, this approach is no
longer possible.

It was extremely useful to extend some of these core classes outside the
package and toss in extensions with minimal coding. I assume this is not
encouraged?

Thanks,
Arul

From brian.goetz at oracle.com  Sun Feb  3 14:18:07 2013
From: brian.goetz at oracle.com (Brian Goetz)
Date: Sun, 03 Feb 2013 17:18:07 -0500
Subject: Custom stream extensions
In-Reply-To: <CAKEXrxnaBjkst6tO0rt_zgWSn1uQH=bHTGRHSTuCXTqPGcLzjw@mail.gmail.com>
References: <CAKEXrxnaBjkst6tO0rt_zgWSn1uQH=bHTGRHSTuCXTqPGcLzjw@mail.gmail.com>
Message-ID: <510EE21F.9090300@oracle.com>

Right.  During initial development, all these classes were public, 
mostly for convenience of testing.

There always has been an extensibility strategy in place, but it will 
sadly not be ready for 8.  Eventually, we will make public the XxxOp 
classes, which will enable you to write your own ops, and thread them 
into pipeline with the pipeline() method:

   stream.filter(...)
         .pipeline(myCustomOp(args))
         .map(...)
         ...

The built-in ops all use this API, so we have been eating our own 
dogfood.  However, it is clear that this API is not yet ready to be 
carved in stone.  So the responsible thing to do is to keep it private 
for now, until it is ready, at which point this extensibility mechanism 
will be available to everyone.



On 2/3/2013 4:56 PM, Arul Dhesiaseelan wrote:
> I was able to add extensions to my custom list implementation in earlier
> builds.
>
>    public MyStream<E> stream() {
>      return new MyReferencePipeline<>(() -> Arrays.spliterator((E[])
> this.toArray(), 0, this.size()), StreamOpFlag.IS_SIZED |
> StreamOpFlag.IS_ORDERED);
>    }
>
>
> Now that, ReferencePipeline is made package local, this approach is no
> longer possible.
>
> It was extremely useful to extend some of these core classes outside the
> package and toss in extensions with minimal coding. I assume this is not
> encouraged?
>
> Thanks,
> Arul
>

From aruld at acm.org  Sun Feb  3 14:43:46 2013
From: aruld at acm.org (Arul Dhesiaseelan)
Date: Sun, 3 Feb 2013 12:43:46 -1000
Subject: Custom stream extensions
In-Reply-To: <510EE21F.9090300@oracle.com>
References: <CAKEXrxnaBjkst6tO0rt_zgWSn1uQH=bHTGRHSTuCXTqPGcLzjw@mail.gmail.com>
	<510EE21F.9090300@oracle.com>
Message-ID: <CAKEXrxnifStY4KU+Ub9BCT7o5VfoYHd4je0C8Za_QpEJyjZgTw@mail.gmail.com>

Thanks Brian. This approach looks awesome. I hope it sees light some day.


On Sun, Feb 3, 2013 at 12:18 PM, Brian Goetz <brian.goetz at oracle.com> wrote:

> Right.  During initial development, all these classes were public, mostly
> for convenience of testing.
>
> There always has been an extensibility strategy in place, but it will
> sadly not be ready for 8.  Eventually, we will make public the XxxOp
> classes, which will enable you to write your own ops, and thread them into
> pipeline with the pipeline() method:
>
>   stream.filter(...)
>         .pipeline(myCustomOp(args))
>         .map(...)
>         ...
>
> The built-in ops all use this API, so we have been eating our own dogfood.
>  However, it is clear that this API is not yet ready to be carved in stone.
>  So the responsible thing to do is to keep it private for now, until it is
> ready, at which point this extensibility mechanism will be available to
> everyone.
>
>
>
>
> On 2/3/2013 4:56 PM, Arul Dhesiaseelan wrote:
>
>> I was able to add extensions to my custom list implementation in earlier
>> builds.
>>
>>    public MyStream<E> stream() {
>>      return new MyReferencePipeline<>(() -> Arrays.spliterator((E[])
>> this.toArray(), 0, this.size()), StreamOpFlag.IS_SIZED |
>> StreamOpFlag.IS_ORDERED);
>>    }
>>
>>
>> Now that, ReferencePipeline is made package local, this approach is no
>> longer possible.
>>
>> It was extremely useful to extend some of these core classes outside the
>> package and toss in extensions with minimal coding. I assume this is not
>> encouraged?
>>
>> Thanks,
>> Arul
>>
>>

From brian.goetz at oracle.com  Sun Feb  3 16:34:34 2013
From: brian.goetz at oracle.com (Brian Goetz)
Date: Sun, 03 Feb 2013 19:34:34 -0500
Subject: Custom stream extensions
In-Reply-To: <CAKEXrxnifStY4KU+Ub9BCT7o5VfoYHd4je0C8Za_QpEJyjZgTw@mail.gmail.com>
References: <CAKEXrxnaBjkst6tO0rt_zgWSn1uQH=bHTGRHSTuCXTqPGcLzjw@mail.gmail.com>
	<510EE21F.9090300@oracle.com>
	<CAKEXrxnifStY4KU+Ub9BCT7o5VfoYHd4je0C8Za_QpEJyjZgTw@mail.gmail.com>
Message-ID: <510F021A.1060601@oracle.com>

>     Right.  During initial development, all these classes were public,
>     mostly for convenience of testing.

Just to give you an idea of how hard we make life for ourselves...

The "standard" testing trick for unit-testing package-private classes is 
to have a parallel source hierarchy for tests:

src/com/foo/Blah.java
...
test/com/foo/BlahTest.java

so the tests can be in the same package as the source.  But, that 
doesn't work for the JDK.  Unfortunately, you can't load java.* classes 
except from the bootclasspath.  Which means that big chunks of the 
tests, along with framework pieces like testng, end up on the 
bootclasspath in our test environment.  Which is a pain (and also means 
we're testing in a slightly different environment than our customers 
will run.)

So this is why the classes were all public until we bit the bullet and 
reorg'ed the tests into the appropriate bootclasspath/non-bootclasspath 
buckets.

I've got it on my list to see if I can shave down that set of 
bootclasspath classes further.  Which will almost certainly require 
nasty tricks :(


From aruld at acm.org  Sun Feb  3 17:38:07 2013
From: aruld at acm.org (Arul Dhesiaseelan)
Date: Sun, 3 Feb 2013 15:38:07 -1000
Subject: Custom stream extensions
In-Reply-To: <510F021A.1060601@oracle.com>
References: <CAKEXrxnaBjkst6tO0rt_zgWSn1uQH=bHTGRHSTuCXTqPGcLzjw@mail.gmail.com>
	<510EE21F.9090300@oracle.com>
	<CAKEXrxnifStY4KU+Ub9BCT7o5VfoYHd4je0C8Za_QpEJyjZgTw@mail.gmail.com>
	<510F021A.1060601@oracle.com>
Message-ID: <CAKEXrxnikviDp+uaPJXBzduD+Z28=ccr_-yzeK=2xYvG_KLYQQ@mail.gmail.com>

Thanks for that hint. It works for me. I believe it is a valid case to use
-Xbootclasspath/p atleast in my case :-)



On Sun, Feb 3, 2013 at 2:34 PM, Brian Goetz <brian.goetz at oracle.com> wrote:

>     Right.  During initial development, all these classes were public,
>>     mostly for convenience of testing.
>>
>
> Just to give you an idea of how hard we make life for ourselves...
>
> The "standard" testing trick for unit-testing package-private classes is
> to have a parallel source hierarchy for tests:
>
> src/com/foo/Blah.java
> ...
> test/com/foo/BlahTest.java
>
> so the tests can be in the same package as the source.  But, that doesn't
> work for the JDK.  Unfortunately, you can't load java.* classes except from
> the bootclasspath.  Which means that big chunks of the tests, along with
> framework pieces like testng, end up on the bootclasspath in our test
> environment.  Which is a pain (and also means we're testing in a slightly
> different environment than our customers will run.)
>
> So this is why the classes were all public until we bit the bullet and
> reorg'ed the tests into the appropriate bootclasspath/non-**bootclasspath
> buckets.
>
> I've got it on my list to see if I can shave down that set of
> bootclasspath classes further.  Which will almost certainly require nasty
> tricks :(
>
>

From maurizio.cimadamore at oracle.com  Mon Feb  4 04:53:02 2013
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Mon, 04 Feb 2013 12:53:02 +0000
Subject: hg: lambda/lambda/langtools: 56 new changesets
Message-ID: <20130204125530.5A78D477DC@hg.openjdk.java.net>

Changeset: 45fed5cfd1c3
Author:    katleman
Date:      2013-01-10 09:56 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/45fed5cfd1c3

Added tag jdk8-b72 for changeset 6f0986ed9b7e

! .hgtags

Changeset: 0c244701188e
Author:    mchung
Date:      2012-12-28 22:25 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/0c244701188e

8003562: Provide a CLI tool to analyze class dependencies
Reviewed-by: jjg, alanb, ulfzibis, erikj

! make/build.properties
! makefiles/BuildLangtools.gmk
! src/share/classes/com/sun/tools/classfile/Dependencies.java
! src/share/classes/com/sun/tools/classfile/Dependency.java
+ src/share/classes/com/sun/tools/jdeps/Archive.java
+ src/share/classes/com/sun/tools/jdeps/ClassFileReader.java
+ src/share/classes/com/sun/tools/jdeps/JdepsTask.java
+ src/share/classes/com/sun/tools/jdeps/Main.java
+ src/share/classes/com/sun/tools/jdeps/PlatformClassPath.java
+ src/share/classes/com/sun/tools/jdeps/resources/jdeps.properties
+ src/share/classes/com/sun/tools/jdeps/resources/jdk.properties
+ src/share/classes/com/sun/tools/jdeps/resources/version.properties-template
! test/Makefile
+ test/tools/jdeps/Basic.java
+ test/tools/jdeps/Test.java
+ test/tools/jdeps/p/Foo.java

Changeset: 31780dd06ec7
Author:    jjg
Date:      2012-12-29 17:33 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/31780dd06ec7

8004727: Add compiler support for parameter reflection
Reviewed-by: jjg
Contributed-by: eric.mccorkle at oracle.com

! src/share/classes/com/sun/tools/classfile/Attribute.java
! src/share/classes/com/sun/tools/classfile/ClassWriter.java
+ src/share/classes/com/sun/tools/classfile/MethodParameters_attribute.java
! src/share/classes/com/sun/tools/javac/code/Symbol.java
! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java
! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java
! src/share/classes/com/sun/tools/javac/main/Option.java
! src/share/classes/com/sun/tools/javac/resources/javac.properties
! src/share/classes/com/sun/tools/javac/util/Names.java
! src/share/classes/com/sun/tools/javap/AttributeWriter.java
+ test/tools/javac/MethodParameters.java
+ test/tools/javap/MethodParameters.java

Changeset: 383bc0fbd759
Author:    jjg
Date:      2012-12-30 06:17 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/383bc0fbd759

8005195: Doclint regression tests fail on windows
Reviewed-by: mcimadamore

! test/tools/doclint/DocLintTester.java

Changeset: 1d8438db45f2
Author:    lana
Date:      2013-01-01 17:50 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/1d8438db45f2

Merge


Changeset: 0e17c3c23e3b
Author:    bpatel
Date:      2013-01-04 23:06 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/0e17c3c23e3b

8004891: Check for abstract method in javadoc does not conform to the language model
Reviewed-by: jjg

! src/share/classes/com/sun/tools/doclets/formats/html/AbstractMemberWriter.java
! src/share/classes/com/sun/tools/javadoc/MethodDocImpl.java
+ test/com/sun/javadoc/testAbstractMethod/TestAbstractMethod.java
+ test/com/sun/javadoc/testAbstractMethod/pkg/A.java
+ test/com/sun/javadoc/testAbstractMethod/pkg/B.java
+ test/com/sun/javadoc/testAbstractMethod/pkg/C.java

Changeset: 8c0c63a6e3b7
Author:    bpatel
Date:      2013-01-05 00:55 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/8c0c63a6e3b7

8005092: javadoc should check for synthesized bit on an annotation
Reviewed-by: jjg

! src/share/classes/com/sun/javadoc/AnnotationDesc.java
! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java
! src/share/classes/com/sun/tools/javadoc/AnnotationDescImpl.java
+ test/com/sun/javadoc/testRepeatedAnnotations/TestRepeatedAnnotations.java
+ test/com/sun/javadoc/testRepeatedAnnotations/pkg/C.java
+ test/com/sun/javadoc/testRepeatedAnnotations/pkg/ContaineeRegDoc.java
+ test/com/sun/javadoc/testRepeatedAnnotations/pkg/ContaineeSynthDoc.java
+ test/com/sun/javadoc/testRepeatedAnnotations/pkg/ContainerRegDoc.java
+ test/com/sun/javadoc/testRepeatedAnnotations/pkg/ContainerRegNotDoc.java
+ test/com/sun/javadoc/testRepeatedAnnotations/pkg/ContainerSynthDoc.java
+ test/com/sun/javadoc/testRepeatedAnnotations/pkg/D.java
+ test/com/sun/javadoc/testRepeatedAnnotations/pkg/NonSynthDocContainer.java
+ test/com/sun/javadoc/testRepeatedAnnotations/pkg/RegArryDoc.java
+ test/com/sun/javadoc/testRepeatedAnnotations/pkg/RegContaineeDoc.java
+ test/com/sun/javadoc/testRepeatedAnnotations/pkg/RegContaineeNotDoc.java
+ test/com/sun/javadoc/testRepeatedAnnotations/pkg/RegContainerDoc.java
+ test/com/sun/javadoc/testRepeatedAnnotations/pkg/RegContainerNotDoc.java
+ test/com/sun/javadoc/testRepeatedAnnotations/pkg/RegDoc.java
+ test/com/sun/javadoc/testRepeatedAnnotations/pkg1/C.java
+ test/com/sun/javadoc/testRepeatedAnnotations/pkg1/ContaineeNotDoc.java
+ test/com/sun/javadoc/testRepeatedAnnotations/pkg1/ContaineeSynthDoc.java
+ test/com/sun/javadoc/testRepeatedAnnotations/pkg1/ContainerSynthNotDoc.java
+ test/com/sun/javadoc/testRepeatedAnnotations/pkg1/ContainerValDoc.java
+ test/com/sun/javadoc/testRepeatedAnnotations/pkg1/ContainerValNotDoc.java
+ test/com/sun/javadoc/testRepeatedAnnotations/pkg1/RegContaineeDoc.java
+ test/com/sun/javadoc/testRepeatedAnnotations/pkg1/RegContaineeNotDoc.java
+ test/com/sun/javadoc/testRepeatedAnnotations/pkg1/RegContainerValDoc.java
+ test/com/sun/javadoc/testRepeatedAnnotations/pkg1/RegContainerValNotDoc.java

Changeset: a9cb93cca229
Author:    jjh
Date:      2013-01-07 17:51 +0000
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/a9cb93cca229

8005647: langtools/test/tools/javap/MethodParameters.java fails on windows
Summary: Fix javap to not output \r\r\n
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javap/ClassWriter.java
! test/tools/javac/MethodParameters.java
! test/tools/javap/MethodParameters.java

Changeset: 38d3d1027f5a
Author:    mcimadamore
Date:      2013-01-08 10:15 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/38d3d1027f5a

8005243: Restructure method check code to allow pluggable checkers
Summary: Add interface to perform a method check - to be implemented by helper classes
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/Infer.java
! src/share/classes/com/sun/tools/javac/comp/Resolve.java

Changeset: db91d860156a
Author:    mcimadamore
Date:      2013-01-08 10:16 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/db91d860156a

8005179: Cleanup Resolve.AmbiguityError
Summary: Linearize nested ambiguity errors
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/Resolve.java
! test/tools/javac/lambda/TargetType21.java
! test/tools/javac/lambda/TargetType21.out

Changeset: d07340b61e6a
Author:    mcimadamore
Date:      2013-01-08 10:17 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/d07340b61e6a

8005184: Restructure DeferredAttr to allow pluggable deferred type completers
Summary: Add hooks to generalize deferred type completion via custom helper objects
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/DeferredAttr.java

Changeset: 954541f13717
Author:    vromero
Date:      2013-01-08 13:47 +0000
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/954541f13717

8005167: execution time of combo tests in javac should be improved
Reviewed-by: jjg, jjh

! test/tools/javac/Diagnostics/6769027/T6769027.java
! test/tools/javac/T7093325.java
! test/tools/javac/cast/intersection/IntersectionTypeCastTest.java
! test/tools/javac/defaultMethods/super/TestDefaultSuperCall.java
! test/tools/javac/failover/CheckAttributedTree.java
! test/tools/javac/generics/diamond/7046778/DiamondAndInnerClassTest.java
! test/tools/javac/generics/rawOverride/7062745/GenericOverrideTest.java
! test/tools/javac/lambda/FunctionalInterfaceConversionTest.java
! test/tools/javac/lambda/LambdaParserTest.java
! test/tools/javac/lambda/MethodReferenceParserTest.java
! test/tools/javac/lambda/TestInvokeDynamic.java
! test/tools/javac/lambda/mostSpecific/StructuralMostSpecificTest.java
! test/tools/javac/lambda/typeInference/combo/TypeInferenceComboTest.java
+ test/tools/javac/lib/JavacTestingAbstractThreadedTest.java
! test/tools/javac/multicatch/7030606/DisjunctiveTypeWellFormednessTest.java
! test/tools/javac/varargs/7042566/T7042566.java
! test/tools/javac/varargs/warning/Warn4.java
! test/tools/javac/varargs/warning/Warn5.java

Changeset: d2eb08b3f64f
Author:    jjg
Date:      2013-01-09 10:26 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/d2eb08b3f64f

8005644: set default max errs and max warns
Reviewed-by: darcy

! src/share/classes/com/sun/tools/javadoc/Messager.java
+ test/tools/javadoc/MaxWarns.java

Changeset: 7612fe48be90
Author:    darcy
Date:      2013-01-09 20:02 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/7612fe48be90

8004730: Add language model support for parameter reflection
Reviewed-by: abuckley

! src/share/classes/javax/lang/model/element/Element.java
! src/share/classes/javax/lang/model/element/VariableElement.java
! src/share/classes/javax/lang/model/element/package-info.java

Changeset: d462da465da6
Author:    jjg
Date:      2013-01-10 14:09 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/d462da465da6

8006037: extra space in javac -help for -J and @ options
Reviewed-by: darcy

! src/share/classes/com/sun/tools/javac/main/Option.java
+ test/tools/javac/main/Option_J_At_Test.java

Changeset: 7d2f628f04f1
Author:    jjg
Date:      2013-01-10 15:48 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/7d2f628f04f1

8006033: bug in Pretty.toSimpleString
Reviewed-by: darcy

! src/share/classes/com/sun/tools/javac/tree/Pretty.java
+ test/tools/javac/tree/PrettySimpleStringTest.java

Changeset: 8d0baee36c71
Author:    lana
Date:      2013-01-10 15:53 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/8d0baee36c71

Merge


Changeset: 56c97aff46bb
Author:    katleman
Date:      2013-01-16 12:00 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/56c97aff46bb

Added tag jdk8-b73 for changeset 8d0baee36c71

! .hgtags

Changeset: 54e4ba223319
Author:    katleman
Date:      2013-01-24 16:49 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/54e4ba223319

Added tag jdk8-b74 for changeset 56c97aff46bb

! .hgtags

Changeset: fc4cb1577ad6
Author:    jjg
Date:      2013-01-10 19:38 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/fc4cb1577ad6

8004834: Add doclint support into javadoc
Reviewed-by: darcy

! src/share/classes/com/sun/tools/doclets/formats/html/ConfigurationImpl.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclets.properties
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/MessageRetriever.java
! src/share/classes/com/sun/tools/javac/comp/Enter.java
! src/share/classes/com/sun/tools/javadoc/DocEnv.java
! src/share/classes/com/sun/tools/javadoc/DocImpl.java
! src/share/classes/com/sun/tools/javadoc/JavadocMemberEnter.java
! src/share/classes/com/sun/tools/javadoc/RootDocImpl.java
! test/com/sun/javadoc/5093723/T5093723.java
! test/com/sun/javadoc/testBadSourceFile/TestBadSourceFile.java
! test/com/sun/javadoc/testHtmlDefinitionListTag/TestHtmlDefinitionListTag.java
! test/com/sun/javadoc/testNewLanguageFeatures/TestNewLanguageFeatures.java
! test/com/sun/javadoc/testReturnTag/TestReturnTag.java
! test/com/sun/javadoc/testTagInheritence/TestTagInheritence.java
! test/com/sun/javadoc/testTagMisuse/TestTagMisuse.java
! test/com/sun/javadoc/testValueTag/TestValueTag.java
! test/com/sun/javadoc/testWarnBadParamNames/TestWarnBadParamNames.java
! test/com/sun/javadoc/testWarnings/TestWarnings.java
! test/tools/javadoc/6958836/Test.java
! test/tools/javadoc/6964914/Test.java
! test/tools/javadoc/6964914/TestStdDoclet.java
! test/tools/javadoc/MaxWarns.java
! test/tools/javadoc/T6551367.java
+ test/tools/javadoc/doclint/DocLintTest.java

Changeset: 9f42a06a49c0
Author:    jfranck
Date:      2013-01-14 19:52 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/9f42a06a49c0

7193719: Support repeating annotations in javax.lang.model
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Symbol.java
! src/share/classes/com/sun/tools/javac/model/JavacElements.java
! src/share/classes/javax/lang/model/element/Element.java

Changeset: df694c775e8a
Author:    jjg
Date:      2013-01-14 13:50 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/df694c775e8a

8006119: update javac to follow latest spec for repeatable annotations
Reviewed-by: darcy

! src/share/classes/com/sun/tools/javac/code/Annotations.java
! src/share/classes/com/sun/tools/javac/code/Symtab.java
! src/share/classes/com/sun/tools/javac/comp/Annotate.java
! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/Check.java
! src/share/classes/com/sun/tools/javac/model/JavacElements.java
! src/share/classes/com/sun/tools/javac/resources/compiler.properties
! test/com/sun/javadoc/testRepeatedAnnotations/pkg/ContaineeSynthDoc.java
! test/com/sun/javadoc/testRepeatedAnnotations/pkg/ContainerSynthDoc.java
! test/com/sun/javadoc/testRepeatedAnnotations/pkg1/ContaineeSynthDoc.java
! test/com/sun/javadoc/testRepeatedAnnotations/pkg1/ContainerSynthNotDoc.java
! test/tools/javac/annotations/repeatingAnnotations/BaseAnnoAsContainerAnno.java
! test/tools/javac/annotations/repeatingAnnotations/BaseAnnoAsContainerAnno.out
! test/tools/javac/annotations/repeatingAnnotations/BasicRepeatingAnnotations.java
! test/tools/javac/annotations/repeatingAnnotations/CheckTargets.java
! test/tools/javac/annotations/repeatingAnnotations/ClassReaderDefault.java
! test/tools/javac/annotations/repeatingAnnotations/ContainerHasRepeatedContained.java
! test/tools/javac/annotations/repeatingAnnotations/CyclicAnnotation.java
! test/tools/javac/annotations/repeatingAnnotations/CyclicAnnotation.out
! test/tools/javac/annotations/repeatingAnnotations/DefaultCasePresent.java
! test/tools/javac/annotations/repeatingAnnotations/DelayRepeatedContainer.java
! test/tools/javac/annotations/repeatingAnnotations/DocumentedContainerAnno.java
! test/tools/javac/annotations/repeatingAnnotations/DocumentedContainerAnno.out
! test/tools/javac/annotations/repeatingAnnotations/InheritedContainerAnno.java
! test/tools/javac/annotations/repeatingAnnotations/InheritedContainerAnno.out
! test/tools/javac/annotations/repeatingAnnotations/InvalidTarget.java
- test/tools/javac/annotations/repeatingAnnotations/MissingContainedBy.java
! test/tools/javac/annotations/repeatingAnnotations/MissingContainer.java
! test/tools/javac/annotations/repeatingAnnotations/MissingContainer.out
- test/tools/javac/annotations/repeatingAnnotations/MissingContainerFor.java
! test/tools/javac/annotations/repeatingAnnotations/MissingDefaultCase1.java
! test/tools/javac/annotations/repeatingAnnotations/MissingDefaultCase1.out
! test/tools/javac/annotations/repeatingAnnotations/MissingDefaultCase2.java
! test/tools/javac/annotations/repeatingAnnotations/MissingDefaultCase2.out
! test/tools/javac/annotations/repeatingAnnotations/MissingValueMethod.java
! test/tools/javac/annotations/repeatingAnnotations/MissingValueMethod.out
! test/tools/javac/annotations/repeatingAnnotations/MultiLevelRepeatableAnno.java
! test/tools/javac/annotations/repeatingAnnotations/MultipleAnnoMixedOrder.java
! test/tools/javac/annotations/repeatingAnnotations/NestedContainers.java
! test/tools/javac/annotations/repeatingAnnotations/NoRepeatableAnno.out
! test/tools/javac/annotations/repeatingAnnotations/RepMemberAnno.java
! test/tools/javac/annotations/repeatingAnnotations/RepSelfMemberAnno.java
! test/tools/javac/annotations/repeatingAnnotations/RepeatingAndContainerPresent.java
! test/tools/javac/annotations/repeatingAnnotations/RepeatingTargetNotAllowed.java
! test/tools/javac/annotations/repeatingAnnotations/RepeatingTargetNotAllowed.out
! test/tools/javac/annotations/repeatingAnnotations/SelfRepeatingAnnotations.java
! test/tools/javac/annotations/repeatingAnnotations/SingleRepeatingAndContainer.java
- test/tools/javac/annotations/repeatingAnnotations/UseWrongContainedBy.java
- test/tools/javac/annotations/repeatingAnnotations/UseWrongContainerFor.java
+ test/tools/javac/annotations/repeatingAnnotations/UseWrongRepeatable.java
- test/tools/javac/annotations/repeatingAnnotations/WrongContainedBy.java
- test/tools/javac/annotations/repeatingAnnotations/WrongContainerFor.java
! test/tools/javac/annotations/repeatingAnnotations/WrongReturnTypeForValue.java
! test/tools/javac/annotations/repeatingAnnotations/WrongReturnTypeForValue.out
! test/tools/javac/annotations/repeatingAnnotations/combo/BasicSyntaxCombo.java
! test/tools/javac/annotations/repeatingAnnotations/combo/DeprecatedAnnoCombo.java
! test/tools/javac/annotations/repeatingAnnotations/combo/DocumentedAnnoCombo.java
! test/tools/javac/annotations/repeatingAnnotations/combo/Helper.java
! test/tools/javac/annotations/repeatingAnnotations/combo/InheritedAnnoCombo.java
! test/tools/javac/annotations/repeatingAnnotations/combo/RetentionAnnoCombo.java
! test/tools/javac/diags/examples.not-yet.txt
- test/tools/javac/diags/examples/ContainedByDocumentedMismatch.java
- test/tools/javac/diags/examples/ContainedByInheritedMismatch.java
- test/tools/javac/diags/examples/ContainedByNoValue.java
- test/tools/javac/diags/examples/ContainedByNonDefault.java
- test/tools/javac/diags/examples/ContainedByRetentionMismatch.java
- test/tools/javac/diags/examples/ContainedByTargetMismatch.java
- test/tools/javac/diags/examples/ContainedByWrongValueType.java
! test/tools/javac/diags/examples/InvalidDuplicateAnnotation.java
+ test/tools/javac/diags/examples/RepeatableDocumentedMismatch.java
+ test/tools/javac/diags/examples/RepeatableInheritedMismatch.java
+ test/tools/javac/diags/examples/RepeatableNoValue.java
+ test/tools/javac/diags/examples/RepeatableNonDefault.java
+ test/tools/javac/diags/examples/RepeatableRetentionMismatch.java
+ test/tools/javac/diags/examples/RepeatableTargetMismatch.java
+ test/tools/javac/diags/examples/RepeatableWrongValueType.java
! test/tools/javac/diags/examples/RepeatingAnnotationAndContainer.java
- test/tools/javac/diags/examples/WrongContainedBy.java
- test/tools/javac/diags/examples/WrongContainerFor.java

Changeset: d54b4a091450
Author:    jjg
Date:      2013-01-14 14:17 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/d54b4a091450

8006241: Test DocRootSlash.java fails
Reviewed-by: darcy

! test/com/sun/javadoc/DocRootSlash/DocRootSlash.java

Changeset: f805b5e3c9d1
Author:    chegar
Date:      2013-01-15 20:38 +0000
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/f805b5e3c9d1

8006344: Broken javadoc link in javax.lang.model.element.Element
Reviewed-by: lancea, alanb, jfranck

! src/share/classes/javax/lang/model/element/Element.java

Changeset: bc1023e0e533
Author:    jjg
Date:      2013-01-15 13:03 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/bc1023e0e533

8006224: Doclint NPE for attribute with no value
Reviewed-by: darcy

! src/share/classes/com/sun/tools/doclint/Checker.java
! src/share/classes/com/sun/tools/doclint/resources/doclint.properties
+ test/tools/doclint/AnchorTest.java
+ test/tools/doclint/AnchorTest.out

Changeset: f785dcac17b7
Author:    mcimadamore
Date:      2013-01-16 16:27 +0000
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/f785dcac17b7

8005854: Add support for array constructor references
Summary: Support constructor references of the kind int[]::new
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/Check.java
! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java
! src/share/classes/com/sun/tools/javac/comp/Resolve.java
! src/share/classes/com/sun/tools/javac/tree/JCTree.java
+ test/tools/javac/lambda/MethodReference59.java
+ test/tools/javac/lambda/MethodReference60.java
+ test/tools/javac/lambda/MethodReference60.out

Changeset: 7aa2025bbb7b
Author:    mcimadamore
Date:      2013-01-16 16:30 +0000
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/7aa2025bbb7b

8005299: Add FunctionalInterface checking to javac
Summary: Javac should check that types annotated with @FunctionalInterface are indeed functional interfaces
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Symtab.java
! src/share/classes/com/sun/tools/javac/code/Types.java
! src/share/classes/com/sun/tools/javac/comp/Check.java
! src/share/classes/com/sun/tools/javac/resources/compiler.properties
! src/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.java
! test/tools/javac/diags/examples.not-yet.txt
+ test/tools/javac/diags/examples/BadFunctionalIntfAnno.java
! test/tools/javac/lambda/BadConv03.out
! test/tools/javac/lambda/BadLambdaPos.out
! test/tools/javac/lambda/BadTargetType.out
+ test/tools/javac/lambda/FunctionalInterfaceAnno.java
+ test/tools/javac/lambda/FunctionalInterfaceAnno.out
! test/tools/javac/lambda/Intersection01.out
! test/tools/javac/lambda/LambdaConv09.out
! test/tools/javac/lambda/LambdaExpr10.out
! test/tools/javac/lambda/MethodReference04.out
! test/tools/javac/lambda/TargetType17.out
! test/tools/javac/lambda/TargetType43.out
! test/tools/javac/lambda/funcInterfaces/LambdaTest2_neg1.out
! test/tools/javac/lambda/funcInterfaces/NonSAM1.out
! test/tools/javac/lambda/funcInterfaces/NonSAM3.out
! test/tools/javac/lambda/lambdaExpression/AbstractClass_neg.out
! test/tools/javac/lambda/lambdaExpression/InvalidExpression5.out

Changeset: 1afdf1f1472b
Author:    mcimadamore
Date:      2013-01-16 17:40 +0000
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/1afdf1f1472b

8005964: Regression: difference in error recovery after ambiguity causes JCK test failure
Summary: Wrong implementation of ResolveError.access in AmbiguityError
Reviewed-by: jjh

! src/share/classes/com/sun/tools/javac/comp/Resolve.java

Changeset: 6b6311a8c9cc
Author:    jjg
Date:      2013-01-16 10:29 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/6b6311a8c9cc

8006236: doclint: structural issue hidden
Reviewed-by: darcy

! src/share/classes/com/sun/tools/doclint/Checker.java
+ test/tools/doclint/EndTagsTest.java
+ test/tools/doclint/EndTagsTest.out

Changeset: 63b20bde7cd6
Author:    lana
Date:      2013-01-16 12:14 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/63b20bde7cd6

Merge


Changeset: 8b749558767b
Author:    darcy
Date:      2013-01-16 13:22 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/8b749558767b

8006283: Change to Class.cast() in javax.lang.model implementation for repeating annotations
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/model/JavacElements.java

Changeset: 916143318f10
Author:    jjg
Date:      2013-01-16 20:41 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/916143318f10

8006228: Doclint doesn't detect <code> {@code nested inline} </code>
Reviewed-by: darcy

! src/share/classes/com/sun/tools/doclint/Checker.java
! src/share/classes/com/sun/tools/doclint/resources/doclint.properties
+ test/tools/doclint/LiteralTest.java
+ test/tools/doclint/LiteralTest.out

Changeset: 2d2b2be57c78
Author:    mcimadamore
Date:      2013-01-17 18:15 +0000
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/2d2b2be57c78

8005852: Treatment of '_' as identifier
Summary: warn when '_' is found in an identifier position
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/parser/JavacParser.java
! src/share/classes/com/sun/tools/javac/parser/Tokens.java
! src/share/classes/com/sun/tools/javac/resources/compiler.properties
! test/tools/javac/lambda/LambdaParserTest.java

Changeset: 22e417cdddee
Author:    ohrstrom
Date:      2013-01-18 00:16 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/22e417cdddee

8004658: Add internal smart javac wrapper to solve JEP 139
Reviewed-by: jjg

! make/build.properties
! make/build.xml
+ src/share/classes/com/sun/tools/sjavac/BuildState.java
+ src/share/classes/com/sun/tools/sjavac/CleanProperties.java
+ src/share/classes/com/sun/tools/sjavac/CompileChunk.java
+ src/share/classes/com/sun/tools/sjavac/CompileJavaPackages.java
+ src/share/classes/com/sun/tools/sjavac/CompileProperties.java
+ src/share/classes/com/sun/tools/sjavac/CopyFile.java
+ src/share/classes/com/sun/tools/sjavac/JavacState.java
+ src/share/classes/com/sun/tools/sjavac/Log.java
+ src/share/classes/com/sun/tools/sjavac/Main.java
+ src/share/classes/com/sun/tools/sjavac/Module.java
+ src/share/classes/com/sun/tools/sjavac/Package.java
+ src/share/classes/com/sun/tools/sjavac/ProblemException.java
+ src/share/classes/com/sun/tools/sjavac/Source.java
+ src/share/classes/com/sun/tools/sjavac/Transformer.java
+ src/share/classes/com/sun/tools/sjavac/Util.java
+ src/share/classes/com/sun/tools/sjavac/comp/Dependencies.java
+ src/share/classes/com/sun/tools/sjavac/comp/JavaCompilerWithDeps.java
+ src/share/classes/com/sun/tools/sjavac/comp/PubapiVisitor.java
+ src/share/classes/com/sun/tools/sjavac/comp/ResolveWithDeps.java
+ src/share/classes/com/sun/tools/sjavac/comp/SmartFileManager.java
+ src/share/classes/com/sun/tools/sjavac/comp/SmartFileObject.java
+ src/share/classes/com/sun/tools/sjavac/comp/SmartWriter.java
+ src/share/classes/com/sun/tools/sjavac/server/CompilerPool.java
+ src/share/classes/com/sun/tools/sjavac/server/CompilerThread.java
+ src/share/classes/com/sun/tools/sjavac/server/JavacServer.java
+ src/share/classes/com/sun/tools/sjavac/server/PortFile.java
+ src/share/classes/com/sun/tools/sjavac/server/SysInfo.java
+ test/tools/sjavac/SJavac.java

Changeset: 3d84ae209919
Author:    mcimadamore
Date:      2013-01-18 15:38 +0000
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/3d84ae209919

8006561: Langtools test failure: missing diags/examples
Summary: forgot to hg add tests
Reviewed-by: jjg

+ test/tools/javac/diags/examples/UnderscoreAsIdentifier.java
+ test/tools/javac/lambda/WarnUnderscoreAsIdent.java
+ test/tools/javac/lambda/WarnUnderscoreAsIdent.out

Changeset: 4a3cfc970c6f
Author:    jjg
Date:      2013-01-21 10:00 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/4a3cfc970c6f

8006263: Supplementary test cases needed for doclint
Reviewed-by: mcimadamore
Contributed-by: peter.jensen at oracle.com

! src/share/classes/com/sun/tools/doclint/Checker.java
! src/share/classes/com/sun/tools/doclint/DocLint.java
! src/share/classes/com/sun/tools/doclint/Entity.java
! src/share/classes/com/sun/tools/doclint/HtmlTag.java
+ test/tools/doclint/CoverageExtras.java
! test/tools/doclint/DocLintTester.java
+ test/tools/doclint/html/EntitiesTest.java
+ test/tools/doclint/html/EntitiesTest.out
+ test/tools/doclint/tool/HelpTest.java
+ test/tools/doclint/tool/HelpTest.out
+ test/tools/doclint/tool/MaxDiagsTest.java
+ test/tools/doclint/tool/MaxDiagsTest.out
+ test/tools/doclint/tool/PathsTest.java
+ test/tools/doclint/tool/RunTest.java
+ test/tools/doclint/tool/StatsTest.java
+ test/tools/doclint/tool/StatsTest.out

Changeset: 967052c425a1
Author:    jjg
Date:      2013-01-21 10:07 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/967052c425a1

8006251: doclint: incorrect position for diagnostic for illegal text in tags
Reviewed-by: mcimadamore

! src/share/classes/com/sun/tools/doclint/Checker.java
! src/share/classes/com/sun/tools/doclint/HtmlTag.java
! src/share/classes/com/sun/tools/doclint/resources/doclint.properties
! test/tools/doclint/HtmlTagsTest.java
! test/tools/doclint/HtmlTagsTest.out
+ test/tools/doclint/html/BlockTagsTest.java
+ test/tools/doclint/html/InlineTagsTest.java
+ test/tools/doclint/html/ListTagsTest.java
+ test/tools/doclint/html/OtherTagsTest.java
+ test/tools/doclint/html/OtherTagsTest.out
+ test/tools/doclint/html/TableTagsTest.java
+ test/tools/doclint/html/TagNotAllowed.java
+ test/tools/doclint/html/TagNotAllowed.out
+ test/tools/doclint/html/TextNotAllowed.java
+ test/tools/doclint/html/TextNotAllowed.out
! test/tools/doclint/tidy/ParaInPre.out
! test/tools/doclint/tidy/TextNotAllowed.out

Changeset: b450959b42ff
Author:    lana
Date:      2013-01-20 23:39 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/b450959b42ff

Merge


Changeset: 1985e35e97b2
Author:    lana
Date:      2013-01-21 11:16 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/1985e35e97b2

Merge


Changeset: 7873d37f5b37
Author:    mcimadamore
Date:      2013-01-21 20:13 +0000
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/7873d37f5b37

8005244: Implement overload resolution as per latest spec EDR
Summary: Add support for stuck expressions and provisional applicability
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Source.java
! src/share/classes/com/sun/tools/javac/code/Types.java
! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/Check.java
! src/share/classes/com/sun/tools/javac/comp/DeferredAttr.java
! src/share/classes/com/sun/tools/javac/comp/Infer.java
! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java
! src/share/classes/com/sun/tools/javac/comp/Resolve.java
! src/share/classes/com/sun/tools/javac/comp/TransTypes.java
! src/share/classes/com/sun/tools/javac/tree/JCTree.java
! src/share/classes/com/sun/tools/javac/tree/Pretty.java
! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java
! test/tools/javac/Diagnostics/6722234/T6722234d_1.out
! test/tools/javac/Diagnostics/6722234/T6722234d_2.out
! test/tools/javac/diags/examples.not-yet.txt
! test/tools/javac/diags/examples/CyclicInference.java
- test/tools/javac/diags/examples/InferredDoNotConformToLower.java
- test/tools/javac/diags/examples/NoUniqueMaximalInstance.java
! test/tools/javac/diags/examples/WhereIntersection.java
! test/tools/javac/generics/diamond/T6939780.out
! test/tools/javac/generics/diamond/neg/Neg05.out
! test/tools/javac/generics/diamond/neg/Neg10.java
! test/tools/javac/generics/diamond/neg/Neg10.out
! test/tools/javac/generics/inference/6315770/T6315770.out
! test/tools/javac/generics/inference/6638712/T6638712b.out
! test/tools/javac/generics/inference/6650759/T6650759m.out
! test/tools/javac/lambda/MethodReference25.java
+ test/tools/javac/lambda/MethodReference25.out
! test/tools/javac/lambda/MethodReference26.java
- test/tools/javac/lambda/MethodReference26.out
! test/tools/javac/lambda/MethodReference43.java
! test/tools/javac/lambda/TargetType01.java
+ test/tools/javac/lambda/TargetType01.out
! test/tools/javac/lambda/TargetType06.java
- test/tools/javac/lambda/TargetType06.out
! test/tools/javac/lambda/TargetType10.out
! test/tools/javac/lambda/TargetType11.java
- test/tools/javac/lambda/TargetType11.out
! test/tools/javac/lambda/TargetType14.out
! test/tools/javac/lambda/TargetType21.java
! test/tools/javac/lambda/TargetType21.out
! test/tools/javac/lambda/TargetType26.out
! test/tools/javac/lambda/TargetType27.out
! test/tools/javac/lambda/TargetType28.out
! test/tools/javac/lambda/TargetType39.out
! test/tools/javac/lambda/TargetType45.java
- test/tools/javac/lambda/TargetType45.out
! test/tools/javac/lambda/TargetType50.out
+ test/tools/javac/lambda/TargetType51.java
+ test/tools/javac/lambda/TargetType52.java
+ test/tools/javac/lambda/TargetType52.out
! test/tools/javac/lambda/VoidCompatibility.java
- test/tools/javac/lambda/VoidCompatibility.out
! test/tools/javac/lambda/lambdaExpression/SamConversionComboTest.java
! test/tools/javac/lambda/methodReference/SamConversion.java
! test/tools/javac/lambda/methodReference/SamConversionComboTest.java
! test/tools/javac/lambda/typeInference/InferenceTest_neg5.out
! test/tools/javac/resolve/tests/PrimitiveOverReferenceVarargsAmbiguous.java

Changeset: c7c41a044e7c
Author:    mcimadamore
Date:      2013-01-21 20:14 +0000
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/c7c41a044e7c

8006566: Remove transient lambda-related guards from JavacParser
Summary: Remove transitional internal flag for allowing intersection types in cast
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/parser/JavacParser.java
! test/tools/javac/cast/intersection/IntersectionTypeCastTest.java
! test/tools/javac/cast/intersection/IntersectionTypeParserTest.java
! test/tools/javac/cast/intersection/model/Model01.java
! test/tools/javac/diags/examples/SecondaryBoundMustBeMarkerIntf.java
! test/tools/javac/lambda/Intersection01.java
! test/tools/javac/lambda/intersection/IntersectionTargetTypeTest.java

Changeset: b12ffdfa1341
Author:    mcimadamore
Date:      2013-01-21 20:15 +0000
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/b12ffdfa1341

8005851: Remove support for synchronized interface methods
Summary: Synchronized default methods are no longer supported
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Flags.java
! test/tools/javac/defaultMethods/syntax/TestDefaultMethodsSyntax.java
! test/tools/javac/lambdaShapes/org/openjdk/tests/vm/DefaultMethodsTest.java

Changeset: cf84b07a82db
Author:    mcimadamore
Date:      2013-01-21 20:19 +0000
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/cf84b07a82db

8005166: Add support for static interface methods
Summary: Support public static interface methods
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Flags.java
! src/share/classes/com/sun/tools/javac/code/Source.java
! src/share/classes/com/sun/tools/javac/code/Symbol.java
! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/Check.java
! src/share/classes/com/sun/tools/javac/parser/JavacParser.java
! src/share/classes/com/sun/tools/javac/resources/compiler.properties
+ test/tools/javac/defaultMethods/static/Static01.java
+ test/tools/javac/defaultMethods/static/Static02.java
+ test/tools/javac/defaultMethods/static/Static02.out
+ test/tools/javac/defaultMethods/static/hiding/InterfaceMethodHidingTest.java
+ test/tools/javac/defaultMethods/static/import/StaticImport1.java
+ test/tools/javac/defaultMethods/static/import/StaticImport2.java
+ test/tools/javac/defaultMethods/static/import/StaticImport2.out
+ test/tools/javac/defaultMethods/static/import/StaticImport3.java
+ test/tools/javac/defaultMethods/static/import/StaticImport3.out
+ test/tools/javac/defaultMethods/static/import/pkg/A.java
+ test/tools/javac/defaultMethods/static/import/pkg/B.java
+ test/tools/javac/defaultMethods/static/import/pkg/C.java
! test/tools/javac/defaultMethods/syntax/TestDefaultMethodsSyntax.java
+ test/tools/javac/diags/examples/IllegalStaticIntfMethCall.java
+ test/tools/javac/diags/examples/StaticIntfMethodNotSupported.java

Changeset: be443002e970
Author:    mcimadamore
Date:      2013-01-22 16:23 +0000
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/be443002e970

8006673: TargetType52 fails because of bad golden file
Summary: Fix golden file in negative test
Reviewed-by: jjg

! test/tools/javac/lambda/TargetType52.out

Changeset: b61e5f801f7c
Author:    mcimadamore
Date:      2013-01-22 16:39 +0000
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/b61e5f801f7c

8006684: Compiler produces java.lang.VerifyError: Bad type on operand stack
Summary: Lambda desugaring generates spurious references to 'this' in static contexts
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java
+ test/tools/javac/lambda/LambdaExpr21.java

Changeset: 8943b4213f59
Author:    jjg
Date:      2013-01-22 18:43 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/8943b4213f59

8006723: sjavac test fails to compile on clean build
Reviewed-by: ksrini

! test/tools/sjavac/SJavac.java
+ test/tools/sjavac/SJavacWrapper.java

Changeset: f5b70712e0d5
Author:    jjg
Date:      2013-01-22 19:06 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/f5b70712e0d5

8006728: temporarily workaround jtreg problems for doclint tests in othervm
Reviewed-by: jjh

+ test/tools/doclint/html/AAA.java
+ test/tools/doclint/tidy/AAA.java
+ test/tools/doclint/tool/AAA.java

Changeset: 385828dd5604
Author:    jjg
Date:      2013-01-22 19:07 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/385828dd5604

Merge


Changeset: 97bd5e7151bc
Author:    mcimadamore
Date:      2013-01-23 15:08 +0000
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/97bd5e7151bc

8006692: jdk/test/java/util/Collections/BigBinarySearch.java fails to compile
Summary: Missing boxing cause spurious inference failure
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/Infer.java
+ test/tools/javac/generics/inference/8006692/T8006692.java

Changeset: 5c956be64b9e
Author:    vromero
Date:      2013-01-23 20:57 +0000
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/5c956be64b9e

8006694: temporarily workaround combo tests are causing time out in several platforms
Reviewed-by: jjg
Contributed-by: maurizio.cimadamore at oracle.com

! test/Makefile
! test/tools/javac/Diagnostics/6769027/T6769027.java
! test/tools/javac/T7093325.java
! test/tools/javac/cast/intersection/IntersectionTypeCastTest.java
! test/tools/javac/defaultMethods/super/TestDefaultSuperCall.java
! test/tools/javac/failover/CheckAttributedTree.java
! test/tools/javac/generics/diamond/7046778/DiamondAndInnerClassTest.java
! test/tools/javac/generics/rawOverride/7062745/GenericOverrideTest.java
! test/tools/javac/lambda/FunctionalInterfaceConversionTest.java
! test/tools/javac/lambda/LambdaParserTest.java
! test/tools/javac/lambda/MethodReferenceParserTest.java
! test/tools/javac/lambda/TestInvokeDynamic.java
! test/tools/javac/lambda/mostSpecific/StructuralMostSpecificTest.java
! test/tools/javac/lambda/typeInference/combo/TypeInferenceComboTest.java
! test/tools/javac/lambdaShapes/org/openjdk/tests/vm/FDSeparateCompilationTest.java
! test/tools/javac/lib/JavacTestingAbstractThreadedTest.java
! test/tools/javac/multicatch/7030606/DisjunctiveTypeWellFormednessTest.java
! test/tools/javac/varargs/7042566/T7042566.java
! test/tools/javac/varargs/warning/Warn4.java
! test/tools/javac/varargs/warning/Warn5.java

Changeset: 71f35e4b93a5
Author:    jjg
Date:      2013-01-23 13:27 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/71f35e4b93a5

8006775: JSR 308: Compiler changes in JDK8
Reviewed-by: jjg
Contributed-by: mernst at cs.washington.edu, wmdietl at cs.washington.edu, mpapi at csail.mit.edu, mahmood at notnoop.com

+ src/share/classes/com/sun/javadoc/AnnotatedType.java
! src/share/classes/com/sun/javadoc/ExecutableMemberDoc.java
! src/share/classes/com/sun/javadoc/Type.java
! src/share/classes/com/sun/javadoc/TypeVariable.java
+ src/share/classes/com/sun/source/tree/AnnotatedTypeTree.java
! src/share/classes/com/sun/source/tree/MethodTree.java
! src/share/classes/com/sun/source/tree/Tree.java
! src/share/classes/com/sun/source/tree/TreeVisitor.java
! src/share/classes/com/sun/source/tree/TypeParameterTree.java
! src/share/classes/com/sun/source/util/SimpleTreeVisitor.java
! src/share/classes/com/sun/source/util/TaskEvent.java
! src/share/classes/com/sun/source/util/TreeScanner.java
! src/share/classes/com/sun/tools/classfile/Attribute.java
! src/share/classes/com/sun/tools/classfile/ClassWriter.java
+ src/share/classes/com/sun/tools/classfile/RuntimeInvisibleTypeAnnotations_attribute.java
+ src/share/classes/com/sun/tools/classfile/RuntimeTypeAnnotations_attribute.java
+ src/share/classes/com/sun/tools/classfile/RuntimeVisibleTypeAnnotations_attribute.java
+ src/share/classes/com/sun/tools/classfile/TypeAnnotation.java
! src/share/classes/com/sun/tools/doclets/formats/html/AbstractExecutableMemberWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/ConstructorWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/LinkFactoryImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/LinkInfoImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/MethodWriterImpl.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Util.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/links/LinkFactory.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/links/LinkInfo.java
! src/share/classes/com/sun/tools/javac/code/Annotations.java
! src/share/classes/com/sun/tools/javac/code/Attribute.java
! src/share/classes/com/sun/tools/javac/code/Flags.java
! src/share/classes/com/sun/tools/javac/code/Lint.java
! src/share/classes/com/sun/tools/javac/code/Printer.java
! src/share/classes/com/sun/tools/javac/code/Source.java
! src/share/classes/com/sun/tools/javac/code/Symbol.java
! src/share/classes/com/sun/tools/javac/code/TargetType.java
! src/share/classes/com/sun/tools/javac/code/Type.java
! src/share/classes/com/sun/tools/javac/code/TypeAnnotationPosition.java
+ src/share/classes/com/sun/tools/javac/code/TypeAnnotations.java
! src/share/classes/com/sun/tools/javac/code/Types.java
! src/share/classes/com/sun/tools/javac/comp/Annotate.java
! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/Check.java
! src/share/classes/com/sun/tools/javac/comp/ConstFold.java
! src/share/classes/com/sun/tools/javac/comp/Flow.java
! src/share/classes/com/sun/tools/javac/comp/Lower.java
! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java
! src/share/classes/com/sun/tools/javac/comp/Resolve.java
! src/share/classes/com/sun/tools/javac/comp/TransTypes.java
! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java
! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java
! src/share/classes/com/sun/tools/javac/jvm/Code.java
! src/share/classes/com/sun/tools/javac/jvm/Gen.java
! src/share/classes/com/sun/tools/javac/jvm/JNIWriter.java
! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java
! src/share/classes/com/sun/tools/javac/model/JavacTypes.java
! src/share/classes/com/sun/tools/javac/parser/JavacParser.java
! src/share/classes/com/sun/tools/javac/parser/Scanner.java
! src/share/classes/com/sun/tools/javac/parser/UnicodeReader.java
! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java
! src/share/classes/com/sun/tools/javac/resources/compiler.properties
! src/share/classes/com/sun/tools/javac/resources/compiler_ja.properties
! src/share/classes/com/sun/tools/javac/resources/compiler_zh_CN.properties
! src/share/classes/com/sun/tools/javac/tree/JCTree.java
! src/share/classes/com/sun/tools/javac/tree/Pretty.java
! src/share/classes/com/sun/tools/javac/tree/TreeCopier.java
! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java
! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java
! src/share/classes/com/sun/tools/javac/tree/TreeScanner.java
! src/share/classes/com/sun/tools/javac/tree/TreeTranslator.java
! src/share/classes/com/sun/tools/javac/util/JCDiagnostic.java
! src/share/classes/com/sun/tools/javac/util/Log.java
! src/share/classes/com/sun/tools/javadoc/AbstractTypeImpl.java
+ src/share/classes/com/sun/tools/javadoc/AnnotatedTypeImpl.java
! src/share/classes/com/sun/tools/javadoc/ClassDocImpl.java
! src/share/classes/com/sun/tools/javadoc/ExecutableMemberDocImpl.java
! src/share/classes/com/sun/tools/javadoc/PrimitiveType.java
! src/share/classes/com/sun/tools/javadoc/TypeMaker.java
! src/share/classes/com/sun/tools/javadoc/TypeVariableImpl.java
! src/share/classes/com/sun/tools/javap/AnnotationWriter.java
! src/share/classes/com/sun/tools/javap/AttributeWriter.java
! src/share/classes/com/sun/tools/javap/CodeWriter.java
! src/share/classes/com/sun/tools/javap/InstructionDetailWriter.java
+ src/share/classes/com/sun/tools/javap/TypeAnnotationWriter.java
! src/share/classes/javax/lang/model/SourceVersion.java
+ src/share/classes/javax/lang/model/type/AnnotatedType.java
! src/share/classes/javax/lang/model/type/ExecutableType.java
! src/share/classes/javax/lang/model/type/TypeKind.java
! src/share/classes/javax/lang/model/type/TypeVisitor.java
! src/share/classes/javax/lang/model/util/AbstractTypeVisitor6.java
! src/share/classes/javax/lang/model/util/Types.java
+ test/com/sun/javadoc/testAnnotationOptional/TestAnnotationOptional.java
+ test/com/sun/javadoc/testAnnotationOptional/pkg/AnnotationOptional.java
+ test/com/sun/javadoc/typeAnnotations/smoke/TestSmoke.java
+ test/com/sun/javadoc/typeAnnotations/smoke/pkg/TargetTypes.java
! test/tools/javac/7129225/TestImportStar.java
! test/tools/javac/7129225/TestImportStar.ref
! test/tools/javac/T6873845.java
+ test/tools/javac/T6985181.java
! test/tools/javac/annotations/6881115/T6881115.java
! test/tools/javac/annotations/6881115/T6881115.out
+ test/tools/javac/annotations/typeAnnotations/6967002/T6967002.java
+ test/tools/javac/annotations/typeAnnotations/6967002/T6967002.out
+ test/tools/javac/annotations/typeAnnotations/InnerClass.java
+ test/tools/javac/annotations/typeAnnotations/MultipleTargets.java
+ test/tools/javac/annotations/typeAnnotations/TargetTypes.java
+ test/tools/javac/annotations/typeAnnotations/TypeParameterTarget.java
+ test/tools/javac/annotations/typeAnnotations/TypeProcOnly.java
+ test/tools/javac/annotations/typeAnnotations/TypeUseTarget.java
+ test/tools/javac/annotations/typeAnnotations/api/AnnotatedArrayOrder.java
+ test/tools/javac/annotations/typeAnnotations/api/ArrayCreationTree.java
+ test/tools/javac/annotations/typeAnnotations/api/ArrayPositionConsistency.java
+ test/tools/javac/annotations/typeAnnotations/attribution/Scopes.java
+ test/tools/javac/annotations/typeAnnotations/classfile/ClassfileTestHelper.java
+ test/tools/javac/annotations/typeAnnotations/classfile/CombinationsTargetTest1.java
+ test/tools/javac/annotations/typeAnnotations/classfile/CombinationsTargetTest2.java
+ test/tools/javac/annotations/typeAnnotations/classfile/DeadCode.java
+ test/tools/javac/annotations/typeAnnotations/classfile/NewTypeArguments.java
+ test/tools/javac/annotations/typeAnnotations/classfile/NoTargetAnnotations.java
+ test/tools/javac/annotations/typeAnnotations/classfile/TypeCasts.java
+ test/tools/javac/annotations/typeAnnotations/classfile/Wildcards.java
+ test/tools/javac/annotations/typeAnnotations/failures/AnnotatedImport.java
+ test/tools/javac/annotations/typeAnnotations/failures/AnnotatedImport.out
+ test/tools/javac/annotations/typeAnnotations/failures/AnnotatedPackage1.java
+ test/tools/javac/annotations/typeAnnotations/failures/AnnotatedPackage1.out
+ test/tools/javac/annotations/typeAnnotations/failures/AnnotatedPackage2.java
+ test/tools/javac/annotations/typeAnnotations/failures/AnnotatedPackage2.out
+ test/tools/javac/annotations/typeAnnotations/failures/AnnotationVersion.java
+ test/tools/javac/annotations/typeAnnotations/failures/AnnotationVersion.out
+ test/tools/javac/annotations/typeAnnotations/failures/AnnotationVersion7.out
+ test/tools/javac/annotations/typeAnnotations/failures/BadCast.java
+ test/tools/javac/annotations/typeAnnotations/failures/BadCast.out
+ test/tools/javac/annotations/typeAnnotations/failures/CantAnnotateStaticClass.java
+ test/tools/javac/annotations/typeAnnotations/failures/CantAnnotateStaticClass.out
+ test/tools/javac/annotations/typeAnnotations/failures/IncompleteArray.java
+ test/tools/javac/annotations/typeAnnotations/failures/IncompleteArray.out
+ test/tools/javac/annotations/typeAnnotations/failures/IncompleteVararg.java
+ test/tools/javac/annotations/typeAnnotations/failures/IncompleteVararg.out
+ test/tools/javac/annotations/typeAnnotations/failures/IndexArray.java
+ test/tools/javac/annotations/typeAnnotations/failures/IndexArray.out
+ test/tools/javac/annotations/typeAnnotations/failures/LintCast.java
+ test/tools/javac/annotations/typeAnnotations/failures/LintCast.out
+ test/tools/javac/annotations/typeAnnotations/failures/OldArray.java
+ test/tools/javac/annotations/typeAnnotations/failures/Scopes.java
+ test/tools/javac/annotations/typeAnnotations/failures/Scopes.out
+ test/tools/javac/annotations/typeAnnotations/failures/StaticFields.java
+ test/tools/javac/annotations/typeAnnotations/failures/StaticFields.out
+ test/tools/javac/annotations/typeAnnotations/failures/StaticMethods.java
+ test/tools/javac/annotations/typeAnnotations/failures/StaticMethods.out
+ test/tools/javac/annotations/typeAnnotations/failures/TypeAndField.java
+ test/tools/javac/annotations/typeAnnotations/failures/VoidGenericMethod.java
+ test/tools/javac/annotations/typeAnnotations/failures/common/arrays/DuplicateAnnotationValue.java
+ test/tools/javac/annotations/typeAnnotations/failures/common/arrays/DuplicateAnnotationValue.out
+ test/tools/javac/annotations/typeAnnotations/failures/common/arrays/DuplicateTypeAnnotation.java
+ test/tools/javac/annotations/typeAnnotations/failures/common/arrays/DuplicateTypeAnnotation.out
+ test/tools/javac/annotations/typeAnnotations/failures/common/arrays/InvalidLocation.java
+ test/tools/javac/annotations/typeAnnotations/failures/common/arrays/InvalidLocation.out
+ test/tools/javac/annotations/typeAnnotations/failures/common/arrays/MissingAnnotationValue.java
+ test/tools/javac/annotations/typeAnnotations/failures/common/arrays/MissingAnnotationValue.out
+ test/tools/javac/annotations/typeAnnotations/failures/common/innertypeparams/DuplicateAnnotationValue.java
+ test/tools/javac/annotations/typeAnnotations/failures/common/innertypeparams/DuplicateAnnotationValue.out
+ test/tools/javac/annotations/typeAnnotations/failures/common/innertypeparams/DuplicateTypeAnnotation.java
+ test/tools/javac/annotations/typeAnnotations/failures/common/innertypeparams/DuplicateTypeAnnotation.out
+ test/tools/javac/annotations/typeAnnotations/failures/common/innertypeparams/InvalidLocation.java
+ test/tools/javac/annotations/typeAnnotations/failures/common/innertypeparams/InvalidLocation.out
+ test/tools/javac/annotations/typeAnnotations/failures/common/innertypeparams/MissingAnnotationValue.java
+ test/tools/javac/annotations/typeAnnotations/failures/common/innertypeparams/MissingAnnotationValue.out
+ test/tools/javac/annotations/typeAnnotations/failures/common/newarray/DuplicateAnnotationValue.java
+ test/tools/javac/annotations/typeAnnotations/failures/common/newarray/DuplicateAnnotationValue.out
+ test/tools/javac/annotations/typeAnnotations/failures/common/newarray/DuplicateTypeAnnotation.java
+ test/tools/javac/annotations/typeAnnotations/failures/common/newarray/DuplicateTypeAnnotation.out
+ test/tools/javac/annotations/typeAnnotations/failures/common/newarray/InvalidLocation.java
+ test/tools/javac/annotations/typeAnnotations/failures/common/newarray/InvalidLocation.out
+ test/tools/javac/annotations/typeAnnotations/failures/common/newarray/MissingAnnotationValue.java
+ test/tools/javac/annotations/typeAnnotations/failures/common/newarray/MissingAnnotationValue.out
+ test/tools/javac/annotations/typeAnnotations/failures/common/parambounds/BrokenAnnotation.java
+ test/tools/javac/annotations/typeAnnotations/failures/common/parambounds/BrokenAnnotation.out
+ test/tools/javac/annotations/typeAnnotations/failures/common/parambounds/DuplicateAnnotationValue.java
+ test/tools/javac/annotations/typeAnnotations/failures/common/parambounds/DuplicateAnnotationValue.out
+ test/tools/javac/annotations/typeAnnotations/failures/common/parambounds/DuplicateTypeAnnotation.java
+ test/tools/javac/annotations/typeAnnotations/failures/common/parambounds/DuplicateTypeAnnotation.out
+ test/tools/javac/annotations/typeAnnotations/failures/common/parambounds/InvalidLocation.java
+ test/tools/javac/annotations/typeAnnotations/failures/common/parambounds/InvalidLocation.out
+ test/tools/javac/annotations/typeAnnotations/failures/common/parambounds/MissingAnnotationValue.java
+ test/tools/javac/annotations/typeAnnotations/failures/common/parambounds/MissingAnnotationValue.out
+ test/tools/javac/annotations/typeAnnotations/failures/common/receiver/DuplicateAnnotationValue.java
+ test/tools/javac/annotations/typeAnnotations/failures/common/receiver/DuplicateAnnotationValue.out
+ test/tools/javac/annotations/typeAnnotations/failures/common/receiver/DuplicateTypeAnnotation.java
+ test/tools/javac/annotations/typeAnnotations/failures/common/receiver/DuplicateTypeAnnotation.out
+ test/tools/javac/annotations/typeAnnotations/failures/common/receiver/InvalidLocation.java
+ test/tools/javac/annotations/typeAnnotations/failures/common/receiver/InvalidLocation.out
+ test/tools/javac/annotations/typeAnnotations/failures/common/receiver/MissingAnnotationValue.java
+ test/tools/javac/annotations/typeAnnotations/failures/common/receiver/MissingAnnotationValue.out
+ test/tools/javac/annotations/typeAnnotations/failures/common/receiver/Nesting.java
+ test/tools/javac/annotations/typeAnnotations/failures/common/receiver/StaticThings.java
+ test/tools/javac/annotations/typeAnnotations/failures/common/receiver/StaticThings.out
+ test/tools/javac/annotations/typeAnnotations/failures/common/receiver/WrongType.java
+ test/tools/javac/annotations/typeAnnotations/failures/common/receiver/WrongType.out
+ test/tools/javac/annotations/typeAnnotations/failures/common/rest/DuplicateAnnotationValue.java
+ test/tools/javac/annotations/typeAnnotations/failures/common/rest/DuplicateAnnotationValue.out
+ test/tools/javac/annotations/typeAnnotations/failures/common/rest/DuplicateTypeAnnotation.java
+ test/tools/javac/annotations/typeAnnotations/failures/common/rest/DuplicateTypeAnnotation.out
+ test/tools/javac/annotations/typeAnnotations/failures/common/rest/InvalidLocation.java
+ test/tools/javac/annotations/typeAnnotations/failures/common/rest/InvalidLocation.out
+ test/tools/javac/annotations/typeAnnotations/failures/common/rest/MissingAnnotationValue.java
+ test/tools/javac/annotations/typeAnnotations/failures/common/rest/MissingAnnotationValue.out
+ test/tools/javac/annotations/typeAnnotations/failures/common/typeArgs/DuplicateAnnotationValue.java
+ test/tools/javac/annotations/typeAnnotations/failures/common/typeArgs/DuplicateAnnotationValue.out
+ test/tools/javac/annotations/typeAnnotations/failures/common/typeArgs/DuplicateTypeAnnotation.java
+ test/tools/javac/annotations/typeAnnotations/failures/common/typeArgs/DuplicateTypeAnnotation.out
+ test/tools/javac/annotations/typeAnnotations/failures/common/typeArgs/InvalidLocation.java
+ test/tools/javac/annotations/typeAnnotations/failures/common/typeArgs/InvalidLocation.out
+ test/tools/javac/annotations/typeAnnotations/failures/common/typeArgs/MissingAnnotationValue.java
+ test/tools/javac/annotations/typeAnnotations/failures/common/typeArgs/MissingAnnotationValue.out
+ test/tools/javac/annotations/typeAnnotations/failures/common/typeparams/DuplicateAnnotationValue.java
+ test/tools/javac/annotations/typeAnnotations/failures/common/typeparams/DuplicateAnnotationValue.out
+ test/tools/javac/annotations/typeAnnotations/failures/common/typeparams/DuplicateTypeAnnotation.java
+ test/tools/javac/annotations/typeAnnotations/failures/common/typeparams/DuplicateTypeAnnotation.out
+ test/tools/javac/annotations/typeAnnotations/failures/common/typeparams/InvalidLocation.java
+ test/tools/javac/annotations/typeAnnotations/failures/common/typeparams/InvalidLocation.out
+ test/tools/javac/annotations/typeAnnotations/failures/common/typeparams/MissingAnnotationValue.java
+ test/tools/javac/annotations/typeAnnotations/failures/common/typeparams/MissingAnnotationValue.out
+ test/tools/javac/annotations/typeAnnotations/failures/common/wildcards/DuplicateAnnotationValue.java
+ test/tools/javac/annotations/typeAnnotations/failures/common/wildcards/DuplicateAnnotationValue.out
+ test/tools/javac/annotations/typeAnnotations/failures/common/wildcards/DuplicateTypeAnnotation.java
+ test/tools/javac/annotations/typeAnnotations/failures/common/wildcards/DuplicateTypeAnnotation.out
+ test/tools/javac/annotations/typeAnnotations/failures/common/wildcards/InvalidLocation.java
+ test/tools/javac/annotations/typeAnnotations/failures/common/wildcards/InvalidLocation.out
+ test/tools/javac/annotations/typeAnnotations/failures/common/wildcards/MissingAnnotationValue.java
+ test/tools/javac/annotations/typeAnnotations/failures/common/wildcards/MissingAnnotationValue.out
+ test/tools/javac/annotations/typeAnnotations/failures/target/Constructor.java
+ test/tools/javac/annotations/typeAnnotations/failures/target/Constructor.out
+ test/tools/javac/annotations/typeAnnotations/failures/target/DotClass.java
+ test/tools/javac/annotations/typeAnnotations/failures/target/DotClass.out
+ test/tools/javac/annotations/typeAnnotations/failures/target/IncompleteArray.java
+ test/tools/javac/annotations/typeAnnotations/failures/target/IncompleteArray.out
+ test/tools/javac/annotations/typeAnnotations/failures/target/NotTypeParameter.java
+ test/tools/javac/annotations/typeAnnotations/failures/target/NotTypeParameter.out
+ test/tools/javac/annotations/typeAnnotations/failures/target/NotTypeUse.java
+ test/tools/javac/annotations/typeAnnotations/failures/target/NotTypeUse.out
+ test/tools/javac/annotations/typeAnnotations/failures/target/VoidMethod.java
+ test/tools/javac/annotations/typeAnnotations/failures/target/VoidMethod.out
+ test/tools/javac/annotations/typeAnnotations/newlocations/BasicTest.java
+ test/tools/javac/annotations/typeAnnotations/newlocations/ClassExtends.java
+ test/tools/javac/annotations/typeAnnotations/newlocations/ClassParameters.java
+ test/tools/javac/annotations/typeAnnotations/newlocations/ConstructorTypeArgs.java
+ test/tools/javac/annotations/typeAnnotations/newlocations/ExceptionParameters.java
+ test/tools/javac/annotations/typeAnnotations/newlocations/Expressions.java
+ test/tools/javac/annotations/typeAnnotations/newlocations/Fields.java
+ test/tools/javac/annotations/typeAnnotations/newlocations/LocalVariables.java
+ test/tools/javac/annotations/typeAnnotations/newlocations/MethodReturnType.java
+ test/tools/javac/annotations/typeAnnotations/newlocations/MethodTypeArgs.java
+ test/tools/javac/annotations/typeAnnotations/newlocations/MethodTypeParameters.java
+ test/tools/javac/annotations/typeAnnotations/newlocations/MultiCatch.java
+ test/tools/javac/annotations/typeAnnotations/newlocations/NestedTypes.java
+ test/tools/javac/annotations/typeAnnotations/newlocations/Parameters.java
+ test/tools/javac/annotations/typeAnnotations/newlocations/Receivers.java
+ test/tools/javac/annotations/typeAnnotations/newlocations/RepeatingTypeAnnotations.java
+ test/tools/javac/annotations/typeAnnotations/newlocations/RepeatingTypeAnnotations.out
+ test/tools/javac/annotations/typeAnnotations/newlocations/ResourceVariables.java
+ test/tools/javac/annotations/typeAnnotations/newlocations/Throws.java
+ test/tools/javac/annotations/typeAnnotations/newlocations/TopLevelBlocks.java
+ test/tools/javac/annotations/typeAnnotations/newlocations/TypeCasts.java
+ test/tools/javac/annotations/typeAnnotations/newlocations/TypeParameters.java
+ test/tools/javac/annotations/typeAnnotations/newlocations/Varargs.java
+ test/tools/javac/annotations/typeAnnotations/newlocations/Wildcards.java
+ test/tools/javac/annotations/typeAnnotations/packageanno/PackageProcessor.java
+ test/tools/javac/annotations/typeAnnotations/packageanno/mypackage/Anno.java
+ test/tools/javac/annotations/typeAnnotations/packageanno/mypackage/MyClass.java
+ test/tools/javac/annotations/typeAnnotations/packageanno/mypackage/package-info.java
+ test/tools/javac/annotations/typeAnnotations/referenceinfos/ClassExtends.java
+ test/tools/javac/annotations/typeAnnotations/referenceinfos/ClassTypeParam.java
+ test/tools/javac/annotations/typeAnnotations/referenceinfos/Constructors.java
+ test/tools/javac/annotations/typeAnnotations/referenceinfos/Driver.java
+ test/tools/javac/annotations/typeAnnotations/referenceinfos/ExceptionParameters.java
+ test/tools/javac/annotations/typeAnnotations/referenceinfos/Fields.java
+ test/tools/javac/annotations/typeAnnotations/referenceinfos/FromSpecification.java
+ test/tools/javac/annotations/typeAnnotations/referenceinfos/MethodParameters.java
+ test/tools/javac/annotations/typeAnnotations/referenceinfos/MethodReceivers.java
+ test/tools/javac/annotations/typeAnnotations/referenceinfos/MethodReturns.java
+ test/tools/javac/annotations/typeAnnotations/referenceinfos/MethodThrows.java
+ test/tools/javac/annotations/typeAnnotations/referenceinfos/MethodTypeParam.java
+ test/tools/javac/annotations/typeAnnotations/referenceinfos/MultiCatch.java
+ test/tools/javac/annotations/typeAnnotations/referenceinfos/NestedTypes.java
+ test/tools/javac/annotations/typeAnnotations/referenceinfos/NewObjects.java
+ test/tools/javac/annotations/typeAnnotations/referenceinfos/ReferenceInfoUtil.java
+ test/tools/javac/annotations/typeAnnotations/referenceinfos/RepeatingTypeAnnotations.java
+ test/tools/javac/annotations/typeAnnotations/referenceinfos/TypeCasts.java
+ test/tools/javac/annotations/typeAnnotations/referenceinfos/TypeTests.java
! test/tools/javac/api/EndPositions.java
! test/tools/javac/diags/CheckResourceKeys.java
! test/tools/javac/diags/examples.not-yet.txt
+ test/tools/javac/diags/examples/CantAnnotateNestedType.java
+ test/tools/javac/diags/examples/CantAnnotateStaticClass.java
+ test/tools/javac/diags/examples/IncorrectReceiverType.java
+ test/tools/javac/diags/examples/NoAnnotationsOnDotClass.java
+ test/tools/javac/diags/examples/ThisAsIdentifier.java
+ test/tools/javac/diags/examples/TypeAnnotationsNotSupported.java
! test/tools/javac/failover/CheckAttributedTree.java
! test/tools/javac/processing/6994946/SemanticErrorTest.2.out
! test/tools/javac/processing/model/element/TestAnonClassNames.java
! test/tools/javac/processing/model/element/TestMissingElement/TestMissingElement.java
+ test/tools/javac/processing/model/element/TestMissingElement/TestMissingElement.ref
! test/tools/javac/processing/model/util/directSupersOfErr/DirectSupersOfErr.java
+ test/tools/javac/processing/model/util/directSupersOfErr/DirectSupersOfErr.ref
! test/tools/javac/tree/TreeKindTest.java
! test/tools/javac/tree/TreePosTest.java
+ test/tools/javac/treeannotests/AnnoTreeTests.java
! test/tools/javac/treeannotests/TestProcessor.java
- test/tools/javac/typeAnnotations/newlocations/BasicTest.java
- test/tools/javac/typeAnnotations/newlocations/BasicTest.out
+ test/tools/javap/typeAnnotations/JSR175Annotations.java
+ test/tools/javap/typeAnnotations/NewArray.java
+ test/tools/javap/typeAnnotations/Presence.java
+ test/tools/javap/typeAnnotations/PresenceInner.java
+ test/tools/javap/typeAnnotations/T6855990.java
+ test/tools/javap/typeAnnotations/TypeCasts.java
+ test/tools/javap/typeAnnotations/Visibility.java
+ test/tools/javap/typeAnnotations/Wildcards.java

Changeset: 09f65aad4759
Author:    darcy
Date:      2013-01-23 20:11 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/09f65aad4759

8006264: Add explanation of why default methods cannot be used in JDK 8 javax.lang.model
Reviewed-by: jjg

! src/share/classes/javax/lang/model/element/AnnotationValueVisitor.java
! src/share/classes/javax/lang/model/element/ElementVisitor.java
! src/share/classes/javax/lang/model/type/TypeVisitor.java
! src/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitor6.java
! src/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitor7.java
! src/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitor8.java
! src/share/classes/javax/lang/model/util/AbstractElementVisitor6.java
! src/share/classes/javax/lang/model/util/AbstractElementVisitor7.java
! src/share/classes/javax/lang/model/util/AbstractElementVisitor8.java
! src/share/classes/javax/lang/model/util/AbstractTypeVisitor6.java
! src/share/classes/javax/lang/model/util/AbstractTypeVisitor7.java
! src/share/classes/javax/lang/model/util/AbstractTypeVisitor8.java
! src/share/classes/javax/lang/model/util/ElementKindVisitor6.java
! src/share/classes/javax/lang/model/util/ElementKindVisitor7.java
! src/share/classes/javax/lang/model/util/ElementKindVisitor8.java
! src/share/classes/javax/lang/model/util/SimpleAnnotationValueVisitor6.java
! src/share/classes/javax/lang/model/util/SimpleAnnotationValueVisitor7.java
! src/share/classes/javax/lang/model/util/SimpleAnnotationValueVisitor8.java
! src/share/classes/javax/lang/model/util/SimpleElementVisitor6.java
! src/share/classes/javax/lang/model/util/SimpleElementVisitor7.java
! src/share/classes/javax/lang/model/util/SimpleElementVisitor8.java
! src/share/classes/javax/lang/model/util/SimpleTypeVisitor6.java
! src/share/classes/javax/lang/model/util/SimpleTypeVisitor7.java
! src/share/classes/javax/lang/model/util/SimpleTypeVisitor8.java
! src/share/classes/javax/lang/model/util/TypeKindVisitor6.java
! src/share/classes/javax/lang/model/util/TypeKindVisitor7.java
! src/share/classes/javax/lang/model/util/TypeKindVisitor8.java

Changeset: c2e11e2ec4a3
Author:    lana
Date:      2013-01-26 19:24 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/c2e11e2ec4a3

Merge

- test/tools/javac/annotations/repeatingAnnotations/MissingContainedBy.java
- test/tools/javac/annotations/repeatingAnnotations/MissingContainerFor.java
- test/tools/javac/annotations/repeatingAnnotations/UseWrongContainedBy.java
- test/tools/javac/annotations/repeatingAnnotations/UseWrongContainerFor.java
- test/tools/javac/annotations/repeatingAnnotations/WrongContainedBy.java
- test/tools/javac/annotations/repeatingAnnotations/WrongContainerFor.java
- test/tools/javac/diags/examples/ContainedByDocumentedMismatch.java
- test/tools/javac/diags/examples/ContainedByInheritedMismatch.java
- test/tools/javac/diags/examples/ContainedByNoValue.java
- test/tools/javac/diags/examples/ContainedByNonDefault.java
- test/tools/javac/diags/examples/ContainedByRetentionMismatch.java
- test/tools/javac/diags/examples/ContainedByTargetMismatch.java
- test/tools/javac/diags/examples/ContainedByWrongValueType.java
- test/tools/javac/diags/examples/InferredDoNotConformToLower.java
- test/tools/javac/diags/examples/NoUniqueMaximalInstance.java
- test/tools/javac/diags/examples/WrongContainedBy.java
- test/tools/javac/diags/examples/WrongContainerFor.java
- test/tools/javac/lambda/MethodReference26.out
- test/tools/javac/lambda/TargetType06.out
- test/tools/javac/lambda/TargetType11.out
- test/tools/javac/lambda/TargetType45.out
- test/tools/javac/lambda/VoidCompatibility.out
- test/tools/javac/typeAnnotations/newlocations/BasicTest.java
- test/tools/javac/typeAnnotations/newlocations/BasicTest.out

Changeset: 716935fec613
Author:    katleman
Date:      2013-01-31 17:04 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/716935fec613

Added tag jdk8-b75 for changeset c2e11e2ec4a3

! .hgtags

Changeset: e5376e58cc8b
Author:    mcimadamore
Date:      2013-02-04 11:58 +0000
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/e5376e58cc8b

merge with jdk8-b75

! .hgtags
! make/build.properties
! make/build.xml
! src/share/classes/com/sun/source/tree/Tree.java
! src/share/classes/com/sun/source/tree/TreeVisitor.java
! src/share/classes/com/sun/source/util/SimpleTreeVisitor.java
! src/share/classes/com/sun/source/util/TreeScanner.java
! src/share/classes/com/sun/tools/classfile/Attribute.java
! src/share/classes/com/sun/tools/classfile/ClassWriter.java
! src/share/classes/com/sun/tools/classfile/Dependencies.java
! src/share/classes/com/sun/tools/doclets/formats/html/AbstractMemberWriter.java
! src/share/classes/com/sun/tools/javac/code/Annotations.java
! src/share/classes/com/sun/tools/javac/code/Attribute.java
! src/share/classes/com/sun/tools/javac/code/Flags.java
! src/share/classes/com/sun/tools/javac/code/Lint.java
! src/share/classes/com/sun/tools/javac/code/Printer.java
! src/share/classes/com/sun/tools/javac/code/Source.java
! src/share/classes/com/sun/tools/javac/code/Symbol.java
! src/share/classes/com/sun/tools/javac/code/Symtab.java
! src/share/classes/com/sun/tools/javac/code/TargetType.java
! src/share/classes/com/sun/tools/javac/code/Type.java
! src/share/classes/com/sun/tools/javac/code/Types.java
! src/share/classes/com/sun/tools/javac/comp/Annotate.java
! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/Check.java
! src/share/classes/com/sun/tools/javac/comp/ConstFold.java
! src/share/classes/com/sun/tools/javac/comp/DeferredAttr.java
! src/share/classes/com/sun/tools/javac/comp/Enter.java
! src/share/classes/com/sun/tools/javac/comp/Flow.java
! src/share/classes/com/sun/tools/javac/comp/Infer.java
! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java
! src/share/classes/com/sun/tools/javac/comp/Lower.java
! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java
! src/share/classes/com/sun/tools/javac/comp/Resolve.java
! src/share/classes/com/sun/tools/javac/comp/TransTypes.java
! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java
! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java
! src/share/classes/com/sun/tools/javac/jvm/Code.java
! src/share/classes/com/sun/tools/javac/jvm/Gen.java
! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java
! src/share/classes/com/sun/tools/javac/main/Option.java
! src/share/classes/com/sun/tools/javac/model/JavacTypes.java
! src/share/classes/com/sun/tools/javac/parser/JavacParser.java
! src/share/classes/com/sun/tools/javac/parser/Scanner.java
! src/share/classes/com/sun/tools/javac/parser/Tokens.java
! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java
! src/share/classes/com/sun/tools/javac/resources/compiler.properties
! src/share/classes/com/sun/tools/javac/resources/javac.properties
! src/share/classes/com/sun/tools/javac/tree/JCTree.java
! src/share/classes/com/sun/tools/javac/tree/Pretty.java
! src/share/classes/com/sun/tools/javac/tree/TreeCopier.java
! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java
! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java
! src/share/classes/com/sun/tools/javac/tree/TreeScanner.java
! src/share/classes/com/sun/tools/javac/tree/TreeTranslator.java
! src/share/classes/com/sun/tools/javac/util/Log.java
! src/share/classes/com/sun/tools/javac/util/Names.java
! src/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.java
! src/share/classes/com/sun/tools/javadoc/ClassDocImpl.java
! src/share/classes/com/sun/tools/javadoc/DocEnv.java
! src/share/classes/com/sun/tools/javadoc/DocImpl.java
! src/share/classes/com/sun/tools/javadoc/ExecutableMemberDocImpl.java
! src/share/classes/com/sun/tools/javadoc/JavadocMemberEnter.java
! src/share/classes/com/sun/tools/javadoc/MethodDocImpl.java
! src/share/classes/com/sun/tools/javadoc/RootDocImpl.java
! src/share/classes/com/sun/tools/javap/AttributeWriter.java
! src/share/classes/javax/lang/model/SourceVersion.java
! src/share/classes/javax/lang/model/type/TypeKind.java
! src/share/classes/javax/lang/model/type/TypeVisitor.java
! src/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitor7.java
! src/share/classes/javax/lang/model/util/AbstractTypeVisitor6.java
! src/share/classes/javax/lang/model/util/AbstractTypeVisitor8.java
! src/share/classes/javax/lang/model/util/ElementKindVisitor8.java
! src/share/classes/javax/lang/model/util/Types.java
! test/tools/javac/7129225/TestImportStar.java
- test/tools/javac/annotations/repeatingAnnotations/MissingContainedBy.java
- test/tools/javac/annotations/repeatingAnnotations/MissingContainerFor.java
! test/tools/javac/annotations/repeatingAnnotations/MissingDefaultCase1.java
! test/tools/javac/annotations/repeatingAnnotations/MissingDefaultCase1.out
! test/tools/javac/annotations/repeatingAnnotations/MissingDefaultCase2.java
! test/tools/javac/annotations/repeatingAnnotations/MissingDefaultCase2.out
! test/tools/javac/annotations/repeatingAnnotations/NoRepeatableAnno.out
- test/tools/javac/annotations/repeatingAnnotations/UseWrongContainedBy.java
- test/tools/javac/annotations/repeatingAnnotations/UseWrongContainerFor.java
- test/tools/javac/annotations/repeatingAnnotations/WrongContainedBy.java
- test/tools/javac/annotations/repeatingAnnotations/WrongContainerFor.java
+ test/tools/javac/annotations/typeAnnotations/failures/AnnotatedPackage2.out
! test/tools/javac/cast/intersection/IntersectionTypeCastTest.java
! test/tools/javac/cast/intersection/model/Model01.java
! test/tools/javac/defaultMethods/static/Static01.java
! test/tools/javac/defaultMethods/static/hiding/InterfaceMethodHidingTest.java
! test/tools/javac/defaultMethods/syntax/TestDefaultMethodsSyntax.java
! test/tools/javac/diags/examples.not-yet.txt
- test/tools/javac/diags/examples/ContainedByDocumentedMismatch.java
- test/tools/javac/diags/examples/ContainedByInheritedMismatch.java
- test/tools/javac/diags/examples/ContainedByNoValue.java
- test/tools/javac/diags/examples/ContainedByNonDefault.java
- test/tools/javac/diags/examples/ContainedByRetentionMismatch.java
- test/tools/javac/diags/examples/ContainedByTargetMismatch.java
- test/tools/javac/diags/examples/ContainedByWrongValueType.java
+ test/tools/javac/diags/examples/RepeatableNonDefault.java
- test/tools/javac/diags/examples/WrongContainedBy.java
- test/tools/javac/diags/examples/WrongContainerFor.java
! test/tools/javac/failover/CheckAttributedTree.java
! test/tools/javac/generics/diamond/neg/Neg10.java
! test/tools/javac/generics/inference/6315770/T6315770.out
! test/tools/javac/generics/inference/6638712/T6638712b.out
! test/tools/javac/generics/inference/6650759/T6650759m.out
! test/tools/javac/generics/rawOverride/7062745/GenericOverrideTest.java
! test/tools/javac/lambda/BadConv03.out
! test/tools/javac/lambda/BadLambdaPos.out
! test/tools/javac/lambda/BadTargetType.out
! test/tools/javac/lambda/FunctionalInterfaceConversionTest.java
! test/tools/javac/lambda/Intersection01.java
! test/tools/javac/lambda/Intersection01.out
! test/tools/javac/lambda/LambdaConv09.out
! test/tools/javac/lambda/LambdaExpr10.out
! test/tools/javac/lambda/LambdaParserTest.java
! test/tools/javac/lambda/MethodReference04.out
! test/tools/javac/lambda/MethodReference25.java
! test/tools/javac/lambda/MethodReference26.java
! test/tools/javac/lambda/MethodReference43.java
! test/tools/javac/lambda/MethodReference59.java
! test/tools/javac/lambda/MethodReference60.java
! test/tools/javac/lambda/MethodReferenceParserTest.java
! test/tools/javac/lambda/TargetType01.java
! test/tools/javac/lambda/TargetType06.java
- test/tools/javac/lambda/TargetType06.out
! test/tools/javac/lambda/TargetType10.out
! test/tools/javac/lambda/TargetType11.java
- test/tools/javac/lambda/TargetType11.out
! test/tools/javac/lambda/TargetType14.out
! test/tools/javac/lambda/TargetType17.out
! test/tools/javac/lambda/TargetType21.java
! test/tools/javac/lambda/TargetType21.out
! test/tools/javac/lambda/TargetType26.out
! test/tools/javac/lambda/TargetType27.out
! test/tools/javac/lambda/TargetType28.out
! test/tools/javac/lambda/TargetType39.out
! test/tools/javac/lambda/TargetType43.out
! test/tools/javac/lambda/TargetType45.java
! test/tools/javac/lambda/TargetType52.java
! test/tools/javac/lambda/TestInvokeDynamic.java
! test/tools/javac/lambda/VoidCompatibility.java
! test/tools/javac/lambda/WarnUnderscoreAsIdent.java
! test/tools/javac/lambda/WarnUnderscoreAsIdent.out
! test/tools/javac/lambda/intersection/IntersectionTargetTypeTest.java
! test/tools/javac/lambda/mostSpecific/StructuralMostSpecificTest.java
! test/tools/javac/lambdaShapes/org/openjdk/tests/vm/DefaultMethodsTest.java
! test/tools/javac/lambdaShapes/org/openjdk/tests/vm/FDSeparateCompilationTest.java
! test/tools/javac/processing/model/element/TestAnonClassNames.java
! test/tools/javac/processing/model/element/TestMissingElement/TestMissingElement.java
! test/tools/javac/processing/model/util/directSupersOfErr/DirectSupersOfErr.java
- test/tools/javac/typeAnnotations/newlocations/BasicTest.java
- test/tools/javac/typeAnnotations/newlocations/BasicTest.out

Changeset: 368e6db3e9dc
Author:    mcimadamore
Date:      2013-02-04 12:42 +0000
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/368e6db3e9dc

merge

! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java
! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java
! src/share/classes/com/sun/tools/javac/util/Names.java


From paul.sandoz at oracle.com  Mon Feb  4 04:58:57 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 4 Feb 2013 13:58:57 +0100
Subject: Grouping stream elements by their position - how to handle tail
	of stream ?
In-Reply-To: <CAB_DFWaUEv8jAo6Ok58d7EthS6gZubSvr8rbXxGoEVLVAmjeug@mail.gmail.com>
References: <CAB_DFWaUEv8jAo6Ok58d7EthS6gZubSvr8rbXxGoEVLVAmjeug@mail.gmail.com>
Message-ID: <218D84FF-04B5-4F6B-AB22-F3EE9CE9950E@oracle.com>

Hi,

Just exploring ideas here... it's fun :-)

If your source is of some repeatable information one could do it as per the code below. Quite a mouthful! plus you have to be explicit about sequential or parallel.

If zip could take a third stream that acts as a pad one could avoid the concat:

  Stream<Pair<A, A>> sz = Streams.zip(s1, s2, Stream.<A>generate(() -> null), Pair::new);
 
The zip code is not complex, i cheat and use iterators for an easy implementation, so it would also be easy to support padding.

My general point here is that it is sometimes possible to compose streams by composing the escape hatch spliterators/iterators of those streams. Obviously in some cases this is not as ideal as implementing an operation but it might be sufficient for some cases in the interim.

Paul.

import java.util.Arrays;
import java.util.List;
import java.util.stream.Stream;
import java.util.stream.Streams;

public class Test {

    static class Pair<A, B> {
        final A a;
        final B b;

        Pair(A a, B b) {
            this.a = a;
            this.b = b;
        }

        @Override
        public String toString() {
            return "[" + a + ", " + b + "]";
        }
    }

    public static void main(String[] args) {
        List<Integer> l = Arrays.asList(1, 2, 3, 4, 5);

        Stream<Integer> s1 = l.stream();
        Stream<Integer> s2 = Streams.concat(l.stream().substream(1), Arrays.asList(new Integer[]{null}).stream());
        Stream<Pair<Integer, Integer>> sz = Streams.zip(s1, s2, Pair::new);
        sz.forEach(System.out::println);
    }
}



On Feb 2, 2013, at 9:35 PM, Boaz Nahum <boaznahum at gmail.com> wrote:

> Hi.
> 
> I looking in Stream interface for a way to convert a stream of
>   {  t1, t2, .. Tn }
> to
>   { {t1,t2}, ... {Tn-1, Tn} }
> or
>   { {t1,t2}, ... {Tn, null}}
> 
> Lets assume {t1, t2} are aggeraget by Pair<T,T>
> 
> 
> 
> So I tried to use explode:
> 
> *        Stream<Integer> si = Arrays.asList(1, 2, 3, 4, 5).stream();
> 
>        Stream<Pair<Integer, Integer>> spi = si.sequential().explode(new
> BiConsumer<Stream.Downstream<Pair<Integer, Integer>>, Integer>() {
> 
>            Integer firstValue;
> 
>            @Override
>            public void accept(Stream.Downstream<Pair<Integer, Integer>>
> pairDownstream, Integer v) {
> 
>                if (firstValue == null) {
>                    firstValue = v;
>                } else {
> 
>                    pairDownstream.send(new Pair<>(firstValue, v));
>                    firstValue = null;
> 
>                }
>            }
> 
>        });
> *
> 
> But I didn't find a way to add the tail of input stream {.., 5} to the new
> stream { ,,, {5, null}}.
> 
> Of-course this only simplified example of more general problem I have.
> 
> Thanks
> Boaz
> 


From maurizio.cimadamore at oracle.com  Mon Feb  4 06:37:51 2013
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Mon, 04 Feb 2013 14:37:51 +0000
Subject: hg: lambda/lambda/langtools: Misc cleanups
Message-ID: <20130204143756.3E901477E2@hg.openjdk.java.net>

Changeset: 4732ae0ca8b4
Author:    mcimadamore
Date:      2013-02-04 14:37 +0000
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/4732ae0ca8b4

Misc cleanups

! make/build.properties
! make/build.xml
- src/share/bin/java.sh-template
! src/share/bin/launcher.sh-template
! src/share/classes/com/sun/javadoc/ClassDoc.java
! src/share/classes/com/sun/javadoc/MethodDoc.java
! src/share/classes/com/sun/source/tree/Tree.java
! src/share/classes/com/sun/source/util/SimpleTreeVisitor.java
! src/share/classes/com/sun/source/util/TreeScanner.java
! src/share/classes/com/sun/tools/classfile/AccessFlags.java
! src/share/classes/com/sun/tools/classfile/Attribute.java
! src/share/classes/com/sun/tools/classfile/Dependencies.java
! src/share/classes/com/sun/tools/javac/code/Flags.java
! src/share/classes/com/sun/tools/javac/code/Source.java
! src/share/classes/com/sun/tools/javac/code/Symbol.java
! src/share/classes/com/sun/tools/javac/code/Type.java
! src/share/classes/com/sun/tools/javac/code/Types.java
! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/Check.java
! src/share/classes/com/sun/tools/javac/comp/Enter.java
! src/share/classes/com/sun/tools/javac/comp/Resolve.java
! src/share/classes/com/sun/tools/javac/comp/TransTypes.java
! src/share/classes/com/sun/tools/javac/jvm/Target.java
! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java
! src/share/classes/com/sun/tools/javac/main/Main.java
! src/share/classes/com/sun/tools/javac/model/JavacTypes.java
! src/share/classes/com/sun/tools/javac/parser/JavacParser.java
! src/share/classes/com/sun/tools/javac/tree/Pretty.java
! src/share/classes/com/sun/tools/javac/tree/TreeCopier.java
! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java
! src/share/classes/com/sun/tools/javac/tree/TreeScanner.java
! src/share/classes/com/sun/tools/javac/tree/TreeTranslator.java
! src/share/classes/com/sun/tools/javadoc/MethodDocImpl.java
! src/share/classes/com/sun/tools/javap/ConstantWriter.java
! src/share/classes/javax/lang/model/util/AbstractTypeVisitor6.java
! src/share/classes/javax/lang/model/util/Types.java
! test/tools/javac/6758789/T6758789b.out
! test/tools/javac/api/TestContainTypes.java
! test/tools/javac/diags/examples/KindnameConstructor.java
! test/tools/javac/failover/CheckAttributedTree.java
! test/tools/javac/generics/7015430/T7015430.out
! test/tools/javac/lambda/LambdaParserTest.java
! test/tools/javac/lambda/MethodReference33.java
! test/tools/javac/lambda/TargetType05.java
! test/tools/javac/lambda/TargetType35.java
! test/tools/javac/lambda/intersection/IntersectionTargetTypeTest.java
! test/tools/javac/meth/InvokeMH.java
! test/tools/javac/nativeHeaders/NativeHeaderTest.java


From paul.sandoz at oracle.com  Mon Feb  4 08:27:26 2013
From: paul.sandoz at oracle.com (paul.sandoz at oracle.com)
Date: Mon, 04 Feb 2013 16:27:26 +0000
Subject: hg: lambda/lambda/jdk: Spliterator implementations for various
	java.util.concurrent-based collections
Message-ID: <20130204162809.2CCB1477EB@hg.openjdk.java.net>

Changeset: dfabd7437f98
Author:    psandoz
Date:      2013-02-04 17:26 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/dfabd7437f98

Spliterator implementations for various java.util.concurrent-based collections
and maps.
Contributed-by: Doug Lea <dl at cs.oswego.edu>

! src/share/classes/java/util/concurrent/ConcurrentHashMap.java
! src/share/classes/java/util/concurrent/ConcurrentSkipListMap.java
! src/share/classes/java/util/concurrent/ConcurrentSkipListSet.java
! src/share/classes/java/util/concurrent/CopyOnWriteArrayList.java
! src/share/classes/java/util/concurrent/CopyOnWriteArraySet.java
- src/share/classes/java/util/concurrent/LongAdderTable.java
! src/share/classes/java/util/concurrent/PriorityBlockingQueue.java


From brian.goetz at oracle.com  Mon Feb  4 08:40:04 2013
From: brian.goetz at oracle.com (brian.goetz at oracle.com)
Date: Mon, 04 Feb 2013 16:40:04 +0000
Subject: hg: lambda/lambda/jdk: Update BaseStream type arguments to know the
	strem tpe, so sequential/parlalel can be moved to BaseStream
Message-ID: <20130204164016.9322D477EC@hg.openjdk.java.net>

Changeset: d7d887e5bc1a
Author:    briangoetz
Date:      2013-02-04 11:39 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/d7d887e5bc1a

Update BaseStream type arguments to know the strem tpe, so sequential/parlalel can be moved to BaseStream

! src/share/classes/java/util/stream/AbstractPipeline.java
! src/share/classes/java/util/stream/BaseStream.java
! src/share/classes/java/util/stream/DoubleStream.java
! src/share/classes/java/util/stream/IntStream.java
! src/share/classes/java/util/stream/LongStream.java
! src/share/classes/java/util/stream/Stream.java
! test-ng/bootlib/java/util/stream/DoubleStreamTestScenario.java
! test-ng/bootlib/java/util/stream/IntStreamTestScenario.java
! test-ng/bootlib/java/util/stream/LambdaTestHelpers.java
! test-ng/bootlib/java/util/stream/LongStreamTestScenario.java
! test-ng/bootlib/java/util/stream/OpTestCase.java
! test-ng/bootlib/java/util/stream/StreamTestScenario.java
! test-ng/boottests/java/util/stream/StreamReuseTest.java
! test-ng/boottests/java/util/stream/UnorderedTest.java


From pbenedict at apache.org  Mon Feb  4 08:55:48 2013
From: pbenedict at apache.org (Paul Benedict)
Date: Mon, 4 Feb 2013 10:55:48 -0600
Subject: Stream vs BaseStream
Message-ID: <CABLGb9woPgu9NkMQ+QMbozmbWZM28qq=6OfKsAo=6ME1bOSidw@mail.gmail.com>

For any API designers out there, what is the deal with Stream and
BaseStream? My OOAD skills say Stream should naturally be the "base"
abstraction .. so what is so "base" about BaseStream then that Stream
cannot fulfill?

Paul

From brian.goetz at oracle.com  Mon Feb  4 09:16:44 2013
From: brian.goetz at oracle.com (Brian Goetz)
Date: Mon, 04 Feb 2013 12:16:44 -0500
Subject: Stream vs BaseStream
In-Reply-To: <CABLGb9woPgu9NkMQ+QMbozmbWZM28qq=6OfKsAo=6ME1bOSidw@mail.gmail.com>
References: <CABLGb9woPgu9NkMQ+QMbozmbWZM28qq=6OfKsAo=6ME1bOSidw@mail.gmail.com>
Message-ID: <510FECFC.6020209@oracle.com>

Stream <: BaseStream
IntStream <: BaseStream

but IntStream is NOT a subtype of Stream<Integer>.

On 2/4/2013 11:55 AM, Paul Benedict wrote:
> For any API designers out there, what is the deal with Stream and
> BaseStream? My OOAD skills say Stream should naturally be the "base"
> abstraction .. so what is so "base" about BaseStream then that Stream
> cannot fulfill?
>
> Paul
>

From henry.jen at oracle.com  Mon Feb  4 09:55:06 2013
From: henry.jen at oracle.com (Henry Jen)
Date: Mon, 4 Feb 2013 09:55:06 -0800
Subject: CloseableStream exceptions [was: Re: experience trying out
	lambda-8-b74]
In-Reply-To: <510CA649.5050000@gmail.com>
References: <51053A5A.24195.AAF1F6@v.a.ammodytes.googlemail.com>
	<5105762A.8040002@oracle.com>
	<E61425C5-6E01-49C3-B149-151D2A3B81F3@wonderly.org>
	<CC95D104-28E2-42DE-B1A4-DD02BAD67F38@oracle.com>
	<510633DE.9060001@gmail.com> <510C5348.8020107@oracle.com>
	<510CA649.5050000@gmail.com>
Message-ID: <153DE41A-FCF6-47C0-B5F5-8B7D49D4CBDE@oracle.com>

My preference is mainly build on top of that factory methods throws IOException. I still believe factory methods should throw IOException instead of wrap it up into UncheckedIOException so to enforce a try thus better reminds using try-with-resource to ensure close. So that is not going to change for those APIs in nio.

However, that should probably be a separate concern from what is in CloseableStream, not all factory method need to throw IOException although it is more likely.

The wrapping cost and suppress of exceptions(as in JDK 7[1]) is not really a big deal, it's great if we don't need them, but if we have to, we have to.

On change the definition of CloseableStream, which would be preferred?

CloseableStream<T> close();

or

CloseableStream<T> close() throws Exception;

Also should we change it into AutoCloseableStream() as it is really just an AutoCloseable? Personally I like CloseableStream as I assume AutoCloseable is just a remedy for Closeable.

Cheers,
Henry 

[1] http://docs.oracle.com/javase/tutorial/essential/exceptions/tryResourceClose.html#suppressed-exceptions


On Feb 1, 2013, at 9:38 PM, Peter Levart <peter.levart at gmail.com> wrote:

> 
> On 02/02/2013 12:44 AM, Henry Jen wrote:
>> On 01/28/2013 12:16 AM, Peter Levart wrote:
>> 
>>> On 01/28/2013 12:06 AM, Henry Jen wrote:
>>> 
>>>> http://cr.openjdk.java.net/~henryjen/lambda/nio.5/webrev/
>>>> 
>>>> 
>>>> 
>>> Hi Henry,
>>> 
>>> I can imagine that many times a single block of code would be
>>> responsible for constructing a Path stream (possibly enclosed into a
>>> try-with-resources construct) and consuming it's results, so having to
>>> deal with the duality of IOException/UncheckedIOException is a
>>> complication for a user in my opinion. Wouldn't it be better also for
>>> the stream-factory methods to throw UncheckedIOException and for
>>> CloseableStream.close() to also throw UncheckedIOException (that means,
>>> only inheriting from AutoCloseable, not Closeable and co-variant-ly
>>> redefining the throws declaration):
>>> 
>>> public interface CloseableStream<T> extends Stream<T>, AutoCloseable {
>>>     @Override
>>>     void close() throws UncheckedIOException;
>>> }
>>> 
>>> 
>> Hi Peter,
> 
> Hi Henry,
> 
>> Sorry for the late reply, I want to let the idea sink a little bit.
>> 
>> After couple days, I am slightly prefer not to change it because,
>> 
>> 1) The CloseableStream-factory method throws IOException reminds use of
>> try-with-resource better than an unchecked exception.
>> 
> 
> The CloseableStream method return type name also reminds of that ;-)
> 
>> 2) As factory methods throwing IOException, developer is dealing with
>> duality already.
>> 
> 
> He is dealing with duality already *if* the factory methods are throwing IOException. If they are throwing UncheckedIOException, he is not dealing with duality.
> 
>> 3) If the close method throws UncheckedIOException as the stream
>> handling, the suppressing of exceptions will be more confusing. Should
>> developer look into cause IOException or the UncheckedIOException?
>> 
> 
> Do you think a programmer might want to handle different subtypes of IOException differently? If that is the case, the javadoc should document all the possible situations. And what about different     subtypes of IOException wrapped by UncheckedIOException while consuming the stream? If the programmer already bothers to unwrap the unchecked exception to do the cause analisys, then this same handler would be good also for dealing with exceptions thrown in factory methods and CloseableStream.close(). The streams API is a higher-lever wrapper over the java.nio.file.DirectoryStream API and it is already wrapping the lower-level IOException with UncheckedIOException when consuming the CloseableStream. I think it should do it consistently. By doing it consistently, it simplifies correct exception handling logic in *all* situations.
> 
>> 4) When the implementation is a Closeable, the wrapping of IOException
>> into an UncheckedIOException doesn't do any good except overhead in case
>> developer want to deal with it. On the other hand, a IOException handler
>> is probably in place as the factory methods throws IOException.
>> 
> 
> It is probably in place *if* the factory methods are throwing IOException. If they are throwing UncheckedIOException, then such handler is not there. The question is whether the UncheckedIOException handler is in place too. If I look in one of your tests:
> 
>  148         public void testWalk() {
>  149                 try(CloseableStream<Path> s = Files.walk(testFolder)) {
>  150                         Object[] actual = s.sorted(Comparators.naturalOrder()).toArray();
>  151                         assertEquals(actual, all);
>  152                 } catch (IOException ioe) {
>  153                         fail("Unexpected IOException");
>  154                 }
>  155         }
> 
> 
> You haven't bothered to handle the UncheckedIOException (because the test would fail anyway if it was thrown). But I'm afraid that average programmer will walk away from similar codes with false sense of confidence that he handled all exceptional situations when he put the checked exception handler in place. I think that being consistent and throwing UncheckedIOException everywhere would     actually have greater probability for average programmer to not miss the handling of exceptional situations while consuming the stream - at least all exceptional situations would be handled or not handled equally.
> 
> Regards, Peter
> 
>> Does it make sense?
>> 
>> I updated the webrev to have some test coverage for exception handling,
>> it's painful as always, but the duality is not what bothers me.
>> 
>> 
>> http://cr.openjdk.java.net/~henryjen/lambda/nio.6/webrev/
>> 
>> 
>> Cheers,
>> Henry
>> 
>> 
> 


From henry.jen at oracle.com  Mon Feb  4 10:01:00 2013
From: henry.jen at oracle.com (Henry Jen)
Date: Mon, 4 Feb 2013 10:01:00 -0800
Subject: experience trying out lambda-8-b74
In-Reply-To: <CACuKZqEWJKBxUh0=j8krP47f=UOZcTB6dREJuhdj0H7L4pYfTg@mail.gmail.com>
References: <51053A5A.24195.AAF1F6@v.a.ammodytes.googlemail.com>
	<5105762A.8040002@oracle.com>
	<E61425C5-6E01-49C3-B149-151D2A3B81F3@wonderly.org>
	<CC95D104-28E2-42DE-B1A4-DD02BAD67F38@oracle.com>
	<510633DE.9060001@gmail.com> <510C5348.8020107@oracle.com>
	<510CA649.5050000@gmail.com>
	<CACuKZqEWJKBxUh0=j8krP47f=UOZcTB6dREJuhdj0H7L4pYfTg@mail.gmail.com>
Message-ID: <98694886-DF0D-4C82-B3FC-EFDBF4F6A796@oracle.com>

If we don't extend any exception handling or need type information, we don't really need a wrapper as Throwable already has hasCause() method.

I recall there were discussion of transparent exception handling, which is still an open topic I believe.

Cheers,
Henry

On Feb 2, 2013, at 9:06 AM, Zhong Yu <zhong.j.yu at gmail.com> wrote:

> Also, what about other checked exceptions? If I make a stream based on
> JDBC ResultSet, how do I handle SQLExceptions? Should I create a
> proprietary UncheckedSQLException? Should multiple libraries each
> provide their own version of UncheckedXxxExceptions for every
> XxxException? We'll be in this hell for some years to come before the
> language gives a better device.
> 
> Meanwhile, why not provide a generic wrapper exception whose explicit
> and sole purpose is to wrap another checked exception? I know the idea
> is trivia, but why not?
> 
> The Wrapper can provide convenience methods like
> 
>    class Wrapper extends RuntimeException
> 
>        // if cause is E1, throw cause; otherwise throw wrapper.
>        <E1> RuntimeException rethrow(Class<E1> type) throws E1, Wrapper
> 
> so we can
> 
>    catch(Wrapper w)
>        throw w.rethrow(IOException.class, SQLException.class);
> 
> or to handle causes inline
> 
>    catch(Wrapper w)
>        w.on(IOException.class, e->{ handle e; })
>           .on(SQLException.class, e->{ handle e; });
> 
>    <Ei, Eo> Wrapper on(Class<Ei> type, ExceptionHandler<Ei,Eo>) throws Eo;
> 
>    interface ExceptionHandler<Ei,Eo>
>        void handle(Ei e) throws Eo;
> 
> obviously not elegant, but at least give us something of the sort that
> can alleviate the pain in the short term.
> 
> Zhong Yu
> 
> 
> On Fri, Feb 1, 2013 at 11:38 PM, Peter Levart <peter.levart at gmail.com> wrote:
>> 
>> On 02/02/2013 12:44 AM, Henry Jen wrote:
>>> On 01/28/2013 12:16 AM, Peter Levart wrote:
>>>> On 01/28/2013 12:06 AM, Henry Jen wrote:
>>>>> http://cr.openjdk.java.net/~henryjen/lambda/nio.5/webrev/
>>>>> 
>>>> Hi Henry,
>>>> 
>>>> I can imagine that many times a single block of code would be
>>>> responsible for constructing a Path stream (possibly enclosed into a
>>>> try-with-resources construct) and consuming it's results, so having to
>>>> deal with the duality of IOException/UncheckedIOException is a
>>>> complication for a user in my opinion. Wouldn't it be better also for
>>>> the stream-factory methods to throw UncheckedIOException and for
>>>> CloseableStream.close() to also throw UncheckedIOException (that means,
>>>> only inheriting from AutoCloseable, not Closeable and co-variant-ly
>>>> redefining the throws declaration):
>>>> 
>>>> public interface CloseableStream<T> extends Stream<T>, AutoCloseable {
>>>>     @Override
>>>>     void close() throws UncheckedIOException;
>>>> }
>>>> 
>>> Hi Peter,
>> 
>> Hi Henry,
>> 
>>> Sorry for the late reply, I want to let the idea sink a little bit.
>>> 
>>> After couple days, I am slightly prefer not to change it because,
>>> 
>>> 1) The CloseableStream-factory method throws IOException reminds use of
>>> try-with-resource better than an unchecked exception.
>> 
>> The *Closeable*Stream method return type name also reminds of that ;-)
>> 
>>> 2) As factory methods throwing IOException, developer is dealing with
>>> duality already.
>> 
>> He is dealing with duality already *if* the factory methods are throwing
>> IOException. If they are throwing UncheckedIOException, he is not
>> dealing with duality.
>> 
>>> 3) If the close method throws UncheckedIOException as the stream
>>> handling, the suppressing of exceptions will be more confusing. Should
>>> developer look into cause IOException or the UncheckedIOException?
>> 
>> Do you think a programmer might want to handle different subtypes of
>> IOException differently? If that is the case, the javadoc should
>> document all the possible situations. And what about different subtypes
>> of IOException wrapped by UncheckedIOException while consuming the
>> stream? If the programmer already bothers to unwrap the unchecked
>> exception to do the cause analisys, then this same handler would be good
>> also for dealing with exceptions thrown in factory methods and
>> CloseableStream.close(). The streams API is a higher-lever wrapper over
>> the java.nio.file.DirectoryStream API and it is already wrapping the
>> lower-level IOException with UncheckedIOException when consuming the
>> CloseableStream. I think it should do it consistently. By doing it
>> consistently, it simplifies correct exception handling logic in *all*
>> situations.
>> 
>>> 4) When the implementation is a Closeable, the wrapping of IOException
>>> into an UncheckedIOException doesn't do any good except overhead in case
>>> developer want to deal with it. On the other hand, a IOException handler
>>> is probably in place as the factory methods throws IOException.
>> 
>> It is probably in place *if* the factory methods are throwing
>> IOException. If they are throwing UncheckedIOException, then such
>> handler is not there. The question is whether the UncheckedIOException
>> handler is in place too. If I look in one of your tests:
>> 
>>  148         public void testWalk() {
>>  149                 try(CloseableStream<Path> s = Files.walk(testFolder)) {
>>  150                         Object[] actual = s.sorted(Comparators.naturalOrder()).toArray();
>>  151                         assertEquals(actual, all);
>>  152                 } catch (IOException ioe) {
>>  153                         fail("Unexpected IOException");
>>  154                 }
>>  155         }
>> 
>> 
>> You haven't bothered to handle the UncheckedIOException (because the
>> test would fail anyway if it was thrown). But I'm afraid that average
>> programmer will walk away from similar codes with false sense of
>> confidence that he handled all exceptional situations when he put the
>> checked exception handler in place. I think that being consistent and
>> throwing UncheckedIOException everywhere would actually have greater
>> probability for average programmer to not miss the handling of
>> exceptional situations while consuming the stream - at least all
>> exceptional situations would be handled or not handled equally.
>> 
>> Regards, Peter
>> 
>>> Does it make sense?
>>> 
>>> I updated the webrev to have some test coverage for exception handling,
>>> it's painful as always, but the duality is not what bothers me.
>>> 
>>> http://cr.openjdk.java.net/~henryjen/lambda/nio.6/webrev/
>>> 
>>> Cheers,
>>> Henry
>>> 
>> 
>> 


From peter.levart at gmail.com  Mon Feb  4 10:17:46 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Mon, 04 Feb 2013 19:17:46 +0100
Subject: CloseableStream exceptions [was: Re: experience trying out
	lambda-8-b74]
In-Reply-To: <153DE41A-FCF6-47C0-B5F5-8B7D49D4CBDE@oracle.com>
References: <51053A5A.24195.AAF1F6@v.a.ammodytes.googlemail.com>
	<5105762A.8040002@oracle.com>
	<E61425C5-6E01-49C3-B149-151D2A3B81F3@wonderly.org>
	<CC95D104-28E2-42DE-B1A4-DD02BAD67F38@oracle.com>
	<510633DE.9060001@gmail.com> <510C5348.8020107@oracle.com>
	<510CA649.5050000@gmail.com>
	<153DE41A-FCF6-47C0-B5F5-8B7D49D4CBDE@oracle.com>
Message-ID: <510FFB4A.1040501@gmail.com>


On 02/04/2013 06:55 PM, Henry Jen wrote:
> My preference is mainly build on top of that factory methods throws IOException. I still believe factory methods should throw IOException instead of wrap it up into UncheckedIOException so to enforce a try thus better reminds using try-with-resource to ensure close. So that is not going to change for those APIs in nio.

Why do you think throwing IOException would remind of using 
try-with-resource? The construct was designed for general AutoCloseable 
resources regardless of types of checked or unchecked exceptions thrown 
by creating, consuming or closing them...

> However, that should probably be a separate concern from what is in CloseableStream, not all factory method need to throw IOException although it is more likely.

It's unfortunate that java.nio.file.Files already contains other static 
methods, not connected with streams API, that throw checked IOException. 
So I understand that mixing-in methods that instead throw 
UncheckedIOException is confusing at first for the user. So maybe, there 
should be a separate class for those methods to distinguish them from 
"normal" nio.file methods?

> The wrapping cost and suppress of exceptions(as in JDK 7[1]) is not really a big deal, it's great if we don't need them, but if we have to, we have to.
>
> On change the definition of CloseableStream, which would be preferred?
>
> CloseableStream<T> close();

you meant:

void close();

Could be, yes, but why not be more "documentary" and declaring it 
throwing the unchecked exception, like:

void close() throws UncheckedIOException;

> or
>
> CloseableStream<T> close() throws Exception;

Definitely not, since then, user is forced to catch or re-throw the 
generic checked Exception.

Regards, Peter

> Also should we change it into AutoCloseableStream() as it is really just an AutoCloseable? Personally I like CloseableStream as I assume AutoCloseable is just a remedy for Closeable.
>
> Cheers,
> Henry
>
> [1] http://docs.oracle.com/javase/tutorial/essential/exceptions/tryResourceClose.html#suppressed-exceptions
>
>
> On Feb 1, 2013, at 9:38 PM, Peter Levart <peter.levart at gmail.com> wrote:
>
>> On 02/02/2013 12:44 AM, Henry Jen wrote:
>>> On 01/28/2013 12:16 AM, Peter Levart wrote:
>>>
>>>> On 01/28/2013 12:06 AM, Henry Jen wrote:
>>>>
>>>>> http://cr.openjdk.java.net/~henryjen/lambda/nio.5/webrev/
>>>>>
>>>>>
>>>>>
>>>> Hi Henry,
>>>>
>>>> I can imagine that many times a single block of code would be
>>>> responsible for constructing a Path stream (possibly enclosed into a
>>>> try-with-resources construct) and consuming it's results, so having to
>>>> deal with the duality of IOException/UncheckedIOException is a
>>>> complication for a user in my opinion. Wouldn't it be better also for
>>>> the stream-factory methods to throw UncheckedIOException and for
>>>> CloseableStream.close() to also throw UncheckedIOException (that means,
>>>> only inheriting from AutoCloseable, not Closeable and co-variant-ly
>>>> redefining the throws declaration):
>>>>
>>>> public interface CloseableStream<T> extends Stream<T>, AutoCloseable {
>>>>      @Override
>>>>      void close() throws UncheckedIOException;
>>>> }
>>>>
>>>>
>>> Hi Peter,
>> Hi Henry,
>>
>>> Sorry for the late reply, I want to let the idea sink a little bit.
>>>
>>> After couple days, I am slightly prefer not to change it because,
>>>
>>> 1) The CloseableStream-factory method throws IOException reminds use of
>>> try-with-resource better than an unchecked exception.
>>>
>> The CloseableStream method return type name also reminds of that ;-)
>>
>>> 2) As factory methods throwing IOException, developer is dealing with
>>> duality already.
>>>
>> He is dealing with duality already *if* the factory methods are throwing IOException. If they are throwing UncheckedIOException, he is not dealing with duality.
>>
>>> 3) If the close method throws UncheckedIOException as the stream
>>> handling, the suppressing of exceptions will be more confusing. Should
>>> developer look into cause IOException or the UncheckedIOException?
>>>
>> Do you think a programmer might want to handle different subtypes of IOException differently? If that is the case, the javadoc should document all the possible situations. And what about different     subtypes of IOException wrapped by UncheckedIOException while consuming the stream? If the programmer already bothers to unwrap the unchecked exception to do the cause analisys, then this same handler would be good also for dealing with exceptions thrown in factory methods and CloseableStream.close(). The streams API is a higher-lever wrapper over the java.nio.file.DirectoryStream API and it is already wrapping the lower-level IOException with UncheckedIOException when consuming the CloseableStream. I think it should do it consistently. By doing it consistently, it simplifies correct exception handling logic in *all* situations.
>>
>>> 4) When the implementation is a Closeable, the wrapping of IOException
>>> into an UncheckedIOException doesn't do any good except overhead in case
>>> developer want to deal with it. On the other hand, a IOException handler
>>> is probably in place as the factory methods throws IOException.
>>>
>> It is probably in place *if* the factory methods are throwing IOException. If they are throwing UncheckedIOException, then such handler is not there. The question is whether the UncheckedIOException handler is in place too. If I look in one of your tests:
>>
>>   148         public void testWalk() {
>>   149                 try(CloseableStream<Path> s = Files.walk(testFolder)) {
>>   150                         Object[] actual = s.sorted(Comparators.naturalOrder()).toArray();
>>   151                         assertEquals(actual, all);
>>   152                 } catch (IOException ioe) {
>>   153                         fail("Unexpected IOException");
>>   154                 }
>>   155         }
>>
>>
>> You haven't bothered to handle the UncheckedIOException (because the test would fail anyway if it was thrown). But I'm afraid that average programmer will walk away from similar codes with false sense of confidence that he handled all exceptional situations when he put the checked exception handler in place. I think that being consistent and throwing UncheckedIOException everywhere would     actually have greater probability for average programmer to not miss the handling of exceptional situations while consuming the stream - at least all exceptional situations would be handled or not handled equally.
>>
>> Regards, Peter
>>
>>> Does it make sense?
>>>
>>> I updated the webrev to have some test coverage for exception handling,
>>> it's painful as always, but the duality is not what bothers me.
>>>
>>>
>>> http://cr.openjdk.java.net/~henryjen/lambda/nio.6/webrev/
>>>
>>>
>>> Cheers,
>>> Henry
>>>
>>>


From henry.jen at oracle.com  Mon Feb  4 10:27:28 2013
From: henry.jen at oracle.com (Henry Jen)
Date: Mon, 4 Feb 2013 10:27:28 -0800
Subject: CloseableStream exceptions [was: Re: experience trying out
	lambda-8-b74]
In-Reply-To: <510FFB4A.1040501@gmail.com>
References: <51053A5A.24195.AAF1F6@v.a.ammodytes.googlemail.com>
	<5105762A.8040002@oracle.com>
	<E61425C5-6E01-49C3-B149-151D2A3B81F3@wonderly.org>
	<CC95D104-28E2-42DE-B1A4-DD02BAD67F38@oracle.com>
	<510633DE.9060001@gmail.com> <510C5348.8020107@oracle.com>
	<510CA649.5050000@gmail.com>
	<153DE41A-FCF6-47C0-B5F5-8B7D49D4CBDE@oracle.com>
	<510FFB4A.1040501@gmail.com>
Message-ID: <D5FA5DFE-70FD-4C81-92D7-B4AAA8122446@oracle.com>

On Feb 4, 2013, at 10:17 AM, Peter Levart <peter.levart at gmail.com> wrote:

> 
> On 02/04/2013 06:55 PM, Henry Jen wrote:
>> My preference is mainly build on top of that factory methods throws IOException. I still believe factory methods should throw IOException instead of wrap it up into UncheckedIOException so to enforce a try thus better reminds using try-with-resource to ensure close. So that is not going to change for those APIs in nio.
> 
> Why do you think throwing IOException would remind of using try-with-resource? The construct was designed for general AutoCloseable resources regardless of types of checked or unchecked exceptions thrown by creating, consuming or closing them?
> 

Because of forcing a try block with checked exception. Better chance than unchecked exception. Also this is not defined by CloseableStream, it's the implementation class to decide what exceptions are proper.

> 
>> The wrapping cost and suppress of exceptions(as in JDK 7[1]) is not really a big deal, it's great if we don't need them, but if we have to, we have to.
>> 
>> On change the definition of CloseableStream, which would be preferred?
>> 
>> CloseableStream<T> close();
>> 
> 
> you meant:
> 
> void close();
> 
> Could be, yes, but why not be more "documentary" and declaring it throwing the unchecked exception, like:
> 
> void close() throws UncheckedIOException;
> 

Because RuntimeException by convention won't be there, but in JavaDoc. In this case, we won't even mentioned in JavaDoc, the implementation class should decide if there are any RuntimeException it will need to throw and how.

Cheers,
Henry


From peter.levart at gmail.com  Mon Feb  4 11:02:47 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Mon, 04 Feb 2013 20:02:47 +0100
Subject: CloseableStream exceptions [was: Re: experience trying out
	lambda-8-b74]
In-Reply-To: <D5FA5DFE-70FD-4C81-92D7-B4AAA8122446@oracle.com>
References: <51053A5A.24195.AAF1F6@v.a.ammodytes.googlemail.com>
	<5105762A.8040002@oracle.com>
	<E61425C5-6E01-49C3-B149-151D2A3B81F3@wonderly.org>
	<CC95D104-28E2-42DE-B1A4-DD02BAD67F38@oracle.com>
	<510633DE.9060001@gmail.com> <510C5348.8020107@oracle.com>
	<510CA649.5050000@gmail.com>
	<153DE41A-FCF6-47C0-B5F5-8B7D49D4CBDE@oracle.com>
	<510FFB4A.1040501@gmail.com>
	<D5FA5DFE-70FD-4C81-92D7-B4AAA8122446@oracle.com>
Message-ID: <511005D7.9070501@gmail.com>


On 02/04/2013 07:27 PM, Henry Jen wrote:
> On Feb 4, 2013, at 10:17 AM, Peter Levart <peter.levart at gmail.com> wrote:
>
>> On 02/04/2013 06:55 PM, Henry Jen wrote:
>>> My preference is mainly build on top of that factory methods throws IOException. I still believe factory methods should throw IOException instead of wrap it up into UncheckedIOException so to enforce a try thus better reminds using try-with-resource to ensure close. So that is not going to change for those APIs in nio.
>> Why do you think throwing IOException would remind of using try-with-resource? The construct was designed for general AutoCloseable resources regardless of types of checked or unchecked exceptions thrown by creating, consuming or closing them?
>>
> Because of forcing a try block with checked exception. Better chance than unchecked exception. Also this is not defined by CloseableStream, it's the implementation class to decide what exceptions are proper.

I think that every new API or feature takes some time to get used. When 
try-with-resources was introduced, nobody was thinking to use it just 
because of java.io methods throwing checked IOException. I aggree that 
now many programmers mentally associate IOException with 
try-with-resources and you want to piggy-back on that mental perception. 
You might get quick response at the beginning, but for the price of 
long-term ugliness of exception handling when using the API. I expect 
people would be asking for another factory method throwing 
UncheckedIOException in JDK9 after the API is going to get used massively...

>>> The wrapping cost and suppress of exceptions(as in JDK 7[1]) is not really a big deal, it's great if we don't need them, but if we have to, we have to.
>>>
>>> On change the definition of CloseableStream, which would be preferred?
>>>
>>> CloseableStream<T> close();
>>>
>> you meant:
>>
>> void close();
>>
>> Could be, yes, but why not be more "documentary" and declaring it throwing the unchecked exception, like:
>>
>> void close() throws UncheckedIOException;
>>
> Because RuntimeException by convention won't be there, but in JavaDoc. In this case, we won't even mentioned in JavaDoc, the implementation class should decide if there are any RuntimeException it will need to throw and how.

Ah, sorry, I haven't noticed the package name of CloseableStream. I 
thought it was part of java.nio.file API, but it is in java.util.stream. 
Do you think a generic java.util.stream.CloseableStream is mandated? No 
API in java.util.stream uses it. Maybe it would be good just for 
enforcing the convention for any CloseableStream to not throw a checked 
exception on .close()...

In that case, yes, It should re-declare the close() by not throwing 
anything.

Regards, Peter

> Cheers,
> Henry
>


From Alan.Bateman at oracle.com  Mon Feb  4 11:45:51 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 04 Feb 2013 19:45:51 +0000
Subject: CloseableStream exceptions [was: Re: experience trying out
	lambda-8-b74]
In-Reply-To: <511005D7.9070501@gmail.com>
References: <51053A5A.24195.AAF1F6@v.a.ammodytes.googlemail.com>
	<5105762A.8040002@oracle.com>
	<E61425C5-6E01-49C3-B149-151D2A3B81F3@wonderly.org>
	<CC95D104-28E2-42DE-B1A4-DD02BAD67F38@oracle.com>
	<510633DE.9060001@gmail.com> <510C5348.8020107@oracle.com>
	<510CA649.5050000@gmail.com>
	<153DE41A-FCF6-47C0-B5F5-8B7D49D4CBDE@oracle.com>
	<510FFB4A.1040501@gmail.com>
	<D5FA5DFE-70FD-4C81-92D7-B4AAA8122446@oracle.com>
	<511005D7.9070501@gmail.com>
Message-ID: <51100FEF.2090300@oracle.com>

On 04/02/2013 19:02, Peter Levart wrote:
>
> I think that every new API or feature takes some time to get used. When
> try-with-resources was introduced, nobody was thinking to use it just
> because of java.io methods throwing checked IOException. I aggree that
> now many programmers mentally associate IOException with
> try-with-resources and you want to piggy-back on that mental perception.
> You might get quick response at the beginning, but for the price of
> long-term ugliness of exception handling when using the API. I expect
> people would be asking for another factory method throwing
> UncheckedIOException in JDK9 after the API is going to get used massively...
>
All methods to open or access files, directories, etc. in this API throw 
the checked IOException. It would be inconsistent to introduce a 
parallel set of methods at this point, particularly because this API 
also defines also many specific IOExceptions for cases where recovery 
might be required for specific cases.

So I think if CloseableStream is used in a try-with-resources that opens 
the file or directory then it will probably lead to usages such as:

try (...) {
      :
} catch (UncheckedIOException e) {
     throw e.getCause();
}

or

try (...) {
     :
} catch (IOException ioe) {
     throw new UncheckedIOException(ioe);
}

depending on whether you want to propagate a checked or unchecked 
exception. One of two examples in the javadoc might help.

-Alan.


From peter.levart at gmail.com  Mon Feb  4 12:35:22 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Mon, 04 Feb 2013 21:35:22 +0100
Subject: CloseableStream exceptions [was: Re: experience trying out
	lambda-8-b74]
In-Reply-To: <51100FEF.2090300@oracle.com>
References: <51053A5A.24195.AAF1F6@v.a.ammodytes.googlemail.com>
	<5105762A.8040002@oracle.com>
	<E61425C5-6E01-49C3-B149-151D2A3B81F3@wonderly.org>
	<CC95D104-28E2-42DE-B1A4-DD02BAD67F38@oracle.com>
	<510633DE.9060001@gmail.com> <510C5348.8020107@oracle.com>
	<510CA649.5050000@gmail.com>
	<153DE41A-FCF6-47C0-B5F5-8B7D49D4CBDE@oracle.com>
	<510FFB4A.1040501@gmail.com>
	<D5FA5DFE-70FD-4C81-92D7-B4AAA8122446@oracle.com>
	<511005D7.9070501@gmail.com> <51100FEF.2090300@oracle.com>
Message-ID: <51101B8A.5070505@gmail.com>


On 02/04/2013 08:45 PM, Alan Bateman wrote:
> On 04/02/2013 19:02, Peter Levart wrote:
>>
>> I think that every new API or feature takes some time to get used. When
>> try-with-resources was introduced, nobody was thinking to use it just
>> because of java.io methods throwing checked IOException. I aggree that
>> now many programmers mentally associate IOException with
>> try-with-resources and you want to piggy-back on that mental perception.
>> You might get quick response at the beginning, but for the price of
>> long-term ugliness of exception handling when using the API. I expect
>> people would be asking for another factory method throwing
>> UncheckedIOException in JDK9 after the API is going to get used 
>> massively...
>>
> All methods to open or access files, directories, etc. in this API 
> throw the checked IOException. It would be inconsistent to introduce a 
> parallel set of methods at this point, particularly because this API 
> also defines also many specific IOExceptions for cases where recovery 
> might be required for specific cases.

Are the specific IOExceptions only relevant when creating the stream or 
also when consuming and/or closing it?

>
> So I think if CloseableStream is used in a try-with-resources that 
> opens the file or directory then it will probably lead to usages such as:
>
> try (...) {
>      :
> } catch (UncheckedIOException e) {
>     throw e.getCause();
> }

The above example would stay exactly the same if the factory method 
threw UncheckedIOException.

>
> or
>
> try (...) {
>     :
> } catch (IOException ioe) {
>     throw new UncheckedIOException(ioe);
> }
>

The catch and manual wrap in UncheckedIOException in above example would 
not be needed if the factory method threw UncheckedIOException already...

> depending on whether you want to propagate a checked or unchecked 
> exception. One of two examples in the javadoc might help.
>
> -Alan.
>

Regards, Peter


From Alan.Bateman at oracle.com  Mon Feb  4 12:45:45 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 04 Feb 2013 20:45:45 +0000
Subject: CloseableStream exceptions [was: Re: experience trying out
	lambda-8-b74]
In-Reply-To: <51101B8A.5070505@gmail.com>
References: <51053A5A.24195.AAF1F6@v.a.ammodytes.googlemail.com>
	<5105762A.8040002@oracle.com>
	<E61425C5-6E01-49C3-B149-151D2A3B81F3@wonderly.org>
	<CC95D104-28E2-42DE-B1A4-DD02BAD67F38@oracle.com>
	<510633DE.9060001@gmail.com> <510C5348.8020107@oracle.com>
	<510CA649.5050000@gmail.com>
	<153DE41A-FCF6-47C0-B5F5-8B7D49D4CBDE@oracle.com>
	<510FFB4A.1040501@gmail.com>
	<D5FA5DFE-70FD-4C81-92D7-B4AAA8122446@oracle.com>
	<511005D7.9070501@gmail.com> <51100FEF.2090300@oracle.com>
	<51101B8A.5070505@gmail.com>
Message-ID: <51101DF9.90307@oracle.com>

On 04/02/2013 20:35, Peter Levart wrote:
> :
>
> Are the specific IOExceptions only relevant when creating the stream 
> or also when consuming and/or closing it?
Opening files/directories mostly (although many of the operations on 
files that are nothing to do with streams can specify specific 
exceptions too). As soon as you do I/O (either classic java.io or NIO) 
then it involves checked IOExceptions, irrespective of whether the 
method to get the CloseableStream throws checked or unexpected exceptions.

-Alan

From paul.sandoz at oracle.com  Mon Feb  4 12:45:55 2013
From: paul.sandoz at oracle.com (paul.sandoz at oracle.com)
Date: Mon, 04 Feb 2013 20:45:55 +0000
Subject: hg: lambda/lambda/jdk: Correct headers.
Message-ID: <20130204204616.5F20D477FC@hg.openjdk.java.net>

Changeset: 9e643801f516
Author:    psandoz
Date:      2013-02-04 21:44 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/9e643801f516

Correct headers.
Contributed-by: Chris Hegarty <chris.hegarty at oracle.com>

! src/share/classes/java/util/concurrent/ConcurrentHashMap.java
! src/share/classes/java/util/concurrent/ConcurrentSkipListMap.java
! src/share/classes/java/util/concurrent/ConcurrentSkipListSet.java
! src/share/classes/java/util/concurrent/CopyOnWriteArrayList.java
! src/share/classes/java/util/concurrent/CopyOnWriteArraySet.java
! src/share/classes/java/util/concurrent/PriorityBlockingQueue.java


From peter.levart at gmail.com  Mon Feb  4 13:31:32 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Mon, 04 Feb 2013 22:31:32 +0100
Subject: CloseableStream exceptions [was: Re: experience trying out
	lambda-8-b74]
In-Reply-To: <51101DF9.90307@oracle.com>
References: <51053A5A.24195.AAF1F6@v.a.ammodytes.googlemail.com>
	<5105762A.8040002@oracle.com>
	<E61425C5-6E01-49C3-B149-151D2A3B81F3@wonderly.org>
	<CC95D104-28E2-42DE-B1A4-DD02BAD67F38@oracle.com>
	<510633DE.9060001@gmail.com> <510C5348.8020107@oracle.com>
	<510CA649.5050000@gmail.com>
	<153DE41A-FCF6-47C0-B5F5-8B7D49D4CBDE@oracle.com>
	<510FFB4A.1040501@gmail.com>
	<D5FA5DFE-70FD-4C81-92D7-B4AAA8122446@oracle.com>
	<511005D7.9070501@gmail.com> <51100FEF.2090300@oracle.com>
	<51101B8A.5070505@gmail.com> <51101DF9.90307@oracle.com>
Message-ID: <511028B4.4080307@gmail.com>


On 02/04/2013 09:45 PM, Alan Bateman wrote:
> On 04/02/2013 20:35, Peter Levart wrote:
>> :
>>
>> Are the specific IOExceptions only relevant when creating the stream 
>> or also when consuming and/or closing it?
> Opening files/directories mostly (although many of the operations on 
> files that are nothing to do with streams can specify specific 
> exceptions too). As soon as you do I/O (either classic java.io or NIO) 
> then it involves checked IOExceptions, irrespective of whether the 
> method to get the CloseableStream throws checked or unexpected exceptions.
Oh yes, I've forgot that getting Path(s) is only half-way....

Regards, Peter

>
> -Alan


From zhong.j.yu at gmail.com  Mon Feb  4 15:03:59 2013
From: zhong.j.yu at gmail.com (Zhong Yu)
Date: Mon, 4 Feb 2013 17:03:59 -0600
Subject: experience trying out lambda-8-b74
In-Reply-To: <98694886-DF0D-4C82-B3FC-EFDBF4F6A796@oracle.com>
References: <51053A5A.24195.AAF1F6@v.a.ammodytes.googlemail.com>
	<5105762A.8040002@oracle.com>
	<E61425C5-6E01-49C3-B149-151D2A3B81F3@wonderly.org>
	<CC95D104-28E2-42DE-B1A4-DD02BAD67F38@oracle.com>
	<510633DE.9060001@gmail.com> <510C5348.8020107@oracle.com>
	<510CA649.5050000@gmail.com>
	<CACuKZqEWJKBxUh0=j8krP47f=UOZcTB6dREJuhdj0H7L4pYfTg@mail.gmail.com>
	<98694886-DF0D-4C82-B3FC-EFDBF4F6A796@oracle.com>
Message-ID: <CACuKZqHAYZ8U4NYU-e_=sy-0AtVXkzCmFHPBt-p-3FLDkRdo=g@mail.gmail.com>

On Mon, Feb 4, 2013 at 12:01 PM, Henry Jen <henry.jen at oracle.com> wrote:
> If we don't extend any exception handling or need type information, we don't really need a wrapper as Throwable already has hasCause() method.

UncheckedIOException is a wrapper for IOException. I'm arguing that
JDK should instead have a generic wrapper for Exception, so that all
libraries have a uniformed way of smuggling/unsmuggling checked
exceptions. Otherwise there are serious interoperability obstacles.

It appears that the lambda team does not take checked exceptions
seriously. It might be the right attitude academically, but real world
Java applications are full of checked exceptions. Without a guideline
from Java czars, lots of hacky ways will be invented when they try to
integrate with Stream.

Zhong Yu

> I recall there were discussion of transparent exception handling, which is still an open topic I believe.
>
> Cheers,
> Henry
>
> On Feb 2, 2013, at 9:06 AM, Zhong Yu <zhong.j.yu at gmail.com> wrote:
>
>> Also, what about other checked exceptions? If I make a stream based on
>> JDBC ResultSet, how do I handle SQLExceptions? Should I create a
>> proprietary UncheckedSQLException? Should multiple libraries each
>> provide their own version of UncheckedXxxExceptions for every
>> XxxException? We'll be in this hell for some years to come before the
>> language gives a better device.
>>
>> Meanwhile, why not provide a generic wrapper exception whose explicit
>> and sole purpose is to wrap another checked exception? I know the idea
>> is trivia, but why not?
>>
>> The Wrapper can provide convenience methods like
>>
>>    class Wrapper extends RuntimeException
>>
>>        // if cause is E1, throw cause; otherwise throw wrapper.
>>        <E1> RuntimeException rethrow(Class<E1> type) throws E1, Wrapper
>>
>> so we can
>>
>>    catch(Wrapper w)
>>        throw w.rethrow(IOException.class, SQLException.class);
>>
>> or to handle causes inline
>>
>>    catch(Wrapper w)
>>        w.on(IOException.class, e->{ handle e; })
>>           .on(SQLException.class, e->{ handle e; });
>>
>>    <Ei, Eo> Wrapper on(Class<Ei> type, ExceptionHandler<Ei,Eo>) throws Eo;
>>
>>    interface ExceptionHandler<Ei,Eo>
>>        void handle(Ei e) throws Eo;
>>
>> obviously not elegant, but at least give us something of the sort that
>> can alleviate the pain in the short term.
>>
>> Zhong Yu
>>
>>
>> On Fri, Feb 1, 2013 at 11:38 PM, Peter Levart <peter.levart at gmail.com> wrote:
>>>
>>> On 02/02/2013 12:44 AM, Henry Jen wrote:
>>>> On 01/28/2013 12:16 AM, Peter Levart wrote:
>>>>> On 01/28/2013 12:06 AM, Henry Jen wrote:
>>>>>> http://cr.openjdk.java.net/~henryjen/lambda/nio.5/webrev/
>>>>>>
>>>>> Hi Henry,
>>>>>
>>>>> I can imagine that many times a single block of code would be
>>>>> responsible for constructing a Path stream (possibly enclosed into a
>>>>> try-with-resources construct) and consuming it's results, so having to
>>>>> deal with the duality of IOException/UncheckedIOException is a
>>>>> complication for a user in my opinion. Wouldn't it be better also for
>>>>> the stream-factory methods to throw UncheckedIOException and for
>>>>> CloseableStream.close() to also throw UncheckedIOException (that means,
>>>>> only inheriting from AutoCloseable, not Closeable and co-variant-ly
>>>>> redefining the throws declaration):
>>>>>
>>>>> public interface CloseableStream<T> extends Stream<T>, AutoCloseable {
>>>>>     @Override
>>>>>     void close() throws UncheckedIOException;
>>>>> }
>>>>>
>>>> Hi Peter,
>>>
>>> Hi Henry,
>>>
>>>> Sorry for the late reply, I want to let the idea sink a little bit.
>>>>
>>>> After couple days, I am slightly prefer not to change it because,
>>>>
>>>> 1) The CloseableStream-factory method throws IOException reminds use of
>>>> try-with-resource better than an unchecked exception.
>>>
>>> The *Closeable*Stream method return type name also reminds of that ;-)
>>>
>>>> 2) As factory methods throwing IOException, developer is dealing with
>>>> duality already.
>>>
>>> He is dealing with duality already *if* the factory methods are throwing
>>> IOException. If they are throwing UncheckedIOException, he is not
>>> dealing with duality.
>>>
>>>> 3) If the close method throws UncheckedIOException as the stream
>>>> handling, the suppressing of exceptions will be more confusing. Should
>>>> developer look into cause IOException or the UncheckedIOException?
>>>
>>> Do you think a programmer might want to handle different subtypes of
>>> IOException differently? If that is the case, the javadoc should
>>> document all the possible situations. And what about different subtypes
>>> of IOException wrapped by UncheckedIOException while consuming the
>>> stream? If the programmer already bothers to unwrap the unchecked
>>> exception to do the cause analisys, then this same handler would be good
>>> also for dealing with exceptions thrown in factory methods and
>>> CloseableStream.close(). The streams API is a higher-lever wrapper over
>>> the java.nio.file.DirectoryStream API and it is already wrapping the
>>> lower-level IOException with UncheckedIOException when consuming the
>>> CloseableStream. I think it should do it consistently. By doing it
>>> consistently, it simplifies correct exception handling logic in *all*
>>> situations.
>>>
>>>> 4) When the implementation is a Closeable, the wrapping of IOException
>>>> into an UncheckedIOException doesn't do any good except overhead in case
>>>> developer want to deal with it. On the other hand, a IOException handler
>>>> is probably in place as the factory methods throws IOException.
>>>
>>> It is probably in place *if* the factory methods are throwing
>>> IOException. If they are throwing UncheckedIOException, then such
>>> handler is not there. The question is whether the UncheckedIOException
>>> handler is in place too. If I look in one of your tests:
>>>
>>>  148         public void testWalk() {
>>>  149                 try(CloseableStream<Path> s = Files.walk(testFolder)) {
>>>  150                         Object[] actual = s.sorted(Comparators.naturalOrder()).toArray();
>>>  151                         assertEquals(actual, all);
>>>  152                 } catch (IOException ioe) {
>>>  153                         fail("Unexpected IOException");
>>>  154                 }
>>>  155         }
>>>
>>>
>>> You haven't bothered to handle the UncheckedIOException (because the
>>> test would fail anyway if it was thrown). But I'm afraid that average
>>> programmer will walk away from similar codes with false sense of
>>> confidence that he handled all exceptional situations when he put the
>>> checked exception handler in place. I think that being consistent and
>>> throwing UncheckedIOException everywhere would actually have greater
>>> probability for average programmer to not miss the handling of
>>> exceptional situations while consuming the stream - at least all
>>> exceptional situations would be handled or not handled equally.
>>>
>>> Regards, Peter
>>>
>>>> Does it make sense?
>>>>
>>>> I updated the webrev to have some test coverage for exception handling,
>>>> it's painful as always, but the duality is not what bothers me.
>>>>
>>>> http://cr.openjdk.java.net/~henryjen/lambda/nio.6/webrev/
>>>>
>>>> Cheers,
>>>> Henry
>>>>
>>>
>>>
>

From brian.goetz at oracle.com  Mon Feb  4 15:11:31 2013
From: brian.goetz at oracle.com (Brian Goetz)
Date: Mon, 04 Feb 2013 18:11:31 -0500
Subject: experience trying out lambda-8-b74
In-Reply-To: <CACuKZqHAYZ8U4NYU-e_=sy-0AtVXkzCmFHPBt-p-3FLDkRdo=g@mail.gmail.com>
References: <51053A5A.24195.AAF1F6@v.a.ammodytes.googlemail.com>
	<5105762A.8040002@oracle.com>
	<E61425C5-6E01-49C3-B149-151D2A3B81F3@wonderly.org>
	<CC95D104-28E2-42DE-B1A4-DD02BAD67F38@oracle.com>
	<510633DE.9060001@gmail.com> <510C5348.8020107@oracle.com>
	<510CA649.5050000@gmail.com>
	<CACuKZqEWJKBxUh0=j8krP47f=UOZcTB6dREJuhdj0H7L4pYfTg@mail.gmail.com>
	<98694886-DF0D-4C82-B3FC-EFDBF4F6A796@oracle.com>
	<CACuKZqHAYZ8U4NYU-e_=sy-0AtVXkzCmFHPBt-p-3FLDkRdo=g@mail.gmail.com>
Message-ID: <51104023.4020502@oracle.com>

I knew it wouldn't be long before this turned into yet another 
barely-laundered proposal to try yet again to get us to deprecate 
checked exceptions.  I get it, you find checked exceptions frustrating. 
  Sometimes I do too.  But we still believe a world without them would 
be worse, and we're not interested in pushing people towards that.

There are places in the Java libraries -- mostly from the very early 
days -- where the use of checked exceptions turned out to be a mistake. 
  (An obvious example is close() throwing IOException -- what could a 
user possibly do to recover from that?)  The workarounds we're doing 
here are to mitigate the worst mistakes of the past, not to rewrite 
history.  And we're satisfied that this small workaround handles 90% of 
the 2% of cases where exceptions turn out to intrude in lambda 
libraries.  So we've made the decision to stop there for now, and not 
because it didn't occur to us to go farther.



On 2/4/2013 6:03 PM, Zhong Yu wrote:
> On Mon, Feb 4, 2013 at 12:01 PM, Henry Jen <henry.jen at oracle.com> wrote:
>> If we don't extend any exception handling or need type information, we don't really need a wrapper as Throwable already has hasCause() method.
>
> UncheckedIOException is a wrapper for IOException. I'm arguing that
> JDK should instead have a generic wrapper for Exception, so that all
> libraries have a uniformed way of smuggling/unsmuggling checked
> exceptions. Otherwise there are serious interoperability obstacles.
>
> It appears that the lambda team does not take checked exceptions
> seriously. It might be the right attitude academically, but real world
> Java applications are full of checked exceptions. Without a guideline
> from Java czars, lots of hacky ways will be invented when they try to
> integrate with Stream.
>
> Zhong Yu
>
>> I recall there were discussion of transparent exception handling, which is still an open topic I believe.
>>
>> Cheers,
>> Henry
>>
>> On Feb 2, 2013, at 9:06 AM, Zhong Yu <zhong.j.yu at gmail.com> wrote:
>>
>>> Also, what about other checked exceptions? If I make a stream based on
>>> JDBC ResultSet, how do I handle SQLExceptions? Should I create a
>>> proprietary UncheckedSQLException? Should multiple libraries each
>>> provide their own version of UncheckedXxxExceptions for every
>>> XxxException? We'll be in this hell for some years to come before the
>>> language gives a better device.
>>>
>>> Meanwhile, why not provide a generic wrapper exception whose explicit
>>> and sole purpose is to wrap another checked exception? I know the idea
>>> is trivia, but why not?
>>>
>>> The Wrapper can provide convenience methods like
>>>
>>>     class Wrapper extends RuntimeException
>>>
>>>         // if cause is E1, throw cause; otherwise throw wrapper.
>>>         <E1> RuntimeException rethrow(Class<E1> type) throws E1, Wrapper
>>>
>>> so we can
>>>
>>>     catch(Wrapper w)
>>>         throw w.rethrow(IOException.class, SQLException.class);
>>>
>>> or to handle causes inline
>>>
>>>     catch(Wrapper w)
>>>         w.on(IOException.class, e->{ handle e; })
>>>            .on(SQLException.class, e->{ handle e; });
>>>
>>>     <Ei, Eo> Wrapper on(Class<Ei> type, ExceptionHandler<Ei,Eo>) throws Eo;
>>>
>>>     interface ExceptionHandler<Ei,Eo>
>>>         void handle(Ei e) throws Eo;
>>>
>>> obviously not elegant, but at least give us something of the sort that
>>> can alleviate the pain in the short term.
>>>
>>> Zhong Yu
>>>
>>>
>>> On Fri, Feb 1, 2013 at 11:38 PM, Peter Levart <peter.levart at gmail.com> wrote:
>>>>
>>>> On 02/02/2013 12:44 AM, Henry Jen wrote:
>>>>> On 01/28/2013 12:16 AM, Peter Levart wrote:
>>>>>> On 01/28/2013 12:06 AM, Henry Jen wrote:
>>>>>>> http://cr.openjdk.java.net/~henryjen/lambda/nio.5/webrev/
>>>>>>>
>>>>>> Hi Henry,
>>>>>>
>>>>>> I can imagine that many times a single block of code would be
>>>>>> responsible for constructing a Path stream (possibly enclosed into a
>>>>>> try-with-resources construct) and consuming it's results, so having to
>>>>>> deal with the duality of IOException/UncheckedIOException is a
>>>>>> complication for a user in my opinion. Wouldn't it be better also for
>>>>>> the stream-factory methods to throw UncheckedIOException and for
>>>>>> CloseableStream.close() to also throw UncheckedIOException (that means,
>>>>>> only inheriting from AutoCloseable, not Closeable and co-variant-ly
>>>>>> redefining the throws declaration):
>>>>>>
>>>>>> public interface CloseableStream<T> extends Stream<T>, AutoCloseable {
>>>>>>      @Override
>>>>>>      void close() throws UncheckedIOException;
>>>>>> }
>>>>>>
>>>>> Hi Peter,
>>>>
>>>> Hi Henry,
>>>>
>>>>> Sorry for the late reply, I want to let the idea sink a little bit.
>>>>>
>>>>> After couple days, I am slightly prefer not to change it because,
>>>>>
>>>>> 1) The CloseableStream-factory method throws IOException reminds use of
>>>>> try-with-resource better than an unchecked exception.
>>>>
>>>> The *Closeable*Stream method return type name also reminds of that ;-)
>>>>
>>>>> 2) As factory methods throwing IOException, developer is dealing with
>>>>> duality already.
>>>>
>>>> He is dealing with duality already *if* the factory methods are throwing
>>>> IOException. If they are throwing UncheckedIOException, he is not
>>>> dealing with duality.
>>>>
>>>>> 3) If the close method throws UncheckedIOException as the stream
>>>>> handling, the suppressing of exceptions will be more confusing. Should
>>>>> developer look into cause IOException or the UncheckedIOException?
>>>>
>>>> Do you think a programmer might want to handle different subtypes of
>>>> IOException differently? If that is the case, the javadoc should
>>>> document all the possible situations. And what about different subtypes
>>>> of IOException wrapped by UncheckedIOException while consuming the
>>>> stream? If the programmer already bothers to unwrap the unchecked
>>>> exception to do the cause analisys, then this same handler would be good
>>>> also for dealing with exceptions thrown in factory methods and
>>>> CloseableStream.close(). The streams API is a higher-lever wrapper over
>>>> the java.nio.file.DirectoryStream API and it is already wrapping the
>>>> lower-level IOException with UncheckedIOException when consuming the
>>>> CloseableStream. I think it should do it consistently. By doing it
>>>> consistently, it simplifies correct exception handling logic in *all*
>>>> situations.
>>>>
>>>>> 4) When the implementation is a Closeable, the wrapping of IOException
>>>>> into an UncheckedIOException doesn't do any good except overhead in case
>>>>> developer want to deal with it. On the other hand, a IOException handler
>>>>> is probably in place as the factory methods throws IOException.
>>>>
>>>> It is probably in place *if* the factory methods are throwing
>>>> IOException. If they are throwing UncheckedIOException, then such
>>>> handler is not there. The question is whether the UncheckedIOException
>>>> handler is in place too. If I look in one of your tests:
>>>>
>>>>   148         public void testWalk() {
>>>>   149                 try(CloseableStream<Path> s = Files.walk(testFolder)) {
>>>>   150                         Object[] actual = s.sorted(Comparators.naturalOrder()).toArray();
>>>>   151                         assertEquals(actual, all);
>>>>   152                 } catch (IOException ioe) {
>>>>   153                         fail("Unexpected IOException");
>>>>   154                 }
>>>>   155         }
>>>>
>>>>
>>>> You haven't bothered to handle the UncheckedIOException (because the
>>>> test would fail anyway if it was thrown). But I'm afraid that average
>>>> programmer will walk away from similar codes with false sense of
>>>> confidence that he handled all exceptional situations when he put the
>>>> checked exception handler in place. I think that being consistent and
>>>> throwing UncheckedIOException everywhere would actually have greater
>>>> probability for average programmer to not miss the handling of
>>>> exceptional situations while consuming the stream - at least all
>>>> exceptional situations would be handled or not handled equally.
>>>>
>>>> Regards, Peter
>>>>
>>>>> Does it make sense?
>>>>>
>>>>> I updated the webrev to have some test coverage for exception handling,
>>>>> it's painful as always, but the duality is not what bothers me.
>>>>>
>>>>> http://cr.openjdk.java.net/~henryjen/lambda/nio.6/webrev/
>>>>>
>>>>> Cheers,
>>>>> Henry
>>>>>
>>>>
>>>>
>>
>

From henry.jen at oracle.com  Mon Feb  4 15:14:57 2013
From: henry.jen at oracle.com (Henry Jen)
Date: Mon, 04 Feb 2013 15:14:57 -0800
Subject: experience trying out lambda-8-b74
In-Reply-To: <CACuKZqHAYZ8U4NYU-e_=sy-0AtVXkzCmFHPBt-p-3FLDkRdo=g@mail.gmail.com>
References: <51053A5A.24195.AAF1F6@v.a.ammodytes.googlemail.com>
	<5105762A.8040002@oracle.com>
	<E61425C5-6E01-49C3-B149-151D2A3B81F3@wonderly.org>
	<CC95D104-28E2-42DE-B1A4-DD02BAD67F38@oracle.com>
	<510633DE.9060001@gmail.com> <510C5348.8020107@oracle.com>
	<510CA649.5050000@gmail.com>
	<CACuKZqEWJKBxUh0=j8krP47f=UOZcTB6dREJuhdj0H7L4pYfTg@mail.gmail.com>
	<98694886-DF0D-4C82-B3FC-EFDBF4F6A796@oracle.com>
	<CACuKZqHAYZ8U4NYU-e_=sy-0AtVXkzCmFHPBt-p-3FLDkRdo=g@mail.gmail.com>
Message-ID: <511040F1.2040001@oracle.com>

On 02/04/2013 03:03 PM, Zhong Yu wrote:
> On Mon, Feb 4, 2013 at 12:01 PM, Henry Jen <henry.jen at oracle.com> wrote:
>> If we don't extend any exception handling or need type information, we don't really need a wrapper as Throwable already has hasCause() method.
> 
> UncheckedIOException is a wrapper for IOException. I'm arguing that
> JDK should instead have a generic wrapper for Exception, so that all
> libraries have a uniformed way of smuggling/unsmuggling checked
> exceptions. Otherwise there are serious interoperability obstacles.
> 

I don't disagree, just saying RuntimeException is that wrapper class if
nothing more than cause is needed.

> It appears that the lambda team does not take checked exceptions
> seriously. It might be the right attitude academically, but real world
> Java applications are full of checked exceptions. Without a guideline
> from Java czars, lots of hacky ways will be invented when they try to
> integrate with Stream.
> 

I think opposite. I am guessing it's just that there is not an obvious
good way to deal with checked exception yet. At least that's what I see
in stream API. Thus it is still open.

Cheers,
Henry


From zhong.j.yu at gmail.com  Mon Feb  4 15:22:15 2013
From: zhong.j.yu at gmail.com (Zhong Yu)
Date: Mon, 4 Feb 2013 17:22:15 -0600
Subject: CloseableStream exceptions [was: Re: experience trying out
	lambda-8-b74]
In-Reply-To: <510FFB4A.1040501@gmail.com>
References: <51053A5A.24195.AAF1F6@v.a.ammodytes.googlemail.com>
	<5105762A.8040002@oracle.com>
	<E61425C5-6E01-49C3-B149-151D2A3B81F3@wonderly.org>
	<CC95D104-28E2-42DE-B1A4-DD02BAD67F38@oracle.com>
	<510633DE.9060001@gmail.com> <510C5348.8020107@oracle.com>
	<510CA649.5050000@gmail.com>
	<153DE41A-FCF6-47C0-B5F5-8B7D49D4CBDE@oracle.com>
	<510FFB4A.1040501@gmail.com>
Message-ID: <CACuKZqHZV9BfCY=q3deQKKYwE_UmBxS5EGStZgJteqKCVFda_A@mail.gmail.com>

On Mon, Feb 4, 2013 at 12:17 PM, Peter Levart <peter.levart at gmail.com> wrote:
>
> On 02/04/2013 06:55 PM, Henry Jen wrote:
>> My preference is mainly build on top of that factory methods throws IOException. I still believe factory methods should throw IOException instead of wrap it up into UncheckedIOException so to enforce a try thus better reminds using try-with-resource to ensure close. So that is not going to change for those APIs in nio.
>
> Why do you think throwing IOException would remind of using
> try-with-resource? The construct was designed for general AutoCloseable
> resources regardless of types of checked or unchecked exceptions thrown
> by creating, consuming or closing them...
>
>> However, that should probably be a separate concern from what is in CloseableStream, not all factory method need to throw IOException although it is more likely.
>
> It's unfortunate that java.nio.file.Files already contains other static
> methods, not connected with streams API, that throw checked IOException.
> So I understand that mixing-in methods that instead throw
> UncheckedIOException is confusing at first for the user. So maybe, there
> should be a separate class for those methods to distinguish them from
> "normal" nio.file methods?

Say we cannot do

    Consumer<Path> deleteAction = Files::delete;

since Files.delete() throws IOException. But a generic wrapper would do

    Consumer<Path> deleteAction = wrap(Files::delete);

    static <T> Consumer<T> wrap(ConsumerEx<T>){..}
    // ... and wrap() for other functional interfaces

Zhong Yu

>> The wrapping cost and suppress of exceptions(as in JDK 7[1]) is not really a big deal, it's great if we don't need them, but if we have to, we have to.
>>
>> On change the definition of CloseableStream, which would be preferred?
>>
>> CloseableStream<T> close();
>
> you meant:
>
> void close();
>
> Could be, yes, but why not be more "documentary" and declaring it
> throwing the unchecked exception, like:
>
> void close() throws UncheckedIOException;
>
>> or
>>
>> CloseableStream<T> close() throws Exception;
>
> Definitely not, since then, user is forced to catch or re-throw the
> generic checked Exception.
>
> Regards, Peter
>
>> Also should we change it into AutoCloseableStream() as it is really just an AutoCloseable? Personally I like CloseableStream as I assume AutoCloseable is just a remedy for Closeable.
>>
>> Cheers,
>> Henry
>>
>> [1] http://docs.oracle.com/javase/tutorial/essential/exceptions/tryResourceClose.html#suppressed-exceptions
>>
>>
>> On Feb 1, 2013, at 9:38 PM, Peter Levart <peter.levart at gmail.com> wrote:
>>
>>> On 02/02/2013 12:44 AM, Henry Jen wrote:
>>>> On 01/28/2013 12:16 AM, Peter Levart wrote:
>>>>
>>>>> On 01/28/2013 12:06 AM, Henry Jen wrote:
>>>>>
>>>>>> http://cr.openjdk.java.net/~henryjen/lambda/nio.5/webrev/
>>>>>>
>>>>>>
>>>>>>
>>>>> Hi Henry,
>>>>>
>>>>> I can imagine that many times a single block of code would be
>>>>> responsible for constructing a Path stream (possibly enclosed into a
>>>>> try-with-resources construct) and consuming it's results, so having to
>>>>> deal with the duality of IOException/UncheckedIOException is a
>>>>> complication for a user in my opinion. Wouldn't it be better also for
>>>>> the stream-factory methods to throw UncheckedIOException and for
>>>>> CloseableStream.close() to also throw UncheckedIOException (that means,
>>>>> only inheriting from AutoCloseable, not Closeable and co-variant-ly
>>>>> redefining the throws declaration):
>>>>>
>>>>> public interface CloseableStream<T> extends Stream<T>, AutoCloseable {
>>>>>      @Override
>>>>>      void close() throws UncheckedIOException;
>>>>> }
>>>>>
>>>>>
>>>> Hi Peter,
>>> Hi Henry,
>>>
>>>> Sorry for the late reply, I want to let the idea sink a little bit.
>>>>
>>>> After couple days, I am slightly prefer not to change it because,
>>>>
>>>> 1) The CloseableStream-factory method throws IOException reminds use of
>>>> try-with-resource better than an unchecked exception.
>>>>
>>> The CloseableStream method return type name also reminds of that ;-)
>>>
>>>> 2) As factory methods throwing IOException, developer is dealing with
>>>> duality already.
>>>>
>>> He is dealing with duality already *if* the factory methods are throwing IOException. If they are throwing UncheckedIOException, he is not dealing with duality.
>>>
>>>> 3) If the close method throws UncheckedIOException as the stream
>>>> handling, the suppressing of exceptions will be more confusing. Should
>>>> developer look into cause IOException or the UncheckedIOException?
>>>>
>>> Do you think a programmer might want to handle different subtypes of IOException differently? If that is the case, the javadoc should document all the possible situations. And what about different     subtypes of IOException wrapped by UncheckedIOException while consuming the stream? If the programmer already bothers to unwrap the unchecked exception to do the cause analisys, then this same handler would be good also for dealing with exceptions thrown in factory methods and CloseableStream.close(). The streams API is a higher-lever wrapper over the java.nio.file.DirectoryStream API and it is already wrapping the lower-level IOException with UncheckedIOException when consuming the CloseableStream. I think it should do it consistently. By doing it consistently, it simplifies correct exception handling logic in *all* situations.
>>>
>>>> 4) When the implementation is a Closeable, the wrapping of IOException
>>>> into an UncheckedIOException doesn't do any good except overhead in case
>>>> developer want to deal with it. On the other hand, a IOException handler
>>>> is probably in place as the factory methods throws IOException.
>>>>
>>> It is probably in place *if* the factory methods are throwing IOException. If they are throwing UncheckedIOException, then such handler is not there. The question is whether the UncheckedIOException handler is in place too. If I look in one of your tests:
>>>
>>>   148         public void testWalk() {
>>>   149                 try(CloseableStream<Path> s = Files.walk(testFolder)) {
>>>   150                         Object[] actual = s.sorted(Comparators.naturalOrder()).toArray();
>>>   151                         assertEquals(actual, all);
>>>   152                 } catch (IOException ioe) {
>>>   153                         fail("Unexpected IOException");
>>>   154                 }
>>>   155         }
>>>
>>>
>>> You haven't bothered to handle the UncheckedIOException (because the test would fail anyway if it was thrown). But I'm afraid that average programmer will walk away from similar codes with false sense of confidence that he handled all exceptional situations when he put the checked exception handler in place. I think that being consistent and throwing UncheckedIOException everywhere would     actually have greater probability for average programmer to not miss the handling of exceptional situations while consuming the stream - at least all exceptional situations would be handled or not handled equally.
>>>
>>> Regards, Peter
>>>
>>>> Does it make sense?
>>>>
>>>> I updated the webrev to have some test coverage for exception handling,
>>>> it's painful as always, but the duality is not what bothers me.
>>>>
>>>>
>>>> http://cr.openjdk.java.net/~henryjen/lambda/nio.6/webrev/
>>>>
>>>>
>>>> Cheers,
>>>> Henry
>>>>
>>>>
>
>

From zhong.j.yu at gmail.com  Mon Feb  4 15:24:28 2013
From: zhong.j.yu at gmail.com (Zhong Yu)
Date: Mon, 4 Feb 2013 17:24:28 -0600
Subject: CloseableStream exceptions [was: Re: experience trying out
	lambda-8-b74]
In-Reply-To: <51101B8A.5070505@gmail.com>
References: <51053A5A.24195.AAF1F6@v.a.ammodytes.googlemail.com>
	<5105762A.8040002@oracle.com>
	<E61425C5-6E01-49C3-B149-151D2A3B81F3@wonderly.org>
	<CC95D104-28E2-42DE-B1A4-DD02BAD67F38@oracle.com>
	<510633DE.9060001@gmail.com> <510C5348.8020107@oracle.com>
	<510CA649.5050000@gmail.com>
	<153DE41A-FCF6-47C0-B5F5-8B7D49D4CBDE@oracle.com>
	<510FFB4A.1040501@gmail.com>
	<D5FA5DFE-70FD-4C81-92D7-B4AAA8122446@oracle.com>
	<511005D7.9070501@gmail.com> <51100FEF.2090300@oracle.com>
	<51101B8A.5070505@gmail.com>
Message-ID: <CACuKZqFifg4_vraXpYvK4yRiYD16p57LUJiPu94HpP96Dt0LRQ@mail.gmail.com>

I agree %100 with Peter - unchecked wrapper exception here would be
more consistent and more convenient.

On Mon, Feb 4, 2013 at 2:35 PM, Peter Levart <peter.levart at gmail.com> wrote:
>
> On 02/04/2013 08:45 PM, Alan Bateman wrote:
>> On 04/02/2013 19:02, Peter Levart wrote:
>>>
>>> I think that every new API or feature takes some time to get used. When
>>> try-with-resources was introduced, nobody was thinking to use it just
>>> because of java.io methods throwing checked IOException. I aggree that
>>> now many programmers mentally associate IOException with
>>> try-with-resources and you want to piggy-back on that mental perception.
>>> You might get quick response at the beginning, but for the price of
>>> long-term ugliness of exception handling when using the API. I expect
>>> people would be asking for another factory method throwing
>>> UncheckedIOException in JDK9 after the API is going to get used
>>> massively...
>>>
>> All methods to open or access files, directories, etc. in this API
>> throw the checked IOException. It would be inconsistent to introduce a
>> parallel set of methods at this point, particularly because this API
>> also defines also many specific IOExceptions for cases where recovery
>> might be required for specific cases.
>
> Are the specific IOExceptions only relevant when creating the stream or
> also when consuming and/or closing it?
>
>>
>> So I think if CloseableStream is used in a try-with-resources that
>> opens the file or directory then it will probably lead to usages such as:
>>
>> try (...) {
>>      :
>> } catch (UncheckedIOException e) {
>>     throw e.getCause();
>> }
>
> The above example would stay exactly the same if the factory method
> threw UncheckedIOException.
>
>>
>> or
>>
>> try (...) {
>>     :
>> } catch (IOException ioe) {
>>     throw new UncheckedIOException(ioe);
>> }
>>
>
> The catch and manual wrap in UncheckedIOException in above example would
> not be needed if the factory method threw UncheckedIOException already...
>
>> depending on whether you want to propagate a checked or unchecked
>> exception. One of two examples in the javadoc might help.
>>
>> -Alan.
>>
>
> Regards, Peter
>
>

From howard.lovatt at gmail.com  Mon Feb  4 15:27:24 2013
From: howard.lovatt at gmail.com (Howard Lovatt)
Date: Tue, 5 Feb 2013 10:27:24 +1100
Subject: Grouping stream elements by their position - how to handle tail
	of stream ?
In-Reply-To: <510DE1B1.3030904@oracle.com>
References: <CAB_DFWaUEv8jAo6Ok58d7EthS6gZubSvr8rbXxGoEVLVAmjeug@mail.gmail.com>
	<510D8B41.6040109@oracle.com>
	<CAKJVG8Z3R4ax-ySsuGEPhptjjx6_frnhak3HksfqsHnnT3ZEMA@mail.gmail.com>
	<510DE1B1.3030904@oracle.com>
Message-ID: <CACR_FB6Y0zDETfxDc_UB2_z7j+ytm8eCF7HaZQveMDrFWFng0A@mail.gmail.com>

Hi Brian,

This is an enquiry related to grouping or parsing an input stream, but
a little different.

In numerical programs common operations are matrix: transpose, other
reshaping, or 'sparsification'. I have seen these implemented on
parallel architectures as an indirection of indexes, something like:

matrix[indexTransformation[index]]

Has thought been given to such a capability for the stream library?

Thanks,

 -- Howard.

Sent from my iPad

On 03/02/2013, at 3:04 PM, Brian Goetz <brian.goetz at oracle.com> wrote:

> Look at the implementations in Collectors for a hint.  Obviously we owe
> some significant documentation, which unfortunately lags the code by too
> much.  But a Collector is basically a mutable foldl/inject; you provide
> a way to create a new mutable container, a way to add a single element
> to it, and a way to combine two mutable containers.  The framework
> decomposes the source, creates a bunch of little containers at the
> leaves, and them goes up the tree, merging.
>
> Dumping the elements into an ArrayList maps easily to Collector:
>
>  collect(ArrayList::new, ArrayList::add, ArrayList::addAll)
>
> This parallelizes, as we can collect each chunk into a list, and then
> merge the lists up the tree with addAll.
>
> The "how do I get the last element" problem goes away, since your data
> structure can explicitly maintain the state of whether the chunk ends
> with a balanced pair or an extra.
>
> But, you need to calculate BOTH p0 and p1 for each chunk (except maybe
> the left-spine chunks), because you don't know until the end which will
> have the right parity.
>
> On 2/2/2013 7:49 PM, Lattie wrote:
>>> Now, that said, here's a parallel algorithm you can implement with
>>> collect(), though you may find the performance overhead too offensive.
>>> Basically, for each chunk of the input t1..tn, you compute two possible
>>> answers:
>>>
>>> p0 = (t1,t2), (t3,t4), ..., maybe leftover tn
>>
>> This is what I want... the ability to compute p0.  I was not able to
>> figure out how to use collect() to do this though, and so I went down
>> the road of explode() with a stateful lambda... can someone point me
>> to any tutorial or info on how to properly use collect()?
>>
>> TIA
>>
>>
>> On Sat, Feb 2, 2013 at 1:55 PM, Brian Goetz <brian.goetz at oracle.com> wrote:
>>> The glass is half full, or half empty, depending on your disposition.
>>>
>>> While its trivial to write a version of explode() that remembers the
>>> last element seen, and either emits nothing or a pair (you have a little
>>> fixup at the end to deal with, but that's easy too, just annoying), once
>>> you start writing such stateful lambdas, you are tying yourself to
>>> sequential execution in a very error-prone way.  The type system can't
>>> record this assumption, so when someone helpfully later adds a
>>> .parallel() somewhere, your code will silently turn to sewage.  So,
>>> don't ever do this.
>>>
>>> Too see why the obvious algorithm is sequential only, consider a
>>> decomposition of a data source with a spliterator.  In most cases, we
>>> don't necessarily know the even-ness or odd-ness of the sum of sizes of
>>> all prior splits.  Which means we don't know whether the first element
>>> of any given split is the left element of some pair or the right element
>>> of some pair.
>>>
>>> You might say: I don't care about parallelism, I only care about
>>> sequential.
>>>
>>> To which we'd respond: fine, but we're not really interested in
>>> distorting the model to encourage that.  The Stream API is designed
>>> around operations that can be equally well performed in serial or
>>> parallel.  There are no "serial only" operations supported, and that was
>>> an explicit design choice.  Passing state-holding lambdas to these
>>> methods is likely to be a spec violation.  We can't enforce it, any more
>>> than we can enforce the lack of data races, but bear in mind that if you
>>> do this, you're writing broken code, and asking for trouble.
>>>
>>> Now, that said, here's a parallel algorithm you can implement with
>>> collect(), though you may find the performance overhead too offensive.
>>> Basically, for each chunk of the input t1..tn, you compute two possible
>>> answers:
>>>
>>> p0 = (t1,t2), t3,t4), ..., maybe leftover tn
>>> p1 = t1, (t2, t3), (t4, t5), ... maybe leftover tn
>>>
>>> then you combine these pairs chunks in the mostly obvious way (observe
>>> that p0 has trailing element = !(p1 has trailing element)).  Then when
>>> you get to the top of the tree, you take the one that doesn't have an
>>> orphaned initial element, and toss the other.  Basically you're doing 2x
>>> work for each input element, but it parallelizes fairly cleanly.
>>>
>>> Such an algorithm is ideally suited to collect(), because a Collector is
>>> a representation of a catamorphism, which the above transformation is.
>>> Because the combination logic is associative, it parallelizes cleanly
>>> without needing any nasty stateful lambdas.
>>>
>>> When we expose the Op APIs and you can write your own
>>> decomposition-aware operations, you'll have another option: write a
>>> StatefulOp.  This won't be an option for 8, but once we do, its easy
>>> enough, and it will let you avoid the extra overhead by creating a
>>> custom operation.
>>>
>>> So, to sum up:
>>>   - If you're looking for a one-liner, you'll be disappointed;
>>>   - If you convince yourself "I would never need parallelism here" and
>>> write the obvious unsafe stateful lambda, please write your manager a
>>> letter first explaining how your incompetence is putting the reliability
>>> of his product in jeopardy;
>>>   - If you're willing to write the above collector, you'll likely be
>>> happy enough with the result.
>>>
>>>
>>> On 2/2/2013 3:35 PM, Boaz Nahum wrote:
>>>> Hi.
>>>>
>>>> I looking in Stream interface for a way to convert a stream of
>>>>     {  t1, t2, .. Tn }
>>>> to
>>>>     { {t1,t2}, ... {Tn-1, Tn} }
>>>> or
>>>>     { {t1,t2}, ... {Tn, null}}
>>>>
>>>> Lets assume {t1, t2} are aggeraget by Pair<T,T>
>>>>
>>>>
>>>>
>>>> So I tried to use explode:
>>>>
>>>> *        Stream<Integer> si = Arrays.asList(1, 2, 3, 4, 5).stream();
>>>>
>>>>          Stream<Pair<Integer, Integer>> spi = si.sequential().explode(new
>>>> BiConsumer<Stream.Downstream<Pair<Integer, Integer>>, Integer>() {
>>>>
>>>>              Integer firstValue;
>>>>
>>>>              @Override
>>>>              public void accept(Stream.Downstream<Pair<Integer, Integer>>
>>>> pairDownstream, Integer v) {
>>>>
>>>>                  if (firstValue == null) {
>>>>                      firstValue = v;
>>>>                  } else {
>>>>
>>>>                      pairDownstream.send(new Pair<>(firstValue, v));
>>>>                      firstValue = null;
>>>>
>>>>                  }
>>>>              }
>>>>
>>>>          });
>>>> *
>>>>
>>>> But I didn't find a way to add the tail of input stream {.., 5} to the new
>>>> stream { ,,, {5, null}}.
>>>>
>>>> Of-course this only simplified example of more general problem I have.
>>>>
>>>> Thanks
>>>> Boaz
>

From zhong.j.yu at gmail.com  Mon Feb  4 15:32:55 2013
From: zhong.j.yu at gmail.com (Zhong Yu)
Date: Mon, 4 Feb 2013 17:32:55 -0600
Subject: experience trying out lambda-8-b74
In-Reply-To: <51104023.4020502@oracle.com>
References: <51053A5A.24195.AAF1F6@v.a.ammodytes.googlemail.com>
	<5105762A.8040002@oracle.com>
	<E61425C5-6E01-49C3-B149-151D2A3B81F3@wonderly.org>
	<CC95D104-28E2-42DE-B1A4-DD02BAD67F38@oracle.com>
	<510633DE.9060001@gmail.com> <510C5348.8020107@oracle.com>
	<510CA649.5050000@gmail.com>
	<CACuKZqEWJKBxUh0=j8krP47f=UOZcTB6dREJuhdj0H7L4pYfTg@mail.gmail.com>
	<98694886-DF0D-4C82-B3FC-EFDBF4F6A796@oracle.com>
	<CACuKZqHAYZ8U4NYU-e_=sy-0AtVXkzCmFHPBt-p-3FLDkRdo=g@mail.gmail.com>
	<51104023.4020502@oracle.com>
Message-ID: <CACuKZqGmZdnB37cYiv-KnvZ-zabsvW-j54bGgXmuV-HCy35KPQ@mail.gmail.com>

On Mon, Feb 4, 2013 at 5:11 PM, Brian Goetz <brian.goetz at oracle.com> wrote:
> I knew it wouldn't be long before this turned into yet another
> barely-laundered proposal to try yet again to get us to deprecate checked
> exceptions.  I get it, you find checked exceptions frustrating.  Sometimes I
> do too.  But we still believe a world without them would be worse, and we're
> not interested in pushing people towards that.

I neither hate or love checked exceptions; they are here, they are
widely used by Java applications, so we must deal with it.

> There are places in the Java libraries -- mostly from the very early days --
> where the use of checked exceptions turned out to be a mistake.  (An obvious
> example is close() throwing IOException -- what could a user possibly do to
> recover from that?)  The workarounds we're doing here are to mitigate the

(digression - failure of close() is real and is important; at least
app can tell the user that the file can't be saved, instead of
assuming otherwise)

> worst mistakes of the past, not to rewrite history.  And we're satisfied
> that this small workaround handles 90% of the 2% of cases where exceptions
> turn out to intrude in lambda libraries.  So we've made the decision to stop
> there for now, and not because it didn't occur to us to go farther.

I don't quite get it - are you saying that IOException is the 90% of
the checked exceptions, so UncheckedIOException is good enough,
instead of a more generic wrapper for arbitrary Exception.

I don't think IOException is that special. And there's nothing harmful
to make a more general UncheckedAnyException, instead of just
UncheckedIOException.

>
>
> On 2/4/2013 6:03 PM, Zhong Yu wrote:
>>
>> On Mon, Feb 4, 2013 at 12:01 PM, Henry Jen <henry.jen at oracle.com> wrote:
>>>
>>> If we don't extend any exception handling or need type information, we
>>> don't really need a wrapper as Throwable already has hasCause() method.
>>
>>
>> UncheckedIOException is a wrapper for IOException. I'm arguing that
>> JDK should instead have a generic wrapper for Exception, so that all
>> libraries have a uniformed way of smuggling/unsmuggling checked
>> exceptions. Otherwise there are serious interoperability obstacles.
>>
>> It appears that the lambda team does not take checked exceptions
>> seriously. It might be the right attitude academically, but real world
>> Java applications are full of checked exceptions. Without a guideline
>> from Java czars, lots of hacky ways will be invented when they try to
>> integrate with Stream.
>>
>> Zhong Yu
>>
>>> I recall there were discussion of transparent exception handling, which
>>> is still an open topic I believe.
>>>
>>> Cheers,
>>> Henry
>>>
>>> On Feb 2, 2013, at 9:06 AM, Zhong Yu <zhong.j.yu at gmail.com> wrote:
>>>
>>>> Also, what about other checked exceptions? If I make a stream based on
>>>> JDBC ResultSet, how do I handle SQLExceptions? Should I create a
>>>> proprietary UncheckedSQLException? Should multiple libraries each
>>>> provide their own version of UncheckedXxxExceptions for every
>>>> XxxException? We'll be in this hell for some years to come before the
>>>> language gives a better device.
>>>>
>>>> Meanwhile, why not provide a generic wrapper exception whose explicit
>>>> and sole purpose is to wrap another checked exception? I know the idea
>>>> is trivia, but why not?
>>>>
>>>> The Wrapper can provide convenience methods like
>>>>
>>>>     class Wrapper extends RuntimeException
>>>>
>>>>         // if cause is E1, throw cause; otherwise throw wrapper.
>>>>         <E1> RuntimeException rethrow(Class<E1> type) throws E1, Wrapper
>>>>
>>>> so we can
>>>>
>>>>     catch(Wrapper w)
>>>>         throw w.rethrow(IOException.class, SQLException.class);
>>>>
>>>> or to handle causes inline
>>>>
>>>>     catch(Wrapper w)
>>>>         w.on(IOException.class, e->{ handle e; })
>>>>            .on(SQLException.class, e->{ handle e; });
>>>>
>>>>     <Ei, Eo> Wrapper on(Class<Ei> type, ExceptionHandler<Ei,Eo>) throws
>>>> Eo;
>>>>
>>>>     interface ExceptionHandler<Ei,Eo>
>>>>         void handle(Ei e) throws Eo;
>>>>
>>>> obviously not elegant, but at least give us something of the sort that
>>>> can alleviate the pain in the short term.
>>>>
>>>> Zhong Yu
>>>>
>>>>
>>>> On Fri, Feb 1, 2013 at 11:38 PM, Peter Levart <peter.levart at gmail.com>
>>>> wrote:
>>>>>
>>>>>
>>>>> On 02/02/2013 12:44 AM, Henry Jen wrote:
>>>>>>
>>>>>> On 01/28/2013 12:16 AM, Peter Levart wrote:
>>>>>>>
>>>>>>> On 01/28/2013 12:06 AM, Henry Jen wrote:
>>>>>>>>
>>>>>>>> http://cr.openjdk.java.net/~henryjen/lambda/nio.5/webrev/
>>>>>>>>
>>>>>>> Hi Henry,
>>>>>>>
>>>>>>> I can imagine that many times a single block of code would be
>>>>>>> responsible for constructing a Path stream (possibly enclosed into a
>>>>>>> try-with-resources construct) and consuming it's results, so having
>>>>>>> to
>>>>>>> deal with the duality of IOException/UncheckedIOException is a
>>>>>>> complication for a user in my opinion. Wouldn't it be better also for
>>>>>>> the stream-factory methods to throw UncheckedIOException and for
>>>>>>> CloseableStream.close() to also throw UncheckedIOException (that
>>>>>>> means,
>>>>>>> only inheriting from AutoCloseable, not Closeable and co-variant-ly
>>>>>>> redefining the throws declaration):
>>>>>>>
>>>>>>> public interface CloseableStream<T> extends Stream<T>, AutoCloseable
>>>>>>> {
>>>>>>>      @Override
>>>>>>>      void close() throws UncheckedIOException;
>>>>>>> }
>>>>>>>
>>>>>> Hi Peter,
>>>>>
>>>>>
>>>>> Hi Henry,
>>>>>
>>>>>> Sorry for the late reply, I want to let the idea sink a little bit.
>>>>>>
>>>>>> After couple days, I am slightly prefer not to change it because,
>>>>>>
>>>>>> 1) The CloseableStream-factory method throws IOException reminds use
>>>>>> of
>>>>>> try-with-resource better than an unchecked exception.
>>>>>
>>>>>
>>>>> The *Closeable*Stream method return type name also reminds of that ;-)
>>>>>
>>>>>> 2) As factory methods throwing IOException, developer is dealing with
>>>>>> duality already.
>>>>>
>>>>>
>>>>> He is dealing with duality already *if* the factory methods are
>>>>> throwing
>>>>> IOException. If they are throwing UncheckedIOException, he is not
>>>>> dealing with duality.
>>>>>
>>>>>> 3) If the close method throws UncheckedIOException as the stream
>>>>>> handling, the suppressing of exceptions will be more confusing. Should
>>>>>> developer look into cause IOException or the UncheckedIOException?
>>>>>
>>>>>
>>>>> Do you think a programmer might want to handle different subtypes of
>>>>> IOException differently? If that is the case, the javadoc should
>>>>> document all the possible situations. And what about different subtypes
>>>>> of IOException wrapped by UncheckedIOException while consuming the
>>>>> stream? If the programmer already bothers to unwrap the unchecked
>>>>> exception to do the cause analisys, then this same handler would be
>>>>> good
>>>>> also for dealing with exceptions thrown in factory methods and
>>>>> CloseableStream.close(). The streams API is a higher-lever wrapper over
>>>>> the java.nio.file.DirectoryStream API and it is already wrapping the
>>>>> lower-level IOException with UncheckedIOException when consuming the
>>>>> CloseableStream. I think it should do it consistently. By doing it
>>>>> consistently, it simplifies correct exception handling logic in *all*
>>>>> situations.
>>>>>
>>>>>> 4) When the implementation is a Closeable, the wrapping of IOException
>>>>>> into an UncheckedIOException doesn't do any good except overhead in
>>>>>> case
>>>>>> developer want to deal with it. On the other hand, a IOException
>>>>>> handler
>>>>>> is probably in place as the factory methods throws IOException.
>>>>>
>>>>>
>>>>> It is probably in place *if* the factory methods are throwing
>>>>> IOException. If they are throwing UncheckedIOException, then such
>>>>> handler is not there. The question is whether the UncheckedIOException
>>>>> handler is in place too. If I look in one of your tests:
>>>>>
>>>>>   148         public void testWalk() {
>>>>>   149                 try(CloseableStream<Path> s =
>>>>> Files.walk(testFolder)) {
>>>>>   150                         Object[] actual =
>>>>> s.sorted(Comparators.naturalOrder()).toArray();
>>>>>   151                         assertEquals(actual, all);
>>>>>   152                 } catch (IOException ioe) {
>>>>>   153                         fail("Unexpected IOException");
>>>>>   154                 }
>>>>>   155         }
>>>>>
>>>>>
>>>>> You haven't bothered to handle the UncheckedIOException (because the
>>>>> test would fail anyway if it was thrown). But I'm afraid that average
>>>>> programmer will walk away from similar codes with false sense of
>>>>> confidence that he handled all exceptional situations when he put the
>>>>> checked exception handler in place. I think that being consistent and
>>>>> throwing UncheckedIOException everywhere would actually have greater
>>>>> probability for average programmer to not miss the handling of
>>>>> exceptional situations while consuming the stream - at least all
>>>>> exceptional situations would be handled or not handled equally.
>>>>>
>>>>> Regards, Peter
>>>>>
>>>>>> Does it make sense?
>>>>>>
>>>>>> I updated the webrev to have some test coverage for exception
>>>>>> handling,
>>>>>> it's painful as always, but the duality is not what bothers me.
>>>>>>
>>>>>> http://cr.openjdk.java.net/~henryjen/lambda/nio.6/webrev/
>>>>>>
>>>>>> Cheers,
>>>>>> Henry
>>>>>>
>>>>>
>>>>>
>>>
>>
>

From brian.goetz at oracle.com  Mon Feb  4 15:47:43 2013
From: brian.goetz at oracle.com (Brian Goetz)
Date: Mon, 04 Feb 2013 18:47:43 -0500
Subject: Grouping stream elements by their position - how to handle tail
	of stream ?
In-Reply-To: <CACR_FB6Y0zDETfxDc_UB2_z7j+ytm8eCF7HaZQveMDrFWFng0A@mail.gmail.com>
References: <CAB_DFWaUEv8jAo6Ok58d7EthS6gZubSvr8rbXxGoEVLVAmjeug@mail.gmail.com>
	<510D8B41.6040109@oracle.com>
	<CAKJVG8Z3R4ax-ySsuGEPhptjjx6_frnhak3HksfqsHnnT3ZEMA@mail.gmail.com>
	<510DE1B1.3030904@oracle.com>
	<CACR_FB6Y0zDETfxDc_UB2_z7j+ytm8eCF7HaZQveMDrFWFng0A@mail.gmail.com>
Message-ID: <5110489F.7000309@oracle.com>

Could you clarify what you are suggesting?

On 2/4/2013 6:27 PM, Howard Lovatt wrote:
> Hi Brian,
>
> This is an enquiry related to grouping or parsing an input stream, but
> a little different.
>
> In numerical programs common operations are matrix: transpose, other
> reshaping, or 'sparsification'. I have seen these implemented on
> parallel architectures as an indirection of indexes, something like:
>
> matrix[indexTransformation[index]]
>
> Has thought been given to such a capability for the stream library?
>
> Thanks,
>
>   -- Howard.
>
> Sent from my iPad
>
> On 03/02/2013, at 3:04 PM, Brian Goetz <brian.goetz at oracle.com> wrote:
>
>> Look at the implementations in Collectors for a hint.  Obviously we owe
>> some significant documentation, which unfortunately lags the code by too
>> much.  But a Collector is basically a mutable foldl/inject; you provide
>> a way to create a new mutable container, a way to add a single element
>> to it, and a way to combine two mutable containers.  The framework
>> decomposes the source, creates a bunch of little containers at the
>> leaves, and them goes up the tree, merging.
>>
>> Dumping the elements into an ArrayList maps easily to Collector:
>>
>>   collect(ArrayList::new, ArrayList::add, ArrayList::addAll)
>>
>> This parallelizes, as we can collect each chunk into a list, and then
>> merge the lists up the tree with addAll.
>>
>> The "how do I get the last element" problem goes away, since your data
>> structure can explicitly maintain the state of whether the chunk ends
>> with a balanced pair or an extra.
>>
>> But, you need to calculate BOTH p0 and p1 for each chunk (except maybe
>> the left-spine chunks), because you don't know until the end which will
>> have the right parity.
>>
>> On 2/2/2013 7:49 PM, Lattie wrote:
>>>> Now, that said, here's a parallel algorithm you can implement with
>>>> collect(), though you may find the performance overhead too offensive.
>>>> Basically, for each chunk of the input t1..tn, you compute two possible
>>>> answers:
>>>>
>>>> p0 = (t1,t2), (t3,t4), ..., maybe leftover tn
>>>
>>> This is what I want... the ability to compute p0.  I was not able to
>>> figure out how to use collect() to do this though, and so I went down
>>> the road of explode() with a stateful lambda... can someone point me
>>> to any tutorial or info on how to properly use collect()?
>>>
>>> TIA
>>>
>>>
>>> On Sat, Feb 2, 2013 at 1:55 PM, Brian Goetz <brian.goetz at oracle.com> wrote:
>>>> The glass is half full, or half empty, depending on your disposition.
>>>>
>>>> While its trivial to write a version of explode() that remembers the
>>>> last element seen, and either emits nothing or a pair (you have a little
>>>> fixup at the end to deal with, but that's easy too, just annoying), once
>>>> you start writing such stateful lambdas, you are tying yourself to
>>>> sequential execution in a very error-prone way.  The type system can't
>>>> record this assumption, so when someone helpfully later adds a
>>>> .parallel() somewhere, your code will silently turn to sewage.  So,
>>>> don't ever do this.
>>>>
>>>> Too see why the obvious algorithm is sequential only, consider a
>>>> decomposition of a data source with a spliterator.  In most cases, we
>>>> don't necessarily know the even-ness or odd-ness of the sum of sizes of
>>>> all prior splits.  Which means we don't know whether the first element
>>>> of any given split is the left element of some pair or the right element
>>>> of some pair.
>>>>
>>>> You might say: I don't care about parallelism, I only care about
>>>> sequential.
>>>>
>>>> To which we'd respond: fine, but we're not really interested in
>>>> distorting the model to encourage that.  The Stream API is designed
>>>> around operations that can be equally well performed in serial or
>>>> parallel.  There are no "serial only" operations supported, and that was
>>>> an explicit design choice.  Passing state-holding lambdas to these
>>>> methods is likely to be a spec violation.  We can't enforce it, any more
>>>> than we can enforce the lack of data races, but bear in mind that if you
>>>> do this, you're writing broken code, and asking for trouble.
>>>>
>>>> Now, that said, here's a parallel algorithm you can implement with
>>>> collect(), though you may find the performance overhead too offensive.
>>>> Basically, for each chunk of the input t1..tn, you compute two possible
>>>> answers:
>>>>
>>>> p0 = (t1,t2), t3,t4), ..., maybe leftover tn
>>>> p1 = t1, (t2, t3), (t4, t5), ... maybe leftover tn
>>>>
>>>> then you combine these pairs chunks in the mostly obvious way (observe
>>>> that p0 has trailing element = !(p1 has trailing element)).  Then when
>>>> you get to the top of the tree, you take the one that doesn't have an
>>>> orphaned initial element, and toss the other.  Basically you're doing 2x
>>>> work for each input element, but it parallelizes fairly cleanly.
>>>>
>>>> Such an algorithm is ideally suited to collect(), because a Collector is
>>>> a representation of a catamorphism, which the above transformation is.
>>>> Because the combination logic is associative, it parallelizes cleanly
>>>> without needing any nasty stateful lambdas.
>>>>
>>>> When we expose the Op APIs and you can write your own
>>>> decomposition-aware operations, you'll have another option: write a
>>>> StatefulOp.  This won't be an option for 8, but once we do, its easy
>>>> enough, and it will let you avoid the extra overhead by creating a
>>>> custom operation.
>>>>
>>>> So, to sum up:
>>>>    - If you're looking for a one-liner, you'll be disappointed;
>>>>    - If you convince yourself "I would never need parallelism here" and
>>>> write the obvious unsafe stateful lambda, please write your manager a
>>>> letter first explaining how your incompetence is putting the reliability
>>>> of his product in jeopardy;
>>>>    - If you're willing to write the above collector, you'll likely be
>>>> happy enough with the result.
>>>>
>>>>
>>>> On 2/2/2013 3:35 PM, Boaz Nahum wrote:
>>>>> Hi.
>>>>>
>>>>> I looking in Stream interface for a way to convert a stream of
>>>>>      {  t1, t2, .. Tn }
>>>>> to
>>>>>      { {t1,t2}, ... {Tn-1, Tn} }
>>>>> or
>>>>>      { {t1,t2}, ... {Tn, null}}
>>>>>
>>>>> Lets assume {t1, t2} are aggeraget by Pair<T,T>
>>>>>
>>>>>
>>>>>
>>>>> So I tried to use explode:
>>>>>
>>>>> *        Stream<Integer> si = Arrays.asList(1, 2, 3, 4, 5).stream();
>>>>>
>>>>>           Stream<Pair<Integer, Integer>> spi = si.sequential().explode(new
>>>>> BiConsumer<Stream.Downstream<Pair<Integer, Integer>>, Integer>() {
>>>>>
>>>>>               Integer firstValue;
>>>>>
>>>>>               @Override
>>>>>               public void accept(Stream.Downstream<Pair<Integer, Integer>>
>>>>> pairDownstream, Integer v) {
>>>>>
>>>>>                   if (firstValue == null) {
>>>>>                       firstValue = v;
>>>>>                   } else {
>>>>>
>>>>>                       pairDownstream.send(new Pair<>(firstValue, v));
>>>>>                       firstValue = null;
>>>>>
>>>>>                   }
>>>>>               }
>>>>>
>>>>>           });
>>>>> *
>>>>>
>>>>> But I didn't find a way to add the tail of input stream {.., 5} to the new
>>>>> stream { ,,, {5, null}}.
>>>>>
>>>>> Of-course this only simplified example of more general problem I have.
>>>>>
>>>>> Thanks
>>>>> Boaz
>>

From zhong.j.yu at gmail.com  Mon Feb  4 16:16:11 2013
From: zhong.j.yu at gmail.com (Zhong Yu)
Date: Mon, 4 Feb 2013 18:16:11 -0600
Subject: UncheckedIOException and suppressed exception
Message-ID: <CACuKZqHn-bSHz0Lc-S0mCC+Zi-8G=BVpnY0P5c_P-DO6_DcdVA@mail.gmail.com>

Suppose we have an UncheckedIOException e1, which wraps an IOException
e2. Then another exception e3 occurs that we want suppress. Should we
do e1.addSuppressed(e3), or e2.addSuppressed(e3)? That's pretty
confusing.

If UncheckedIOException is not a *real* exception, maybe we should
make it a "control" exception. It should have no stacktrace; it should
have no cause (the wrapped exception is not a cause); it should not
contain suppressed exceptions.

Maybe it can override addSuppressed() to forward suppressed exceptions
to the wrapped exception. (Though addSuppressed() is `final`, there's
no problem to leave a backdoor for another JDK class)

Zhong Yu

From david.holmes at oracle.com  Mon Feb  4 17:56:55 2013
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 05 Feb 2013 11:56:55 +1000
Subject: UncheckedIOException and suppressed exception
In-Reply-To: <CACuKZqHn-bSHz0Lc-S0mCC+Zi-8G=BVpnY0P5c_P-DO6_DcdVA@mail.gmail.com>
References: <CACuKZqHn-bSHz0Lc-S0mCC+Zi-8G=BVpnY0P5c_P-DO6_DcdVA@mail.gmail.com>
Message-ID: <511066E7.1010506@oracle.com>

On 5/02/2013 10:16 AM, Zhong Yu wrote:
> Suppose we have an UncheckedIOException e1, which wraps an IOException
> e2. Then another exception e3 occurs that we want suppress. Should we
> do e1.addSuppressed(e3), or e2.addSuppressed(e3)? That's pretty
> confusing.

I don't see any confusion except for your numbering. You have one 
exception that is inflight, e1, and then e3 occurs. If you want to 
continue throwing e1 then e1 is suppressing e3.

> If UncheckedIOException is not a *real* exception, maybe we should
> make it a "control" exception. It should have no stacktrace; it should
> have no cause (the wrapped exception is not a cause); it should not
> contain suppressed exceptions.

Any wrapping exception should have the original exception as its cause. 
Why should this wrapper be any different? Throwable even defines it so:

" Throwing a "wrapped exception" (i.e., an exception containing a cause) 
..."

Suppression is about control over which exception is propagating - so 
again why should this be a special case?

> Maybe it can override addSuppressed() to forward suppressed exceptions
> to the wrapped exception. (Though addSuppressed() is `final`, there's
> no problem to leave a backdoor for another JDK class)

I think your exception processing model is slightly confused here.

David
-----

> Zhong Yu
>

From joe.darcy at oracle.com  Mon Feb  4 18:11:21 2013
From: joe.darcy at oracle.com (Joseph Darcy)
Date: Mon, 04 Feb 2013 18:11:21 -0800
Subject: UncheckedIOException and suppressed exception
In-Reply-To: <511066E7.1010506@oracle.com>
References: <CACuKZqHn-bSHz0Lc-S0mCC+Zi-8G=BVpnY0P5c_P-DO6_DcdVA@mail.gmail.com>
	<511066E7.1010506@oracle.com>
Message-ID: <51106A49.7010002@oracle.com>

On 2/4/2013 5:56 PM, David Holmes wrote:
> On 5/02/2013 10:16 AM, Zhong Yu wrote:
>> Suppose we have an UncheckedIOException e1, which wraps an IOException
>> e2. Then another exception e3 occurs that we want suppress. Should we
>> do e1.addSuppressed(e3), or e2.addSuppressed(e3)? That's pretty
>> confusing.
> I don't see any confusion except for your numbering. You have one
> exception that is inflight, e1, and then e3 occurs. If you want to
> continue throwing e1 then e1 is suppressing e3.
>
>> If UncheckedIOException is not a *real* exception, maybe we should
>> make it a "control" exception. It should have no stacktrace; it should
>> have no cause (the wrapped exception is not a cause); it should not
>> contain suppressed exceptions.
> Any wrapping exception should have the original exception as its cause.
> Why should this wrapper be any different? Throwable even defines it so:
>
> " Throwing a "wrapped exception" (i.e., an exception containing a cause)
> ..."
>
> Suppression is about control over which exception is propagating - so
> again why should this be a special case?
>
>> Maybe it can override addSuppressed() to forward suppressed exceptions
>> to the wrapped exception. (Though addSuppressed() is `final`, there's
>> no problem to leave a backdoor for another JDK class)
> I think your exception processing model is slightly confused here.
>

As an addendum, the Throwable.addSuppressed method discusses the 
difference between exception suppression and caused-by linkage:

>
> Note that when one exception causes another exception, the first 
> exception is usually caught and then the second exception is thrown in 
> response. In other words, there is a causal connection between the two 
> exceptions. In contrast, there are situations where two independent 
> exceptions can be thrown in sibling code blocks, in particular in the 
> try block of a try-with-resources statement and the compiler-generated 
> finally block which closes the resource. In these situations, only one 
> of the thrown exceptions can be propagated. In the try-with-resources 
> statement, when there are two such exceptions, the exception 
> originating from the try block is propagated and the exception from 
> the finally block is added to the list of exceptions suppressed by the 
> exception from the try block. As an exception unwinds the stack, it 
> can accumulate multiple suppressed exceptions.
>
> An exception may have suppressed exceptions while also being caused by 
> another exception. Whether or not an exception has a cause is 
> semantically known at the time of its creation, unlike whether or not 
> an exception will suppress other exceptions which is typically only 
> determined after an exception is thrown. 
http://docs.oracle.com/javase/7/docs/api/java/lang/Throwable.html#addSuppressed(java.lang.Throwable)

-Joe

From ricky.clarkson at gmail.com  Mon Feb  4 18:45:48 2013
From: ricky.clarkson at gmail.com (Ricky Clarkson)
Date: Mon, 4 Feb 2013 23:45:48 -0300
Subject: experience trying out lambda-8-b74
In-Reply-To: <CACuKZqGmZdnB37cYiv-KnvZ-zabsvW-j54bGgXmuV-HCy35KPQ@mail.gmail.com>
References: <51053A5A.24195.AAF1F6@v.a.ammodytes.googlemail.com>
	<5105762A.8040002@oracle.com>
	<E61425C5-6E01-49C3-B149-151D2A3B81F3@wonderly.org>
	<CC95D104-28E2-42DE-B1A4-DD02BAD67F38@oracle.com>
	<510633DE.9060001@gmail.com>
	<510C5348.8020107@oracle.com> <510CA649.5050000@gmail.com>
	<CACuKZqEWJKBxUh0=j8krP47f=UOZcTB6dREJuhdj0H7L4pYfTg@mail.gmail.com>
	<98694886-DF0D-4C82-B3FC-EFDBF4F6A796@oracle.com>
	<CACuKZqHAYZ8U4NYU-e_=sy-0AtVXkzCmFHPBt-p-3FLDkRdo=g@mail.gmail.com>
	<51104023.4020502@oracle.com>
	<CACuKZqGmZdnB37cYiv-KnvZ-zabsvW-j54bGgXmuV-HCy35KPQ@mail.gmail.com>
Message-ID: <CAOBi2H8XMC3bomAMtxGL5fe6Y_iezpYnASv5iB9MmVqDkM=uAQ@mail.gmail.com>

"And there's nothing harmful
to make a more general UncheckedAnyException, instead of just
UncheckedIOException."

What's wrong with RuntimeException for that?


On Mon, Feb 4, 2013 at 8:32 PM, Zhong Yu <zhong.j.yu at gmail.com> wrote:

> On Mon, Feb 4, 2013 at 5:11 PM, Brian Goetz <brian.goetz at oracle.com>
> wrote:
> > I knew it wouldn't be long before this turned into yet another
> > barely-laundered proposal to try yet again to get us to deprecate checked
> > exceptions.  I get it, you find checked exceptions frustrating.
>  Sometimes I
> > do too.  But we still believe a world without them would be worse, and
> we're
> > not interested in pushing people towards that.
>
> I neither hate or love checked exceptions; they are here, they are
> widely used by Java applications, so we must deal with it.
>
> > There are places in the Java libraries -- mostly from the very early
> days --
> > where the use of checked exceptions turned out to be a mistake.  (An
> obvious
> > example is close() throwing IOException -- what could a user possibly do
> to
> > recover from that?)  The workarounds we're doing here are to mitigate the
>
> (digression - failure of close() is real and is important; at least
> app can tell the user that the file can't be saved, instead of
> assuming otherwise)
>
> > worst mistakes of the past, not to rewrite history.  And we're satisfied
> > that this small workaround handles 90% of the 2% of cases where
> exceptions
> > turn out to intrude in lambda libraries.  So we've made the decision to
> stop
> > there for now, and not because it didn't occur to us to go farther.
>
> I don't quite get it - are you saying that IOException is the 90% of
> the checked exceptions, so UncheckedIOException is good enough,
> instead of a more generic wrapper for arbitrary Exception.
>
> I don't think IOException is that special. And there's nothing harmful
> to make a more general UncheckedAnyException, instead of just
> UncheckedIOException.
>
> >
> >
> > On 2/4/2013 6:03 PM, Zhong Yu wrote:
> >>
> >> On Mon, Feb 4, 2013 at 12:01 PM, Henry Jen <henry.jen at oracle.com>
> wrote:
> >>>
> >>> If we don't extend any exception handling or need type information, we
> >>> don't really need a wrapper as Throwable already has hasCause() method.
> >>
> >>
> >> UncheckedIOException is a wrapper for IOException. I'm arguing that
> >> JDK should instead have a generic wrapper for Exception, so that all
> >> libraries have a uniformed way of smuggling/unsmuggling checked
> >> exceptions. Otherwise there are serious interoperability obstacles.
> >>
> >> It appears that the lambda team does not take checked exceptions
> >> seriously. It might be the right attitude academically, but real world
> >> Java applications are full of checked exceptions. Without a guideline
> >> from Java czars, lots of hacky ways will be invented when they try to
> >> integrate with Stream.
> >>
> >> Zhong Yu
> >>
> >>> I recall there were discussion of transparent exception handling, which
> >>> is still an open topic I believe.
> >>>
> >>> Cheers,
> >>> Henry
> >>>
> >>> On Feb 2, 2013, at 9:06 AM, Zhong Yu <zhong.j.yu at gmail.com> wrote:
> >>>
> >>>> Also, what about other checked exceptions? If I make a stream based on
> >>>> JDBC ResultSet, how do I handle SQLExceptions? Should I create a
> >>>> proprietary UncheckedSQLException? Should multiple libraries each
> >>>> provide their own version of UncheckedXxxExceptions for every
> >>>> XxxException? We'll be in this hell for some years to come before the
> >>>> language gives a better device.
> >>>>
> >>>> Meanwhile, why not provide a generic wrapper exception whose explicit
> >>>> and sole purpose is to wrap another checked exception? I know the idea
> >>>> is trivia, but why not?
> >>>>
> >>>> The Wrapper can provide convenience methods like
> >>>>
> >>>>     class Wrapper extends RuntimeException
> >>>>
> >>>>         // if cause is E1, throw cause; otherwise throw wrapper.
> >>>>         <E1> RuntimeException rethrow(Class<E1> type) throws E1,
> Wrapper
> >>>>
> >>>> so we can
> >>>>
> >>>>     catch(Wrapper w)
> >>>>         throw w.rethrow(IOException.class, SQLException.class);
> >>>>
> >>>> or to handle causes inline
> >>>>
> >>>>     catch(Wrapper w)
> >>>>         w.on(IOException.class, e->{ handle e; })
> >>>>            .on(SQLException.class, e->{ handle e; });
> >>>>
> >>>>     <Ei, Eo> Wrapper on(Class<Ei> type, ExceptionHandler<Ei,Eo>)
> throws
> >>>> Eo;
> >>>>
> >>>>     interface ExceptionHandler<Ei,Eo>
> >>>>         void handle(Ei e) throws Eo;
> >>>>
> >>>> obviously not elegant, but at least give us something of the sort that
> >>>> can alleviate the pain in the short term.
> >>>>
> >>>> Zhong Yu
> >>>>
> >>>>
> >>>> On Fri, Feb 1, 2013 at 11:38 PM, Peter Levart <peter.levart at gmail.com
> >
> >>>> wrote:
> >>>>>
> >>>>>
> >>>>> On 02/02/2013 12:44 AM, Henry Jen wrote:
> >>>>>>
> >>>>>> On 01/28/2013 12:16 AM, Peter Levart wrote:
> >>>>>>>
> >>>>>>> On 01/28/2013 12:06 AM, Henry Jen wrote:
> >>>>>>>>
> >>>>>>>> http://cr.openjdk.java.net/~henryjen/lambda/nio.5/webrev/
> >>>>>>>>
> >>>>>>> Hi Henry,
> >>>>>>>
> >>>>>>> I can imagine that many times a single block of code would be
> >>>>>>> responsible for constructing a Path stream (possibly enclosed into
> a
> >>>>>>> try-with-resources construct) and consuming it's results, so having
> >>>>>>> to
> >>>>>>> deal with the duality of IOException/UncheckedIOException is a
> >>>>>>> complication for a user in my opinion. Wouldn't it be better also
> for
> >>>>>>> the stream-factory methods to throw UncheckedIOException and for
> >>>>>>> CloseableStream.close() to also throw UncheckedIOException (that
> >>>>>>> means,
> >>>>>>> only inheriting from AutoCloseable, not Closeable and co-variant-ly
> >>>>>>> redefining the throws declaration):
> >>>>>>>
> >>>>>>> public interface CloseableStream<T> extends Stream<T>,
> AutoCloseable
> >>>>>>> {
> >>>>>>>      @Override
> >>>>>>>      void close() throws UncheckedIOException;
> >>>>>>> }
> >>>>>>>
> >>>>>> Hi Peter,
> >>>>>
> >>>>>
> >>>>> Hi Henry,
> >>>>>
> >>>>>> Sorry for the late reply, I want to let the idea sink a little bit.
> >>>>>>
> >>>>>> After couple days, I am slightly prefer not to change it because,
> >>>>>>
> >>>>>> 1) The CloseableStream-factory method throws IOException reminds use
> >>>>>> of
> >>>>>> try-with-resource better than an unchecked exception.
> >>>>>
> >>>>>
> >>>>> The *Closeable*Stream method return type name also reminds of that
> ;-)
> >>>>>
> >>>>>> 2) As factory methods throwing IOException, developer is dealing
> with
> >>>>>> duality already.
> >>>>>
> >>>>>
> >>>>> He is dealing with duality already *if* the factory methods are
> >>>>> throwing
> >>>>> IOException. If they are throwing UncheckedIOException, he is not
> >>>>> dealing with duality.
> >>>>>
> >>>>>> 3) If the close method throws UncheckedIOException as the stream
> >>>>>> handling, the suppressing of exceptions will be more confusing.
> Should
> >>>>>> developer look into cause IOException or the UncheckedIOException?
> >>>>>
> >>>>>
> >>>>> Do you think a programmer might want to handle different subtypes of
> >>>>> IOException differently? If that is the case, the javadoc should
> >>>>> document all the possible situations. And what about different
> subtypes
> >>>>> of IOException wrapped by UncheckedIOException while consuming the
> >>>>> stream? If the programmer already bothers to unwrap the unchecked
> >>>>> exception to do the cause analisys, then this same handler would be
> >>>>> good
> >>>>> also for dealing with exceptions thrown in factory methods and
> >>>>> CloseableStream.close(). The streams API is a higher-lever wrapper
> over
> >>>>> the java.nio.file.DirectoryStream API and it is already wrapping the
> >>>>> lower-level IOException with UncheckedIOException when consuming the
> >>>>> CloseableStream. I think it should do it consistently. By doing it
> >>>>> consistently, it simplifies correct exception handling logic in *all*
> >>>>> situations.
> >>>>>
> >>>>>> 4) When the implementation is a Closeable, the wrapping of
> IOException
> >>>>>> into an UncheckedIOException doesn't do any good except overhead in
> >>>>>> case
> >>>>>> developer want to deal with it. On the other hand, a IOException
> >>>>>> handler
> >>>>>> is probably in place as the factory methods throws IOException.
> >>>>>
> >>>>>
> >>>>> It is probably in place *if* the factory methods are throwing
> >>>>> IOException. If they are throwing UncheckedIOException, then such
> >>>>> handler is not there. The question is whether the
> UncheckedIOException
> >>>>> handler is in place too. If I look in one of your tests:
> >>>>>
> >>>>>   148         public void testWalk() {
> >>>>>   149                 try(CloseableStream<Path> s =
> >>>>> Files.walk(testFolder)) {
> >>>>>   150                         Object[] actual =
> >>>>> s.sorted(Comparators.naturalOrder()).toArray();
> >>>>>   151                         assertEquals(actual, all);
> >>>>>   152                 } catch (IOException ioe) {
> >>>>>   153                         fail("Unexpected IOException");
> >>>>>   154                 }
> >>>>>   155         }
> >>>>>
> >>>>>
> >>>>> You haven't bothered to handle the UncheckedIOException (because the
> >>>>> test would fail anyway if it was thrown). But I'm afraid that average
> >>>>> programmer will walk away from similar codes with false sense of
> >>>>> confidence that he handled all exceptional situations when he put the
> >>>>> checked exception handler in place. I think that being consistent and
> >>>>> throwing UncheckedIOException everywhere would actually have greater
> >>>>> probability for average programmer to not miss the handling of
> >>>>> exceptional situations while consuming the stream - at least all
> >>>>> exceptional situations would be handled or not handled equally.
> >>>>>
> >>>>> Regards, Peter
> >>>>>
> >>>>>> Does it make sense?
> >>>>>>
> >>>>>> I updated the webrev to have some test coverage for exception
> >>>>>> handling,
> >>>>>> it's painful as always, but the duality is not what bothers me.
> >>>>>>
> >>>>>> http://cr.openjdk.java.net/~henryjen/lambda/nio.6/webrev/
> >>>>>>
> >>>>>> Cheers,
> >>>>>> Henry
> >>>>>>
> >>>>>
> >>>>>
> >>>
> >>
> >
>
>

From brian.goetz at oracle.com  Mon Feb  4 19:17:12 2013
From: brian.goetz at oracle.com (brian.goetz at oracle.com)
Date: Tue, 05 Feb 2013 03:17:12 +0000
Subject: hg: lambda/lambda/jdk: 2 new changesets
Message-ID: <20130205031736.142FC47812@hg.openjdk.java.net>

Changeset: dcf80058e235
Author:    briangoetz
Date:      2013-02-04 19:16 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/dcf80058e235

Initial checkin of serialization testing agent

+ test-ng/agent/Readme
+ test-ng/agent/conf/agent.props
+ test-ng/agent/conf/serialize.list
+ test-ng/agent/make/build.xml
+ test-ng/agent/src/com/oracle/lambda/Agent.java
+ test-ng/agent/src/com/oracle/lambda/Main.java
+ test-ng/agent/src/com/oracle/lambda/SerializationInjector.java
+ test-ng/agent/src/com/oracle/lambda/TestLambdaSerialization.java
! test-ng/build.xml

Changeset: 0a7186b58729
Author:    briangoetz
Date:      2013-02-04 22:17 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/0a7186b58729

Merge



From brian.goetz at oracle.com  Mon Feb  4 19:19:05 2013
From: brian.goetz at oracle.com (brian.goetz at oracle.com)
Date: Tue, 05 Feb 2013 03:19:05 +0000
Subject: hg: lambda/lambda/jdk: Fix serialization injector to also update
	signature; add single-file-mangle mode
Message-ID: <20130205031917.C436047813@hg.openjdk.java.net>

Changeset: 1e86e61afa18
Author:    briangoetz
Date:      2013-02-04 22:19 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/1e86e61afa18

Fix serialization injector to also update signature; add single-file-mangle mode

! test-ng/agent/src/com/oracle/lambda/Agent.java
! test-ng/agent/src/com/oracle/lambda/Main.java
! test-ng/agent/src/com/oracle/lambda/SerializationInjector.java
! test-ng/build.xml


From zhong.j.yu at gmail.com  Mon Feb  4 19:39:09 2013
From: zhong.j.yu at gmail.com (Zhong Yu)
Date: Mon, 4 Feb 2013 21:39:09 -0600
Subject: UncheckedIOException and suppressed exception
In-Reply-To: <511066E7.1010506@oracle.com>
References: <CACuKZqHn-bSHz0Lc-S0mCC+Zi-8G=BVpnY0P5c_P-DO6_DcdVA@mail.gmail.com>
	<511066E7.1010506@oracle.com>
Message-ID: <CACuKZqGCyfDWnxxZ45uDBGsBUAfVKn7KPWBNX5AXypMU3MPvYg@mail.gmail.com>

On Mon, Feb 4, 2013 at 7:56 PM, David Holmes <david.holmes at oracle.com> wrote:
> On 5/02/2013 10:16 AM, Zhong Yu wrote:
>>
>> Suppose we have an UncheckedIOException e1, which wraps an IOException
>> e2. Then another exception e3 occurs that we want suppress. Should we
>> do e1.addSuppressed(e3), or e2.addSuppressed(e3)? That's pretty
>> confusing.
>
>
> I don't see any confusion except for your numbering. You have one exception
> that is inflight, e1, and then e3 occurs. If you want to continue throwing
> e1 then e1 is suppressing e3.

The catcher of an UncheckedIOException e1 would see it simply as a
container, so it'll extract the contained IOException e2, and deal
with e2 afterwards, for example, rethrow e2. If e3 was added as e1's
suppressed exception, e3 is then lost.

This "containing" relation is different from the usual "causal"
relation between an exception and its cause. Let's be honest, the only
purpose of an UncheckedIOException is to smuggle an IOException as
unchecked; UncheckedIOException itself has no "business meaning".

>> If UncheckedIOException is not a *real* exception, maybe we should
>> make it a "control" exception. It should have no stacktrace; it should
>> have no cause (the wrapped exception is not a cause); it should not
>> contain suppressed exceptions.
>
>
> Any wrapping exception should have the original exception as its cause. Why
> should this wrapper be any different? Throwable even defines it so:
>
> " Throwing a "wrapped exception" (i.e., an exception containing a cause)
> ..."
>
> Suppression is about control over which exception is propagating - so again
> why should this be a special case?
>
>
>> Maybe it can override addSuppressed() to forward suppressed exceptions
>> to the wrapped exception. (Though addSuppressed() is `final`, there's
>> no problem to leave a backdoor for another JDK class)
>
>
> I think your exception processing model is slightly confused here.
>
> David
> -----
>
>> Zhong Yu
>>
>

From david.holmes at oracle.com  Mon Feb  4 19:47:25 2013
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 05 Feb 2013 13:47:25 +1000
Subject: UncheckedIOException and suppressed exception
In-Reply-To: <CACuKZqGCyfDWnxxZ45uDBGsBUAfVKn7KPWBNX5AXypMU3MPvYg@mail.gmail.com>
References: <CACuKZqHn-bSHz0Lc-S0mCC+Zi-8G=BVpnY0P5c_P-DO6_DcdVA@mail.gmail.com>
	<511066E7.1010506@oracle.com>
	<CACuKZqGCyfDWnxxZ45uDBGsBUAfVKn7KPWBNX5AXypMU3MPvYg@mail.gmail.com>
Message-ID: <511080CD.2020409@oracle.com>

On 5/02/2013 1:39 PM, Zhong Yu wrote:
> On Mon, Feb 4, 2013 at 7:56 PM, David Holmes<david.holmes at oracle.com>  wrote:
>> On 5/02/2013 10:16 AM, Zhong Yu wrote:
>>>
>>> Suppose we have an UncheckedIOException e1, which wraps an IOException
>>> e2. Then another exception e3 occurs that we want suppress. Should we
>>> do e1.addSuppressed(e3), or e2.addSuppressed(e3)? That's pretty
>>> confusing.
>>
>>
>> I don't see any confusion except for your numbering. You have one exception
>> that is inflight, e1, and then e3 occurs. If you want to continue throwing
>> e1 then e1 is suppressing e3.
>
> The catcher of an UncheckedIOException e1 would see it simply as a
> container, so it'll extract the contained IOException e2, and deal
> with e2 afterwards, for example, rethrow e2. If e3 was added as e1's
> suppressed exception, e3 is then lost.

Then the catch is showing their ignorance of suppressed exceptions. BUt 
this is not specific to this situation. Anytime you catch an exception 
with a cause and a suppression list you have to decide what it is you 
want to do with it.

> This "containing" relation is different from the usual "causal"
> relation between an exception and its cause. Let's be honest, the only
> purpose of an UncheckedIOException is to smuggle an IOException as
> unchecked; UncheckedIOException itself has no "business meaning".

Again read the Throwable javadoc that Joe pointed out top you. This 
"conversion" situation is one of the primary uses for setting a cause:

"A second reason that a throwable may have a cause is that the method 
that throws it must conform to a general-purpose interface that does not 
permit the method to throw the cause directly. For example, suppose a 
persistent collection conforms to the Collection interface, and that its 
persistence is implemented atop java.io. Suppose the internals of the 
add method can throw an IOException. The implementation can communicate 
the details of the IOException to its caller while conforming to the 
Collection interface by wrapping the IOException in an appropriate 
unchecked exception. (The specification for the persistent collection 
should indicate that it is capable of throwing such exceptions.) "

David
-----

>>> If UncheckedIOException is not a *real* exception, maybe we should
>>> make it a "control" exception. It should have no stacktrace; it should
>>> have no cause (the wrapped exception is not a cause); it should not
>>> contain suppressed exceptions.
>>
>>
>> Any wrapping exception should have the original exception as its cause. Why
>> should this wrapper be any different? Throwable even defines it so:
>>
>> " Throwing a "wrapped exception" (i.e., an exception containing a cause)
>> ..."
>>
>> Suppression is about control over which exception is propagating - so again
>> why should this be a special case?
>>
>>
>>> Maybe it can override addSuppressed() to forward suppressed exceptions
>>> to the wrapped exception. (Though addSuppressed() is `final`, there's
>>> no problem to leave a backdoor for another JDK class)
>>
>>
>> I think your exception processing model is slightly confused here.
>>
>> David
>> -----
>>
>>> Zhong Yu
>>>
>>
>

From zhong.j.yu at gmail.com  Mon Feb  4 19:48:55 2013
From: zhong.j.yu at gmail.com (Zhong Yu)
Date: Mon, 4 Feb 2013 21:48:55 -0600
Subject: experience trying out lambda-8-b74
In-Reply-To: <CAOBi2H8XMC3bomAMtxGL5fe6Y_iezpYnASv5iB9MmVqDkM=uAQ@mail.gmail.com>
References: <51053A5A.24195.AAF1F6@v.a.ammodytes.googlemail.com>
	<5105762A.8040002@oracle.com>
	<E61425C5-6E01-49C3-B149-151D2A3B81F3@wonderly.org>
	<CC95D104-28E2-42DE-B1A4-DD02BAD67F38@oracle.com>
	<510633DE.9060001@gmail.com> <510C5348.8020107@oracle.com>
	<510CA649.5050000@gmail.com>
	<CACuKZqEWJKBxUh0=j8krP47f=UOZcTB6dREJuhdj0H7L4pYfTg@mail.gmail.com>
	<98694886-DF0D-4C82-B3FC-EFDBF4F6A796@oracle.com>
	<CACuKZqHAYZ8U4NYU-e_=sy-0AtVXkzCmFHPBt-p-3FLDkRdo=g@mail.gmail.com>
	<51104023.4020502@oracle.com>
	<CACuKZqGmZdnB37cYiv-KnvZ-zabsvW-j54bGgXmuV-HCy35KPQ@mail.gmail.com>
	<CAOBi2H8XMC3bomAMtxGL5fe6Y_iezpYnASv5iB9MmVqDkM=uAQ@mail.gmail.com>
Message-ID: <CACuKZqFYwxgwA7Kjihq+uejgmULSyFJVNh_Yi4V3vURrQFwbCA@mail.gmail.com>

On Mon, Feb 4, 2013 at 8:45 PM, Ricky Clarkson <ricky.clarkson at gmail.com> wrote:
> "And there's nothing harmful
> to make a more general UncheckedAnyException, instead of just
> UncheckedIOException."
>
> What's wrong with RuntimeException for that?

We cannot unambiguously determine whether a RuntimeException e1 is a
simple wrapper of an checked exception e2 for the purpose of smuggling
e2 across a method that doesn't throw checked exception, or an
ordinary exception that represents an erroneous condition by itself.

We had a similar discussion on Doug Lea's CompletableFuture.
Originally it used RuntimeException to smuggle checked exceptions. It
was then changed to use a specific "CompletionException" for the
purpose. My fear is that each library will invent its own wrapper
exception for the purpose. Why not have an official wrapper?

> On Mon, Feb 4, 2013 at 8:32 PM, Zhong Yu <zhong.j.yu at gmail.com> wrote:
>>
>> On Mon, Feb 4, 2013 at 5:11 PM, Brian Goetz <brian.goetz at oracle.com>
>> wrote:
>> > I knew it wouldn't be long before this turned into yet another
>> > barely-laundered proposal to try yet again to get us to deprecate
>> > checked
>> > exceptions.  I get it, you find checked exceptions frustrating.
>> > Sometimes I
>> > do too.  But we still believe a world without them would be worse, and
>> > we're
>> > not interested in pushing people towards that.
>>
>> I neither hate or love checked exceptions; they are here, they are
>> widely used by Java applications, so we must deal with it.
>>
>> > There are places in the Java libraries -- mostly from the very early
>> > days --
>> > where the use of checked exceptions turned out to be a mistake.  (An
>> > obvious
>> > example is close() throwing IOException -- what could a user possibly do
>> > to
>> > recover from that?)  The workarounds we're doing here are to mitigate
>> > the
>>
>> (digression - failure of close() is real and is important; at least
>> app can tell the user that the file can't be saved, instead of
>> assuming otherwise)
>>
>> > worst mistakes of the past, not to rewrite history.  And we're satisfied
>> > that this small workaround handles 90% of the 2% of cases where
>> > exceptions
>> > turn out to intrude in lambda libraries.  So we've made the decision to
>> > stop
>> > there for now, and not because it didn't occur to us to go farther.
>>
>> I don't quite get it - are you saying that IOException is the 90% of
>> the checked exceptions, so UncheckedIOException is good enough,
>> instead of a more generic wrapper for arbitrary Exception.
>>
>> I don't think IOException is that special. And there's nothing harmful
>> to make a more general UncheckedAnyException, instead of just
>> UncheckedIOException.
>>
>> >
>> >
>> > On 2/4/2013 6:03 PM, Zhong Yu wrote:
>> >>
>> >> On Mon, Feb 4, 2013 at 12:01 PM, Henry Jen <henry.jen at oracle.com>
>> >> wrote:
>> >>>
>> >>> If we don't extend any exception handling or need type information, we
>> >>> don't really need a wrapper as Throwable already has hasCause()
>> >>> method.
>> >>
>> >>
>> >> UncheckedIOException is a wrapper for IOException. I'm arguing that
>> >> JDK should instead have a generic wrapper for Exception, so that all
>> >> libraries have a uniformed way of smuggling/unsmuggling checked
>> >> exceptions. Otherwise there are serious interoperability obstacles.
>> >>
>> >> It appears that the lambda team does not take checked exceptions
>> >> seriously. It might be the right attitude academically, but real world
>> >> Java applications are full of checked exceptions. Without a guideline
>> >> from Java czars, lots of hacky ways will be invented when they try to
>> >> integrate with Stream.
>> >>
>> >> Zhong Yu
>> >>
>> >>> I recall there were discussion of transparent exception handling,
>> >>> which
>> >>> is still an open topic I believe.
>> >>>
>> >>> Cheers,
>> >>> Henry
>> >>>
>> >>> On Feb 2, 2013, at 9:06 AM, Zhong Yu <zhong.j.yu at gmail.com> wrote:
>> >>>
>> >>>> Also, what about other checked exceptions? If I make a stream based
>> >>>> on
>> >>>> JDBC ResultSet, how do I handle SQLExceptions? Should I create a
>> >>>> proprietary UncheckedSQLException? Should multiple libraries each
>> >>>> provide their own version of UncheckedXxxExceptions for every
>> >>>> XxxException? We'll be in this hell for some years to come before the
>> >>>> language gives a better device.
>> >>>>
>> >>>> Meanwhile, why not provide a generic wrapper exception whose explicit
>> >>>> and sole purpose is to wrap another checked exception? I know the
>> >>>> idea
>> >>>> is trivia, but why not?
>> >>>>
>> >>>> The Wrapper can provide convenience methods like
>> >>>>
>> >>>>     class Wrapper extends RuntimeException
>> >>>>
>> >>>>         // if cause is E1, throw cause; otherwise throw wrapper.
>> >>>>         <E1> RuntimeException rethrow(Class<E1> type) throws E1,
>> >>>> Wrapper
>> >>>>
>> >>>> so we can
>> >>>>
>> >>>>     catch(Wrapper w)
>> >>>>         throw w.rethrow(IOException.class, SQLException.class);
>> >>>>
>> >>>> or to handle causes inline
>> >>>>
>> >>>>     catch(Wrapper w)
>> >>>>         w.on(IOException.class, e->{ handle e; })
>> >>>>            .on(SQLException.class, e->{ handle e; });
>> >>>>
>> >>>>     <Ei, Eo> Wrapper on(Class<Ei> type, ExceptionHandler<Ei,Eo>)
>> >>>> throws
>> >>>> Eo;
>> >>>>
>> >>>>     interface ExceptionHandler<Ei,Eo>
>> >>>>         void handle(Ei e) throws Eo;
>> >>>>
>> >>>> obviously not elegant, but at least give us something of the sort
>> >>>> that
>> >>>> can alleviate the pain in the short term.
>> >>>>
>> >>>> Zhong Yu
>> >>>>
>> >>>>
>> >>>> On Fri, Feb 1, 2013 at 11:38 PM, Peter Levart
>> >>>> <peter.levart at gmail.com>
>> >>>> wrote:
>> >>>>>
>> >>>>>
>> >>>>> On 02/02/2013 12:44 AM, Henry Jen wrote:
>> >>>>>>
>> >>>>>> On 01/28/2013 12:16 AM, Peter Levart wrote:
>> >>>>>>>
>> >>>>>>> On 01/28/2013 12:06 AM, Henry Jen wrote:
>> >>>>>>>>
>> >>>>>>>> http://cr.openjdk.java.net/~henryjen/lambda/nio.5/webrev/
>> >>>>>>>>
>> >>>>>>> Hi Henry,
>> >>>>>>>
>> >>>>>>> I can imagine that many times a single block of code would be
>> >>>>>>> responsible for constructing a Path stream (possibly enclosed into
>> >>>>>>> a
>> >>>>>>> try-with-resources construct) and consuming it's results, so
>> >>>>>>> having
>> >>>>>>> to
>> >>>>>>> deal with the duality of IOException/UncheckedIOException is a
>> >>>>>>> complication for a user in my opinion. Wouldn't it be better also
>> >>>>>>> for
>> >>>>>>> the stream-factory methods to throw UncheckedIOException and for
>> >>>>>>> CloseableStream.close() to also throw UncheckedIOException (that
>> >>>>>>> means,
>> >>>>>>> only inheriting from AutoCloseable, not Closeable and
>> >>>>>>> co-variant-ly
>> >>>>>>> redefining the throws declaration):
>> >>>>>>>
>> >>>>>>> public interface CloseableStream<T> extends Stream<T>,
>> >>>>>>> AutoCloseable
>> >>>>>>> {
>> >>>>>>>      @Override
>> >>>>>>>      void close() throws UncheckedIOException;
>> >>>>>>> }
>> >>>>>>>
>> >>>>>> Hi Peter,
>> >>>>>
>> >>>>>
>> >>>>> Hi Henry,
>> >>>>>
>> >>>>>> Sorry for the late reply, I want to let the idea sink a little bit.
>> >>>>>>
>> >>>>>> After couple days, I am slightly prefer not to change it because,
>> >>>>>>
>> >>>>>> 1) The CloseableStream-factory method throws IOException reminds
>> >>>>>> use
>> >>>>>> of
>> >>>>>> try-with-resource better than an unchecked exception.
>> >>>>>
>> >>>>>
>> >>>>> The *Closeable*Stream method return type name also reminds of that
>> >>>>> ;-)
>> >>>>>
>> >>>>>> 2) As factory methods throwing IOException, developer is dealing
>> >>>>>> with
>> >>>>>> duality already.
>> >>>>>
>> >>>>>
>> >>>>> He is dealing with duality already *if* the factory methods are
>> >>>>> throwing
>> >>>>> IOException. If they are throwing UncheckedIOException, he is not
>> >>>>> dealing with duality.
>> >>>>>
>> >>>>>> 3) If the close method throws UncheckedIOException as the stream
>> >>>>>> handling, the suppressing of exceptions will be more confusing.
>> >>>>>> Should
>> >>>>>> developer look into cause IOException or the UncheckedIOException?
>> >>>>>
>> >>>>>
>> >>>>> Do you think a programmer might want to handle different subtypes of
>> >>>>> IOException differently? If that is the case, the javadoc should
>> >>>>> document all the possible situations. And what about different
>> >>>>> subtypes
>> >>>>> of IOException wrapped by UncheckedIOException while consuming the
>> >>>>> stream? If the programmer already bothers to unwrap the unchecked
>> >>>>> exception to do the cause analisys, then this same handler would be
>> >>>>> good
>> >>>>> also for dealing with exceptions thrown in factory methods and
>> >>>>> CloseableStream.close(). The streams API is a higher-lever wrapper
>> >>>>> over
>> >>>>> the java.nio.file.DirectoryStream API and it is already wrapping the
>> >>>>> lower-level IOException with UncheckedIOException when consuming the
>> >>>>> CloseableStream. I think it should do it consistently. By doing it
>> >>>>> consistently, it simplifies correct exception handling logic in
>> >>>>> *all*
>> >>>>> situations.
>> >>>>>
>> >>>>>> 4) When the implementation is a Closeable, the wrapping of
>> >>>>>> IOException
>> >>>>>> into an UncheckedIOException doesn't do any good except overhead in
>> >>>>>> case
>> >>>>>> developer want to deal with it. On the other hand, a IOException
>> >>>>>> handler
>> >>>>>> is probably in place as the factory methods throws IOException.
>> >>>>>
>> >>>>>
>> >>>>> It is probably in place *if* the factory methods are throwing
>> >>>>> IOException. If they are throwing UncheckedIOException, then such
>> >>>>> handler is not there. The question is whether the
>> >>>>> UncheckedIOException
>> >>>>> handler is in place too. If I look in one of your tests:
>> >>>>>
>> >>>>>   148         public void testWalk() {
>> >>>>>   149                 try(CloseableStream<Path> s =
>> >>>>> Files.walk(testFolder)) {
>> >>>>>   150                         Object[] actual =
>> >>>>> s.sorted(Comparators.naturalOrder()).toArray();
>> >>>>>   151                         assertEquals(actual, all);
>> >>>>>   152                 } catch (IOException ioe) {
>> >>>>>   153                         fail("Unexpected IOException");
>> >>>>>   154                 }
>> >>>>>   155         }
>> >>>>>
>> >>>>>
>> >>>>> You haven't bothered to handle the UncheckedIOException (because the
>> >>>>> test would fail anyway if it was thrown). But I'm afraid that
>> >>>>> average
>> >>>>> programmer will walk away from similar codes with false sense of
>> >>>>> confidence that he handled all exceptional situations when he put
>> >>>>> the
>> >>>>> checked exception handler in place. I think that being consistent
>> >>>>> and
>> >>>>> throwing UncheckedIOException everywhere would actually have greater
>> >>>>> probability for average programmer to not miss the handling of
>> >>>>> exceptional situations while consuming the stream - at least all
>> >>>>> exceptional situations would be handled or not handled equally.
>> >>>>>
>> >>>>> Regards, Peter
>> >>>>>
>> >>>>>> Does it make sense?
>> >>>>>>
>> >>>>>> I updated the webrev to have some test coverage for exception
>> >>>>>> handling,
>> >>>>>> it's painful as always, but the duality is not what bothers me.
>> >>>>>>
>> >>>>>> http://cr.openjdk.java.net/~henryjen/lambda/nio.6/webrev/
>> >>>>>>
>> >>>>>> Cheers,
>> >>>>>> Henry
>> >>>>>>
>> >>>>>
>> >>>>>
>> >>>
>> >>
>> >
>>
>

From zhong.j.yu at gmail.com  Mon Feb  4 20:00:11 2013
From: zhong.j.yu at gmail.com (Zhong Yu)
Date: Mon, 4 Feb 2013 22:00:11 -0600
Subject: experience trying out lambda-8-b74
In-Reply-To: <CACuKZqFYwxgwA7Kjihq+uejgmULSyFJVNh_Yi4V3vURrQFwbCA@mail.gmail.com>
References: <51053A5A.24195.AAF1F6@v.a.ammodytes.googlemail.com>
	<5105762A.8040002@oracle.com>
	<E61425C5-6E01-49C3-B149-151D2A3B81F3@wonderly.org>
	<CC95D104-28E2-42DE-B1A4-DD02BAD67F38@oracle.com>
	<510633DE.9060001@gmail.com> <510C5348.8020107@oracle.com>
	<510CA649.5050000@gmail.com>
	<CACuKZqEWJKBxUh0=j8krP47f=UOZcTB6dREJuhdj0H7L4pYfTg@mail.gmail.com>
	<98694886-DF0D-4C82-B3FC-EFDBF4F6A796@oracle.com>
	<CACuKZqHAYZ8U4NYU-e_=sy-0AtVXkzCmFHPBt-p-3FLDkRdo=g@mail.gmail.com>
	<51104023.4020502@oracle.com>
	<CACuKZqGmZdnB37cYiv-KnvZ-zabsvW-j54bGgXmuV-HCy35KPQ@mail.gmail.com>
	<CAOBi2H8XMC3bomAMtxGL5fe6Y_iezpYnASv5iB9MmVqDkM=uAQ@mail.gmail.com>
	<CACuKZqFYwxgwA7Kjihq+uejgmULSyFJVNh_Yi4V3vURrQFwbCA@mail.gmail.com>
Message-ID: <CACuKZqFC=byqPRfDUAmegOuiYdGm6BCnnhjAgEjnuGd4X9xpXA@mail.gmail.com>

On Mon, Feb 4, 2013 at 9:48 PM, Zhong Yu <zhong.j.yu at gmail.com> wrote:
> On Mon, Feb 4, 2013 at 8:45 PM, Ricky Clarkson <ricky.clarkson at gmail.com> wrote:
>> "And there's nothing harmful
>> to make a more general UncheckedAnyException, instead of just
>> UncheckedIOException."
>>
>> What's wrong with RuntimeException for that?
>
> We cannot unambiguously determine whether a RuntimeException e1 is a
> simple wrapper of an checked exception e2 for the purpose of smuggling
> e2 across a method that doesn't throw checked exception, or an
> ordinary exception that represents an erroneous condition by itself.
>
> We had a similar discussion on Doug Lea's CompletableFuture.
> Originally it used RuntimeException to smuggle checked exceptions. It
> was then changed to use a specific "CompletionException" for the

see http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/java/util/concurrent/CompletableFuture.java?revision=1.36&view=markup

search "instanceof CompletionException"

Apparently CompletionException is just a shell; it's discarded
whenever not needed; it doesn't carry meaning of app error by itself.

> purpose. My fear is that each library will invent its own wrapper
> exception for the purpose. Why not have an official wrapper?
>
>> On Mon, Feb 4, 2013 at 8:32 PM, Zhong Yu <zhong.j.yu at gmail.com> wrote:
>>>
>>> On Mon, Feb 4, 2013 at 5:11 PM, Brian Goetz <brian.goetz at oracle.com>
>>> wrote:
>>> > I knew it wouldn't be long before this turned into yet another
>>> > barely-laundered proposal to try yet again to get us to deprecate
>>> > checked
>>> > exceptions.  I get it, you find checked exceptions frustrating.
>>> > Sometimes I
>>> > do too.  But we still believe a world without them would be worse, and
>>> > we're
>>> > not interested in pushing people towards that.
>>>
>>> I neither hate or love checked exceptions; they are here, they are
>>> widely used by Java applications, so we must deal with it.
>>>
>>> > There are places in the Java libraries -- mostly from the very early
>>> > days --
>>> > where the use of checked exceptions turned out to be a mistake.  (An
>>> > obvious
>>> > example is close() throwing IOException -- what could a user possibly do
>>> > to
>>> > recover from that?)  The workarounds we're doing here are to mitigate
>>> > the
>>>
>>> (digression - failure of close() is real and is important; at least
>>> app can tell the user that the file can't be saved, instead of
>>> assuming otherwise)
>>>
>>> > worst mistakes of the past, not to rewrite history.  And we're satisfied
>>> > that this small workaround handles 90% of the 2% of cases where
>>> > exceptions
>>> > turn out to intrude in lambda libraries.  So we've made the decision to
>>> > stop
>>> > there for now, and not because it didn't occur to us to go farther.
>>>
>>> I don't quite get it - are you saying that IOException is the 90% of
>>> the checked exceptions, so UncheckedIOException is good enough,
>>> instead of a more generic wrapper for arbitrary Exception.
>>>
>>> I don't think IOException is that special. And there's nothing harmful
>>> to make a more general UncheckedAnyException, instead of just
>>> UncheckedIOException.
>>>
>>> >
>>> >
>>> > On 2/4/2013 6:03 PM, Zhong Yu wrote:
>>> >>
>>> >> On Mon, Feb 4, 2013 at 12:01 PM, Henry Jen <henry.jen at oracle.com>
>>> >> wrote:
>>> >>>
>>> >>> If we don't extend any exception handling or need type information, we
>>> >>> don't really need a wrapper as Throwable already has hasCause()
>>> >>> method.
>>> >>
>>> >>
>>> >> UncheckedIOException is a wrapper for IOException. I'm arguing that
>>> >> JDK should instead have a generic wrapper for Exception, so that all
>>> >> libraries have a uniformed way of smuggling/unsmuggling checked
>>> >> exceptions. Otherwise there are serious interoperability obstacles.
>>> >>
>>> >> It appears that the lambda team does not take checked exceptions
>>> >> seriously. It might be the right attitude academically, but real world
>>> >> Java applications are full of checked exceptions. Without a guideline
>>> >> from Java czars, lots of hacky ways will be invented when they try to
>>> >> integrate with Stream.
>>> >>
>>> >> Zhong Yu
>>> >>
>>> >>> I recall there were discussion of transparent exception handling,
>>> >>> which
>>> >>> is still an open topic I believe.
>>> >>>
>>> >>> Cheers,
>>> >>> Henry
>>> >>>
>>> >>> On Feb 2, 2013, at 9:06 AM, Zhong Yu <zhong.j.yu at gmail.com> wrote:
>>> >>>
>>> >>>> Also, what about other checked exceptions? If I make a stream based
>>> >>>> on
>>> >>>> JDBC ResultSet, how do I handle SQLExceptions? Should I create a
>>> >>>> proprietary UncheckedSQLException? Should multiple libraries each
>>> >>>> provide their own version of UncheckedXxxExceptions for every
>>> >>>> XxxException? We'll be in this hell for some years to come before the
>>> >>>> language gives a better device.
>>> >>>>
>>> >>>> Meanwhile, why not provide a generic wrapper exception whose explicit
>>> >>>> and sole purpose is to wrap another checked exception? I know the
>>> >>>> idea
>>> >>>> is trivia, but why not?
>>> >>>>
>>> >>>> The Wrapper can provide convenience methods like
>>> >>>>
>>> >>>>     class Wrapper extends RuntimeException
>>> >>>>
>>> >>>>         // if cause is E1, throw cause; otherwise throw wrapper.
>>> >>>>         <E1> RuntimeException rethrow(Class<E1> type) throws E1,
>>> >>>> Wrapper
>>> >>>>
>>> >>>> so we can
>>> >>>>
>>> >>>>     catch(Wrapper w)
>>> >>>>         throw w.rethrow(IOException.class, SQLException.class);
>>> >>>>
>>> >>>> or to handle causes inline
>>> >>>>
>>> >>>>     catch(Wrapper w)
>>> >>>>         w.on(IOException.class, e->{ handle e; })
>>> >>>>            .on(SQLException.class, e->{ handle e; });
>>> >>>>
>>> >>>>     <Ei, Eo> Wrapper on(Class<Ei> type, ExceptionHandler<Ei,Eo>)
>>> >>>> throws
>>> >>>> Eo;
>>> >>>>
>>> >>>>     interface ExceptionHandler<Ei,Eo>
>>> >>>>         void handle(Ei e) throws Eo;
>>> >>>>
>>> >>>> obviously not elegant, but at least give us something of the sort
>>> >>>> that
>>> >>>> can alleviate the pain in the short term.
>>> >>>>
>>> >>>> Zhong Yu
>>> >>>>
>>> >>>>
>>> >>>> On Fri, Feb 1, 2013 at 11:38 PM, Peter Levart
>>> >>>> <peter.levart at gmail.com>
>>> >>>> wrote:
>>> >>>>>
>>> >>>>>
>>> >>>>> On 02/02/2013 12:44 AM, Henry Jen wrote:
>>> >>>>>>
>>> >>>>>> On 01/28/2013 12:16 AM, Peter Levart wrote:
>>> >>>>>>>
>>> >>>>>>> On 01/28/2013 12:06 AM, Henry Jen wrote:
>>> >>>>>>>>
>>> >>>>>>>> http://cr.openjdk.java.net/~henryjen/lambda/nio.5/webrev/
>>> >>>>>>>>
>>> >>>>>>> Hi Henry,
>>> >>>>>>>
>>> >>>>>>> I can imagine that many times a single block of code would be
>>> >>>>>>> responsible for constructing a Path stream (possibly enclosed into
>>> >>>>>>> a
>>> >>>>>>> try-with-resources construct) and consuming it's results, so
>>> >>>>>>> having
>>> >>>>>>> to
>>> >>>>>>> deal with the duality of IOException/UncheckedIOException is a
>>> >>>>>>> complication for a user in my opinion. Wouldn't it be better also
>>> >>>>>>> for
>>> >>>>>>> the stream-factory methods to throw UncheckedIOException and for
>>> >>>>>>> CloseableStream.close() to also throw UncheckedIOException (that
>>> >>>>>>> means,
>>> >>>>>>> only inheriting from AutoCloseable, not Closeable and
>>> >>>>>>> co-variant-ly
>>> >>>>>>> redefining the throws declaration):
>>> >>>>>>>
>>> >>>>>>> public interface CloseableStream<T> extends Stream<T>,
>>> >>>>>>> AutoCloseable
>>> >>>>>>> {
>>> >>>>>>>      @Override
>>> >>>>>>>      void close() throws UncheckedIOException;
>>> >>>>>>> }
>>> >>>>>>>
>>> >>>>>> Hi Peter,
>>> >>>>>
>>> >>>>>
>>> >>>>> Hi Henry,
>>> >>>>>
>>> >>>>>> Sorry for the late reply, I want to let the idea sink a little bit.
>>> >>>>>>
>>> >>>>>> After couple days, I am slightly prefer not to change it because,
>>> >>>>>>
>>> >>>>>> 1) The CloseableStream-factory method throws IOException reminds
>>> >>>>>> use
>>> >>>>>> of
>>> >>>>>> try-with-resource better than an unchecked exception.
>>> >>>>>
>>> >>>>>
>>> >>>>> The *Closeable*Stream method return type name also reminds of that
>>> >>>>> ;-)
>>> >>>>>
>>> >>>>>> 2) As factory methods throwing IOException, developer is dealing
>>> >>>>>> with
>>> >>>>>> duality already.
>>> >>>>>
>>> >>>>>
>>> >>>>> He is dealing with duality already *if* the factory methods are
>>> >>>>> throwing
>>> >>>>> IOException. If they are throwing UncheckedIOException, he is not
>>> >>>>> dealing with duality.
>>> >>>>>
>>> >>>>>> 3) If the close method throws UncheckedIOException as the stream
>>> >>>>>> handling, the suppressing of exceptions will be more confusing.
>>> >>>>>> Should
>>> >>>>>> developer look into cause IOException or the UncheckedIOException?
>>> >>>>>
>>> >>>>>
>>> >>>>> Do you think a programmer might want to handle different subtypes of
>>> >>>>> IOException differently? If that is the case, the javadoc should
>>> >>>>> document all the possible situations. And what about different
>>> >>>>> subtypes
>>> >>>>> of IOException wrapped by UncheckedIOException while consuming the
>>> >>>>> stream? If the programmer already bothers to unwrap the unchecked
>>> >>>>> exception to do the cause analisys, then this same handler would be
>>> >>>>> good
>>> >>>>> also for dealing with exceptions thrown in factory methods and
>>> >>>>> CloseableStream.close(). The streams API is a higher-lever wrapper
>>> >>>>> over
>>> >>>>> the java.nio.file.DirectoryStream API and it is already wrapping the
>>> >>>>> lower-level IOException with UncheckedIOException when consuming the
>>> >>>>> CloseableStream. I think it should do it consistently. By doing it
>>> >>>>> consistently, it simplifies correct exception handling logic in
>>> >>>>> *all*
>>> >>>>> situations.
>>> >>>>>
>>> >>>>>> 4) When the implementation is a Closeable, the wrapping of
>>> >>>>>> IOException
>>> >>>>>> into an UncheckedIOException doesn't do any good except overhead in
>>> >>>>>> case
>>> >>>>>> developer want to deal with it. On the other hand, a IOException
>>> >>>>>> handler
>>> >>>>>> is probably in place as the factory methods throws IOException.
>>> >>>>>
>>> >>>>>
>>> >>>>> It is probably in place *if* the factory methods are throwing
>>> >>>>> IOException. If they are throwing UncheckedIOException, then such
>>> >>>>> handler is not there. The question is whether the
>>> >>>>> UncheckedIOException
>>> >>>>> handler is in place too. If I look in one of your tests:
>>> >>>>>
>>> >>>>>   148         public void testWalk() {
>>> >>>>>   149                 try(CloseableStream<Path> s =
>>> >>>>> Files.walk(testFolder)) {
>>> >>>>>   150                         Object[] actual =
>>> >>>>> s.sorted(Comparators.naturalOrder()).toArray();
>>> >>>>>   151                         assertEquals(actual, all);
>>> >>>>>   152                 } catch (IOException ioe) {
>>> >>>>>   153                         fail("Unexpected IOException");
>>> >>>>>   154                 }
>>> >>>>>   155         }
>>> >>>>>
>>> >>>>>
>>> >>>>> You haven't bothered to handle the UncheckedIOException (because the
>>> >>>>> test would fail anyway if it was thrown). But I'm afraid that
>>> >>>>> average
>>> >>>>> programmer will walk away from similar codes with false sense of
>>> >>>>> confidence that he handled all exceptional situations when he put
>>> >>>>> the
>>> >>>>> checked exception handler in place. I think that being consistent
>>> >>>>> and
>>> >>>>> throwing UncheckedIOException everywhere would actually have greater
>>> >>>>> probability for average programmer to not miss the handling of
>>> >>>>> exceptional situations while consuming the stream - at least all
>>> >>>>> exceptional situations would be handled or not handled equally.
>>> >>>>>
>>> >>>>> Regards, Peter
>>> >>>>>
>>> >>>>>> Does it make sense?
>>> >>>>>>
>>> >>>>>> I updated the webrev to have some test coverage for exception
>>> >>>>>> handling,
>>> >>>>>> it's painful as always, but the duality is not what bothers me.
>>> >>>>>>
>>> >>>>>> http://cr.openjdk.java.net/~henryjen/lambda/nio.6/webrev/
>>> >>>>>>
>>> >>>>>> Cheers,
>>> >>>>>> Henry
>>> >>>>>>
>>> >>>>>
>>> >>>>>
>>> >>>
>>> >>
>>> >
>>>
>>

From spullara at gmail.com  Mon Feb  4 20:07:49 2013
From: spullara at gmail.com (Sam Pullara)
Date: Mon, 4 Feb 2013 20:07:49 -0800
Subject: UncheckedIOException and suppressed exception
In-Reply-To: <511080CD.2020409@oracle.com>
References: <CACuKZqHn-bSHz0Lc-S0mCC+Zi-8G=BVpnY0P5c_P-DO6_DcdVA@mail.gmail.com>
	<511066E7.1010506@oracle.com>
	<CACuKZqGCyfDWnxxZ45uDBGsBUAfVKn7KPWBNX5AXypMU3MPvYg@mail.gmail.com>
	<511080CD.2020409@oracle.com>
Message-ID: <-153264222804818422@unknownmsgid>

Wouldn't all these exceptions extend from RuntimeException? Seems like
we already have both the generic version and the specific for the
callers.

Sam

All my photos are panoramas.

On Feb 4, 2013, at 7:56 PM, David Holmes <david.holmes at oracle.com> wrote:

> On 5/02/2013 1:39 PM, Zhong Yu wrote:
>> On Mon, Feb 4, 2013 at 7:56 PM, David Holmes<david.holmes at oracle.com> wrote:
>>> On 5/02/2013 10:16 AM, Zhong Yu wrote:
>>>>
>>>> Suppose we have an UncheckedIOException e1, which wraps an IOException
>>>> e2. Then another exception e3 occurs that we want suppress. Should we
>>>> do e1.addSuppressed(e3), or e2.addSuppressed(e3)? That's pretty
>>>> confusing.
>>>
>>>
>>> I don't see any confusion except for your numbering. You have one exception
>>> that is inflight, e1, and then e3 occurs. If you want to continue throwing
>>> e1 then e1 is suppressing e3.
>>
>> The catcher of an UncheckedIOException e1 would see it simply as a
>> container, so it'll extract the contained IOException e2, and deal
>> with e2 afterwards, for example, rethrow e2. If e3 was added as e1's
>> suppressed exception, e3 is then lost.
>
> Then the catch is showing their ignorance of suppressed exceptions. BUt
> this is not specific to this situation. Anytime you catch an exception
> with a cause and a suppression list you have to decide what it is you
> want to do with it.
>
>> This "containing" relation is different from the usual "causal"
>> relation between an exception and its cause. Let's be honest, the only
>> purpose of an UncheckedIOException is to smuggle an IOException as
>> unchecked; UncheckedIOException itself has no "business meaning".
>
> Again read the Throwable javadoc that Joe pointed out top you. This
> "conversion" situation is one of the primary uses for setting a cause:
>
> "A second reason that a throwable may have a cause is that the method
> that throws it must conform to a general-purpose interface that does not
> permit the method to throw the cause directly. For example, suppose a
> persistent collection conforms to the Collection interface, and that its
> persistence is implemented atop java.io. Suppose the internals of the
> add method can throw an IOException. The implementation can communicate
> the details of the IOException to its caller while conforming to the
> Collection interface by wrapping the IOException in an appropriate
> unchecked exception. (The specification for the persistent collection
> should indicate that it is capable of throwing such exceptions.) "
>
> David
> -----
>
>>>> If UncheckedIOException is not a *real* exception, maybe we should
>>>> make it a "control" exception. It should have no stacktrace; it should
>>>> have no cause (the wrapped exception is not a cause); it should not
>>>> contain suppressed exceptions.
>>>
>>>
>>> Any wrapping exception should have the original exception as its cause. Why
>>> should this wrapper be any different? Throwable even defines it so:
>>>
>>> " Throwing a "wrapped exception" (i.e., an exception containing a cause)
>>> ..."
>>>
>>> Suppression is about control over which exception is propagating - so again
>>> why should this be a special case?
>>>
>>>
>>>> Maybe it can override addSuppressed() to forward suppressed exceptions
>>>> to the wrapped exception. (Though addSuppressed() is `final`, there's
>>>> no problem to leave a backdoor for another JDK class)
>>>
>>>
>>> I think your exception processing model is slightly confused here.
>>>
>>> David
>>> -----
>>>
>>>> Zhong Yu
>

From zhong.j.yu at gmail.com  Mon Feb  4 20:17:40 2013
From: zhong.j.yu at gmail.com (Zhong Yu)
Date: Mon, 4 Feb 2013 22:17:40 -0600
Subject: UncheckedIOException and suppressed exception
In-Reply-To: <511080CD.2020409@oracle.com>
References: <CACuKZqHn-bSHz0Lc-S0mCC+Zi-8G=BVpnY0P5c_P-DO6_DcdVA@mail.gmail.com>
	<511066E7.1010506@oracle.com>
	<CACuKZqGCyfDWnxxZ45uDBGsBUAfVKn7KPWBNX5AXypMU3MPvYg@mail.gmail.com>
	<511080CD.2020409@oracle.com>
Message-ID: <CACuKZqERX=1O2rDDTpxYfkB_x-kOyTzzoVuE37SW+NH5BLMOzQ@mail.gmail.com>

On Mon, Feb 4, 2013 at 9:47 PM, David Holmes <david.holmes at oracle.com> wrote:
> On 5/02/2013 1:39 PM, Zhong Yu wrote:
>>
>> On Mon, Feb 4, 2013 at 7:56 PM, David Holmes<david.holmes at oracle.com>
>> wrote:
>>>
>>> On 5/02/2013 10:16 AM, Zhong Yu wrote:
>>>>
>>>>
>>>> Suppose we have an UncheckedIOException e1, which wraps an IOException
>>>> e2. Then another exception e3 occurs that we want suppress. Should we
>>>> do e1.addSuppressed(e3), or e2.addSuppressed(e3)? That's pretty
>>>> confusing.
>>>
>>>
>>>
>>> I don't see any confusion except for your numbering. You have one
>>> exception
>>> that is inflight, e1, and then e3 occurs. If you want to continue
>>> throwing
>>> e1 then e1 is suppressing e3.
>>
>>
>> The catcher of an UncheckedIOException e1 would see it simply as a
>> container, so it'll extract the contained IOException e2, and deal
>> with e2 afterwards, for example, rethrow e2. If e3 was added as e1's
>> suppressed exception, e3 is then lost.
>
>
> Then the catch is showing their ignorance of suppressed exceptions. BUt this
> is not specific to this situation. Anytime you catch an exception with a
> cause and a suppression list you have to decide what it is you want to do
> with it.

It is far more likely that UncheckIOException is treated as a shell,
and the shell is discarded (along with information attached to it),
leaving only the contained IOException. That is less likely for
"normal" exceptions that represents errors by themselves.

This is probably going to be a common usage

    catch(UncheckedIOException e1)
        throw e.getCause();

however it'll lose suppressed exception on e1.

>> This "containing" relation is different from the usual "causal"
>> relation between an exception and its cause. Let's be honest, the only
>> purpose of an UncheckedIOException is to smuggle an IOException as
>> unchecked; UncheckedIOException itself has no "business meaning".
>
>
> Again read the Throwable javadoc that Joe pointed out top you. This
> "conversion" situation is one of the primary uses for setting a cause:

I'm certainly aware of this practice, unfortunately it is not a good
practice, since there's no reliable way to uncover the original
exception.

> "A second reason that a throwable may have a cause is that the method that
> throws it must conform to a general-purpose interface that does not permit
> the method to throw the cause directly. For example, suppose a persistent
> collection conforms to the Collection interface, and that its persistence is
> implemented atop java.io. Suppose the internals of the add method can throw
> an IOException. The implementation can communicate the details of the
> IOException to its caller while conforming to the Collection interface by
> wrapping the IOException in an appropriate unchecked exception. (The
> specification for the persistent collection should indicate that it is
> capable of throwing such exceptions.) "
>
> David
> -----
>
>
>>>> If UncheckedIOException is not a *real* exception, maybe we should
>>>> make it a "control" exception. It should have no stacktrace; it should
>>>> have no cause (the wrapped exception is not a cause); it should not
>>>> contain suppressed exceptions.
>>>
>>>
>>>
>>> Any wrapping exception should have the original exception as its cause.
>>> Why
>>> should this wrapper be any different? Throwable even defines it so:
>>>
>>> " Throwing a "wrapped exception" (i.e., an exception containing a cause)
>>> ..."
>>>
>>> Suppression is about control over which exception is propagating - so
>>> again
>>> why should this be a special case?
>>>
>>>
>>>> Maybe it can override addSuppressed() to forward suppressed exceptions
>>>> to the wrapped exception. (Though addSuppressed() is `final`, there's
>>>> no problem to leave a backdoor for another JDK class)
>>>
>>>
>>>
>>> I think your exception processing model is slightly confused here.
>>>
>>> David
>>> -----
>>>
>>>> Zhong Yu
>>>>
>>>
>>
>

From ricky.clarkson at gmail.com  Mon Feb  4 21:03:18 2013
From: ricky.clarkson at gmail.com (Ricky Clarkson)
Date: Tue, 5 Feb 2013 02:03:18 -0300
Subject: UncheckedIOException and suppressed exception
In-Reply-To: <CACuKZqERX=1O2rDDTpxYfkB_x-kOyTzzoVuE37SW+NH5BLMOzQ@mail.gmail.com>
References: <CACuKZqHn-bSHz0Lc-S0mCC+Zi-8G=BVpnY0P5c_P-DO6_DcdVA@mail.gmail.com>
	<511066E7.1010506@oracle.com>
	<CACuKZqGCyfDWnxxZ45uDBGsBUAfVKn7KPWBNX5AXypMU3MPvYg@mail.gmail.com>
	<511080CD.2020409@oracle.com>
	<CACuKZqERX=1O2rDDTpxYfkB_x-kOyTzzoVuE37SW+NH5BLMOzQ@mail.gmail.com>
Message-ID: <CAOBi2H_gAa6VvutCC3J+tiiPjnf9heDrci9K-6QwY2FXgixcUg@mail.gmail.com>

If you're expecting catch (UncheckedIOException e1) { throw e.getCause(); }
as a common use case, perhaps using the return value might be a better
approach without having to 'dip' down into untypedville:

List<IOResult<String>> resultList = asList("foo.txt",
"bar.txt").map(trapIOException(IOUtils::readWholeFile));
for (IOResult<String> possibleResult: resultList) {
  String result = possibleResult.getValue(); // would rethrow the original
IOException or return the value depending on what's stored in the IOResult.
  more code here using result.
}

If Java 9 later provided exception transparency, you could then refactor
this code fairly straightforwardly with IDE support or at least with help
from the compiler, whereas if you have to go via an unchecked exception
it's likely to be harder to take advantage of any future improvements.
 This should also work with parallelism, as there's nothing making .map
terminate as soon as reading one file hits an IOException.

Checked exceptions are contentious and I'm not sure I'd include them if I
was designing a language, but they're in Java, they get some valid use that
benefits from type checking and I wouldn't want to see them become a
second-class citizen by being excluded from most lambda-using code in
favour of untyped exceptions.


On Tue, Feb 5, 2013 at 1:17 AM, Zhong Yu <zhong.j.yu at gmail.com> wrote:

> On Mon, Feb 4, 2013 at 9:47 PM, David Holmes <david.holmes at oracle.com>
> wrote:
> > On 5/02/2013 1:39 PM, Zhong Yu wrote:
> >>
> >> On Mon, Feb 4, 2013 at 7:56 PM, David Holmes<david.holmes at oracle.com>
> >> wrote:
> >>>
> >>> On 5/02/2013 10:16 AM, Zhong Yu wrote:
> >>>>
> >>>>
> >>>> Suppose we have an UncheckedIOException e1, which wraps an IOException
> >>>> e2. Then another exception e3 occurs that we want suppress. Should we
> >>>> do e1.addSuppressed(e3), or e2.addSuppressed(e3)? That's pretty
> >>>> confusing.
> >>>
> >>>
> >>>
> >>> I don't see any confusion except for your numbering. You have one
> >>> exception
> >>> that is inflight, e1, and then e3 occurs. If you want to continue
> >>> throwing
> >>> e1 then e1 is suppressing e3.
> >>
> >>
> >> The catcher of an UncheckedIOException e1 would see it simply as a
> >> container, so it'll extract the contained IOException e2, and deal
> >> with e2 afterwards, for example, rethrow e2. If e3 was added as e1's
> >> suppressed exception, e3 is then lost.
> >
> >
> > Then the catch is showing their ignorance of suppressed exceptions. BUt
> this
> > is not specific to this situation. Anytime you catch an exception with a
> > cause and a suppression list you have to decide what it is you want to do
> > with it.
>
> It is far more likely that UncheckIOException is treated as a shell,
> and the shell is discarded (along with information attached to it),
> leaving only the contained IOException. That is less likely for
> "normal" exceptions that represents errors by themselves.
>
> This is probably going to be a common usage
>
>     catch(UncheckedIOException e1)
>         throw e.getCause();
>
> however it'll lose suppressed exception on e1.
>
> >> This "containing" relation is different from the usual "causal"
> >> relation between an exception and its cause. Let's be honest, the only
> >> purpose of an UncheckedIOException is to smuggle an IOException as
> >> unchecked; UncheckedIOException itself has no "business meaning".
> >
> >
> > Again read the Throwable javadoc that Joe pointed out top you. This
> > "conversion" situation is one of the primary uses for setting a cause:
>
> I'm certainly aware of this practice, unfortunately it is not a good
> practice, since there's no reliable way to uncover the original
> exception.
>
> > "A second reason that a throwable may have a cause is that the method
> that
> > throws it must conform to a general-purpose interface that does not
> permit
> > the method to throw the cause directly. For example, suppose a persistent
> > collection conforms to the Collection interface, and that its
> persistence is
> > implemented atop java.io. Suppose the internals of the add method can
> throw
> > an IOException. The implementation can communicate the details of the
> > IOException to its caller while conforming to the Collection interface by
> > wrapping the IOException in an appropriate unchecked exception. (The
> > specification for the persistent collection should indicate that it is
> > capable of throwing such exceptions.) "
> >
> > David
> > -----
> >
> >
> >>>> If UncheckedIOException is not a *real* exception, maybe we should
> >>>> make it a "control" exception. It should have no stacktrace; it should
> >>>> have no cause (the wrapped exception is not a cause); it should not
> >>>> contain suppressed exceptions.
> >>>
> >>>
> >>>
> >>> Any wrapping exception should have the original exception as its cause.
> >>> Why
> >>> should this wrapper be any different? Throwable even defines it so:
> >>>
> >>> " Throwing a "wrapped exception" (i.e., an exception containing a
> cause)
> >>> ..."
> >>>
> >>> Suppression is about control over which exception is propagating - so
> >>> again
> >>> why should this be a special case?
> >>>
> >>>
> >>>> Maybe it can override addSuppressed() to forward suppressed exceptions
> >>>> to the wrapped exception. (Though addSuppressed() is `final`, there's
> >>>> no problem to leave a backdoor for another JDK class)
> >>>
> >>>
> >>>
> >>> I think your exception processing model is slightly confused here.
> >>>
> >>> David
> >>> -----
> >>>
> >>>> Zhong Yu
> >>>>
> >>>
> >>
> >
>
>

From david.holmes at oracle.com  Mon Feb  4 21:44:32 2013
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 05 Feb 2013 15:44:32 +1000
Subject: Hundreds of errors generating javadoc ??
Message-ID: <51109C40.6000303@oracle.com>

Not sure what is going on as this is a fresh clone of the lambda forest 
and the errors are in packages all over the place (unrelated to lambda 
changes).

??

David
-----

/export/users/dh198349/lambda/jdk/src/share/classes/java/applet/Applet.java:527: 
error: tag not allowed here: <p>
      * <p>
        ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/applet/Applet.java:183: 
error: tag not allowed here: <p>
      * <p>
        ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/applet/Applet.java:395: 
error: tag not allowed here: <p>
      * <p><blockquote><pre>
        ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/applet/Applet.java:395: 
error: tag not allowed here: <blockquote>
      * <p><blockquote><pre>
           ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/applet/Applet.java:402: 
error: tag not allowed here: <p>
      * <p>
        ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/applet/Applet.java:451: 
error: tag not allowed here: <p>
      * <p>
        ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/applet/Applet.java:474: 
error: tag not allowed here: <p>
      * <p>
        ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/applet/Applet.java:481: 
error: tag not allowed here: <p>
      * <p>
        ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/applet/Applet.java:506: 
error: tag not allowed here: <p>
      * <p>
        ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/Component.java:2168: 
warning: no @param for width
     public void resize(int width, int height) {
                 ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/Component.java:2168: 
warning: no @param for height
     public void resize(int width, int height) {
                 ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/Component.java:2199: 
warning: no @param for d
     public void resize(Dimension d) {
                 ^
/export/users/dh198349/lambda/jdk/src/share/classes/javax/accessibility/Accessible.java:49: 
warning: no @return
     public AccessibleContext getAccessibleContext();
                              ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/applet/AppletContext.java:59: 
warning: empty <code> tag
      * the screen. The <code>url</code> argument<code> </code>that is
                                                        ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/applet/AppletContext.java:175: 
error: tag not allowed here: <p>
      * <p>
        ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/applet/AppletContext.java:188: 
error: tag not allowed here: <p>
      * <p>
        ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/applet/AppletContext.java:155: 
error: tag not allowed here: <p>
      * <p>
        ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/applet/AppletContext.java:160: 
error: unexpected text
      * @throws <code>IOException</code> if the stream size exceeds a 
certain
        ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/applet/AppletContext.java:165: 
warning: no @throws for java.io.IOException
     public void setStream(String key, InputStream stream)throws 
IOException;
                 ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/applet/AppletContext.java:111: 
error: tag not allowed here: <center>
      * <center><table border="3" summary="Target arguments and their 
descriptions">
        ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/applet/AppletContext.java:128: 
error: tag not allowed here: <p>
      * <p>
        ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/ActiveEvent.java:42: 
error: tag not allowed here: <p>
  * <p>
    ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:51: 
error: tag not allowed here: <p>
  * <p>
    ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:62: 
error: tag not allowed here: <p>
  * <p>
    ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:71: 
error: tag not allowed here: <p>
  * <p>
    ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:75: 
error: tag not allowed here: <blockquote>
  * <blockquote>
    ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:90: 
error: tag not allowed here: <p>
  * <p>
    ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:105: 
error: tag not allowed here: <pre>
  * <pre>
    ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:111: 
error: tag not allowed here: <p>
  * <p>
    ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:115: 
error: tag not allowed here: <blockquote>
  * <blockquote>
    ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:128: 
error: tag not allowed here: <h3>
  * <h3>Preparing Inputs</h3>
    ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:130: 
error: tag not allowed here: <p>
  * <p>
    ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:140: 
error: tag not allowed here: <pre>
  * <pre>
    ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:152: 
error: tag not allowed here: <pre>
  * <pre>
    ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:158: 
error: tag not allowed here: <pre>
  * <pre>
    ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:161: 
error: tag not allowed here: <p>
  * <p>
    ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:165: 
error: tag not allowed here: <pre>
  * <pre>
    ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:169: 
error: tag not allowed here: <h3>
  * <h3>Applying the Blending Equation</h3>
    ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:171: 
error: tag not allowed here: <p>
  * <p>
    ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:178: 
error: tag not allowed here: <p>
  * <p>
    ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:179: 
error: tag not allowed here: <h3>
  * <h3>Preparing Results</h3>
    ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:181: 
error: tag not allowed here: <p>
  * <p>
    ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:186: 
error: tag not allowed here: <pre>
  * <pre>
    ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:196: 
error: tag not allowed here: <p>
  * <p>
    ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:197: 
error: tag not allowed here: <h3>
  * <h3>Performance Considerations</h3>
    ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:199: 
error: tag not allowed here: <p>
  * <p>
    ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:210: 
error: tag not allowed here: <h3>
  * <h3><a name="caveats">Implementation Caveats</a></h3>
    ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:212: 
error: tag not allowed here: <ul>
  * <ul>
    ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:362: 
error: tag not allowed here: <pre>
      *<pre>
       ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:387: 
error: tag not allowed here: <pre>
      *<pre>
       ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:498: 
error: tag not allowed here: <pre>
      *<pre>
       ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:440: 
error: tag not allowed here: <pre>
      *<pre>
       ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:466: 
error: tag not allowed here: <pre>
      *<pre>
       ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:414: 
error: tag not allowed here: <pre>
      *<pre>
       ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:375: 
error: tag not allowed here: <pre>
      *<pre>
       ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:484: 
error: tag not allowed here: <pre>
      *<pre>
       ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:427: 
error: tag not allowed here: <pre>
      *<pre>
       ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:453: 
error: tag not allowed here: <pre>
      *<pre>
       ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:401: 
error: tag not allowed here: <pre>
      *<pre>
       ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:513: 
error: tag not allowed here: <pre>
      *<pre>
       ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:640: 
warning: no @return
     public static AlphaComposite getInstance(int rule) {
                                  ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:688: 
warning: no @return
     public static AlphaComposite getInstance(int rule, float alpha) {
                                  ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/lang/Object.java:71: 
error: tag not allowed here: <ul>
      * <ul>
        ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/lang/Object.java:88: 
error: tag not allowed here: <p>
      * <p>
        ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/lang/Object.java:107: 
error: tag not allowed here: <ul>
      * <ul>
        ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/lang/Object.java:129: 
error: tag not allowed here: <p>
      * <p>
        ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/lang/Object.java:136: 
error: tag not allowed here: <p>
      * <p>
        ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEvent.java:52: 
error: tag not allowed here: <p>
  * <p>
    ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEvent.java:392: 
warning: no @return
     public int getID() {
                ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEvent.java:450: 
warning: no @return
     protected boolean isConsumed() {
                       ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/lang/Object.java:228: 
error: tag not allowed here: <blockquote>
      * <blockquote>
        ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:43: 
error: tag not allowed here: <pre>
  * <pre><code>
    ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:66: 
error: tag not allowed here: <p>
  * <p>
    ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:76: 
error: tag not allowed here: <p>
  * <p>
    ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:83: 
error: tag not allowed here: <p>
  * <p>
    ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:86: 
error: tag not allowed here: <ul>
  * <ul>
    ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:95: 
error: tag not allowed here: <p>
  * <p>Swing makes use of
    ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:635: 
warning: no @return
     public static ActionListener add(ActionListener a, ActionListener b) {
                                  ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:655: 
warning: no @return
     public static AdjustmentListener add(AdjustmentListener a, 
AdjustmentListener b) {
                                      ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:541: 
warning: no @return
     public static ComponentListener add(ComponentListener a, 
ComponentListener b) {
                                     ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:551: 
warning: no @return
     public static ContainerListener add(ContainerListener a, 
ContainerListener b) {
                                     ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:561: 
warning: no @return
     public static FocusListener add(FocusListener a, FocusListener b) {
                                 ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:690: 
warning: no @return
      public static HierarchyBoundsListener add(HierarchyBoundsListener 
a, HierarchyBoundsListener b) {
                                            ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:679: 
warning: no @return
      public static HierarchyListener add(HierarchyListener a, 
HierarchyListener b) {
                                      ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:668: 
warning: no @return
      public static InputMethodListener add(InputMethodListener a, 
InputMethodListener b) {
                                        ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:645: 
warning: no @return
     public static ItemListener add(ItemListener a, ItemListener b) {
                                ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:571: 
warning: no @return
     public static KeyListener add(KeyListener a, KeyListener b) {
                               ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:581: 
warning: no @return
     public static MouseListener add(MouseListener a, MouseListener b) {
                                 ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:591: 
warning: no @return
     public static MouseMotionListener add(MouseMotionListener a, 
MouseMotionListener b) {
                                       ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:701: 
warning: no @return
     public static MouseWheelListener add(MouseWheelListener a,
                                      ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:624: 
warning: no @return
     public static WindowFocusListener add(WindowFocusListener a,
                                       ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:601: 
warning: no @return
     public static WindowListener add(WindowListener a, WindowListener b) {
                                  ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:612: 
warning: no @return
     public static WindowStateListener add(WindowStateListener a,
                                       ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:888: 
warning: no @return
     protected static EventListener addInternal(EventListener a, 
EventListener b) {
                                    ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:1022: 
warning: no @param for <T>
         getListeners(EventListener l, Class<T> listenerType)
         ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:806: 
warning: no @return
     public static ActionListener remove(ActionListener l, 
ActionListener oldl) {
                                  ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:826: 
warning: no @return
     public static AdjustmentListener remove(AdjustmentListener l, 
AdjustmentListener oldl) {
                                      ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:712: 
warning: no @return
     public static ComponentListener remove(ComponentListener l, 
ComponentListener oldl) {
                                     ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:722: 
warning: no @return
     public static ContainerListener remove(ContainerListener l, 
ContainerListener oldl) {
                                     ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:136: 
error: tag not allowed here: <p>
      * <p>
        ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:732: 
warning: no @return
     public static FocusListener remove(FocusListener l, FocusListener 
oldl) {
                                 ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:862: 
warning: no @return
     public static HierarchyBoundsListener 
remove(HierarchyBoundsListener l, HierarchyBoundsListener oldl) {
                                           ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:850: 
warning: no @return
     public static HierarchyListener remove(HierarchyListener l, 
HierarchyListener oldl) {
                                     ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:839: 
warning: no @return
     public static InputMethodListener remove(InputMethodListener l, 
InputMethodListener oldl) {
                                       ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:816: 
warning: no @return
     public static ItemListener remove(ItemListener l, ItemListener oldl) {
                                ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:742: 
warning: no @return
     public static KeyListener remove(KeyListener l, KeyListener oldl) {
                               ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:752: 
warning: no @return
     public static MouseListener remove(MouseListener l, MouseListener 
oldl) {
                                 ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:762: 
warning: no @return
     public static MouseMotionListener remove(MouseMotionListener l, 
MouseMotionListener oldl) {
                                       ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:873: 
warning: no @return
     public static MouseWheelListener remove(MouseWheelListener l,
                                      ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:795: 
warning: no @return
     public static WindowFocusListener remove(WindowFocusListener l,
                                       ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:772: 
warning: no @return
     public static WindowListener remove(WindowListener l, 
WindowListener oldl) {
                                  ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:783: 
warning: no @return
     public static WindowStateListener remove(WindowStateListener l,
                                       ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:905: 
warning: no @return
     protected static EventListener removeInternal(EventListener l, 
EventListener oldl) {
                                    ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/TextListener.java:53: 
warning: no @param for e
     public void textValueChanged(TextEvent e);
                 ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/ComponentListener.java:58: 
warning: no @param for e
     public void componentResized(ComponentEvent e);
                 ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/ComponentListener.java:63: 
warning: no @param for e
     public void componentMoved(ComponentEvent e);
                 ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/ComponentListener.java:68: 
warning: no @param for e
     public void componentShown(ComponentEvent e);
                 ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/ComponentListener.java:73: 
warning: no @param for e
     public void componentHidden(ComponentEvent e);
                 ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/ContainerListener.java:59: 
warning: no @param for e
     public void componentAdded(ContainerEvent e);
                 ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/ContainerListener.java:64: 
warning: no @param for e
     public void componentRemoved(ContainerEvent e);
                 ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/FocusListener.java:55: 
warning: no @param for e
     public void focusGained(FocusEvent e);
                 ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/FocusListener.java:60: 
warning: no @param for e
     public void focusLost(FocusEvent e);
                 ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/KeyListener.java:58: 
warning: no @param for e
     public void keyTyped(KeyEvent e);
                 ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/KeyListener.java:65: 
warning: no @param for e
     public void keyPressed(KeyEvent e);
                 ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/KeyListener.java:72: 
warning: no @param for e
     public void keyReleased(KeyEvent e);
                 ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/MouseListener.java:63: 
warning: no @param for e
     public void mouseClicked(MouseEvent e);
                 ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/MouseListener.java:68: 
warning: no @param for e
     public void mousePressed(MouseEvent e);
                 ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/MouseListener.java:73: 
warning: no @param for e
     public void mouseReleased(MouseEvent e);
                 ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/MouseListener.java:78: 
warning: no @param for e
     public void mouseEntered(MouseEvent e);
                 ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/MouseListener.java:83: 
warning: no @param for e
     public void mouseExited(MouseEvent e);
                 ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/MouseMotionListener.java:63: 
error: semicolon missing
      * Due to platform-dependent Drag&Drop implementations,
                                      ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/MouseMotionListener.java:65: 
error: semicolon missing
      * Drag&Drop operation.
            ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/MouseMotionListener.java:67: 
warning: no @param for e
     public void mouseDragged(MouseEvent e);
                 ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/MouseMotionListener.java:73: 
warning: no @param for e
     public void mouseMoved(MouseEvent e);
                 ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/WindowListener.java:55: 
warning: no @param for e
     public void windowOpened(WindowEvent e);
                 ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/WindowListener.java:61: 
warning: no @param for e
     public void windowClosing(WindowEvent e);
                 ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/WindowListener.java:67: 
warning: no @param for e
     public void windowClosed(WindowEvent e);
                 ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/WindowListener.java:76: 
warning: no @param for e
     public void windowIconified(WindowEvent e);
                 ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/WindowListener.java:82: 
warning: no @param for e
     public void windowDeiconified(WindowEvent e);
                 ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/WindowListener.java:92: 
warning: no @param for e
     public void windowActivated(WindowEvent e);
                 ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/WindowListener.java:102: 
warning: no @param for e
     public void windowDeactivated(WindowEvent e);
                 ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/WindowStateListener.java:54: 
warning: no @param for e
     public void windowStateChanged(WindowEvent e);
                 ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/WindowFocusListener.java:61: 
warning: no @param for e
     public void windowGainedFocus(WindowEvent e);
                 ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/WindowFocusListener.java:68: 
warning: no @param for e
     public void windowLostFocus(WindowEvent e);
                 ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/ActionListener.java:50: 
warning: no @param for e
     public void actionPerformed(ActionEvent e);
                 ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/ItemListener.java:54: 
warning: no @param for e
     void itemStateChanged(ItemEvent e);
          ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/AdjustmentListener.java:41: 
warning: no @param for e
     public void adjustmentValueChanged(AdjustmentEvent e);
                 ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/InputMethodListener.java:49: 
warning: no @param for event
     void inputMethodTextChanged(InputMethodEvent event);
          ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/InputMethodListener.java:54: 
warning: no @param for event
     void caretPositionChanged(InputMethodEvent event);
          ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/HierarchyListener.java:56: 
warning: no @param for e
     public void hierarchyChanged(HierarchyEvent e);
                 ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/HierarchyBoundsListener.java:56: 
warning: no @param for e
     public void ancestorMoved(HierarchyEvent e);
                 ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/HierarchyBoundsListener.java:61: 
warning: no @param for e
     public void ancestorResized(HierarchyEvent e);
                 ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/MouseWheelListener.java:57: 
warning: no @param for e
     public void mouseWheelMoved(MouseWheelEvent e);
                 ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTKeyStroke.java:402: 
error: tag not allowed here: <ul>
      * used to specify the key code. For example:<ul>
                                                  ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTKeyStroke.java:407: 
error: tag not allowed here: <ul>
      * The modifiers consist of any combination of:<ul>
                                                    ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTKeyStroke.java:414: 
error: tag not allowed here: <ul>
      * The old modifiers <ul>
                          ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTKeyStroke.java:352: 
error: tag not allowed here: <ul>
      * used to specify the key code. For example:<ul>
                                                  ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTKeyStroke.java:360: 
error: tag not allowed here: <ul>
      * The modifiers consist of any combination of:<ul>
                                                    ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTKeyStroke.java:367: 
error: tag not allowed here: <ul>
      * The old modifiers <ul>
                          ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTKeyStroke.java:488: 
error: bad use of '>'
      *     "INSERT" => getAWTKeyStroke(KeyEvent.VK_INSERT, 0);
                      ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTKeyStroke.java:489: 
error: bad use of '>'
      *     "control DELETE" => getAWTKeyStroke(KeyEvent.VK_DELETE, 
InputEvent.CTRL_MASK);
                              ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTKeyStroke.java:490: 
error: bad use of '>'
      *     "alt shift X" => getAWTKeyStroke(KeyEvent.VK_X, 
InputEvent.ALT_MASK | InputEvent.SHIFT_MASK);
                           ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTKeyStroke.java:491: 
error: bad use of '>'
      *     "alt shift released X" => getAWTKeyStroke(KeyEvent.VK_X, 
InputEvent.ALT_MASK | InputEvent.SHIFT_MASK, true);
                                    ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTKeyStroke.java:492: 
error: bad use of '>'
      *     "typed a" => getAWTKeyStroke('a');
                       ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTKeyStroke.java:803: 
warning: no @throws for java.io.ObjectStreamException
     protected Object readResolve() throws java.io.ObjectStreamException {
                      ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTPermission.java:41: 
error: tag not allowed here: <P>
  * <P>
    ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTPermission.java:46: 
error: tag not allowed here: <P>
  * <P>
    ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTPermission.java:48: 
error: tag not allowed here: <table>
  * <table border=1 cellpadding=5 summary="AWTPermission target names, 
descriptions, and associated risks.">
    ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/BasicStroke.java:42: 
warning: attribute obsolete, use CSS instead: compact
  * <dl compact>
        ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/BorderLayout.java:61: 
error: tag not allowed here: <p>
  * <p>
    ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/BorderLayout.java:70: 
error: tag not allowed here: <p>
  * <p>
    ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/BorderLayout.java:78: 
error: tag not allowed here: <p>
  * <p>
    ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/BorderLayout.java:83: 
error: tag not allowed here: <p>
  * <p>
    ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/BorderLayout.java:91: 
error: tag not allowed here: <p>
  * <p>
    ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/BorderLayout.java:94: 
error: tag not allowed here: <p>
  * <p>
    ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/BorderLayout.java:99: 
warning: attribute obsolete, use CSS instead: ALIGN
  * ALIGN=center HSPACE=10 VSPACE=7>
    ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/BorderLayout.java:99: 
warning: attribute obsolete, use CSS instead: HSPACE
  * ALIGN=center HSPACE=10 VSPACE=7>
                 ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/BorderLayout.java:99: 
warning: attribute obsolete, use CSS instead: VSPACE
  * ALIGN=center HSPACE=10 VSPACE=7>
                           ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/BorderLayout.java:100: 
error: tag not allowed here: <p>
  * <p>
    ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/BorderLayout.java:102: 
error: tag not allowed here: <p>
  * <p>
    ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/BorderLayout.java:103: 
error: tag not allowed here: <hr>
  * <hr><blockquote><pre>
    ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/BorderLayout.java:103: 
error: tag not allowed here: <blockquote>
  * <hr><blockquote><pre>
        ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/BorderLayout.java:117: 
error: tag not allowed here: <hr>
  * </pre></blockquote><hr>
                       ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/BorderLayout.java:118: 
error: tag not allowed here: <p>
  * <p>
    ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/BorderLayout.java:372: 
warning: no @return
     public int getHgap() {
                ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/BorderLayout.java:389: 
warning: no @return
     public int getVgap() {
                ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/BorderLayout.java:795: 
error: tag not allowed here: <p>
      * <p>
        ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/LayoutManager2.java:61: 
warning: no @param for target
     public Dimension maximumLayoutSize(Container target);
                      ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/LayoutManager2.java:61: 
warning: no @return
     public Dimension maximumLayoutSize(Container target);
                      ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/LayoutManager2.java:70: 
warning: no @param for target
     public float getLayoutAlignmentX(Container target);
                  ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/LayoutManager2.java:70: 
warning: no @return
     public float getLayoutAlignmentX(Container target);
                  ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/awt/LayoutManager2.java:79: 
warning: no @param for target
     public float getLayoutAlignmentY(Container target);
                  ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/lang/Object.java:174: 
error: tag not allowed here: <p>
      * <p>
        ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/lang/Object.java:185: 
error: tag not allowed here: <p>
      * <p>
        ^
/export/users/dh198349/lambda/jdk/src/share/classes/java/lang/Object.java:198: 
error: tag not allowed here: <p>
      * <p>
        ^
100 errors
100 warnings
make[1]: *** 
[/export/users/dh198349/lambda/builds/b00/se-linux-i586-ea/docs/api/index.html] 
Error 1
make: *** [docs-only] Error 2

From mike.duigou at oracle.com  Mon Feb  4 21:57:17 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Mon, 4 Feb 2013 21:57:17 -0800
Subject: Hundreds of errors generating javadoc ??
In-Reply-To: <51109C40.6000303@oracle.com>
References: <51109C40.6000303@oracle.com>
Message-ID: <1A9F9B72-955D-4960-83F0-9D376979136A@oracle.com>

This looks like doclint but that shouldn't be enabled yet for lambda repo. I disabled doclint for all of lambda lat integration. I will investigate in the morning.

On Feb 4, 2013, at 9:44 PM, David Holmes <david.holmes at oracle.com> wrote:

> Not sure what is going on as this is a fresh clone of the lambda forest 
> and the errors are in packages all over the place (unrelated to lambda 
> changes).
> 
> ??
> 
> David
> -----
> 
> /export/users/dh198349/lambda/jdk/src/share/classes/java/applet/Applet.java:527: 
> error: tag not allowed here: <p>
>      * <p>
>        ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/applet/Applet.java:183: 
> error: tag not allowed here: <p>
>      * <p>
>        ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/applet/Applet.java:395: 
> error: tag not allowed here: <p>
>      * <p><blockquote><pre>
>        ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/applet/Applet.java:395: 
> error: tag not allowed here: <blockquote>
>      * <p><blockquote><pre>
>           ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/applet/Applet.java:402: 
> error: tag not allowed here: <p>
>      * <p>
>        ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/applet/Applet.java:451: 
> error: tag not allowed here: <p>
>      * <p>
>        ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/applet/Applet.java:474: 
> error: tag not allowed here: <p>
>      * <p>
>        ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/applet/Applet.java:481: 
> error: tag not allowed here: <p>
>      * <p>
>        ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/applet/Applet.java:506: 
> error: tag not allowed here: <p>
>      * <p>
>        ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/Component.java:2168: 
> warning: no @param for width
>     public void resize(int width, int height) {
>                 ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/Component.java:2168: 
> warning: no @param for height
>     public void resize(int width, int height) {
>                 ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/Component.java:2199: 
> warning: no @param for d
>     public void resize(Dimension d) {
>                 ^
> /export/users/dh198349/lambda/jdk/src/share/classes/javax/accessibility/Accessible.java:49: 
> warning: no @return
>     public AccessibleContext getAccessibleContext();
>                              ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/applet/AppletContext.java:59: 
> warning: empty <code> tag
>      * the screen. The <code>url</code> argument<code> </code>that is
>                                                        ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/applet/AppletContext.java:175: 
> error: tag not allowed here: <p>
>      * <p>
>        ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/applet/AppletContext.java:188: 
> error: tag not allowed here: <p>
>      * <p>
>        ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/applet/AppletContext.java:155: 
> error: tag not allowed here: <p>
>      * <p>
>        ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/applet/AppletContext.java:160: 
> error: unexpected text
>      * @throws <code>IOException</code> if the stream size exceeds a 
> certain
>        ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/applet/AppletContext.java:165: 
> warning: no @throws for java.io.IOException
>     public void setStream(String key, InputStream stream)throws 
> IOException;
>                 ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/applet/AppletContext.java:111: 
> error: tag not allowed here: <center>
>      * <center><table border="3" summary="Target arguments and their 
> descriptions">
>        ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/applet/AppletContext.java:128: 
> error: tag not allowed here: <p>
>      * <p>
>        ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/ActiveEvent.java:42: 
> error: tag not allowed here: <p>
>  * <p>
>    ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:51: 
> error: tag not allowed here: <p>
>  * <p>
>    ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:62: 
> error: tag not allowed here: <p>
>  * <p>
>    ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:71: 
> error: tag not allowed here: <p>
>  * <p>
>    ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:75: 
> error: tag not allowed here: <blockquote>
>  * <blockquote>
>    ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:90: 
> error: tag not allowed here: <p>
>  * <p>
>    ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:105: 
> error: tag not allowed here: <pre>
>  * <pre>
>    ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:111: 
> error: tag not allowed here: <p>
>  * <p>
>    ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:115: 
> error: tag not allowed here: <blockquote>
>  * <blockquote>
>    ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:128: 
> error: tag not allowed here: <h3>
>  * <h3>Preparing Inputs</h3>
>    ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:130: 
> error: tag not allowed here: <p>
>  * <p>
>    ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:140: 
> error: tag not allowed here: <pre>
>  * <pre>
>    ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:152: 
> error: tag not allowed here: <pre>
>  * <pre>
>    ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:158: 
> error: tag not allowed here: <pre>
>  * <pre>
>    ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:161: 
> error: tag not allowed here: <p>
>  * <p>
>    ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:165: 
> error: tag not allowed here: <pre>
>  * <pre>
>    ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:169: 
> error: tag not allowed here: <h3>
>  * <h3>Applying the Blending Equation</h3>
>    ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:171: 
> error: tag not allowed here: <p>
>  * <p>
>    ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:178: 
> error: tag not allowed here: <p>
>  * <p>
>    ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:179: 
> error: tag not allowed here: <h3>
>  * <h3>Preparing Results</h3>
>    ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:181: 
> error: tag not allowed here: <p>
>  * <p>
>    ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:186: 
> error: tag not allowed here: <pre>
>  * <pre>
>    ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:196: 
> error: tag not allowed here: <p>
>  * <p>
>    ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:197: 
> error: tag not allowed here: <h3>
>  * <h3>Performance Considerations</h3>
>    ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:199: 
> error: tag not allowed here: <p>
>  * <p>
>    ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:210: 
> error: tag not allowed here: <h3>
>  * <h3><a name="caveats">Implementation Caveats</a></h3>
>    ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:212: 
> error: tag not allowed here: <ul>
>  * <ul>
>    ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:362: 
> error: tag not allowed here: <pre>
>      *<pre>
>       ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:387: 
> error: tag not allowed here: <pre>
>      *<pre>
>       ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:498: 
> error: tag not allowed here: <pre>
>      *<pre>
>       ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:440: 
> error: tag not allowed here: <pre>
>      *<pre>
>       ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:466: 
> error: tag not allowed here: <pre>
>      *<pre>
>       ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:414: 
> error: tag not allowed here: <pre>
>      *<pre>
>       ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:375: 
> error: tag not allowed here: <pre>
>      *<pre>
>       ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:484: 
> error: tag not allowed here: <pre>
>      *<pre>
>       ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:427: 
> error: tag not allowed here: <pre>
>      *<pre>
>       ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:453: 
> error: tag not allowed here: <pre>
>      *<pre>
>       ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:401: 
> error: tag not allowed here: <pre>
>      *<pre>
>       ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:513: 
> error: tag not allowed here: <pre>
>      *<pre>
>       ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:640: 
> warning: no @return
>     public static AlphaComposite getInstance(int rule) {
>                                  ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:688: 
> warning: no @return
>     public static AlphaComposite getInstance(int rule, float alpha) {
>                                  ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/lang/Object.java:71: 
> error: tag not allowed here: <ul>
>      * <ul>
>        ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/lang/Object.java:88: 
> error: tag not allowed here: <p>
>      * <p>
>        ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/lang/Object.java:107: 
> error: tag not allowed here: <ul>
>      * <ul>
>        ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/lang/Object.java:129: 
> error: tag not allowed here: <p>
>      * <p>
>        ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/lang/Object.java:136: 
> error: tag not allowed here: <p>
>      * <p>
>        ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEvent.java:52: 
> error: tag not allowed here: <p>
>  * <p>
>    ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEvent.java:392: 
> warning: no @return
>     public int getID() {
>                ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEvent.java:450: 
> warning: no @return
>     protected boolean isConsumed() {
>                       ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/lang/Object.java:228: 
> error: tag not allowed here: <blockquote>
>      * <blockquote>
>        ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:43: 
> error: tag not allowed here: <pre>
>  * <pre><code>
>    ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:66: 
> error: tag not allowed here: <p>
>  * <p>
>    ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:76: 
> error: tag not allowed here: <p>
>  * <p>
>    ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:83: 
> error: tag not allowed here: <p>
>  * <p>
>    ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:86: 
> error: tag not allowed here: <ul>
>  * <ul>
>    ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:95: 
> error: tag not allowed here: <p>
>  * <p>Swing makes use of
>    ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:635: 
> warning: no @return
>     public static ActionListener add(ActionListener a, ActionListener b) {
>                                  ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:655: 
> warning: no @return
>     public static AdjustmentListener add(AdjustmentListener a, 
> AdjustmentListener b) {
>                                      ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:541: 
> warning: no @return
>     public static ComponentListener add(ComponentListener a, 
> ComponentListener b) {
>                                     ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:551: 
> warning: no @return
>     public static ContainerListener add(ContainerListener a, 
> ContainerListener b) {
>                                     ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:561: 
> warning: no @return
>     public static FocusListener add(FocusListener a, FocusListener b) {
>                                 ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:690: 
> warning: no @return
>      public static HierarchyBoundsListener add(HierarchyBoundsListener 
> a, HierarchyBoundsListener b) {
>                                            ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:679: 
> warning: no @return
>      public static HierarchyListener add(HierarchyListener a, 
> HierarchyListener b) {
>                                      ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:668: 
> warning: no @return
>      public static InputMethodListener add(InputMethodListener a, 
> InputMethodListener b) {
>                                        ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:645: 
> warning: no @return
>     public static ItemListener add(ItemListener a, ItemListener b) {
>                                ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:571: 
> warning: no @return
>     public static KeyListener add(KeyListener a, KeyListener b) {
>                               ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:581: 
> warning: no @return
>     public static MouseListener add(MouseListener a, MouseListener b) {
>                                 ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:591: 
> warning: no @return
>     public static MouseMotionListener add(MouseMotionListener a, 
> MouseMotionListener b) {
>                                       ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:701: 
> warning: no @return
>     public static MouseWheelListener add(MouseWheelListener a,
>                                      ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:624: 
> warning: no @return
>     public static WindowFocusListener add(WindowFocusListener a,
>                                       ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:601: 
> warning: no @return
>     public static WindowListener add(WindowListener a, WindowListener b) {
>                                  ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:612: 
> warning: no @return
>     public static WindowStateListener add(WindowStateListener a,
>                                       ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:888: 
> warning: no @return
>     protected static EventListener addInternal(EventListener a, 
> EventListener b) {
>                                    ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:1022:
> warning: no @param for <T>
>         getListeners(EventListener l, Class<T> listenerType)
>         ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:806: 
> warning: no @return
>     public static ActionListener remove(ActionListener l, 
> ActionListener oldl) {
>                                  ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:826: 
> warning: no @return
>     public static AdjustmentListener remove(AdjustmentListener l, 
> AdjustmentListener oldl) {
>                                      ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:712: 
> warning: no @return
>     public static ComponentListener remove(ComponentListener l, 
> ComponentListener oldl) {
>                                     ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:722: 
> warning: no @return
>     public static ContainerListener remove(ContainerListener l, 
> ContainerListener oldl) {
>                                     ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:136: 
> error: tag not allowed here: <p>
>      * <p>
>        ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:732: 
> warning: no @return
>     public static FocusListener remove(FocusListener l, FocusListener 
> oldl) {
>                                 ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:862: 
> warning: no @return
>     public static HierarchyBoundsListener 
> remove(HierarchyBoundsListener l, HierarchyBoundsListener oldl) {
>                                           ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:850: 
> warning: no @return
>     public static HierarchyListener remove(HierarchyListener l, 
> HierarchyListener oldl) {
>                                     ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:839: 
> warning: no @return
>     public static InputMethodListener remove(InputMethodListener l, 
> InputMethodListener oldl) {
>                                       ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:816: 
> warning: no @return
>     public static ItemListener remove(ItemListener l, ItemListener oldl) {
>                                ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:742: 
> warning: no @return
>     public static KeyListener remove(KeyListener l, KeyListener oldl) {
>                               ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:752: 
> warning: no @return
>     public static MouseListener remove(MouseListener l, MouseListener 
> oldl) {
>                                 ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:762: 
> warning: no @return
>     public static MouseMotionListener remove(MouseMotionListener l, 
> MouseMotionListener oldl) {
>                                       ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:873: 
> warning: no @return
>     public static MouseWheelListener remove(MouseWheelListener l,
>                                      ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:795: 
> warning: no @return
>     public static WindowFocusListener remove(WindowFocusListener l,
>                                       ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:772: 
> warning: no @return
>     public static WindowListener remove(WindowListener l, 
> WindowListener oldl) {
>                                  ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:783: 
> warning: no @return
>     public static WindowStateListener remove(WindowStateListener l,
>                                       ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:905: 
> warning: no @return
>     protected static EventListener removeInternal(EventListener l, 
> EventListener oldl) {
>                                    ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/TextListener.java:53: 
> warning: no @param for e
>     public void textValueChanged(TextEvent e);
>                 ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/ComponentListener.java:58: 
> warning: no @param for e
>     public void componentResized(ComponentEvent e);
>                 ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/ComponentListener.java:63: 
> warning: no @param for e
>     public void componentMoved(ComponentEvent e);
>                 ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/ComponentListener.java:68: 
> warning: no @param for e
>     public void componentShown(ComponentEvent e);
>                 ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/ComponentListener.java:73: 
> warning: no @param for e
>     public void componentHidden(ComponentEvent e);
>                 ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/ContainerListener.java:59: 
> warning: no @param for e
>     public void componentAdded(ContainerEvent e);
>                 ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/ContainerListener.java:64: 
> warning: no @param for e
>     public void componentRemoved(ContainerEvent e);
>                 ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/FocusListener.java:55: 
> warning: no @param for e
>     public void focusGained(FocusEvent e);
>                 ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/FocusListener.java:60: 
> warning: no @param for e
>     public void focusLost(FocusEvent e);
>                 ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/KeyListener.java:58: 
> warning: no @param for e
>     public void keyTyped(KeyEvent e);
>                 ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/KeyListener.java:65: 
> warning: no @param for e
>     public void keyPressed(KeyEvent e);
>                 ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/KeyListener.java:72: 
> warning: no @param for e
>     public void keyReleased(KeyEvent e);
>                 ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/MouseListener.java:63: 
> warning: no @param for e
>     public void mouseClicked(MouseEvent e);
>                 ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/MouseListener.java:68: 
> warning: no @param for e
>     public void mousePressed(MouseEvent e);
>                 ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/MouseListener.java:73: 
> warning: no @param for e
>     public void mouseReleased(MouseEvent e);
>                 ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/MouseListener.java:78: 
> warning: no @param for e
>     public void mouseEntered(MouseEvent e);
>                 ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/MouseListener.java:83: 
> warning: no @param for e
>     public void mouseExited(MouseEvent e);
>                 ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/MouseMotionListener.java:63: 
> error: semicolon missing
>      * Due to platform-dependent Drag&Drop implementations,
>                                      ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/MouseMotionListener.java:65: 
> error: semicolon missing
>      * Drag&Drop operation.
>            ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/MouseMotionListener.java:67: 
> warning: no @param for e
>     public void mouseDragged(MouseEvent e);
>                 ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/MouseMotionListener.java:73: 
> warning: no @param for e
>     public void mouseMoved(MouseEvent e);
>                 ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/WindowListener.java:55: 
> warning: no @param for e
>     public void windowOpened(WindowEvent e);
>                 ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/WindowListener.java:61: 
> warning: no @param for e
>     public void windowClosing(WindowEvent e);
>                 ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/WindowListener.java:67: 
> warning: no @param for e
>     public void windowClosed(WindowEvent e);
>                 ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/WindowListener.java:76: 
> warning: no @param for e
>     public void windowIconified(WindowEvent e);
>                 ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/WindowListener.java:82: 
> warning: no @param for e
>     public void windowDeiconified(WindowEvent e);
>                 ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/WindowListener.java:92: 
> warning: no @param for e
>     public void windowActivated(WindowEvent e);
>                 ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/WindowListener.java:102: 
> warning: no @param for e
>     public void windowDeactivated(WindowEvent e);
>                 ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/WindowStateListener.java:54: 
> warning: no @param for e
>     public void windowStateChanged(WindowEvent e);
>                 ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/WindowFocusListener.java:61: 
> warning: no @param for e
>     public void windowGainedFocus(WindowEvent e);
>                 ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/WindowFocusListener.java:68: 
> warning: no @param for e
>     public void windowLostFocus(WindowEvent e);
>                 ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/ActionListener.java:50: 
> warning: no @param for e
>     public void actionPerformed(ActionEvent e);
>                 ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/ItemListener.java:54: 
> warning: no @param for e
>     void itemStateChanged(ItemEvent e);
>          ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/AdjustmentListener.java:41: 
> warning: no @param for e
>     public void adjustmentValueChanged(AdjustmentEvent e);
>                 ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/InputMethodListener.java:49: 
> warning: no @param for event
>     void inputMethodTextChanged(InputMethodEvent event);
>          ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/InputMethodListener.java:54: 
> warning: no @param for event
>     void caretPositionChanged(InputMethodEvent event);
>          ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/HierarchyListener.java:56: 
> warning: no @param for e
>     public void hierarchyChanged(HierarchyEvent e);
>                 ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/HierarchyBoundsListener.java:56: 
> warning: no @param for e
>     public void ancestorMoved(HierarchyEvent e);
>                 ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/HierarchyBoundsListener.java:61: 
> warning: no @param for e
>     public void ancestorResized(HierarchyEvent e);
>                 ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/MouseWheelListener.java:57: 
> warning: no @param for e
>     public void mouseWheelMoved(MouseWheelEvent e);
>                 ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTKeyStroke.java:402: 
> error: tag not allowed here: <ul>
>      * used to specify the key code. For example:<ul>
>                                                  ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTKeyStroke.java:407: 
> error: tag not allowed here: <ul>
>      * The modifiers consist of any combination of:<ul>
>                                                    ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTKeyStroke.java:414: 
> error: tag not allowed here: <ul>
>      * The old modifiers <ul>
>                          ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTKeyStroke.java:352: 
> error: tag not allowed here: <ul>
>      * used to specify the key code. For example:<ul>
>                                                  ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTKeyStroke.java:360: 
> error: tag not allowed here: <ul>
>      * The modifiers consist of any combination of:<ul>
>                                                    ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTKeyStroke.java:367: 
> error: tag not allowed here: <ul>
>      * The old modifiers <ul>
>                          ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTKeyStroke.java:488: 
> error: bad use of '>'
>      *     "INSERT" => getAWTKeyStroke(KeyEvent.VK_INSERT, 0);
>                      ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTKeyStroke.java:489: 
> error: bad use of '>'
>      *     "control DELETE" => getAWTKeyStroke(KeyEvent.VK_DELETE, 
> InputEvent.CTRL_MASK);
>                              ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTKeyStroke.java:490: 
> error: bad use of '>'
>      *     "alt shift X" => getAWTKeyStroke(KeyEvent.VK_X, 
> InputEvent.ALT_MASK | InputEvent.SHIFT_MASK);
>                           ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTKeyStroke.java:491: 
> error: bad use of '>'
>      *     "alt shift released X" => getAWTKeyStroke(KeyEvent.VK_X, 
> InputEvent.ALT_MASK | InputEvent.SHIFT_MASK, true);
>                                    ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTKeyStroke.java:492: 
> error: bad use of '>'
>      *     "typed a" => getAWTKeyStroke('a');
>                       ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTKeyStroke.java:803: 
> warning: no @throws for java.io.ObjectStreamException
>     protected Object readResolve() throws java.io.ObjectStreamException {
>                      ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTPermission.java:41: 
> error: tag not allowed here: <P>
>  * <P>
>    ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTPermission.java:46: 
> error: tag not allowed here: <P>
>  * <P>
>    ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTPermission.java:48: 
> error: tag not allowed here: <table>
>  * <table border=1 cellpadding=5 summary="AWTPermission target names, 
> descriptions, and associated risks.">
>    ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/BasicStroke.java:42: 
> warning: attribute obsolete, use CSS instead: compact
>  * <dl compact>
>        ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/BorderLayout.java:61: 
> error: tag not allowed here: <p>
>  * <p>
>    ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/BorderLayout.java:70: 
> error: tag not allowed here: <p>
>  * <p>
>    ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/BorderLayout.java:78: 
> error: tag not allowed here: <p>
>  * <p>
>    ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/BorderLayout.java:83: 
> error: tag not allowed here: <p>
>  * <p>
>    ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/BorderLayout.java:91: 
> error: tag not allowed here: <p>
>  * <p>
>    ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/BorderLayout.java:94: 
> error: tag not allowed here: <p>
>  * <p>
>    ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/BorderLayout.java:99: 
> warning: attribute obsolete, use CSS instead: ALIGN
>  * ALIGN=center HSPACE=10 VSPACE=7>
>    ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/BorderLayout.java:99: 
> warning: attribute obsolete, use CSS instead: HSPACE
>  * ALIGN=center HSPACE=10 VSPACE=7>
>                 ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/BorderLayout.java:99: 
> warning: attribute obsolete, use CSS instead: VSPACE
>  * ALIGN=center HSPACE=10 VSPACE=7>
>                           ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/BorderLayout.java:100: 
> error: tag not allowed here: <p>
>  * <p>
>    ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/BorderLayout.java:102: 
> error: tag not allowed here: <p>
>  * <p>
>    ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/BorderLayout.java:103: 
> error: tag not allowed here: <hr>
>  * <hr><blockquote><pre>
>    ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/BorderLayout.java:103: 
> error: tag not allowed here: <blockquote>
>  * <hr><blockquote><pre>
>        ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/BorderLayout.java:117: 
> error: tag not allowed here: <hr>
>  * </pre></blockquote><hr>
>                       ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/BorderLayout.java:118: 
> error: tag not allowed here: <p>
>  * <p>
>    ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/BorderLayout.java:372: 
> warning: no @return
>     public int getHgap() {
>                ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/BorderLayout.java:389: 
> warning: no @return
>     public int getVgap() {
>                ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/BorderLayout.java:795: 
> error: tag not allowed here: <p>
>      * <p>
>        ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/LayoutManager2.java:61: 
> warning: no @param for target
>     public Dimension maximumLayoutSize(Container target);
>                      ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/LayoutManager2.java:61: 
> warning: no @return
>     public Dimension maximumLayoutSize(Container target);
>                      ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/LayoutManager2.java:70: 
> warning: no @param for target
>     public float getLayoutAlignmentX(Container target);
>                  ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/LayoutManager2.java:70: 
> warning: no @return
>     public float getLayoutAlignmentX(Container target);
>                  ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/LayoutManager2.java:79: 
> warning: no @param for target
>     public float getLayoutAlignmentY(Container target);
>                  ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/lang/Object.java:174: 
> error: tag not allowed here: <p>
>      * <p>
>        ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/lang/Object.java:185: 
> error: tag not allowed here: <p>
>      * <p>
>        ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/lang/Object.java:198: 
> error: tag not allowed here: <p>
>      * <p>
>        ^
> 100 errors
> 100 warnings
> make[1]: *** 
> [/export/users/dh198349/lambda/builds/b00/se-linux-i586-ea/docs/api/index.html] 
> Error 1
> make: *** [docs-only] Error 2
> 

From david.holmes at oracle.com  Mon Feb  4 22:46:03 2013
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 05 Feb 2013 16:46:03 +1000
Subject: Hundreds of errors generating javadoc ??
In-Reply-To: <1A9F9B72-955D-4960-83F0-9D376979136A@oracle.com>
References: <51109C40.6000303@oracle.com>
	<1A9F9B72-955D-4960-83F0-9D376979136A@oracle.com>
Message-ID: <5110AAAB.10203@oracle.com>

Hi Mike,

On 5/02/2013 3:57 PM, Mike Duigou wrote:
> This looks like doclint but that shouldn't be enabled yet for lambda repo. I disabled doclint for all of lambda lat integration. I will investigate in the morning.

Comparing to mainline looks like you need:

                 -Xdoclint:none                          \

added to the javadoc common options in 
common/makefiles/javadoc/Javadoc.gmk. But that doesn't fix it - the 
doclint:none doesn't seem to be getting passed through (or else isn't 
recognized by the javadoc tool). :(

Thanks for the tip! Must say though that I'm slightly concerned that <p> 
tags are prohibited.

David

>
> On Feb 4, 2013, at 9:44 PM, David Holmes<david.holmes at oracle.com>  wrote:
>
>> Not sure what is going on as this is a fresh clone of the lambda forest
>> and the errors are in packages all over the place (unrelated to lambda
>> changes).
>>
>> ??
>>
>> David
>> -----
>>
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/applet/Applet.java:527:
>> error: tag not allowed here:<p>
>>       *<p>
>>         ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/applet/Applet.java:183:
>> error: tag not allowed here:<p>
>>       *<p>
>>         ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/applet/Applet.java:395:
>> error: tag not allowed here:<p>
>>       *<p><blockquote><pre>
>>         ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/applet/Applet.java:395:
>> error: tag not allowed here:<blockquote>
>>       *<p><blockquote><pre>
>>            ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/applet/Applet.java:402:
>> error: tag not allowed here:<p>
>>       *<p>
>>         ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/applet/Applet.java:451:
>> error: tag not allowed here:<p>
>>       *<p>
>>         ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/applet/Applet.java:474:
>> error: tag not allowed here:<p>
>>       *<p>
>>         ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/applet/Applet.java:481:
>> error: tag not allowed here:<p>
>>       *<p>
>>         ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/applet/Applet.java:506:
>> error: tag not allowed here:<p>
>>       *<p>
>>         ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/Component.java:2168:
>> warning: no @param for width
>>      public void resize(int width, int height) {
>>                  ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/Component.java:2168:
>> warning: no @param for height
>>      public void resize(int width, int height) {
>>                  ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/Component.java:2199:
>> warning: no @param for d
>>      public void resize(Dimension d) {
>>                  ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/javax/accessibility/Accessible.java:49:
>> warning: no @return
>>      public AccessibleContext getAccessibleContext();
>>                               ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/applet/AppletContext.java:59:
>> warning: empty<code>  tag
>>       * the screen. The<code>url</code>  argument<code>  </code>that is
>>                                                         ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/applet/AppletContext.java:175:
>> error: tag not allowed here:<p>
>>       *<p>
>>         ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/applet/AppletContext.java:188:
>> error: tag not allowed here:<p>
>>       *<p>
>>         ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/applet/AppletContext.java:155:
>> error: tag not allowed here:<p>
>>       *<p>
>>         ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/applet/AppletContext.java:160:
>> error: unexpected text
>>       * @throws<code>IOException</code>  if the stream size exceeds a
>> certain
>>         ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/applet/AppletContext.java:165:
>> warning: no @throws for java.io.IOException
>>      public void setStream(String key, InputStream stream)throws
>> IOException;
>>                  ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/applet/AppletContext.java:111:
>> error: tag not allowed here:<center>
>>       *<center><table border="3" summary="Target arguments and their
>> descriptions">
>>         ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/applet/AppletContext.java:128:
>> error: tag not allowed here:<p>
>>       *<p>
>>         ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/ActiveEvent.java:42:
>> error: tag not allowed here:<p>
>>   *<p>
>>     ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:51:
>> error: tag not allowed here:<p>
>>   *<p>
>>     ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:62:
>> error: tag not allowed here:<p>
>>   *<p>
>>     ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:71:
>> error: tag not allowed here:<p>
>>   *<p>
>>     ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:75:
>> error: tag not allowed here:<blockquote>
>>   *<blockquote>
>>     ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:90:
>> error: tag not allowed here:<p>
>>   *<p>
>>     ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:105:
>> error: tag not allowed here:<pre>
>>   *<pre>
>>     ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:111:
>> error: tag not allowed here:<p>
>>   *<p>
>>     ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:115:
>> error: tag not allowed here:<blockquote>
>>   *<blockquote>
>>     ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:128:
>> error: tag not allowed here:<h3>
>>   *<h3>Preparing Inputs</h3>
>>     ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:130:
>> error: tag not allowed here:<p>
>>   *<p>
>>     ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:140:
>> error: tag not allowed here:<pre>
>>   *<pre>
>>     ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:152:
>> error: tag not allowed here:<pre>
>>   *<pre>
>>     ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:158:
>> error: tag not allowed here:<pre>
>>   *<pre>
>>     ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:161:
>> error: tag not allowed here:<p>
>>   *<p>
>>     ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:165:
>> error: tag not allowed here:<pre>
>>   *<pre>
>>     ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:169:
>> error: tag not allowed here:<h3>
>>   *<h3>Applying the Blending Equation</h3>
>>     ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:171:
>> error: tag not allowed here:<p>
>>   *<p>
>>     ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:178:
>> error: tag not allowed here:<p>
>>   *<p>
>>     ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:179:
>> error: tag not allowed here:<h3>
>>   *<h3>Preparing Results</h3>
>>     ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:181:
>> error: tag not allowed here:<p>
>>   *<p>
>>     ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:186:
>> error: tag not allowed here:<pre>
>>   *<pre>
>>     ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:196:
>> error: tag not allowed here:<p>
>>   *<p>
>>     ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:197:
>> error: tag not allowed here:<h3>
>>   *<h3>Performance Considerations</h3>
>>     ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:199:
>> error: tag not allowed here:<p>
>>   *<p>
>>     ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:210:
>> error: tag not allowed here:<h3>
>>   *<h3><a name="caveats">Implementation Caveats</a></h3>
>>     ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:212:
>> error: tag not allowed here:<ul>
>>   *<ul>
>>     ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:362:
>> error: tag not allowed here:<pre>
>>       *<pre>
>>        ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:387:
>> error: tag not allowed here:<pre>
>>       *<pre>
>>        ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:498:
>> error: tag not allowed here:<pre>
>>       *<pre>
>>        ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:440:
>> error: tag not allowed here:<pre>
>>       *<pre>
>>        ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:466:
>> error: tag not allowed here:<pre>
>>       *<pre>
>>        ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:414:
>> error: tag not allowed here:<pre>
>>       *<pre>
>>        ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:375:
>> error: tag not allowed here:<pre>
>>       *<pre>
>>        ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:484:
>> error: tag not allowed here:<pre>
>>       *<pre>
>>        ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:427:
>> error: tag not allowed here:<pre>
>>       *<pre>
>>        ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:453:
>> error: tag not allowed here:<pre>
>>       *<pre>
>>        ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:401:
>> error: tag not allowed here:<pre>
>>       *<pre>
>>        ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:513:
>> error: tag not allowed here:<pre>
>>       *<pre>
>>        ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:640:
>> warning: no @return
>>      public static AlphaComposite getInstance(int rule) {
>>                                   ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:688:
>> warning: no @return
>>      public static AlphaComposite getInstance(int rule, float alpha) {
>>                                   ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/lang/Object.java:71:
>> error: tag not allowed here:<ul>
>>       *<ul>
>>         ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/lang/Object.java:88:
>> error: tag not allowed here:<p>
>>       *<p>
>>         ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/lang/Object.java:107:
>> error: tag not allowed here:<ul>
>>       *<ul>
>>         ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/lang/Object.java:129:
>> error: tag not allowed here:<p>
>>       *<p>
>>         ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/lang/Object.java:136:
>> error: tag not allowed here:<p>
>>       *<p>
>>         ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEvent.java:52:
>> error: tag not allowed here:<p>
>>   *<p>
>>     ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEvent.java:392:
>> warning: no @return
>>      public int getID() {
>>                 ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEvent.java:450:
>> warning: no @return
>>      protected boolean isConsumed() {
>>                        ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/lang/Object.java:228:
>> error: tag not allowed here:<blockquote>
>>       *<blockquote>
>>         ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:43:
>> error: tag not allowed here:<pre>
>>   *<pre><code>
>>     ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:66:
>> error: tag not allowed here:<p>
>>   *<p>
>>     ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:76:
>> error: tag not allowed here:<p>
>>   *<p>
>>     ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:83:
>> error: tag not allowed here:<p>
>>   *<p>
>>     ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:86:
>> error: tag not allowed here:<ul>
>>   *<ul>
>>     ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:95:
>> error: tag not allowed here:<p>
>>   *<p>Swing makes use of
>>     ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:635:
>> warning: no @return
>>      public static ActionListener add(ActionListener a, ActionListener b) {
>>                                   ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:655:
>> warning: no @return
>>      public static AdjustmentListener add(AdjustmentListener a,
>> AdjustmentListener b) {
>>                                       ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:541:
>> warning: no @return
>>      public static ComponentListener add(ComponentListener a,
>> ComponentListener b) {
>>                                      ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:551:
>> warning: no @return
>>      public static ContainerListener add(ContainerListener a,
>> ContainerListener b) {
>>                                      ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:561:
>> warning: no @return
>>      public static FocusListener add(FocusListener a, FocusListener b) {
>>                                  ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:690:
>> warning: no @return
>>       public static HierarchyBoundsListener add(HierarchyBoundsListener
>> a, HierarchyBoundsListener b) {
>>                                             ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:679:
>> warning: no @return
>>       public static HierarchyListener add(HierarchyListener a,
>> HierarchyListener b) {
>>                                       ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:668:
>> warning: no @return
>>       public static InputMethodListener add(InputMethodListener a,
>> InputMethodListener b) {
>>                                         ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:645:
>> warning: no @return
>>      public static ItemListener add(ItemListener a, ItemListener b) {
>>                                 ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:571:
>> warning: no @return
>>      public static KeyListener add(KeyListener a, KeyListener b) {
>>                                ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:581:
>> warning: no @return
>>      public static MouseListener add(MouseListener a, MouseListener b) {
>>                                  ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:591:
>> warning: no @return
>>      public static MouseMotionListener add(MouseMotionListener a,
>> MouseMotionListener b) {
>>                                        ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:701:
>> warning: no @return
>>      public static MouseWheelListener add(MouseWheelListener a,
>>                                       ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:624:
>> warning: no @return
>>      public static WindowFocusListener add(WindowFocusListener a,
>>                                        ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:601:
>> warning: no @return
>>      public static WindowListener add(WindowListener a, WindowListener b) {
>>                                   ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:612:
>> warning: no @return
>>      public static WindowStateListener add(WindowStateListener a,
>>                                        ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:888:
>> warning: no @return
>>      protected static EventListener addInternal(EventListener a,
>> EventListener b) {
>>                                     ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:1022:
>> warning: no @param for<T>
>>          getListeners(EventListener l, Class<T>  listenerType)
>>          ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:806:
>> warning: no @return
>>      public static ActionListener remove(ActionListener l,
>> ActionListener oldl) {
>>                                   ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:826:
>> warning: no @return
>>      public static AdjustmentListener remove(AdjustmentListener l,
>> AdjustmentListener oldl) {
>>                                       ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:712:
>> warning: no @return
>>      public static ComponentListener remove(ComponentListener l,
>> ComponentListener oldl) {
>>                                      ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:722:
>> warning: no @return
>>      public static ContainerListener remove(ContainerListener l,
>> ContainerListener oldl) {
>>                                      ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:136:
>> error: tag not allowed here:<p>
>>       *<p>
>>         ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:732:
>> warning: no @return
>>      public static FocusListener remove(FocusListener l, FocusListener
>> oldl) {
>>                                  ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:862:
>> warning: no @return
>>      public static HierarchyBoundsListener
>> remove(HierarchyBoundsListener l, HierarchyBoundsListener oldl) {
>>                                            ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:850:
>> warning: no @return
>>      public static HierarchyListener remove(HierarchyListener l,
>> HierarchyListener oldl) {
>>                                      ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:839:
>> warning: no @return
>>      public static InputMethodListener remove(InputMethodListener l,
>> InputMethodListener oldl) {
>>                                        ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:816:
>> warning: no @return
>>      public static ItemListener remove(ItemListener l, ItemListener oldl) {
>>                                 ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:742:
>> warning: no @return
>>      public static KeyListener remove(KeyListener l, KeyListener oldl) {
>>                                ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:752:
>> warning: no @return
>>      public static MouseListener remove(MouseListener l, MouseListener
>> oldl) {
>>                                  ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:762:
>> warning: no @return
>>      public static MouseMotionListener remove(MouseMotionListener l,
>> MouseMotionListener oldl) {
>>                                        ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:873:
>> warning: no @return
>>      public static MouseWheelListener remove(MouseWheelListener l,
>>                                       ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:795:
>> warning: no @return
>>      public static WindowFocusListener remove(WindowFocusListener l,
>>                                        ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:772:
>> warning: no @return
>>      public static WindowListener remove(WindowListener l,
>> WindowListener oldl) {
>>                                   ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:783:
>> warning: no @return
>>      public static WindowStateListener remove(WindowStateListener l,
>>                                        ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:905:
>> warning: no @return
>>      protected static EventListener removeInternal(EventListener l,
>> EventListener oldl) {
>>                                     ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/TextListener.java:53:
>> warning: no @param for e
>>      public void textValueChanged(TextEvent e);
>>                  ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/ComponentListener.java:58:
>> warning: no @param for e
>>      public void componentResized(ComponentEvent e);
>>                  ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/ComponentListener.java:63:
>> warning: no @param for e
>>      public void componentMoved(ComponentEvent e);
>>                  ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/ComponentListener.java:68:
>> warning: no @param for e
>>      public void componentShown(ComponentEvent e);
>>                  ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/ComponentListener.java:73:
>> warning: no @param for e
>>      public void componentHidden(ComponentEvent e);
>>                  ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/ContainerListener.java:59:
>> warning: no @param for e
>>      public void componentAdded(ContainerEvent e);
>>                  ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/ContainerListener.java:64:
>> warning: no @param for e
>>      public void componentRemoved(ContainerEvent e);
>>                  ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/FocusListener.java:55:
>> warning: no @param for e
>>      public void focusGained(FocusEvent e);
>>                  ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/FocusListener.java:60:
>> warning: no @param for e
>>      public void focusLost(FocusEvent e);
>>                  ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/KeyListener.java:58:
>> warning: no @param for e
>>      public void keyTyped(KeyEvent e);
>>                  ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/KeyListener.java:65:
>> warning: no @param for e
>>      public void keyPressed(KeyEvent e);
>>                  ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/KeyListener.java:72:
>> warning: no @param for e
>>      public void keyReleased(KeyEvent e);
>>                  ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/MouseListener.java:63:
>> warning: no @param for e
>>      public void mouseClicked(MouseEvent e);
>>                  ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/MouseListener.java:68:
>> warning: no @param for e
>>      public void mousePressed(MouseEvent e);
>>                  ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/MouseListener.java:73:
>> warning: no @param for e
>>      public void mouseReleased(MouseEvent e);
>>                  ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/MouseListener.java:78:
>> warning: no @param for e
>>      public void mouseEntered(MouseEvent e);
>>                  ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/MouseListener.java:83:
>> warning: no @param for e
>>      public void mouseExited(MouseEvent e);
>>                  ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/MouseMotionListener.java:63:
>> error: semicolon missing
>>       * Due to platform-dependent Drag&Drop implementations,
>>                                       ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/MouseMotionListener.java:65:
>> error: semicolon missing
>>       * Drag&Drop operation.
>>             ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/MouseMotionListener.java:67:
>> warning: no @param for e
>>      public void mouseDragged(MouseEvent e);
>>                  ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/MouseMotionListener.java:73:
>> warning: no @param for e
>>      public void mouseMoved(MouseEvent e);
>>                  ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/WindowListener.java:55:
>> warning: no @param for e
>>      public void windowOpened(WindowEvent e);
>>                  ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/WindowListener.java:61:
>> warning: no @param for e
>>      public void windowClosing(WindowEvent e);
>>                  ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/WindowListener.java:67:
>> warning: no @param for e
>>      public void windowClosed(WindowEvent e);
>>                  ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/WindowListener.java:76:
>> warning: no @param for e
>>      public void windowIconified(WindowEvent e);
>>                  ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/WindowListener.java:82:
>> warning: no @param for e
>>      public void windowDeiconified(WindowEvent e);
>>                  ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/WindowListener.java:92:
>> warning: no @param for e
>>      public void windowActivated(WindowEvent e);
>>                  ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/WindowListener.java:102:
>> warning: no @param for e
>>      public void windowDeactivated(WindowEvent e);
>>                  ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/WindowStateListener.java:54:
>> warning: no @param for e
>>      public void windowStateChanged(WindowEvent e);
>>                  ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/WindowFocusListener.java:61:
>> warning: no @param for e
>>      public void windowGainedFocus(WindowEvent e);
>>                  ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/WindowFocusListener.java:68:
>> warning: no @param for e
>>      public void windowLostFocus(WindowEvent e);
>>                  ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/ActionListener.java:50:
>> warning: no @param for e
>>      public void actionPerformed(ActionEvent e);
>>                  ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/ItemListener.java:54:
>> warning: no @param for e
>>      void itemStateChanged(ItemEvent e);
>>           ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/AdjustmentListener.java:41:
>> warning: no @param for e
>>      public void adjustmentValueChanged(AdjustmentEvent e);
>>                  ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/InputMethodListener.java:49:
>> warning: no @param for event
>>      void inputMethodTextChanged(InputMethodEvent event);
>>           ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/InputMethodListener.java:54:
>> warning: no @param for event
>>      void caretPositionChanged(InputMethodEvent event);
>>           ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/HierarchyListener.java:56:
>> warning: no @param for e
>>      public void hierarchyChanged(HierarchyEvent e);
>>                  ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/HierarchyBoundsListener.java:56:
>> warning: no @param for e
>>      public void ancestorMoved(HierarchyEvent e);
>>                  ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/HierarchyBoundsListener.java:61:
>> warning: no @param for e
>>      public void ancestorResized(HierarchyEvent e);
>>                  ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/MouseWheelListener.java:57:
>> warning: no @param for e
>>      public void mouseWheelMoved(MouseWheelEvent e);
>>                  ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTKeyStroke.java:402:
>> error: tag not allowed here:<ul>
>>       * used to specify the key code. For example:<ul>
>>                                                   ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTKeyStroke.java:407:
>> error: tag not allowed here:<ul>
>>       * The modifiers consist of any combination of:<ul>
>>                                                     ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTKeyStroke.java:414:
>> error: tag not allowed here:<ul>
>>       * The old modifiers<ul>
>>                           ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTKeyStroke.java:352:
>> error: tag not allowed here:<ul>
>>       * used to specify the key code. For example:<ul>
>>                                                   ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTKeyStroke.java:360:
>> error: tag not allowed here:<ul>
>>       * The modifiers consist of any combination of:<ul>
>>                                                     ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTKeyStroke.java:367:
>> error: tag not allowed here:<ul>
>>       * The old modifiers<ul>
>>                           ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTKeyStroke.java:488:
>> error: bad use of '>'
>>       *     "INSERT" =>  getAWTKeyStroke(KeyEvent.VK_INSERT, 0);
>>                       ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTKeyStroke.java:489:
>> error: bad use of '>'
>>       *     "control DELETE" =>  getAWTKeyStroke(KeyEvent.VK_DELETE,
>> InputEvent.CTRL_MASK);
>>                               ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTKeyStroke.java:490:
>> error: bad use of '>'
>>       *     "alt shift X" =>  getAWTKeyStroke(KeyEvent.VK_X,
>> InputEvent.ALT_MASK | InputEvent.SHIFT_MASK);
>>                            ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTKeyStroke.java:491:
>> error: bad use of '>'
>>       *     "alt shift released X" =>  getAWTKeyStroke(KeyEvent.VK_X,
>> InputEvent.ALT_MASK | InputEvent.SHIFT_MASK, true);
>>                                     ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTKeyStroke.java:492:
>> error: bad use of '>'
>>       *     "typed a" =>  getAWTKeyStroke('a');
>>                        ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTKeyStroke.java:803:
>> warning: no @throws for java.io.ObjectStreamException
>>      protected Object readResolve() throws java.io.ObjectStreamException {
>>                       ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTPermission.java:41:
>> error: tag not allowed here:<P>
>>   *<P>
>>     ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTPermission.java:46:
>> error: tag not allowed here:<P>
>>   *<P>
>>     ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTPermission.java:48:
>> error: tag not allowed here:<table>
>>   *<table border=1 cellpadding=5 summary="AWTPermission target names,
>> descriptions, and associated risks.">
>>     ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/BasicStroke.java:42:
>> warning: attribute obsolete, use CSS instead: compact
>>   *<dl compact>
>>         ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/BorderLayout.java:61:
>> error: tag not allowed here:<p>
>>   *<p>
>>     ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/BorderLayout.java:70:
>> error: tag not allowed here:<p>
>>   *<p>
>>     ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/BorderLayout.java:78:
>> error: tag not allowed here:<p>
>>   *<p>
>>     ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/BorderLayout.java:83:
>> error: tag not allowed here:<p>
>>   *<p>
>>     ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/BorderLayout.java:91:
>> error: tag not allowed here:<p>
>>   *<p>
>>     ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/BorderLayout.java:94:
>> error: tag not allowed here:<p>
>>   *<p>
>>     ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/BorderLayout.java:99:
>> warning: attribute obsolete, use CSS instead: ALIGN
>>   * ALIGN=center HSPACE=10 VSPACE=7>
>>     ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/BorderLayout.java:99:
>> warning: attribute obsolete, use CSS instead: HSPACE
>>   * ALIGN=center HSPACE=10 VSPACE=7>
>>                  ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/BorderLayout.java:99:
>> warning: attribute obsolete, use CSS instead: VSPACE
>>   * ALIGN=center HSPACE=10 VSPACE=7>
>>                            ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/BorderLayout.java:100:
>> error: tag not allowed here:<p>
>>   *<p>
>>     ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/BorderLayout.java:102:
>> error: tag not allowed here:<p>
>>   *<p>
>>     ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/BorderLayout.java:103:
>> error: tag not allowed here:<hr>
>>   *<hr><blockquote><pre>
>>     ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/BorderLayout.java:103:
>> error: tag not allowed here:<blockquote>
>>   *<hr><blockquote><pre>
>>         ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/BorderLayout.java:117:
>> error: tag not allowed here:<hr>
>>   *</pre></blockquote><hr>
>>                        ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/BorderLayout.java:118:
>> error: tag not allowed here:<p>
>>   *<p>
>>     ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/BorderLayout.java:372:
>> warning: no @return
>>      public int getHgap() {
>>                 ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/BorderLayout.java:389:
>> warning: no @return
>>      public int getVgap() {
>>                 ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/BorderLayout.java:795:
>> error: tag not allowed here:<p>
>>       *<p>
>>         ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/LayoutManager2.java:61:
>> warning: no @param for target
>>      public Dimension maximumLayoutSize(Container target);
>>                       ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/LayoutManager2.java:61:
>> warning: no @return
>>      public Dimension maximumLayoutSize(Container target);
>>                       ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/LayoutManager2.java:70:
>> warning: no @param for target
>>      public float getLayoutAlignmentX(Container target);
>>                   ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/LayoutManager2.java:70:
>> warning: no @return
>>      public float getLayoutAlignmentX(Container target);
>>                   ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/LayoutManager2.java:79:
>> warning: no @param for target
>>      public float getLayoutAlignmentY(Container target);
>>                   ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/lang/Object.java:174:
>> error: tag not allowed here:<p>
>>       *<p>
>>         ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/lang/Object.java:185:
>> error: tag not allowed here:<p>
>>       *<p>
>>         ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/lang/Object.java:198:
>> error: tag not allowed here:<p>
>>       *<p>
>>         ^
>> 100 errors
>> 100 warnings
>> make[1]: ***
>> [/export/users/dh198349/lambda/builds/b00/se-linux-i586-ea/docs/api/index.html]
>> Error 1
>> make: *** [docs-only] Error 2
>>

From paul.sandoz at oracle.com  Tue Feb  5 00:44:40 2013
From: paul.sandoz at oracle.com (paul.sandoz at oracle.com)
Date: Tue, 05 Feb 2013 08:44:40 +0000
Subject: hg: lambda/lambda/jdk: Remove PrimitiveIterator and enclose
	primitive-based iterators
Message-ID: <20130205084509.82C4C47825@hg.openjdk.java.net>

Changeset: fefeac4bee4a
Author:    psandoz
Date:      2013-02-05 09:44 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/fefeac4bee4a

Remove PrimitiveIterator and enclose primitive-based iterators
within correspond primtive stream.
Contributed-by: Brian Goetz <brian.goetz at Oracle.COM>

! src/share/classes/java/lang/CharSequence.java
! src/share/classes/java/util/BitSet.java
- src/share/classes/java/util/PrimitiveIterator.java
! src/share/classes/java/util/stream/DoubleStream.java
! src/share/classes/java/util/stream/IntStream.java
! src/share/classes/java/util/stream/LongStream.java
! src/share/classes/java/util/stream/SpinedBuffer.java
! src/share/classes/java/util/stream/Streams.java
! test-ng/bootlib/java/util/stream/DoubleStreamTestData.java
! test-ng/bootlib/java/util/stream/DoubleStreamTestScenario.java
! test-ng/bootlib/java/util/stream/IntStreamTestData.java
! test-ng/bootlib/java/util/stream/IntStreamTestScenario.java
! test-ng/bootlib/java/util/stream/LambdaTestHelpers.java
! test-ng/bootlib/java/util/stream/LongStreamTestData.java
! test-ng/bootlib/java/util/stream/LongStreamTestScenario.java
! test-ng/boottests/java/util/stream/DoubleNodeTest.java
! test-ng/boottests/java/util/stream/IntNodeTest.java
! test-ng/boottests/java/util/stream/LongNodeTest.java
! test-ng/boottests/java/util/stream/NodeBuilderTest.java
! test-ng/boottests/java/util/stream/SpinedBufferTest.java
! test-ng/tests/org/openjdk/tests/java/lang/CharSequenceStreamTest.java
! test-ng/tests/org/openjdk/tests/java/util/BitsetStreamTest.java
! test-ng/tests/org/openjdk/tests/java/util/stream/FindAnyOpTest.java
! test-ng/tests/org/openjdk/tests/java/util/stream/FindFirstOpTest.java
! test-ng/tests/org/openjdk/tests/java/util/stream/MatchOpTest.java
! test/java/util/stream/Stream/IntegerStreamTest.java
! test/java/util/stream/Streams/BasicTest.java


From zhong.j.yu at gmail.com  Tue Feb  5 01:00:22 2013
From: zhong.j.yu at gmail.com (Zhong Yu)
Date: Tue, 5 Feb 2013 03:00:22 -0600
Subject: UncheckedIOException and suppressed exception
In-Reply-To: <CAOBi2H_gAa6VvutCC3J+tiiPjnf9heDrci9K-6QwY2FXgixcUg@mail.gmail.com>
References: <CACuKZqHn-bSHz0Lc-S0mCC+Zi-8G=BVpnY0P5c_P-DO6_DcdVA@mail.gmail.com>
	<511066E7.1010506@oracle.com>
	<CACuKZqGCyfDWnxxZ45uDBGsBUAfVKn7KPWBNX5AXypMU3MPvYg@mail.gmail.com>
	<511080CD.2020409@oracle.com>
	<CACuKZqERX=1O2rDDTpxYfkB_x-kOyTzzoVuE37SW+NH5BLMOzQ@mail.gmail.com>
	<CAOBi2H_gAa6VvutCC3J+tiiPjnf9heDrci9K-6QwY2FXgixcUg@mail.gmail.com>
Message-ID: <CACuKZqGEEvE7Mv1FYMJ7Di104TdZU5Bf2WJGj4s9az5HCJufeQ@mail.gmail.com>

On Mon, Feb 4, 2013 at 11:03 PM, Ricky Clarkson
<ricky.clarkson at gmail.com> wrote:
> If you're expecting catch (UncheckedIOException e1) { throw e.getCause(); }
> as a common use case, perhaps using the return value might be a better
> approach without having to 'dip' down into untypedville:
>
> List<IOResult<String>> resultList = asList("foo.txt",
> "bar.txt").map(trapIOException(IOUtils::readWholeFile));
> for (IOResult<String> possibleResult: resultList) {
>   String result = possibleResult.getValue(); // would rethrow the original
> IOException or return the value depending on what's stored in the IOResult.
>   more code here using result.
> }

Good idea. The behavior is a little different though - in your
version, all files are processed, even if an individual file fails -
while we were discussing an exception that propagate through and
destroy the loop. Another problem is how to propagate error easily.
What I can think of is

    IOResult<String> foo()
        IOResult<String> x = ...;
        if(x.isError()) return x; // propagate
        ...

which is a little cumbersome.

The bigger problem is it's not a recognized practice in current java
world. API authors would hesitate to return errors instead of throw
errors, so this practice is difficult to spread, it likely will remain
private in isolated programs.

> If Java 9 later provided exception transparency, you could then refactor
> this code fairly straightforwardly with IDE support or at least with help
> from the compiler, whereas if you have to go via an unchecked exception it's
> likely to be harder to take advantage of any future improvements.  This
> should also work with parallelism, as there's nothing making .map terminate
> as soon as reading one file hits an IOException.
>
> Checked exceptions are contentious and I'm not sure I'd include them if I
> was designing a language,

True, but the new language would have other devices that make error
handling easier.

> but they're in Java, they get some valid use that
> benefits from type checking and I wouldn't want to see them become a
> second-class citizen by being excluded from most lambda-using code in favour
> of untyped exceptions.

True, the wrapper is less typed; hopefully it's used in contexts where
it's clear what are the possible types of the original exception.

In any case, UncheckedIOException is an odd ball that's bound to raise
questions - what about UncheckedFileNotFoundException? what about
UncheckedAnyException? What's so special about IOException that only
it gets an unchecked cousin?


>
> On Tue, Feb 5, 2013 at 1:17 AM, Zhong Yu <zhong.j.yu at gmail.com> wrote:
>>
>> On Mon, Feb 4, 2013 at 9:47 PM, David Holmes <david.holmes at oracle.com>
>> wrote:
>> > On 5/02/2013 1:39 PM, Zhong Yu wrote:
>> >>
>> >> On Mon, Feb 4, 2013 at 7:56 PM, David Holmes<david.holmes at oracle.com>
>> >> wrote:
>> >>>
>> >>> On 5/02/2013 10:16 AM, Zhong Yu wrote:
>> >>>>
>> >>>>
>> >>>> Suppose we have an UncheckedIOException e1, which wraps an
>> >>>> IOException
>> >>>> e2. Then another exception e3 occurs that we want suppress. Should we
>> >>>> do e1.addSuppressed(e3), or e2.addSuppressed(e3)? That's pretty
>> >>>> confusing.
>> >>>
>> >>>
>> >>>
>> >>> I don't see any confusion except for your numbering. You have one
>> >>> exception
>> >>> that is inflight, e1, and then e3 occurs. If you want to continue
>> >>> throwing
>> >>> e1 then e1 is suppressing e3.
>> >>
>> >>
>> >> The catcher of an UncheckedIOException e1 would see it simply as a
>> >> container, so it'll extract the contained IOException e2, and deal
>> >> with e2 afterwards, for example, rethrow e2. If e3 was added as e1's
>> >> suppressed exception, e3 is then lost.
>> >
>> >
>> > Then the catch is showing their ignorance of suppressed exceptions. BUt
>> > this
>> > is not specific to this situation. Anytime you catch an exception with a
>> > cause and a suppression list you have to decide what it is you want to
>> > do
>> > with it.
>>
>> It is far more likely that UncheckIOException is treated as a shell,
>> and the shell is discarded (along with information attached to it),
>> leaving only the contained IOException. That is less likely for
>> "normal" exceptions that represents errors by themselves.
>>
>> This is probably going to be a common usage
>>
>>     catch(UncheckedIOException e1)
>>         throw e.getCause();
>>
>> however it'll lose suppressed exception on e1.
>>
>> >> This "containing" relation is different from the usual "causal"
>> >> relation between an exception and its cause. Let's be honest, the only
>> >> purpose of an UncheckedIOException is to smuggle an IOException as
>> >> unchecked; UncheckedIOException itself has no "business meaning".
>> >
>> >
>> > Again read the Throwable javadoc that Joe pointed out top you. This
>> > "conversion" situation is one of the primary uses for setting a cause:
>>
>> I'm certainly aware of this practice, unfortunately it is not a good
>> practice, since there's no reliable way to uncover the original
>> exception.
>>
>> > "A second reason that a throwable may have a cause is that the method
>> > that
>> > throws it must conform to a general-purpose interface that does not
>> > permit
>> > the method to throw the cause directly. For example, suppose a
>> > persistent
>> > collection conforms to the Collection interface, and that its
>> > persistence is
>> > implemented atop java.io. Suppose the internals of the add method can
>> > throw
>> > an IOException. The implementation can communicate the details of the
>> > IOException to its caller while conforming to the Collection interface
>> > by
>> > wrapping the IOException in an appropriate unchecked exception. (The
>> > specification for the persistent collection should indicate that it is
>> > capable of throwing such exceptions.) "
>> >
>> > David
>> > -----
>> >
>> >
>> >>>> If UncheckedIOException is not a *real* exception, maybe we should
>> >>>> make it a "control" exception. It should have no stacktrace; it
>> >>>> should
>> >>>> have no cause (the wrapped exception is not a cause); it should not
>> >>>> contain suppressed exceptions.
>> >>>
>> >>>
>> >>>
>> >>> Any wrapping exception should have the original exception as its
>> >>> cause.
>> >>> Why
>> >>> should this wrapper be any different? Throwable even defines it so:
>> >>>
>> >>> " Throwing a "wrapped exception" (i.e., an exception containing a
>> >>> cause)
>> >>> ..."
>> >>>
>> >>> Suppression is about control over which exception is propagating - so
>> >>> again
>> >>> why should this be a special case?
>> >>>
>> >>>
>> >>>> Maybe it can override addSuppressed() to forward suppressed
>> >>>> exceptions
>> >>>> to the wrapped exception. (Though addSuppressed() is `final`, there's
>> >>>> no problem to leave a backdoor for another JDK class)
>> >>>
>> >>>
>> >>>
>> >>> I think your exception processing model is slightly confused here.
>> >>>
>> >>> David
>> >>> -----
>> >>>
>> >>>> Zhong Yu
>> >>>>
>> >>>
>> >>
>> >
>>
>

From peter.levart at gmail.com  Tue Feb  5 01:47:39 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Tue, 05 Feb 2013 10:47:39 +0100
Subject: UncheckedIOException and suppressed exception
In-Reply-To: <511080CD.2020409@oracle.com>
References: <CACuKZqHn-bSHz0Lc-S0mCC+Zi-8G=BVpnY0P5c_P-DO6_DcdVA@mail.gmail.com>
	<511066E7.1010506@oracle.com>
	<CACuKZqGCyfDWnxxZ45uDBGsBUAfVKn7KPWBNX5AXypMU3MPvYg@mail.gmail.com>
	<511080CD.2020409@oracle.com>
Message-ID: <5110D53B.9060502@gmail.com>


On 02/05/2013 04:47 AM, David Holmes wrote:
> On 5/02/2013 1:39 PM, Zhong Yu wrote:
>> On Mon, Feb 4, 2013 at 7:56 PM, David Holmes<david.holmes at oracle.com>  wrote:
>>> On 5/02/2013 10:16 AM, Zhong Yu wrote:
>>>> Suppose we have an UncheckedIOException e1, which wraps an IOException
>>>> e2. Then another exception e3 occurs that we want suppress. Should we
>>>> do e1.addSuppressed(e3), or e2.addSuppressed(e3)? That's pretty
>>>> confusing.
>>> I don't see any confusion except for your numbering. You have one exception
>>> that is inflight, e1, and then e3 occurs. If you want to continue throwing
>>> e1 then e1 is suppressing e3.
>> The catcher of an UncheckedIOException e1 would see it simply as a
>> container, so it'll extract the contained IOException e2, and deal
>> with e2 afterwards, for example, rethrow e2. If e3 was added as e1's
>> suppressed exception, e3 is then lost.
> Then the catch is showing their ignorance of suppressed exceptions. BUt
> this is not specific to this situation. Anytime you catch an exception
> with a cause and a suppression list you have to decide what it is you
> want to do with it.

I agree that suppressed exceptions should be (and are) attached to 
"top-level" thrown exceptions, whatever they are. Also in the situation 
of UncheckedIOException wrapper for IOException. There would be more 
confusion otherwise. But here the "duality" strikes again. I just want 
to discuss possible techiques how to deal with that...

When the body of the try-with-resources construct throws both types 
(IOException and UncheckedIOException), handlers that want to analyze 
suppressed exceptions have to extract them from both types separately. 
You might think multi-catch is the answer:

         try (...) {
             ...
         }
         catch (IOException | UncheckedIOException e) {
             Throwable[] suppressed = e.getSuppressed();
             ...
         }

...but things get complicated when the same handler wants to deal with 
the "potential" cause first (in case of UncheckedIOException):

         try (...) {
             ...
         }
         catch (IOException | UncheckedIOException e) {
             IOException ioe = e instanceof IOException ? (IOException) 
e : ((UncheckedIOException) e).getCause();
             ...
             Throwable[] suppressed = e.getSuppressed();
             ...
         }

...so maybe the following pattern is more appropriate:

         try (...) {
             try {
                 ...
             }
             catch (UncheckedIOException uioe) { throw uioe.getCause(); }
         }
         catch (IOException ioe) {
             ...
             Throwable[] suppressed = e.getSuppressed();
             ...
         }

Now in another thread (CloseableStream exceptions), Alan argued that 
getting Path objects is only half the story. A program would usually 
want to do something with them (do some IO on them perhaps) and those 
operations traditionally throw IOExceptions of multiple subtypes. The 
programmer has to decide how these operations are to be performed. There 
are basically two options:

 1. stay inside of the streams API and perform them inside lambdas. In
    this case the operations themselves would have to wrap IOExceptions
    with UncheckedIOExceptions. Therefore we could get multiple subtypes
    of IOException wrapped in UncheckedIOException - a situation for the
    handler to deal with.
 2. escape streams API by collecting final Paths into a collection and
    doing external iteration on the result, performing IO operations "in
    the open". In this case IOExceptions would be thrown directly, but
    we still would have to take into account the UncheckedIOExceptions
    originating from the Stream<Path> producing operations.


The style that is to be chosen depends largely on what the program wants 
to achieve. One might argue that the programmer will choose the streams 
API for it's main feature - to employ parallelism. In this case he/she 
would want to stay inside the streams API and would have to deal with 
handling the multiple subtypes of IOException wrapped with 
UncheckedIOException. The following pattern seems to be the most general 
for that case and others:

         try (CloseableStream<Path> = ...) {
             try {
                 ... direct Path operations throwing IOException and/or
                 ... Stream<Path> operations throwing UncheckedIOException
             }
             catch (UncheckedIOException uioe) { throw uioe.getCause(); }
         }
         catch (EOFException eofe) {
             // ...
         }
         catch (ZipException ze) {
             // ...
         }
         catch (IOException ioe) {
             //...
         }

That's not so bad. So at the end I feel that the decision about 
CloseableStream factory methods throwing IOException is the right one 
when considering broader view on the matter. The above pattern would not 
be possible otherwise.

Regards, Peter

>> This "containing" relation is different from the usual "causal"
>> relation between an exception and its cause. Let's be honest, the only
>> purpose of an UncheckedIOException is to smuggle an IOException as
>> unchecked; UncheckedIOException itself has no "business meaning".
> Again read the Throwable javadoc that Joe pointed out top you. This
> "conversion" situation is one of the primary uses for setting a cause:
>
> "A second reason that a throwable may have a cause is that the method
> that throws it must conform to a general-purpose interface that does not
> permit the method to throw the cause directly. For example, suppose a
> persistent collection conforms to the Collection interface, and that its
> persistence is implemented atop java.io. Suppose the internals of the
> add method can throw an IOException. The implementation can communicate
> the details of the IOException to its caller while conforming to the
> Collection interface by wrapping the IOException in an appropriate
> unchecked exception. (The specification for the persistent collection
> should indicate that it is capable of throwing such exceptions.) "
>
> David
> -----
>
>>>> If UncheckedIOException is not a *real* exception, maybe we should
>>>> make it a "control" exception. It should have no stacktrace; it should
>>>> have no cause (the wrapped exception is not a cause); it should not
>>>> contain suppressed exceptions.
>>> Any wrapping exception should have the original exception as its cause. Why
>>> should this wrapper be any different? Throwable even defines it so:
>>>
>>> " Throwing a "wrapped exception" (i.e., an exception containing a cause)
>>> ..."
>>>
>>> Suppression is about control over which exception is propagating - so again
>>> why should this be a special case?
>>>
>>>
>>>> Maybe it can override addSuppressed() to forward suppressed exceptions
>>>> to the wrapped exception. (Though addSuppressed() is `final`, there's
>>>> no problem to leave a backdoor for another JDK class)
>>> I think your exception processing model is slightly confused here.
>>>
>>> David
>>> -----
>>>
>>>> Zhong Yu
>>>>


From boaznahum at gmail.com  Tue Feb  5 04:28:55 2013
From: boaznahum at gmail.com (Boaz Nahum)
Date: Tue, 5 Feb 2013 14:28:55 +0200
Subject: Inference question
Message-ID: <CAB_DFWZ5GbMX1wcU67uALSy02n+tKTjNMpYt01gdhQ2Li4yJTw@mail.gmail.com>

Hi.

Can you please confirm if the compilation error  below is compiler bug or
known limitation (works in JDK 7 ):

public class TypeInterfrer3 {


    private interface TKey<T> {

    }

    public static <TK extends TKey<?>> TK createKey(TK relativeKey) {
        return null;
    }


    static <T> T getValue(TKey<T> key) {
        return null;
    }


    public static void main(String[] args) {


        TKey<Integer> ki = new TKey<Integer>() {}



        // *OK*
        int i = getValue(createKey(ki));

        // *OK*
        double d0 = getValue(ki);


        // *OK*
        double d1 = getValue(TypeInterfrer3.<TKey<Integer>>createKey(ki));

        // *OK*
        double d2 = (int)getValue(createKey(ki));

       * // Fails:
        // java: incompatible types: inference variable T has incompatible
bounds
        //   equality constraints:java.lang.Integer
        ///   upper bounds:java.lang.Double, java.lang.Object*
        double d3 = getValue(createKey(ki));


    }


}

Thanks
Boaz

From maurizio.cimadamore at oracle.com  Tue Feb  5 04:33:09 2013
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Tue, 05 Feb 2013 12:33:09 +0000
Subject: hg: lambda/lambda/langtools: Remove hacks from Infer.InferenceContext
Message-ID: <20130205123313.9A4CB47833@hg.openjdk.java.net>

Changeset: c364306b74ad
Author:    mcimadamore
Date:      2013-02-05 12:32 +0000
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/c364306b74ad

Remove hacks from Infer.InferenceContext

! src/share/classes/com/sun/tools/javac/comp/Infer.java


From maurizio.cimadamore at oracle.com  Tue Feb  5 05:12:52 2013
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Tue, 05 Feb 2013 13:12:52 +0000
Subject: Inference question
In-Reply-To: <CAB_DFWZ5GbMX1wcU67uALSy02n+tKTjNMpYt01gdhQ2Li4yJTw@mail.gmail.com>
References: <CAB_DFWZ5GbMX1wcU67uALSy02n+tKTjNMpYt01gdhQ2Li4yJTw@mail.gmail.com>
Message-ID: <51110554.5010308@oracle.com>

This is just a bug.

Maurizio

On 05/02/13 12:28, Boaz Nahum wrote:
> class TypeInterfrer3 {
>
>
>      private interface TKey<T> {
>
>      }
>
>      public static <TK extends TKey<?>> TK createKey(TK relativeKey) {
>          return null;
>      }
>
>
>      static <T> T getValue(TKey<T> key) {
>          return null;
>      }
>
>
>      public static void main(String[] args) {
>
>
>          TKey<Integer> ki = new TKey<Integer>() {}
>
>
>
>          //*OK*
>          int i = getValue(createKey(ki));
>
>          //*OK*
>          double d0 = getValue(ki);
>
>
>          //*OK*
>          double d1 = getValue(TypeInterfrer3.<TKey<Integer>>createKey(ki));
>
>          //*OK*
>          double d2 = (int)getValue(createKey(ki));
>
>         * // Fails:
>          // java: incompatible types: inference variable T has incompatible
> bounds
>          //   equality constraints:java.lang.Integer
>          ///   upper bounds:java.lang.Double, java.lang.Object*
>          double d3 = getValue(createKey(ki));
>
>
>      }
>
>
> }


From maurizio.cimadamore at oracle.com  Tue Feb  5 06:41:44 2013
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Tue, 05 Feb 2013 14:41:44 +0000
Subject: Inference question
In-Reply-To: <51110554.5010308@oracle.com>
References: <CAB_DFWZ5GbMX1wcU67uALSy02n+tKTjNMpYt01gdhQ2Li4yJTw@mail.gmail.com>
	<51110554.5010308@oracle.com>
Message-ID: <51111A28.2030400@oracle.com>

On 05/02/13 13:12, Maurizio Cimadamore wrote:
> This is just a bug.
Fixed.

Maurizio
>
> Maurizio
>
> On 05/02/13 12:28, Boaz Nahum wrote:
>> class TypeInterfrer3 {
>>
>>
>>       private interface TKey<T> {
>>
>>       }
>>
>>       public static <TK extends TKey<?>> TK createKey(TK relativeKey) {
>>           return null;
>>       }
>>
>>
>>       static <T> T getValue(TKey<T> key) {
>>           return null;
>>       }
>>
>>
>>       public static void main(String[] args) {
>>
>>
>>           TKey<Integer> ki = new TKey<Integer>() {}
>>
>>
>>
>>           //*OK*
>>           int i = getValue(createKey(ki));
>>
>>           //*OK*
>>           double d0 = getValue(ki);
>>
>>
>>           //*OK*
>>           double d1 = getValue(TypeInterfrer3.<TKey<Integer>>createKey(ki));
>>
>>           //*OK*
>>           double d2 = (int)getValue(createKey(ki));
>>
>>          * // Fails:
>>           // java: incompatible types: inference variable T has incompatible
>> bounds
>>           //   equality constraints:java.lang.Integer
>>           ///   upper bounds:java.lang.Double, java.lang.Object*
>>           double d3 = getValue(createKey(ki));
>>
>>
>>       }
>>
>>
>> }
>


From maurizio.cimadamore at oracle.com  Tue Feb  5 06:41:21 2013
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Tue, 05 Feb 2013 14:41:21 +0000
Subject: hg: lambda/lambda/langtools: Fix: missing constraints propagation
	leads to spurious errors when nested generic method calls have
	primitive target
Message-ID: <20130205144126.9ED0547839@hg.openjdk.java.net>

Changeset: d6bd8a6c0705
Author:    mcimadamore
Date:      2013-02-05 14:15 +0000
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/d6bd8a6c0705

Fix: missing constraints propagation leads to spurious errors when nested generic method calls have primitive target

! src/share/classes/com/sun/tools/javac/comp/Infer.java
! test/tools/javac/lambda/TargetType56.java


From oleksander.demura at gmail.com  Tue Feb  5 06:47:10 2013
From: oleksander.demura at gmail.com (Olexandr Demura)
Date: Tue, 5 Feb 2013 16:47:10 +0200
Subject: CloseableStream exceptions [was: Re: experience trying out
	lambda-8-b74]
In-Reply-To: <CACuKZqHZV9BfCY=q3deQKKYwE_UmBxS5EGStZgJteqKCVFda_A@mail.gmail.com>
References: <51053A5A.24195.AAF1F6@v.a.ammodytes.googlemail.com>
	<5105762A.8040002@oracle.com>
	<E61425C5-6E01-49C3-B149-151D2A3B81F3@wonderly.org>
	<CC95D104-28E2-42DE-B1A4-DD02BAD67F38@oracle.com>
	<510633DE.9060001@gmail.com> <510C5348.8020107@oracle.com>
	<510CA649.5050000@gmail.com>
	<153DE41A-FCF6-47C0-B5F5-8B7D49D4CBDE@oracle.com>
	<510FFB4A.1040501@gmail.com>
	<CACuKZqHZV9BfCY=q3deQKKYwE_UmBxS5EGStZgJteqKCVFda_A@mail.gmail.com>
Message-ID: <CAJitDuzVc3W7Q+Kqgk2SB+s4anVU9hH1XVG=wsGPH4PUUxyS=w@mail.gmail.com>

Isn't ConsumerEx imply existence of StreamEx &Co. so we do not need any
wraps?
where `StreamEx<T, Ex>` extends `BaseStream<T>`
and `ConsumerEx<T, Ex> { void accept(T o) throws Ex }` is not related to
`Consumer<T>`,
just like with primitives - other essential and dominant java feature.

Then void `close() throws Exception` is natural, leading to `Closeable`
`StreamEx`.

2013/2/5 Zhong Yu <zhong.j.yu at gmail.com>

> Say we cannot do
>
>     Consumer<Path> deleteAction = Files::delete;
>
> since Files.delete() throws IOException. But a generic wrapper would do
>
>     Consumer<Path> deleteAction = wrap(Files::delete);
>
>     static <T> Consumer<T> wrap(ConsumerEx<T>){..}
>     // ... and wrap() for other functional interfaces
>
> Zhong Yu
>

From jonathan.gibbons at oracle.com  Tue Feb  5 07:47:52 2013
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Tue, 05 Feb 2013 07:47:52 -0800
Subject: Hundreds of errors generating javadoc ??
In-Reply-To: <51109C40.6000303@oracle.com>
References: <51109C40.6000303@oracle.com>
Message-ID: <511129A8.8010601@oracle.com>

This is the new doclint feature.  The feature is on by default in javadoc.
It would appear you have lost -Xdoclint:none in the Makefile, which causes
javadoc to revert to its earlier behavior.

-- Jon

On 02/04/2013 09:44 PM, David Holmes wrote:
> Not sure what is going on as this is a fresh clone of the lambda forest
> and the errors are in packages all over the place (unrelated to lambda
> changes).
>
> ??
>
> David
> -----
>
> /export/users/dh198349/lambda/jdk/src/share/classes/java/applet/Applet.java:527:
> error: tag not allowed here: <p>
>        * <p>
>          ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/applet/Applet.java:183:
> error: tag not allowed here: <p>
>        * <p>
>          ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/applet/Applet.java:395:
> error: tag not allowed here: <p>
>        * <p><blockquote><pre>
>          ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/applet/Applet.java:395:
> error: tag not allowed here: <blockquote>
>        * <p><blockquote><pre>
>             ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/applet/Applet.java:402:
> error: tag not allowed here: <p>
>        * <p>
>          ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/applet/Applet.java:451:
> error: tag not allowed here: <p>
>        * <p>
>          ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/applet/Applet.java:474:
> error: tag not allowed here: <p>
>        * <p>
>          ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/applet/Applet.java:481:
> error: tag not allowed here: <p>
>        * <p>
>          ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/applet/Applet.java:506:
> error: tag not allowed here: <p>
>        * <p>
>          ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/Component.java:2168:
> warning: no @param for width
>       public void resize(int width, int height) {
>                   ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/Component.java:2168:
> warning: no @param for height
>       public void resize(int width, int height) {
>                   ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/Component.java:2199:
> warning: no @param for d
>       public void resize(Dimension d) {
>                   ^
> /export/users/dh198349/lambda/jdk/src/share/classes/javax/accessibility/Accessible.java:49:
> warning: no @return
>       public AccessibleContext getAccessibleContext();
>                                ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/applet/AppletContext.java:59:
> warning: empty <code> tag
>        * the screen. The <code>url</code> argument<code> </code>that is
>                                                          ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/applet/AppletContext.java:175:
> error: tag not allowed here: <p>
>        * <p>
>          ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/applet/AppletContext.java:188:
> error: tag not allowed here: <p>
>        * <p>
>          ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/applet/AppletContext.java:155:
> error: tag not allowed here: <p>
>        * <p>
>          ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/applet/AppletContext.java:160:
> error: unexpected text
>        * @throws <code>IOException</code> if the stream size exceeds a
> certain
>          ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/applet/AppletContext.java:165:
> warning: no @throws for java.io.IOException
>       public void setStream(String key, InputStream stream)throws
> IOException;
>                   ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/applet/AppletContext.java:111:
> error: tag not allowed here: <center>
>        * <center><table border="3" summary="Target arguments and their
> descriptions">
>          ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/applet/AppletContext.java:128:
> error: tag not allowed here: <p>
>        * <p>
>          ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/ActiveEvent.java:42:
> error: tag not allowed here: <p>
>    * <p>
>      ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:51:
> error: tag not allowed here: <p>
>    * <p>
>      ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:62:
> error: tag not allowed here: <p>
>    * <p>
>      ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:71:
> error: tag not allowed here: <p>
>    * <p>
>      ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:75:
> error: tag not allowed here: <blockquote>
>    * <blockquote>
>      ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:90:
> error: tag not allowed here: <p>
>    * <p>
>      ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:105:
> error: tag not allowed here: <pre>
>    * <pre>
>      ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:111:
> error: tag not allowed here: <p>
>    * <p>
>      ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:115:
> error: tag not allowed here: <blockquote>
>    * <blockquote>
>      ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:128:
> error: tag not allowed here: <h3>
>    * <h3>Preparing Inputs</h3>
>      ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:130:
> error: tag not allowed here: <p>
>    * <p>
>      ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:140:
> error: tag not allowed here: <pre>
>    * <pre>
>      ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:152:
> error: tag not allowed here: <pre>
>    * <pre>
>      ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:158:
> error: tag not allowed here: <pre>
>    * <pre>
>      ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:161:
> error: tag not allowed here: <p>
>    * <p>
>      ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:165:
> error: tag not allowed here: <pre>
>    * <pre>
>      ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:169:
> error: tag not allowed here: <h3>
>    * <h3>Applying the Blending Equation</h3>
>      ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:171:
> error: tag not allowed here: <p>
>    * <p>
>      ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:178:
> error: tag not allowed here: <p>
>    * <p>
>      ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:179:
> error: tag not allowed here: <h3>
>    * <h3>Preparing Results</h3>
>      ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:181:
> error: tag not allowed here: <p>
>    * <p>
>      ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:186:
> error: tag not allowed here: <pre>
>    * <pre>
>      ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:196:
> error: tag not allowed here: <p>
>    * <p>
>      ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:197:
> error: tag not allowed here: <h3>
>    * <h3>Performance Considerations</h3>
>      ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:199:
> error: tag not allowed here: <p>
>    * <p>
>      ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:210:
> error: tag not allowed here: <h3>
>    * <h3><a name="caveats">Implementation Caveats</a></h3>
>      ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:212:
> error: tag not allowed here: <ul>
>    * <ul>
>      ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:362:
> error: tag not allowed here: <pre>
>        *<pre>
>         ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:387:
> error: tag not allowed here: <pre>
>        *<pre>
>         ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:498:
> error: tag not allowed here: <pre>
>        *<pre>
>         ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:440:
> error: tag not allowed here: <pre>
>        *<pre>
>         ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:466:
> error: tag not allowed here: <pre>
>        *<pre>
>         ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:414:
> error: tag not allowed here: <pre>
>        *<pre>
>         ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:375:
> error: tag not allowed here: <pre>
>        *<pre>
>         ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:484:
> error: tag not allowed here: <pre>
>        *<pre>
>         ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:427:
> error: tag not allowed here: <pre>
>        *<pre>
>         ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:453:
> error: tag not allowed here: <pre>
>        *<pre>
>         ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:401:
> error: tag not allowed here: <pre>
>        *<pre>
>         ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:513:
> error: tag not allowed here: <pre>
>        *<pre>
>         ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:640:
> warning: no @return
>       public static AlphaComposite getInstance(int rule) {
>                                    ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:688:
> warning: no @return
>       public static AlphaComposite getInstance(int rule, float alpha) {
>                                    ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/lang/Object.java:71:
> error: tag not allowed here: <ul>
>        * <ul>
>          ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/lang/Object.java:88:
> error: tag not allowed here: <p>
>        * <p>
>          ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/lang/Object.java:107:
> error: tag not allowed here: <ul>
>        * <ul>
>          ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/lang/Object.java:129:
> error: tag not allowed here: <p>
>        * <p>
>          ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/lang/Object.java:136:
> error: tag not allowed here: <p>
>        * <p>
>          ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEvent.java:52:
> error: tag not allowed here: <p>
>    * <p>
>      ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEvent.java:392:
> warning: no @return
>       public int getID() {
>                  ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEvent.java:450:
> warning: no @return
>       protected boolean isConsumed() {
>                         ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/lang/Object.java:228:
> error: tag not allowed here: <blockquote>
>        * <blockquote>
>          ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:43:
> error: tag not allowed here: <pre>
>    * <pre><code>
>      ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:66:
> error: tag not allowed here: <p>
>    * <p>
>      ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:76:
> error: tag not allowed here: <p>
>    * <p>
>      ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:83:
> error: tag not allowed here: <p>
>    * <p>
>      ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:86:
> error: tag not allowed here: <ul>
>    * <ul>
>      ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:95:
> error: tag not allowed here: <p>
>    * <p>Swing makes use of
>      ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:635:
> warning: no @return
>       public static ActionListener add(ActionListener a, ActionListener b) {
>                                    ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:655:
> warning: no @return
>       public static AdjustmentListener add(AdjustmentListener a,
> AdjustmentListener b) {
>                                        ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:541:
> warning: no @return
>       public static ComponentListener add(ComponentListener a,
> ComponentListener b) {
>                                       ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:551:
> warning: no @return
>       public static ContainerListener add(ContainerListener a,
> ContainerListener b) {
>                                       ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:561:
> warning: no @return
>       public static FocusListener add(FocusListener a, FocusListener b) {
>                                   ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:690:
> warning: no @return
>        public static HierarchyBoundsListener add(HierarchyBoundsListener
> a, HierarchyBoundsListener b) {
>                                              ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:679:
> warning: no @return
>        public static HierarchyListener add(HierarchyListener a,
> HierarchyListener b) {
>                                        ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:668:
> warning: no @return
>        public static InputMethodListener add(InputMethodListener a,
> InputMethodListener b) {
>                                          ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:645:
> warning: no @return
>       public static ItemListener add(ItemListener a, ItemListener b) {
>                                  ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:571:
> warning: no @return
>       public static KeyListener add(KeyListener a, KeyListener b) {
>                                 ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:581:
> warning: no @return
>       public static MouseListener add(MouseListener a, MouseListener b) {
>                                   ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:591:
> warning: no @return
>       public static MouseMotionListener add(MouseMotionListener a,
> MouseMotionListener b) {
>                                         ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:701:
> warning: no @return
>       public static MouseWheelListener add(MouseWheelListener a,
>                                        ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:624:
> warning: no @return
>       public static WindowFocusListener add(WindowFocusListener a,
>                                         ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:601:
> warning: no @return
>       public static WindowListener add(WindowListener a, WindowListener b) {
>                                    ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:612:
> warning: no @return
>       public static WindowStateListener add(WindowStateListener a,
>                                         ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:888:
> warning: no @return
>       protected static EventListener addInternal(EventListener a,
> EventListener b) {
>                                      ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:1022:
> warning: no @param for <T>
>           getListeners(EventListener l, Class<T> listenerType)
>           ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:806:
> warning: no @return
>       public static ActionListener remove(ActionListener l,
> ActionListener oldl) {
>                                    ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:826:
> warning: no @return
>       public static AdjustmentListener remove(AdjustmentListener l,
> AdjustmentListener oldl) {
>                                        ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:712:
> warning: no @return
>       public static ComponentListener remove(ComponentListener l,
> ComponentListener oldl) {
>                                       ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:722:
> warning: no @return
>       public static ContainerListener remove(ContainerListener l,
> ContainerListener oldl) {
>                                       ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:136:
> error: tag not allowed here: <p>
>        * <p>
>          ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:732:
> warning: no @return
>       public static FocusListener remove(FocusListener l, FocusListener
> oldl) {
>                                   ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:862:
> warning: no @return
>       public static HierarchyBoundsListener
> remove(HierarchyBoundsListener l, HierarchyBoundsListener oldl) {
>                                             ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:850:
> warning: no @return
>       public static HierarchyListener remove(HierarchyListener l,
> HierarchyListener oldl) {
>                                       ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:839:
> warning: no @return
>       public static InputMethodListener remove(InputMethodListener l,
> InputMethodListener oldl) {
>                                         ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:816:
> warning: no @return
>       public static ItemListener remove(ItemListener l, ItemListener oldl) {
>                                  ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:742:
> warning: no @return
>       public static KeyListener remove(KeyListener l, KeyListener oldl) {
>                                 ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:752:
> warning: no @return
>       public static MouseListener remove(MouseListener l, MouseListener
> oldl) {
>                                   ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:762:
> warning: no @return
>       public static MouseMotionListener remove(MouseMotionListener l,
> MouseMotionListener oldl) {
>                                         ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:873:
> warning: no @return
>       public static MouseWheelListener remove(MouseWheelListener l,
>                                        ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:795:
> warning: no @return
>       public static WindowFocusListener remove(WindowFocusListener l,
>                                         ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:772:
> warning: no @return
>       public static WindowListener remove(WindowListener l,
> WindowListener oldl) {
>                                    ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:783:
> warning: no @return
>       public static WindowStateListener remove(WindowStateListener l,
>                                         ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:905:
> warning: no @return
>       protected static EventListener removeInternal(EventListener l,
> EventListener oldl) {
>                                      ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/TextListener.java:53:
> warning: no @param for e
>       public void textValueChanged(TextEvent e);
>                   ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/ComponentListener.java:58:
> warning: no @param for e
>       public void componentResized(ComponentEvent e);
>                   ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/ComponentListener.java:63:
> warning: no @param for e
>       public void componentMoved(ComponentEvent e);
>                   ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/ComponentListener.java:68:
> warning: no @param for e
>       public void componentShown(ComponentEvent e);
>                   ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/ComponentListener.java:73:
> warning: no @param for e
>       public void componentHidden(ComponentEvent e);
>                   ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/ContainerListener.java:59:
> warning: no @param for e
>       public void componentAdded(ContainerEvent e);
>                   ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/ContainerListener.java:64:
> warning: no @param for e
>       public void componentRemoved(ContainerEvent e);
>                   ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/FocusListener.java:55:
> warning: no @param for e
>       public void focusGained(FocusEvent e);
>                   ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/FocusListener.java:60:
> warning: no @param for e
>       public void focusLost(FocusEvent e);
>                   ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/KeyListener.java:58:
> warning: no @param for e
>       public void keyTyped(KeyEvent e);
>                   ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/KeyListener.java:65:
> warning: no @param for e
>       public void keyPressed(KeyEvent e);
>                   ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/KeyListener.java:72:
> warning: no @param for e
>       public void keyReleased(KeyEvent e);
>                   ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/MouseListener.java:63:
> warning: no @param for e
>       public void mouseClicked(MouseEvent e);
>                   ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/MouseListener.java:68:
> warning: no @param for e
>       public void mousePressed(MouseEvent e);
>                   ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/MouseListener.java:73:
> warning: no @param for e
>       public void mouseReleased(MouseEvent e);
>                   ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/MouseListener.java:78:
> warning: no @param for e
>       public void mouseEntered(MouseEvent e);
>                   ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/MouseListener.java:83:
> warning: no @param for e
>       public void mouseExited(MouseEvent e);
>                   ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/MouseMotionListener.java:63:
> error: semicolon missing
>        * Due to platform-dependent Drag&Drop implementations,
>                                        ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/MouseMotionListener.java:65:
> error: semicolon missing
>        * Drag&Drop operation.
>              ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/MouseMotionListener.java:67:
> warning: no @param for e
>       public void mouseDragged(MouseEvent e);
>                   ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/MouseMotionListener.java:73:
> warning: no @param for e
>       public void mouseMoved(MouseEvent e);
>                   ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/WindowListener.java:55:
> warning: no @param for e
>       public void windowOpened(WindowEvent e);
>                   ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/WindowListener.java:61:
> warning: no @param for e
>       public void windowClosing(WindowEvent e);
>                   ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/WindowListener.java:67:
> warning: no @param for e
>       public void windowClosed(WindowEvent e);
>                   ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/WindowListener.java:76:
> warning: no @param for e
>       public void windowIconified(WindowEvent e);
>                   ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/WindowListener.java:82:
> warning: no @param for e
>       public void windowDeiconified(WindowEvent e);
>                   ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/WindowListener.java:92:
> warning: no @param for e
>       public void windowActivated(WindowEvent e);
>                   ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/WindowListener.java:102:
> warning: no @param for e
>       public void windowDeactivated(WindowEvent e);
>                   ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/WindowStateListener.java:54:
> warning: no @param for e
>       public void windowStateChanged(WindowEvent e);
>                   ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/WindowFocusListener.java:61:
> warning: no @param for e
>       public void windowGainedFocus(WindowEvent e);
>                   ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/WindowFocusListener.java:68:
> warning: no @param for e
>       public void windowLostFocus(WindowEvent e);
>                   ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/ActionListener.java:50:
> warning: no @param for e
>       public void actionPerformed(ActionEvent e);
>                   ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/ItemListener.java:54:
> warning: no @param for e
>       void itemStateChanged(ItemEvent e);
>            ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/AdjustmentListener.java:41:
> warning: no @param for e
>       public void adjustmentValueChanged(AdjustmentEvent e);
>                   ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/InputMethodListener.java:49:
> warning: no @param for event
>       void inputMethodTextChanged(InputMethodEvent event);
>            ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/InputMethodListener.java:54:
> warning: no @param for event
>       void caretPositionChanged(InputMethodEvent event);
>            ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/HierarchyListener.java:56:
> warning: no @param for e
>       public void hierarchyChanged(HierarchyEvent e);
>                   ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/HierarchyBoundsListener.java:56:
> warning: no @param for e
>       public void ancestorMoved(HierarchyEvent e);
>                   ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/HierarchyBoundsListener.java:61:
> warning: no @param for e
>       public void ancestorResized(HierarchyEvent e);
>                   ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/MouseWheelListener.java:57:
> warning: no @param for e
>       public void mouseWheelMoved(MouseWheelEvent e);
>                   ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTKeyStroke.java:402:
> error: tag not allowed here: <ul>
>        * used to specify the key code. For example:<ul>
>                                                    ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTKeyStroke.java:407:
> error: tag not allowed here: <ul>
>        * The modifiers consist of any combination of:<ul>
>                                                      ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTKeyStroke.java:414:
> error: tag not allowed here: <ul>
>        * The old modifiers <ul>
>                            ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTKeyStroke.java:352:
> error: tag not allowed here: <ul>
>        * used to specify the key code. For example:<ul>
>                                                    ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTKeyStroke.java:360:
> error: tag not allowed here: <ul>
>        * The modifiers consist of any combination of:<ul>
>                                                      ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTKeyStroke.java:367:
> error: tag not allowed here: <ul>
>        * The old modifiers <ul>
>                            ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTKeyStroke.java:488:
> error: bad use of '>'
>        *     "INSERT" => getAWTKeyStroke(KeyEvent.VK_INSERT, 0);
>                        ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTKeyStroke.java:489:
> error: bad use of '>'
>        *     "control DELETE" => getAWTKeyStroke(KeyEvent.VK_DELETE,
> InputEvent.CTRL_MASK);
>                                ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTKeyStroke.java:490:
> error: bad use of '>'
>        *     "alt shift X" => getAWTKeyStroke(KeyEvent.VK_X,
> InputEvent.ALT_MASK | InputEvent.SHIFT_MASK);
>                             ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTKeyStroke.java:491:
> error: bad use of '>'
>        *     "alt shift released X" => getAWTKeyStroke(KeyEvent.VK_X,
> InputEvent.ALT_MASK | InputEvent.SHIFT_MASK, true);
>                                      ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTKeyStroke.java:492:
> error: bad use of '>'
>        *     "typed a" => getAWTKeyStroke('a');
>                         ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTKeyStroke.java:803:
> warning: no @throws for java.io.ObjectStreamException
>       protected Object readResolve() throws java.io.ObjectStreamException {
>                        ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTPermission.java:41:
> error: tag not allowed here: <P>
>    * <P>
>      ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTPermission.java:46:
> error: tag not allowed here: <P>
>    * <P>
>      ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTPermission.java:48:
> error: tag not allowed here: <table>
>    * <table border=1 cellpadding=5 summary="AWTPermission target names,
> descriptions, and associated risks.">
>      ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/BasicStroke.java:42:
> warning: attribute obsolete, use CSS instead: compact
>    * <dl compact>
>          ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/BorderLayout.java:61:
> error: tag not allowed here: <p>
>    * <p>
>      ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/BorderLayout.java:70:
> error: tag not allowed here: <p>
>    * <p>
>      ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/BorderLayout.java:78:
> error: tag not allowed here: <p>
>    * <p>
>      ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/BorderLayout.java:83:
> error: tag not allowed here: <p>
>    * <p>
>      ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/BorderLayout.java:91:
> error: tag not allowed here: <p>
>    * <p>
>      ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/BorderLayout.java:94:
> error: tag not allowed here: <p>
>    * <p>
>      ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/BorderLayout.java:99:
> warning: attribute obsolete, use CSS instead: ALIGN
>    * ALIGN=center HSPACE=10 VSPACE=7>
>      ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/BorderLayout.java:99:
> warning: attribute obsolete, use CSS instead: HSPACE
>    * ALIGN=center HSPACE=10 VSPACE=7>
>                   ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/BorderLayout.java:99:
> warning: attribute obsolete, use CSS instead: VSPACE
>    * ALIGN=center HSPACE=10 VSPACE=7>
>                             ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/BorderLayout.java:100:
> error: tag not allowed here: <p>
>    * <p>
>      ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/BorderLayout.java:102:
> error: tag not allowed here: <p>
>    * <p>
>      ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/BorderLayout.java:103:
> error: tag not allowed here: <hr>
>    * <hr><blockquote><pre>
>      ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/BorderLayout.java:103:
> error: tag not allowed here: <blockquote>
>    * <hr><blockquote><pre>
>          ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/BorderLayout.java:117:
> error: tag not allowed here: <hr>
>    * </pre></blockquote><hr>
>                         ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/BorderLayout.java:118:
> error: tag not allowed here: <p>
>    * <p>
>      ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/BorderLayout.java:372:
> warning: no @return
>       public int getHgap() {
>                  ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/BorderLayout.java:389:
> warning: no @return
>       public int getVgap() {
>                  ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/BorderLayout.java:795:
> error: tag not allowed here: <p>
>        * <p>
>          ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/LayoutManager2.java:61:
> warning: no @param for target
>       public Dimension maximumLayoutSize(Container target);
>                        ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/LayoutManager2.java:61:
> warning: no @return
>       public Dimension maximumLayoutSize(Container target);
>                        ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/LayoutManager2.java:70:
> warning: no @param for target
>       public float getLayoutAlignmentX(Container target);
>                    ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/LayoutManager2.java:70:
> warning: no @return
>       public float getLayoutAlignmentX(Container target);
>                    ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/LayoutManager2.java:79:
> warning: no @param for target
>       public float getLayoutAlignmentY(Container target);
>                    ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/lang/Object.java:174:
> error: tag not allowed here: <p>
>        * <p>
>          ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/lang/Object.java:185:
> error: tag not allowed here: <p>
>        * <p>
>          ^
> /export/users/dh198349/lambda/jdk/src/share/classes/java/lang/Object.java:198:
> error: tag not allowed here: <p>
>        * <p>
>          ^
> 100 errors
> 100 warnings
> make[1]: ***
> [/export/users/dh198349/lambda/builds/b00/se-linux-i586-ea/docs/api/index.html]
> Error 1
> make: *** [docs-only] Error 2
>


From jonathan.gibbons at oracle.com  Tue Feb  5 07:51:06 2013
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Tue, 05 Feb 2013 07:51:06 -0800
Subject: Hundreds of errors generating javadoc ??
In-Reply-To: <5110AAAB.10203@oracle.com>
References: <51109C40.6000303@oracle.com>
	<1A9F9B72-955D-4960-83F0-9D376979136A@oracle.com>
	<5110AAAB.10203@oracle.com>
Message-ID: <51112A6A.4000800@oracle.com>

On 02/04/2013 10:46 PM, David Holmes wrote:
> Thanks for the tip! Must say though that I'm slightly concerned that <p>
> tags are prohibited.

It's contextual, and follows HTML rules.   For example, you can't put
any block tag (such as <p>) within an inline tag (such as <a>, <b> etc)

doclint is intended to catch issues that would cause the generated output
to fail an HTML validation check.

-- Jon

From brian.goetz at oracle.com  Tue Feb  5 08:02:58 2013
From: brian.goetz at oracle.com (brian.goetz at oracle.com)
Date: Tue, 05 Feb 2013 16:02:58 +0000
Subject: hg: lambda/lambda/jdk: Revamp error reporting in serialization agent
Message-ID: <20130205160319.BDB664783C@hg.openjdk.java.net>

Changeset: 16030712f9eb
Author:    briangoetz
Date:      2013-02-05 11:02 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/16030712f9eb

Revamp error reporting in serialization agent

! test-ng/agent/conf/agent.props
! test-ng/agent/src/com/oracle/lambda/TestLambdaSerialization.java


From brian.goetz at oracle.com  Tue Feb  5 08:52:18 2013
From: brian.goetz at oracle.com (brian.goetz at oracle.com)
Date: Tue, 05 Feb 2013 16:52:18 +0000
Subject: hg: lambda/lambda/jdk: Update partition collector to return
	Map<Boolean, T>
Message-ID: <20130205165246.422194783F@hg.openjdk.java.net>

Changeset: 57f32115652d
Author:    briangoetz
Date:      2013-02-05 11:52 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/57f32115652d

Update partition collector to return Map<Boolean,T>

! src/share/classes/java/util/stream/Collectors.java


From zhong.j.yu at gmail.com  Tue Feb  5 09:04:10 2013
From: zhong.j.yu at gmail.com (Zhong Yu)
Date: Tue, 5 Feb 2013 11:04:10 -0600
Subject: UncheckedIOException and suppressed exception
In-Reply-To: <5110D53B.9060502@gmail.com>
References: <CACuKZqHn-bSHz0Lc-S0mCC+Zi-8G=BVpnY0P5c_P-DO6_DcdVA@mail.gmail.com>
	<511066E7.1010506@oracle.com>
	<CACuKZqGCyfDWnxxZ45uDBGsBUAfVKn7KPWBNX5AXypMU3MPvYg@mail.gmail.com>
	<511080CD.2020409@oracle.com> <5110D53B.9060502@gmail.com>
Message-ID: <CACuKZqHoe-Y1Q5fbr=Ju+a-skvcPpzenhhrVVs3mv1yv_y03vA@mail.gmail.com>

On Tue, Feb 5, 2013 at 3:47 AM, Peter Levart <peter.levart at gmail.com> wrote:
>
> On 02/05/2013 04:47 AM, David Holmes wrote:
>
> On 5/02/2013 1:39 PM, Zhong Yu wrote:
>
> On Mon, Feb 4, 2013 at 7:56 PM, David Holmes<david.holmes at oracle.com>
> wrote:
>
> On 5/02/2013 10:16 AM, Zhong Yu wrote:
>
> Suppose we have an UncheckedIOException e1, which wraps an IOException
> e2. Then another exception e3 occurs that we want suppress. Should we
> do e1.addSuppressed(e3), or e2.addSuppressed(e3)? That's pretty
> confusing.
>
> I don't see any confusion except for your numbering. You have one exception
> that is inflight, e1, and then e3 occurs. If you want to continue throwing
> e1 then e1 is suppressing e3.
>
> The catcher of an UncheckedIOException e1 would see it simply as a
> container, so it'll extract the contained IOException e2, and deal
> with e2 afterwards, for example, rethrow e2. If e3 was added as e1's
> suppressed exception, e3 is then lost.
>
> Then the catch is showing their ignorance of suppressed exceptions. BUt
> this is not specific to this situation. Anytime you catch an exception
> with a cause and a suppression list you have to decide what it is you
> want to do with it.
>
>
> I agree that suppressed exceptions should be (and are) attached to
> "top-level" thrown exceptions, whatever they are. Also in the situation of
> UncheckedIOException wrapper for IOException. There would be more confusion
> otherwise. But here the "duality" strikes again. I just want to discuss
> possible techiques how to deal with that...
>
> When the body of the try-with-resources construct throws both types
> (IOException and UncheckedIOException), handlers that want to analyze
> suppressed exceptions have to extract them from both types separately. You
> might think multi-catch is the answer:
>
>         try (...) {
>             ...
>         }
>         catch (IOException | UncheckedIOException e) {
>             Throwable[] suppressed = e.getSuppressed();
>             ...
>         }
>
> ...but things get complicated when the same handler wants to deal with the
> "potential" cause first (in case of UncheckedIOException):
>
>         try (...) {
>             ...
>         }
>         catch (IOException | UncheckedIOException e) {
>             IOException ioe = e instanceof IOException ? (IOException) e :
> ((UncheckedIOException) e).getCause();
>             ...
>             Throwable[] suppressed = e.getSuppressed();
>             ...
>         }
>
> ...so maybe the following pattern is more appropriate:
>
>         try (...) {
>             try {
>                 ...
>             }
>             catch (UncheckedIOException uioe) { throw uioe.getCause(); }
>         }
>         catch (IOException ioe) {
>             ...
>             Throwable[] suppressed = e.getSuppressed();
>             ...
>         }
>
> Now in another thread (CloseableStream exceptions), Alan argued that getting
> Path objects is only half the story. A program would usually want to do
> something with them (do some IO on them perhaps) and those operations
> traditionally throw IOExceptions of multiple subtypes. The programmer has to
> decide how these operations are to be performed. There are basically two
> options:
>
> stay inside of the streams API and perform them inside lambdas. In this case
> the operations themselves would have to wrap IOExceptions with
> UncheckedIOExceptions. Therefore we could get multiple subtypes of
> IOException wrapped in UncheckedIOException - a situation for the handler to
> deal with.
> escape streams API by collecting final Paths into a collection and doing
> external iteration on the result, performing IO operations "in the open". In
> this case IOExceptions would be thrown directly, but we still would have to
> take into account the UncheckedIOExceptions originating from the
> Stream<Path> producing operations.
>
>
> The style that is to be chosen depends largely on what the program wants to
> achieve. One might argue that the programmer will choose the streams API for
> it's main feature - to employ parallelism. In this case he/she would want to
> stay inside the streams API and would have to deal with handling the
> multiple subtypes of IOException wrapped with UncheckedIOException. The
> following pattern seems to be the most general for that case and others:
>
>         try (CloseableStream<Path> = ...) {
>             try {
>                 ... direct Path operations throwing IOException and/or
>                 ... Stream<Path> operations throwing UncheckedIOException
>             }
>             catch (UncheckedIOException uioe) { throw uioe.getCause(); }
>         }
>         catch (EOFException eofe) {
>             // ...
>         }
>         catch (ZipException ze) {
>             // ...
>         }
>         catch (IOException ioe) {
>             //...
>         }

Can you give a more concrete, real-world example?

P.S. your pattern will also lose any information attached to
UncheckedIOException, including message, stacktrace, suppressed
exceptions.

> That's not so bad. So at the end I feel that the decision about
> CloseableStream factory methods throwing IOException is the right one when
> considering broader view on the matter. The above pattern would not be
> possible otherwise.
>
> Regards, Peter
>
>
> This "containing" relation is different from the usual "causal"
> relation between an exception and its cause. Let's be honest, the only
> purpose of an UncheckedIOException is to smuggle an IOException as
> unchecked; UncheckedIOException itself has no "business meaning".
>
> Again read the Throwable javadoc that Joe pointed out top you. This
> "conversion" situation is one of the primary uses for setting a cause:
>
> "A second reason that a throwable may have a cause is that the method
> that throws it must conform to a general-purpose interface that does not
> permit the method to throw the cause directly. For example, suppose a
> persistent collection conforms to the Collection interface, and that its
> persistence is implemented atop java.io. Suppose the internals of the
> add method can throw an IOException. The implementation can communicate
> the details of the IOException to its caller while conforming to the
> Collection interface by wrapping the IOException in an appropriate
> unchecked exception. (The specification for the persistent collection
> should indicate that it is capable of throwing such exceptions.) "
>
> David
> -----
>
> If UncheckedIOException is not a *real* exception, maybe we should
> make it a "control" exception. It should have no stacktrace; it should
> have no cause (the wrapped exception is not a cause); it should not
> contain suppressed exceptions.
>
> Any wrapping exception should have the original exception as its cause. Why
> should this wrapper be any different? Throwable even defines it so:
>
> " Throwing a "wrapped exception" (i.e., an exception containing a cause)
> ..."
>
> Suppression is about control over which exception is propagating - so again
> why should this be a special case?
>
>
> Maybe it can override addSuppressed() to forward suppressed exceptions
> to the wrapped exception. (Though addSuppressed() is `final`, there's
> no problem to leave a backdoor for another JDK class)
>
> I think your exception processing model is slightly confused here.
>
> David
> -----
>
> Zhong Yu
>
>

From Roger.Riggs at oracle.com  Tue Feb  5 09:06:24 2013
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Tue, 05 Feb 2013 12:06:24 -0500
Subject: Hundreds of errors generating javadoc ??
Message-ID: <51113C10.3010204@oracle.com>

Hi,

What are the rules for valid tags? Which html schema is being enforced?

It looks like every <p> tag must be closed with </p>.

Unclosed <p> tags are very common to as paragraph breaks.

Thanks


From jonathan.gibbons at oracle.com  Tue Feb  5 09:36:50 2013
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Tue, 05 Feb 2013 09:36:50 -0800
Subject: Hundreds of errors generating javadoc ??
In-Reply-To: <51113C10.3010204@oracle.com>
References: <51113C10.3010204@oracle.com>
Message-ID: <51114332.8030004@oracle.com>

On 02/05/2013 09:06 AM, Roger Riggs wrote:
> Hi,
>
> What are the rules for valid tags? Which html schema is being enforced?
>
> It looks like every <p> tag must be closed with </p>.
>
> Unclosed <p> tags are very common to as paragraph breaks.
>
> Thanks

Something between 3.2 and 4.01 Transitional.

<p> does not require </p>. If you see evidence to the contrary in
doclint messages, please let me know or file an issue. For now, we
are using tools/javadoc(tool) for doclint issues.

-- Jon

From mike.duigou at oracle.com  Tue Feb  5 09:44:35 2013
From: mike.duigou at oracle.com (mike.duigou at oracle.com)
Date: Tue, 05 Feb 2013 17:44:35 +0000
Subject: hg: lambda/lambda: properly disable doclint now that it is in
	langtools repo.
Message-ID: <20130205174435.D833047845@hg.openjdk.java.net>

Changeset: 02fa42bb47f8
Author:    mduigou
Date:      2013-02-05 09:30 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/rev/02fa42bb47f8

properly disable doclint now that it is in langtools repo.
Backed out changeset 9e009634554b

! common/makefiles/javadoc/Javadoc.gmk


From mike.duigou at oracle.com  Tue Feb  5 09:45:29 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Tue, 5 Feb 2013 09:45:29 -0800
Subject: Hundreds of errors generating javadoc ??
In-Reply-To: <511129A8.8010601@oracle.com>
References: <51109C40.6000303@oracle.com> <511129A8.8010601@oracle.com>
Message-ID: <182C10DC-49F8-47FC-8471-28748AC6DD59@oracle.com>

The problem is now resolved. When I last integrated jdk8/jdk8 -> lambda/lambda  I had to remove the -Xdoclint:none from various make files as doclint had not been integrated yet into the lambda/lambda/langtools version of javac. I created changesets who's only action was removal of the "-Xdoclint:none". I have now backed out those two changesets.

That said, we must consider this incident as a portent. I can't imagine we plan to permanently disable doclint so fix your errors while you still can kiddos!

Mike


On Feb 5 2013, at 07:47 , Jonathan Gibbons wrote:

> This is the new doclint feature.  The feature is on by default in javadoc.
> It would appear you have lost -Xdoclint:none in the Makefile, which causes
> javadoc to revert to its earlier behavior.
> 
> -- Jon
> 
> On 02/04/2013 09:44 PM, David Holmes wrote:
>> Not sure what is going on as this is a fresh clone of the lambda forest
>> and the errors are in packages all over the place (unrelated to lambda
>> changes).
>> 
>> ??
>> 
>> David
>> -----
>> 
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/applet/Applet.java:527:
>> error: tag not allowed here: <p>
>>       * <p>
>>         ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/applet/Applet.java:183:
>> error: tag not allowed here: <p>
>>       * <p>
>>         ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/applet/Applet.java:395:
>> error: tag not allowed here: <p>
>>       * <p><blockquote><pre>
>>         ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/applet/Applet.java:395:
>> error: tag not allowed here: <blockquote>
>>       * <p><blockquote><pre>
>>            ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/applet/Applet.java:402:
>> error: tag not allowed here: <p>
>>       * <p>
>>         ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/applet/Applet.java:451:
>> error: tag not allowed here: <p>
>>       * <p>
>>         ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/applet/Applet.java:474:
>> error: tag not allowed here: <p>
>>       * <p>
>>         ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/applet/Applet.java:481:
>> error: tag not allowed here: <p>
>>       * <p>
>>         ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/applet/Applet.java:506:
>> error: tag not allowed here: <p>
>>       * <p>
>>         ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/Component.java:2168:
>> warning: no @param for width
>>      public void resize(int width, int height) {
>>                  ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/Component.java:2168:
>> warning: no @param for height
>>      public void resize(int width, int height) {
>>                  ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/Component.java:2199:
>> warning: no @param for d
>>      public void resize(Dimension d) {
>>                  ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/javax/accessibility/Accessible.java:49:
>> warning: no @return
>>      public AccessibleContext getAccessibleContext();
>>                               ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/applet/AppletContext.java:59:
>> warning: empty <code> tag
>>       * the screen. The <code>url</code> argument<code> </code>that is
>>                                                         ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/applet/AppletContext.java:175:
>> error: tag not allowed here: <p>
>>       * <p>
>>         ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/applet/AppletContext.java:188:
>> error: tag not allowed here: <p>
>>       * <p>
>>         ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/applet/AppletContext.java:155:
>> error: tag not allowed here: <p>
>>       * <p>
>>         ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/applet/AppletContext.java:160:
>> error: unexpected text
>>       * @throws <code>IOException</code> if the stream size exceeds a
>> certain
>>         ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/applet/AppletContext.java:165:
>> warning: no @throws for java.io.IOException
>>      public void setStream(String key, InputStream stream)throws
>> IOException;
>>                  ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/applet/AppletContext.java:111:
>> error: tag not allowed here: <center>
>>       * <center><table border="3" summary="Target arguments and their
>> descriptions">
>>         ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/applet/AppletContext.java:128:
>> error: tag not allowed here: <p>
>>       * <p>
>>         ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/ActiveEvent.java:42:
>> error: tag not allowed here: <p>
>>   * <p>
>>     ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:51:
>> error: tag not allowed here: <p>
>>   * <p>
>>     ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:62:
>> error: tag not allowed here: <p>
>>   * <p>
>>     ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:71:
>> error: tag not allowed here: <p>
>>   * <p>
>>     ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:75:
>> error: tag not allowed here: <blockquote>
>>   * <blockquote>
>>     ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:90:
>> error: tag not allowed here: <p>
>>   * <p>
>>     ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:105:
>> error: tag not allowed here: <pre>
>>   * <pre>
>>     ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:111:
>> error: tag not allowed here: <p>
>>   * <p>
>>     ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:115:
>> error: tag not allowed here: <blockquote>
>>   * <blockquote>
>>     ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:128:
>> error: tag not allowed here: <h3>
>>   * <h3>Preparing Inputs</h3>
>>     ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:130:
>> error: tag not allowed here: <p>
>>   * <p>
>>     ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:140:
>> error: tag not allowed here: <pre>
>>   * <pre>
>>     ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:152:
>> error: tag not allowed here: <pre>
>>   * <pre>
>>     ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:158:
>> error: tag not allowed here: <pre>
>>   * <pre>
>>     ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:161:
>> error: tag not allowed here: <p>
>>   * <p>
>>     ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:165:
>> error: tag not allowed here: <pre>
>>   * <pre>
>>     ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:169:
>> error: tag not allowed here: <h3>
>>   * <h3>Applying the Blending Equation</h3>
>>     ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:171:
>> error: tag not allowed here: <p>
>>   * <p>
>>     ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:178:
>> error: tag not allowed here: <p>
>>   * <p>
>>     ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:179:
>> error: tag not allowed here: <h3>
>>   * <h3>Preparing Results</h3>
>>     ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:181:
>> error: tag not allowed here: <p>
>>   * <p>
>>     ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:186:
>> error: tag not allowed here: <pre>
>>   * <pre>
>>     ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:196:
>> error: tag not allowed here: <p>
>>   * <p>
>>     ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:197:
>> error: tag not allowed here: <h3>
>>   * <h3>Performance Considerations</h3>
>>     ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:199:
>> error: tag not allowed here: <p>
>>   * <p>
>>     ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:210:
>> error: tag not allowed here: <h3>
>>   * <h3><a name="caveats">Implementation Caveats</a></h3>
>>     ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:212:
>> error: tag not allowed here: <ul>
>>   * <ul>
>>     ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:362:
>> error: tag not allowed here: <pre>
>>       *<pre>
>>        ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:387:
>> error: tag not allowed here: <pre>
>>       *<pre>
>>        ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:498:
>> error: tag not allowed here: <pre>
>>       *<pre>
>>        ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:440:
>> error: tag not allowed here: <pre>
>>       *<pre>
>>        ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:466:
>> error: tag not allowed here: <pre>
>>       *<pre>
>>        ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:414:
>> error: tag not allowed here: <pre>
>>       *<pre>
>>        ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:375:
>> error: tag not allowed here: <pre>
>>       *<pre>
>>        ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:484:
>> error: tag not allowed here: <pre>
>>       *<pre>
>>        ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:427:
>> error: tag not allowed here: <pre>
>>       *<pre>
>>        ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:453:
>> error: tag not allowed here: <pre>
>>       *<pre>
>>        ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:401:
>> error: tag not allowed here: <pre>
>>       *<pre>
>>        ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:513:
>> error: tag not allowed here: <pre>
>>       *<pre>
>>        ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:640:
>> warning: no @return
>>      public static AlphaComposite getInstance(int rule) {
>>                                   ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:688:
>> warning: no @return
>>      public static AlphaComposite getInstance(int rule, float alpha) {
>>                                   ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/lang/Object.java:71:
>> error: tag not allowed here: <ul>
>>       * <ul>
>>         ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/lang/Object.java:88:
>> error: tag not allowed here: <p>
>>       * <p>
>>         ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/lang/Object.java:107:
>> error: tag not allowed here: <ul>
>>       * <ul>
>>         ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/lang/Object.java:129:
>> error: tag not allowed here: <p>
>>       * <p>
>>         ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/lang/Object.java:136:
>> error: tag not allowed here: <p>
>>       * <p>
>>         ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEvent.java:52:
>> error: tag not allowed here: <p>
>>   * <p>
>>     ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEvent.java:392:
>> warning: no @return
>>      public int getID() {
>>                 ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEvent.java:450:
>> warning: no @return
>>      protected boolean isConsumed() {
>>                        ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/lang/Object.java:228:
>> error: tag not allowed here: <blockquote>
>>       * <blockquote>
>>         ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:43:
>> error: tag not allowed here: <pre>
>>   * <pre><code>
>>     ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:66:
>> error: tag not allowed here: <p>
>>   * <p>
>>     ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:76:
>> error: tag not allowed here: <p>
>>   * <p>
>>     ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:83:
>> error: tag not allowed here: <p>
>>   * <p>
>>     ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:86:
>> error: tag not allowed here: <ul>
>>   * <ul>
>>     ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:95:
>> error: tag not allowed here: <p>
>>   * <p>Swing makes use of
>>     ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:635:
>> warning: no @return
>>      public static ActionListener add(ActionListener a, ActionListener b) {
>>                                   ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:655:
>> warning: no @return
>>      public static AdjustmentListener add(AdjustmentListener a,
>> AdjustmentListener b) {
>>                                       ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:541:
>> warning: no @return
>>      public static ComponentListener add(ComponentListener a,
>> ComponentListener b) {
>>                                      ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:551:
>> warning: no @return
>>      public static ContainerListener add(ContainerListener a,
>> ContainerListener b) {
>>                                      ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:561:
>> warning: no @return
>>      public static FocusListener add(FocusListener a, FocusListener b) {
>>                                  ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:690:
>> warning: no @return
>>       public static HierarchyBoundsListener add(HierarchyBoundsListener
>> a, HierarchyBoundsListener b) {
>>                                             ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:679:
>> warning: no @return
>>       public static HierarchyListener add(HierarchyListener a,
>> HierarchyListener b) {
>>                                       ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:668:
>> warning: no @return
>>       public static InputMethodListener add(InputMethodListener a,
>> InputMethodListener b) {
>>                                         ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:645:
>> warning: no @return
>>      public static ItemListener add(ItemListener a, ItemListener b) {
>>                                 ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:571:
>> warning: no @return
>>      public static KeyListener add(KeyListener a, KeyListener b) {
>>                                ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:581:
>> warning: no @return
>>      public static MouseListener add(MouseListener a, MouseListener b) {
>>                                  ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:591:
>> warning: no @return
>>      public static MouseMotionListener add(MouseMotionListener a,
>> MouseMotionListener b) {
>>                                        ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:701:
>> warning: no @return
>>      public static MouseWheelListener add(MouseWheelListener a,
>>                                       ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:624:
>> warning: no @return
>>      public static WindowFocusListener add(WindowFocusListener a,
>>                                        ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:601:
>> warning: no @return
>>      public static WindowListener add(WindowListener a, WindowListener b) {
>>                                   ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:612:
>> warning: no @return
>>      public static WindowStateListener add(WindowStateListener a,
>>                                        ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:888:
>> warning: no @return
>>      protected static EventListener addInternal(EventListener a,
>> EventListener b) {
>>                                     ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:1022:
>> warning: no @param for <T>
>>          getListeners(EventListener l, Class<T> listenerType)
>>          ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:806:
>> warning: no @return
>>      public static ActionListener remove(ActionListener l,
>> ActionListener oldl) {
>>                                   ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:826:
>> warning: no @return
>>      public static AdjustmentListener remove(AdjustmentListener l,
>> AdjustmentListener oldl) {
>>                                       ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:712:
>> warning: no @return
>>      public static ComponentListener remove(ComponentListener l,
>> ComponentListener oldl) {
>>                                      ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:722:
>> warning: no @return
>>      public static ContainerListener remove(ContainerListener l,
>> ContainerListener oldl) {
>>                                      ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:136:
>> error: tag not allowed here: <p>
>>       * <p>
>>         ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:732:
>> warning: no @return
>>      public static FocusListener remove(FocusListener l, FocusListener
>> oldl) {
>>                                  ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:862:
>> warning: no @return
>>      public static HierarchyBoundsListener
>> remove(HierarchyBoundsListener l, HierarchyBoundsListener oldl) {
>>                                            ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:850:
>> warning: no @return
>>      public static HierarchyListener remove(HierarchyListener l,
>> HierarchyListener oldl) {
>>                                      ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:839:
>> warning: no @return
>>      public static InputMethodListener remove(InputMethodListener l,
>> InputMethodListener oldl) {
>>                                        ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:816:
>> warning: no @return
>>      public static ItemListener remove(ItemListener l, ItemListener oldl) {
>>                                 ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:742:
>> warning: no @return
>>      public static KeyListener remove(KeyListener l, KeyListener oldl) {
>>                                ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:752:
>> warning: no @return
>>      public static MouseListener remove(MouseListener l, MouseListener
>> oldl) {
>>                                  ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:762:
>> warning: no @return
>>      public static MouseMotionListener remove(MouseMotionListener l,
>> MouseMotionListener oldl) {
>>                                        ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:873:
>> warning: no @return
>>      public static MouseWheelListener remove(MouseWheelListener l,
>>                                       ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:795:
>> warning: no @return
>>      public static WindowFocusListener remove(WindowFocusListener l,
>>                                        ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:772:
>> warning: no @return
>>      public static WindowListener remove(WindowListener l,
>> WindowListener oldl) {
>>                                   ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:783:
>> warning: no @return
>>      public static WindowStateListener remove(WindowStateListener l,
>>                                        ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:905:
>> warning: no @return
>>      protected static EventListener removeInternal(EventListener l,
>> EventListener oldl) {
>>                                     ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/TextListener.java:53:
>> warning: no @param for e
>>      public void textValueChanged(TextEvent e);
>>                  ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/ComponentListener.java:58:
>> warning: no @param for e
>>      public void componentResized(ComponentEvent e);
>>                  ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/ComponentListener.java:63:
>> warning: no @param for e
>>      public void componentMoved(ComponentEvent e);
>>                  ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/ComponentListener.java:68:
>> warning: no @param for e
>>      public void componentShown(ComponentEvent e);
>>                  ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/ComponentListener.java:73:
>> warning: no @param for e
>>      public void componentHidden(ComponentEvent e);
>>                  ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/ContainerListener.java:59:
>> warning: no @param for e
>>      public void componentAdded(ContainerEvent e);
>>                  ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/ContainerListener.java:64:
>> warning: no @param for e
>>      public void componentRemoved(ContainerEvent e);
>>                  ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/FocusListener.java:55:
>> warning: no @param for e
>>      public void focusGained(FocusEvent e);
>>                  ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/FocusListener.java:60:
>> warning: no @param for e
>>      public void focusLost(FocusEvent e);
>>                  ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/KeyListener.java:58:
>> warning: no @param for e
>>      public void keyTyped(KeyEvent e);
>>                  ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/KeyListener.java:65:
>> warning: no @param for e
>>      public void keyPressed(KeyEvent e);
>>                  ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/KeyListener.java:72:
>> warning: no @param for e
>>      public void keyReleased(KeyEvent e);
>>                  ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/MouseListener.java:63:
>> warning: no @param for e
>>      public void mouseClicked(MouseEvent e);
>>                  ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/MouseListener.java:68:
>> warning: no @param for e
>>      public void mousePressed(MouseEvent e);
>>                  ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/MouseListener.java:73:
>> warning: no @param for e
>>      public void mouseReleased(MouseEvent e);
>>                  ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/MouseListener.java:78:
>> warning: no @param for e
>>      public void mouseEntered(MouseEvent e);
>>                  ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/MouseListener.java:83:
>> warning: no @param for e
>>      public void mouseExited(MouseEvent e);
>>                  ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/MouseMotionListener.java:63:
>> error: semicolon missing
>>       * Due to platform-dependent Drag&Drop implementations,
>>                                       ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/MouseMotionListener.java:65:
>> error: semicolon missing
>>       * Drag&Drop operation.
>>             ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/MouseMotionListener.java:67:
>> warning: no @param for e
>>      public void mouseDragged(MouseEvent e);
>>                  ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/MouseMotionListener.java:73:
>> warning: no @param for e
>>      public void mouseMoved(MouseEvent e);
>>                  ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/WindowListener.java:55:
>> warning: no @param for e
>>      public void windowOpened(WindowEvent e);
>>                  ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/WindowListener.java:61:
>> warning: no @param for e
>>      public void windowClosing(WindowEvent e);
>>                  ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/WindowListener.java:67:
>> warning: no @param for e
>>      public void windowClosed(WindowEvent e);
>>                  ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/WindowListener.java:76:
>> warning: no @param for e
>>      public void windowIconified(WindowEvent e);
>>                  ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/WindowListener.java:82:
>> warning: no @param for e
>>      public void windowDeiconified(WindowEvent e);
>>                  ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/WindowListener.java:92:
>> warning: no @param for e
>>      public void windowActivated(WindowEvent e);
>>                  ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/WindowListener.java:102:
>> warning: no @param for e
>>      public void windowDeactivated(WindowEvent e);
>>                  ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/WindowStateListener.java:54:
>> warning: no @param for e
>>      public void windowStateChanged(WindowEvent e);
>>                  ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/WindowFocusListener.java:61:
>> warning: no @param for e
>>      public void windowGainedFocus(WindowEvent e);
>>                  ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/WindowFocusListener.java:68:
>> warning: no @param for e
>>      public void windowLostFocus(WindowEvent e);
>>                  ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/ActionListener.java:50:
>> warning: no @param for e
>>      public void actionPerformed(ActionEvent e);
>>                  ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/ItemListener.java:54:
>> warning: no @param for e
>>      void itemStateChanged(ItemEvent e);
>>           ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/AdjustmentListener.java:41:
>> warning: no @param for e
>>      public void adjustmentValueChanged(AdjustmentEvent e);
>>                  ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/InputMethodListener.java:49:
>> warning: no @param for event
>>      void inputMethodTextChanged(InputMethodEvent event);
>>           ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/InputMethodListener.java:54:
>> warning: no @param for event
>>      void caretPositionChanged(InputMethodEvent event);
>>           ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/HierarchyListener.java:56:
>> warning: no @param for e
>>      public void hierarchyChanged(HierarchyEvent e);
>>                  ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/HierarchyBoundsListener.java:56:
>> warning: no @param for e
>>      public void ancestorMoved(HierarchyEvent e);
>>                  ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/HierarchyBoundsListener.java:61:
>> warning: no @param for e
>>      public void ancestorResized(HierarchyEvent e);
>>                  ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/MouseWheelListener.java:57:
>> warning: no @param for e
>>      public void mouseWheelMoved(MouseWheelEvent e);
>>                  ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTKeyStroke.java:402:
>> error: tag not allowed here: <ul>
>>       * used to specify the key code. For example:<ul>
>>                                                   ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTKeyStroke.java:407:
>> error: tag not allowed here: <ul>
>>       * The modifiers consist of any combination of:<ul>
>>                                                     ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTKeyStroke.java:414:
>> error: tag not allowed here: <ul>
>>       * The old modifiers <ul>
>>                           ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTKeyStroke.java:352:
>> error: tag not allowed here: <ul>
>>       * used to specify the key code. For example:<ul>
>>                                                   ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTKeyStroke.java:360:
>> error: tag not allowed here: <ul>
>>       * The modifiers consist of any combination of:<ul>
>>                                                     ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTKeyStroke.java:367:
>> error: tag not allowed here: <ul>
>>       * The old modifiers <ul>
>>                           ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTKeyStroke.java:488:
>> error: bad use of '>'
>>       *     "INSERT" => getAWTKeyStroke(KeyEvent.VK_INSERT, 0);
>>                       ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTKeyStroke.java:489:
>> error: bad use of '>'
>>       *     "control DELETE" => getAWTKeyStroke(KeyEvent.VK_DELETE,
>> InputEvent.CTRL_MASK);
>>                               ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTKeyStroke.java:490:
>> error: bad use of '>'
>>       *     "alt shift X" => getAWTKeyStroke(KeyEvent.VK_X,
>> InputEvent.ALT_MASK | InputEvent.SHIFT_MASK);
>>                            ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTKeyStroke.java:491:
>> error: bad use of '>'
>>       *     "alt shift released X" => getAWTKeyStroke(KeyEvent.VK_X,
>> InputEvent.ALT_MASK | InputEvent.SHIFT_MASK, true);
>>                                     ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTKeyStroke.java:492:
>> error: bad use of '>'
>>       *     "typed a" => getAWTKeyStroke('a');
>>                        ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTKeyStroke.java:803:
>> warning: no @throws for java.io.ObjectStreamException
>>      protected Object readResolve() throws java.io.ObjectStreamException {
>>                       ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTPermission.java:41:
>> error: tag not allowed here: <P>
>>   * <P>
>>     ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTPermission.java:46:
>> error: tag not allowed here: <P>
>>   * <P>
>>     ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTPermission.java:48:
>> error: tag not allowed here: <table>
>>   * <table border=1 cellpadding=5 summary="AWTPermission target names,
>> descriptions, and associated risks.">
>>     ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/BasicStroke.java:42:
>> warning: attribute obsolete, use CSS instead: compact
>>   * <dl compact>
>>         ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/BorderLayout.java:61:
>> error: tag not allowed here: <p>
>>   * <p>
>>     ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/BorderLayout.java:70:
>> error: tag not allowed here: <p>
>>   * <p>
>>     ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/BorderLayout.java:78:
>> error: tag not allowed here: <p>
>>   * <p>
>>     ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/BorderLayout.java:83:
>> error: tag not allowed here: <p>
>>   * <p>
>>     ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/BorderLayout.java:91:
>> error: tag not allowed here: <p>
>>   * <p>
>>     ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/BorderLayout.java:94:
>> error: tag not allowed here: <p>
>>   * <p>
>>     ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/BorderLayout.java:99:
>> warning: attribute obsolete, use CSS instead: ALIGN
>>   * ALIGN=center HSPACE=10 VSPACE=7>
>>     ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/BorderLayout.java:99:
>> warning: attribute obsolete, use CSS instead: HSPACE
>>   * ALIGN=center HSPACE=10 VSPACE=7>
>>                  ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/BorderLayout.java:99:
>> warning: attribute obsolete, use CSS instead: VSPACE
>>   * ALIGN=center HSPACE=10 VSPACE=7>
>>                            ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/BorderLayout.java:100:
>> error: tag not allowed here: <p>
>>   * <p>
>>     ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/BorderLayout.java:102:
>> error: tag not allowed here: <p>
>>   * <p>
>>     ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/BorderLayout.java:103:
>> error: tag not allowed here: <hr>
>>   * <hr><blockquote><pre>
>>     ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/BorderLayout.java:103:
>> error: tag not allowed here: <blockquote>
>>   * <hr><blockquote><pre>
>>         ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/BorderLayout.java:117:
>> error: tag not allowed here: <hr>
>>   * </pre></blockquote><hr>
>>                        ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/BorderLayout.java:118:
>> error: tag not allowed here: <p>
>>   * <p>
>>     ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/BorderLayout.java:372:
>> warning: no @return
>>      public int getHgap() {
>>                 ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/BorderLayout.java:389:
>> warning: no @return
>>      public int getVgap() {
>>                 ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/BorderLayout.java:795:
>> error: tag not allowed here: <p>
>>       * <p>
>>         ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/LayoutManager2.java:61:
>> warning: no @param for target
>>      public Dimension maximumLayoutSize(Container target);
>>                       ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/LayoutManager2.java:61:
>> warning: no @return
>>      public Dimension maximumLayoutSize(Container target);
>>                       ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/LayoutManager2.java:70:
>> warning: no @param for target
>>      public float getLayoutAlignmentX(Container target);
>>                   ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/LayoutManager2.java:70:
>> warning: no @return
>>      public float getLayoutAlignmentX(Container target);
>>                   ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/LayoutManager2.java:79:
>> warning: no @param for target
>>      public float getLayoutAlignmentY(Container target);
>>                   ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/lang/Object.java:174:
>> error: tag not allowed here: <p>
>>       * <p>
>>         ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/lang/Object.java:185:
>> error: tag not allowed here: <p>
>>       * <p>
>>         ^
>> /export/users/dh198349/lambda/jdk/src/share/classes/java/lang/Object.java:198:
>> error: tag not allowed here: <p>
>>       * <p>
>>         ^
>> 100 errors
>> 100 warnings
>> make[1]: ***
>> [/export/users/dh198349/lambda/builds/b00/se-linux-i586-ea/docs/api/index.html]
>> Error 1
>> make: *** [docs-only] Error 2
>> 
> 
> 


From mike.duigou at oracle.com  Tue Feb  5 09:44:51 2013
From: mike.duigou at oracle.com (mike.duigou at oracle.com)
Date: Tue, 05 Feb 2013 17:44:51 +0000
Subject: hg: lambda/lambda/jdk: properly disable doclint now that it is
	integrated into langtools
Message-ID: <20130205174514.7549F47846@hg.openjdk.java.net>

Changeset: a4f32e60635c
Author:    mduigou
Date:      2013-02-05 09:31 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/a4f32e60635c

properly disable doclint now that it is integrated into langtools

! make/docs/Makefile


From zhong.j.yu at gmail.com  Tue Feb  5 10:16:21 2013
From: zhong.j.yu at gmail.com (Zhong Yu)
Date: Tue, 5 Feb 2013 12:16:21 -0600
Subject: Inferring Exception type of a lambda body
Message-ID: <CACuKZqHsAonEoi3pPLp-FANC7wAHCJ0rTrPc-2cx7HeU-y_qjA@mail.gmail.com>

Say we have a functional interface in which the method throws a type variable E

    interface Action<E extends Throwable>
    {
        void doIt() throws E;
    }

and a generic method that invokes Action<E> and passes through E

    <E extends Throwable> void invoke(Action<E> action) throws E
    {
        action.doIt(); // throws E
    }

It works for lambdas that throw checked exceptions:

    // compiles, E is inferred as Exception
    void test1() throws Exception
    {
        invoke( ()->{ throw new Exception(); } );
    }

But it doesn't work for unchecked exceptions:

    // fails, E is inferred as Throwable
    void test2()
    {
        invoke( ()->{ } );
        // or invoke( ()->{ throw new RuntimeException(); } );
        // or invoke( ()->{ throw new Error(); } );
    }

Apparently, if the lambda body throws only unchecked exceptions, javac
does not set a lower bound on E, so E is chosen to be its upper bound
Throwable.

I'd argue that Throwable is too broad for E, and E should have a lower
bound. Since any method can throw Error, Action.doIt() actually throws
Error|E, which should be a super type of unchecked exceptions, i.e.
Error|E :> Error|RuntimeException, so we can argue that E :>
RuntimeException.

My suggestion for the inference rule is, very simplistically,

If E has not been inferred from previous steps, and E is in the throw
clause, and E has an upper constraint E<<X,
    if X:>RuntimeException, infer E=RuntimeException
    otherwise, infer E=X. (X is an Error or a checked exception)

Zhong Yu

From maurizio.cimadamore at oracle.com  Tue Feb  5 10:29:41 2013
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Tue, 05 Feb 2013 18:29:41 +0000
Subject: Inferring Exception type of a lambda body
In-Reply-To: <CACuKZqHsAonEoi3pPLp-FANC7wAHCJ0rTrPc-2cx7HeU-y_qjA@mail.gmail.com>
References: <CACuKZqHsAonEoi3pPLp-FANC7wAHCJ0rTrPc-2cx7HeU-y_qjA@mail.gmail.com>
Message-ID: <51114F95.2020207@oracle.com>

On 05/02/13 18:16, Zhong Yu wrote:
> My suggestion for the inference rule is, very simplistically,
>
> If E has not been inferred from previous steps, and E is in the throw
> clause, and E has an upper constraint E<<X,
>      if X:>RuntimeException, infer E=RuntimeException
>      otherwise, infer E=X. (X is an Error or a checked exception)
Stay tuned - we are evaluating something along these lines

Maurizio

From Roger.Riggs at oracle.com  Tue Feb  5 10:45:54 2013
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Tue, 05 Feb 2013 13:45:54 -0500
Subject: Hundreds of errors generating javadoc ??
In-Reply-To: <mailman.8011.1360086344.853.lambda-dev@openjdk.java.net>
References: <mailman.8011.1360086344.853.lambda-dev@openjdk.java.net>
Message-ID: <51115362.1010303@oracle.com>

Hi,

Issue filed with example program:  JDK-8007566.
(Or just check Applet.java).

Thanks, Roger

> On 02/05/2013 09:06 AM, Roger Riggs wrote:
>> >  Hi,
>> >
>> >  What are the rules for valid tags? Which html schema is being enforced?
>> >
>> >  It looks like every<p>  tag must be closed with</p>.
>> >
>> >  Unclosed<p>  tags are very common to as paragraph breaks.
>> >
>> >  Thanks
> Something between 3.2 and 4.01 Transitional.
>
> <p>  does not require</p>. If you see evidence to the contrary in
> doclint messages, please let me know or file an issue. For now, we
> are using tools/javadoc(tool) for doclint issues.
>
> -- Jon


From brian.goetz at oracle.com  Tue Feb  5 11:07:49 2013
From: brian.goetz at oracle.com (brian.goetz at oracle.com)
Date: Tue, 05 Feb 2013 19:07:49 +0000
Subject: hg: lambda/lambda/jdk: 2 new changesets
Message-ID: <20130205190824.1855D47849@hg.openjdk.java.net>

Changeset: c20d8fb25a17
Author:    briangoetz
Date:      2013-02-05 14:07 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/c20d8fb25a17

Clean up FindOp

! src/share/classes/java/util/stream/DoublePipeline.java
! src/share/classes/java/util/stream/FindOp.java
! src/share/classes/java/util/stream/IntPipeline.java
! src/share/classes/java/util/stream/LongPipeline.java
! src/share/classes/java/util/stream/ReferencePipeline.java

Changeset: ad394630273b
Author:    briangoetz
Date:      2013-02-05 14:07 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/ad394630273b

Merge



From jonathan.gibbons at oracle.com  Tue Feb  5 11:41:24 2013
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Tue, 05 Feb 2013 11:41:24 -0800
Subject: Hundreds of errors generating javadoc ??
In-Reply-To: <51115362.1010303@oracle.com>
References: <mailman.8011.1360086344.853.lambda-dev@openjdk.java.net>
	<51115362.1010303@oracle.com>
Message-ID: <51116064.8000906@oracle.com>

Noted.  Definitely a bug. Thanks for filing the issue.

-- Jon

On 02/05/2013 10:45 AM, Roger Riggs wrote:
> Hi,
>
> Issue filed with example program:  JDK-8007566.
> (Or just check Applet.java).
>
> Thanks, Roger
>
>> On 02/05/2013 09:06 AM, Roger Riggs wrote:
>>>>   Hi,
>>>>
>>>>   What are the rules for valid tags? Which html schema is being enforced?
>>>>
>>>>   It looks like every<p>  tag must be closed with</p>.
>>>>
>>>>   Unclosed<p>  tags are very common to as paragraph breaks.
>>>>
>>>>   Thanks
>> Something between 3.2 and 4.01 Transitional.
>>
>> <p>  does not require</p>. If you see evidence to the contrary in
>> doclint messages, please let me know or file an issue. For now, we
>> are using tools/javadoc(tool) for doclint issues.
>>
>> -- Jon
>


From brian.goetz at oracle.com  Tue Feb  5 13:57:14 2013
From: brian.goetz at oracle.com (brian.goetz at oracle.com)
Date: Tue, 05 Feb 2013 21:57:14 +0000
Subject: hg: lambda/lambda/jdk: Cleanup in Collectors implementation of
	averaging; move to something more like ParallelArray.getStatistics
Message-ID: <20130205215738.3C6A94784E@hg.openjdk.java.net>

Changeset: a806c8b615b3
Author:    briangoetz
Date:      2013-02-05 16:57 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/a806c8b615b3

Cleanup in Collectors implementation of averaging; move to something more like ParallelArray.getStatistics

! src/share/classes/java/util/stream/Collectors.java
! src/share/classes/java/util/stream/DoubleStream.java
! src/share/classes/java/util/stream/IntStream.java
! src/share/classes/java/util/stream/LongStream.java
! test-ng/tests/org/openjdk/tests/java/util/stream/PrimitiveSumTest.java


From howard.lovatt at gmail.com  Tue Feb  5 14:41:08 2013
From: howard.lovatt at gmail.com (Howard Lovatt)
Date: Wed, 6 Feb 2013 09:41:08 +1100
Subject: Grouping stream elements by their position - how to handle tail
	of stream ?
In-Reply-To: <5110489F.7000309@oracle.com>
References: <CAB_DFWaUEv8jAo6Ok58d7EthS6gZubSvr8rbXxGoEVLVAmjeug@mail.gmail.com>
	<510D8B41.6040109@oracle.com>
	<CAKJVG8Z3R4ax-ySsuGEPhptjjx6_frnhak3HksfqsHnnT3ZEMA@mail.gmail.com>
	<510DE1B1.3030904@oracle.com>
	<CACR_FB6Y0zDETfxDc_UB2_z7j+ytm8eCF7HaZQveMDrFWFng0A@mail.gmail.com>
	<5110489F.7000309@oracle.com>
Message-ID: <62B8DDFA-86C6-404D-AB17-140D02D77B04@gmail.com>

Hi,

In many engineering/science languages you have a reshape, transpose, and/or sparse function that can be applied to a matrix or vector. Taking transpose as an example (forgive the very sketchy code below using methods/classes that don't exist - hopefully you will get the idea - had to write on iPad on the run):

DoubleMatrix m = {{x1, x2}, {y1, y2}}; // unfortunately no stream literal syntax, yet!
DoubleMatrix mt = m.transpose(); // {{x1, y1}, {x1, y2}

Where:

// Matrix is an immutable Stream
class DoubleMatrix implements Stream<DoubleVector> { 
  private final DoubleVector m; // store the elements in a continuous block to ensure cache hits
  private final int nrows;
  private final int ncols;
  public double getDouble(final int row, final int col) {
     // should check bounds
     return m.getDouble(row * ncols + col);
  }
  public DoubleMatrix transpose() {
     final int[] oldPermute = m.permute();
     final int[] newPermute = new int[nrows * ncols];
     for (int r = 0; r < nrows; r++) {
       for (int c = 0; c < ncols; c++) {
         permute[oldPermute[r * ncols + c]] = c * nrows + r;
      }
    }
    return new DoubleMatrix(m, ncols, nrows, newPermute);
  }
  public DoubleMatrix(final DoubleVector m, final int nrows, final int ncols, final int[] permute) { ... }
  ...
}

// Vector is an immutable Stream
DoubleVector extends AbstractDoubleStream {
 private final static int[] noPermutations = ...;
 private final int[] permute;
 public int[] permute() {
   if (permute == null) { return noPermutations; }
   return permute;
  }
  public double getDouble(final int index) {
    if (permute == null) { return super.getDouble(index); }
    return super.getDouble(permute[index]);
  }
  public DoubleVector(final DoubleVector v, final int[] permute) { ... }
  ...
}


There might be other use cases for permuting streams; like parsing characters into words, which would require permute to be in Stream and not Vector. However the above code is considerably simplified because the collections are immutable. In Stream the permute operations should ideally be lazy, unlike the above which is a paraphrase of existing matrix classes that exist in various libraries. 

Cheers,

-- Howard. 

Sent from my iPad

On 05/02/2013, at 10:47 AM, Brian Goetz <brian.goetz at oracle.com> wrote:

> Could you clarify what you are suggesting?
> 
> On 2/4/2013 6:27 PM, Howard Lovatt wrote:
>> Hi Brian,
>> 
>> This is an enquiry related to grouping or parsing an input stream, but
>> a little different.
>> 
>> In numerical programs common operations are matrix: transpose, other
>> reshaping, or 'sparsification'. I have seen these implemented on
>> parallel architectures as an indirection of indexes, something like:
>> 
>> matrix[indexTransformation[index]]
>> 
>> Has thought been given to such a capability for the stream library?
>> 
>> Thanks,
>> 
>> -- Howard.
>> 
>> Sent from my iPad
>> 
>> On 03/02/2013, at 3:04 PM, Brian Goetz <brian.goetz at oracle.com> wrote:
>> 
>>> Look at the implementations in Collectors for a hint.  Obviously we owe
>>> some significant documentation, which unfortunately lags the code by too
>>> much.  But a Collector is basically a mutable foldl/inject; you provide
>>> a way to create a new mutable container, a way to add a single element
>>> to it, and a way to combine two mutable containers.  The framework
>>> decomposes the source, creates a bunch of little containers at the
>>> leaves, and them goes up the tree, merging.
>>> 
>>> Dumping the elements into an ArrayList maps easily to Collector:
>>> 
>>> collect(ArrayList::new, ArrayList::add, ArrayList::addAll)
>>> 
>>> This parallelizes, as we can collect each chunk into a list, and then
>>> merge the lists up the tree with addAll.
>>> 
>>> The "how do I get the last element" problem goes away, since your data
>>> structure can explicitly maintain the state of whether the chunk ends
>>> with a balanced pair or an extra.
>>> 
>>> But, you need to calculate BOTH p0 and p1 for each chunk (except maybe
>>> the left-spine chunks), because you don't know until the end which will
>>> have the right parity.
>>> 
>>> On 2/2/2013 7:49 PM, Lattie wrote:
>>>>> Now, that said, here's a parallel algorithm you can implement with
>>>>> collect(), though you may find the performance overhead too offensive.
>>>>> Basically, for each chunk of the input t1..tn, you compute two possible
>>>>> answers:
>>>>> 
>>>>> p0 = (t1,t2), (t3,t4), ..., maybe leftover tn
>>>> 
>>>> This is what I want... the ability to compute p0.  I was not able to
>>>> figure out how to use collect() to do this though, and so I went down
>>>> the road of explode() with a stateful lambda... can someone point me
>>>> to any tutorial or info on how to properly use collect()?
>>>> 
>>>> TIA
>>>> 
>>>> 
>>>> On Sat, Feb 2, 2013 at 1:55 PM, Brian Goetz <brian.goetz at oracle.com> wrote:
>>>>> The glass is half full, or half empty, depending on your disposition.
>>>>> 
>>>>> While its trivial to write a version of explode() that remembers the
>>>>> last element seen, and either emits nothing or a pair (you have a little
>>>>> fixup at the end to deal with, but that's easy too, just annoying), once
>>>>> you start writing such stateful lambdas, you are tying yourself to
>>>>> sequential execution in a very error-prone way.  The type system can't
>>>>> record this assumption, so when someone helpfully later adds a
>>>>> .parallel() somewhere, your code will silently turn to sewage.  So,
>>>>> don't ever do this.
>>>>> 
>>>>> Too see why the obvious algorithm is sequential only, consider a
>>>>> decomposition of a data source with a spliterator.  In most cases, we
>>>>> don't necessarily know the even-ness or odd-ness of the sum of sizes of
>>>>> all prior splits.  Which means we don't know whether the first element
>>>>> of any given split is the left element of some pair or the right element
>>>>> of some pair.
>>>>> 
>>>>> You might say: I don't care about parallelism, I only care about
>>>>> sequential.
>>>>> 
>>>>> To which we'd respond: fine, but we're not really interested in
>>>>> distorting the model to encourage that.  The Stream API is designed
>>>>> around operations that can be equally well performed in serial or
>>>>> parallel.  There are no "serial only" operations supported, and that was
>>>>> an explicit design choice.  Passing state-holding lambdas to these
>>>>> methods is likely to be a spec violation.  We can't enforce it, any more
>>>>> than we can enforce the lack of data races, but bear in mind that if you
>>>>> do this, you're writing broken code, and asking for trouble.
>>>>> 
>>>>> Now, that said, here's a parallel algorithm you can implement with
>>>>> collect(), though you may find the performance overhead too offensive.
>>>>> Basically, for each chunk of the input t1..tn, you compute two possible
>>>>> answers:
>>>>> 
>>>>> p0 = (t1,t2), t3,t4), ..., maybe leftover tn
>>>>> p1 = t1, (t2, t3), (t4, t5), ... maybe leftover tn
>>>>> 
>>>>> then you combine these pairs chunks in the mostly obvious way (observe
>>>>> that p0 has trailing element = !(p1 has trailing element)).  Then when
>>>>> you get to the top of the tree, you take the one that doesn't have an
>>>>> orphaned initial element, and toss the other.  Basically you're doing 2x
>>>>> work for each input element, but it parallelizes fairly cleanly.
>>>>> 
>>>>> Such an algorithm is ideally suited to collect(), because a Collector is
>>>>> a representation of a catamorphism, which the above transformation is.
>>>>> Because the combination logic is associative, it parallelizes cleanly
>>>>> without needing any nasty stateful lambdas.
>>>>> 
>>>>> When we expose the Op APIs and you can write your own
>>>>> decomposition-aware operations, you'll have another option: write a
>>>>> StatefulOp.  This won't be an option for 8, but once we do, its easy
>>>>> enough, and it will let you avoid the extra overhead by creating a
>>>>> custom operation.
>>>>> 
>>>>> So, to sum up:
>>>>> - If you're looking for a one-liner, you'll be disappointed;
>>>>> - If you convince yourself "I would never need parallelism here" and
>>>>> write the obvious unsafe stateful lambda, please write your manager a
>>>>> letter first explaining how your incompetence is putting the reliability
>>>>> of his product in jeopardy;
>>>>> - If you're willing to write the above collector, you'll likely be
>>>>> happy enough with the result.
>>>>> 
>>>>> 
>>>>> On 2/2/2013 3:35 PM, Boaz Nahum wrote:
>>>>>> Hi.
>>>>>> 
>>>>>> I looking in Stream interface for a way to convert a stream of
>>>>>>   {  t1, t2, .. Tn }
>>>>>> to
>>>>>>   { {t1,t2}, ... {Tn-1, Tn} }
>>>>>> or
>>>>>>   { {t1,t2}, ... {Tn, null}}
>>>>>> 
>>>>>> Lets assume {t1, t2} are aggeraget by Pair<T,T>
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> So I tried to use explode:
>>>>>> 
>>>>>> *        Stream<Integer> si = Arrays.asList(1, 2, 3, 4, 5).stream();
>>>>>> 
>>>>>>        Stream<Pair<Integer, Integer>> spi = si.sequential().explode(new
>>>>>> BiConsumer<Stream.Downstream<Pair<Integer, Integer>>, Integer>() {
>>>>>> 
>>>>>>            Integer firstValue;
>>>>>> 
>>>>>>            @Override
>>>>>>            public void accept(Stream.Downstream<Pair<Integer, Integer>>
>>>>>> pairDownstream, Integer v) {
>>>>>> 
>>>>>>                if (firstValue == null) {
>>>>>>                    firstValue = v;
>>>>>>                } else {
>>>>>> 
>>>>>>                    pairDownstream.send(new Pair<>(firstValue, v));
>>>>>>                    firstValue = null;
>>>>>> 
>>>>>>                }
>>>>>>            }
>>>>>> 
>>>>>>        });
>>>>>> *
>>>>>> 
>>>>>> But I didn't find a way to add the tail of input stream {.., 5} to the new
>>>>>> stream { ,,, {5, null}}.
>>>>>> 
>>>>>> Of-course this only simplified example of more general problem I have.
>>>>>> 
>>>>>> Thanks
>>>>>> Boaz
>>> 

From henry.jen at oracle.com  Tue Feb  5 19:51:38 2013
From: henry.jen at oracle.com (Henry Jen)
Date: Tue, 05 Feb 2013 19:51:38 -0800
Subject: CFR - updated 8001667: Comparator combinators and extension methods
Message-ID: <5111D34A.4020309@oracle.com>

Hi,

This is an update on previous reviewed version, there are two new method
introduced for Comparators to convert a Comparator into a BinaryOperator
and corresponding test cases.

As there is one new class, java.util.Comparators for 8001667, so we need
to have makefile change, thus involve build-infra.

Comparators.java

public static<T> BinaryOperator<T> lesserOf(Comparator<? super T>
comparator);
public static<T> BinaryOperator<T> greaterOf(Comparator<? super T>
comparator);


[1] http://cr.openjdk.java.net/~henryjen/ccc/8001667.3/webrev

Cheers,
Henry

From david.holmes at oracle.com  Tue Feb  5 20:33:05 2013
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 06 Feb 2013 14:33:05 +1000
Subject: Hundreds of errors generating javadoc ??
In-Reply-To: <182C10DC-49F8-47FC-8471-28748AC6DD59@oracle.com>
References: <51109C40.6000303@oracle.com> <511129A8.8010601@oracle.com>
	<182C10DC-49F8-47FC-8471-28748AC6DD59@oracle.com>
Message-ID: <5111DD01.8070304@oracle.com>

On 6/02/2013 3:45 AM, Mike Duigou wrote:
> The problem is now resolved. When I last integrated jdk8/jdk8 ->  lambda/lambda  I had to remove the -Xdoclint:none from various make files as doclint had not been integrated yet into the lambda/lambda/langtools version of javac. I created changesets who's only action was removal of the "-Xdoclint:none". I have now backed out those two changesets.

Thanks for that Mike. Though I had already applied the top-repo patch 
locally and it did not resolve the issue in the new build. Seems the 
change in the old doc makefile was also needed - weird ??

All fixed now.

David

> That said, we must consider this incident as a portent. I can't imagine we plan to permanently disable doclint so fix your errors while you still can kiddos!
>
> Mike
>
>
> On Feb 5 2013, at 07:47 , Jonathan Gibbons wrote:
>
>> This is the new doclint feature.  The feature is on by default in javadoc.
>> It would appear you have lost -Xdoclint:none in the Makefile, which causes
>> javadoc to revert to its earlier behavior.
>>
>> -- Jon
>>
>> On 02/04/2013 09:44 PM, David Holmes wrote:
>>> Not sure what is going on as this is a fresh clone of the lambda forest
>>> and the errors are in packages all over the place (unrelated to lambda
>>> changes).
>>>
>>> ??
>>>
>>> David
>>> -----
>>>
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/applet/Applet.java:527:
>>> error: tag not allowed here:<p>
>>>        *<p>
>>>          ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/applet/Applet.java:183:
>>> error: tag not allowed here:<p>
>>>        *<p>
>>>          ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/applet/Applet.java:395:
>>> error: tag not allowed here:<p>
>>>        *<p><blockquote><pre>
>>>          ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/applet/Applet.java:395:
>>> error: tag not allowed here:<blockquote>
>>>        *<p><blockquote><pre>
>>>             ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/applet/Applet.java:402:
>>> error: tag not allowed here:<p>
>>>        *<p>
>>>          ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/applet/Applet.java:451:
>>> error: tag not allowed here:<p>
>>>        *<p>
>>>          ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/applet/Applet.java:474:
>>> error: tag not allowed here:<p>
>>>        *<p>
>>>          ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/applet/Applet.java:481:
>>> error: tag not allowed here:<p>
>>>        *<p>
>>>          ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/applet/Applet.java:506:
>>> error: tag not allowed here:<p>
>>>        *<p>
>>>          ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/Component.java:2168:
>>> warning: no @param for width
>>>       public void resize(int width, int height) {
>>>                   ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/Component.java:2168:
>>> warning: no @param for height
>>>       public void resize(int width, int height) {
>>>                   ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/Component.java:2199:
>>> warning: no @param for d
>>>       public void resize(Dimension d) {
>>>                   ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/javax/accessibility/Accessible.java:49:
>>> warning: no @return
>>>       public AccessibleContext getAccessibleContext();
>>>                                ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/applet/AppletContext.java:59:
>>> warning: empty<code>  tag
>>>        * the screen. The<code>url</code>  argument<code>  </code>that is
>>>                                                          ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/applet/AppletContext.java:175:
>>> error: tag not allowed here:<p>
>>>        *<p>
>>>          ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/applet/AppletContext.java:188:
>>> error: tag not allowed here:<p>
>>>        *<p>
>>>          ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/applet/AppletContext.java:155:
>>> error: tag not allowed here:<p>
>>>        *<p>
>>>          ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/applet/AppletContext.java:160:
>>> error: unexpected text
>>>        * @throws<code>IOException</code>  if the stream size exceeds a
>>> certain
>>>          ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/applet/AppletContext.java:165:
>>> warning: no @throws for java.io.IOException
>>>       public void setStream(String key, InputStream stream)throws
>>> IOException;
>>>                   ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/applet/AppletContext.java:111:
>>> error: tag not allowed here:<center>
>>>        *<center><table border="3" summary="Target arguments and their
>>> descriptions">
>>>          ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/applet/AppletContext.java:128:
>>> error: tag not allowed here:<p>
>>>        *<p>
>>>          ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/ActiveEvent.java:42:
>>> error: tag not allowed here:<p>
>>>    *<p>
>>>      ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:51:
>>> error: tag not allowed here:<p>
>>>    *<p>
>>>      ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:62:
>>> error: tag not allowed here:<p>
>>>    *<p>
>>>      ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:71:
>>> error: tag not allowed here:<p>
>>>    *<p>
>>>      ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:75:
>>> error: tag not allowed here:<blockquote>
>>>    *<blockquote>
>>>      ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:90:
>>> error: tag not allowed here:<p>
>>>    *<p>
>>>      ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:105:
>>> error: tag not allowed here:<pre>
>>>    *<pre>
>>>      ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:111:
>>> error: tag not allowed here:<p>
>>>    *<p>
>>>      ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:115:
>>> error: tag not allowed here:<blockquote>
>>>    *<blockquote>
>>>      ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:128:
>>> error: tag not allowed here:<h3>
>>>    *<h3>Preparing Inputs</h3>
>>>      ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:130:
>>> error: tag not allowed here:<p>
>>>    *<p>
>>>      ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:140:
>>> error: tag not allowed here:<pre>
>>>    *<pre>
>>>      ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:152:
>>> error: tag not allowed here:<pre>
>>>    *<pre>
>>>      ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:158:
>>> error: tag not allowed here:<pre>
>>>    *<pre>
>>>      ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:161:
>>> error: tag not allowed here:<p>
>>>    *<p>
>>>      ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:165:
>>> error: tag not allowed here:<pre>
>>>    *<pre>
>>>      ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:169:
>>> error: tag not allowed here:<h3>
>>>    *<h3>Applying the Blending Equation</h3>
>>>      ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:171:
>>> error: tag not allowed here:<p>
>>>    *<p>
>>>      ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:178:
>>> error: tag not allowed here:<p>
>>>    *<p>
>>>      ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:179:
>>> error: tag not allowed here:<h3>
>>>    *<h3>Preparing Results</h3>
>>>      ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:181:
>>> error: tag not allowed here:<p>
>>>    *<p>
>>>      ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:186:
>>> error: tag not allowed here:<pre>
>>>    *<pre>
>>>      ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:196:
>>> error: tag not allowed here:<p>
>>>    *<p>
>>>      ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:197:
>>> error: tag not allowed here:<h3>
>>>    *<h3>Performance Considerations</h3>
>>>      ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:199:
>>> error: tag not allowed here:<p>
>>>    *<p>
>>>      ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:210:
>>> error: tag not allowed here:<h3>
>>>    *<h3><a name="caveats">Implementation Caveats</a></h3>
>>>      ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:212:
>>> error: tag not allowed here:<ul>
>>>    *<ul>
>>>      ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:362:
>>> error: tag not allowed here:<pre>
>>>        *<pre>
>>>         ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:387:
>>> error: tag not allowed here:<pre>
>>>        *<pre>
>>>         ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:498:
>>> error: tag not allowed here:<pre>
>>>        *<pre>
>>>         ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:440:
>>> error: tag not allowed here:<pre>
>>>        *<pre>
>>>         ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:466:
>>> error: tag not allowed here:<pre>
>>>        *<pre>
>>>         ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:414:
>>> error: tag not allowed here:<pre>
>>>        *<pre>
>>>         ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:375:
>>> error: tag not allowed here:<pre>
>>>        *<pre>
>>>         ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:484:
>>> error: tag not allowed here:<pre>
>>>        *<pre>
>>>         ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:427:
>>> error: tag not allowed here:<pre>
>>>        *<pre>
>>>         ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:453:
>>> error: tag not allowed here:<pre>
>>>        *<pre>
>>>         ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:401:
>>> error: tag not allowed here:<pre>
>>>        *<pre>
>>>         ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:513:
>>> error: tag not allowed here:<pre>
>>>        *<pre>
>>>         ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:640:
>>> warning: no @return
>>>       public static AlphaComposite getInstance(int rule) {
>>>                                    ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AlphaComposite.java:688:
>>> warning: no @return
>>>       public static AlphaComposite getInstance(int rule, float alpha) {
>>>                                    ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/lang/Object.java:71:
>>> error: tag not allowed here:<ul>
>>>        *<ul>
>>>          ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/lang/Object.java:88:
>>> error: tag not allowed here:<p>
>>>        *<p>
>>>          ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/lang/Object.java:107:
>>> error: tag not allowed here:<ul>
>>>        *<ul>
>>>          ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/lang/Object.java:129:
>>> error: tag not allowed here:<p>
>>>        *<p>
>>>          ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/lang/Object.java:136:
>>> error: tag not allowed here:<p>
>>>        *<p>
>>>          ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEvent.java:52:
>>> error: tag not allowed here:<p>
>>>    *<p>
>>>      ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEvent.java:392:
>>> warning: no @return
>>>       public int getID() {
>>>                  ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEvent.java:450:
>>> warning: no @return
>>>       protected boolean isConsumed() {
>>>                         ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/lang/Object.java:228:
>>> error: tag not allowed here:<blockquote>
>>>        *<blockquote>
>>>          ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:43:
>>> error: tag not allowed here:<pre>
>>>    *<pre><code>
>>>      ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:66:
>>> error: tag not allowed here:<p>
>>>    *<p>
>>>      ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:76:
>>> error: tag not allowed here:<p>
>>>    *<p>
>>>      ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:83:
>>> error: tag not allowed here:<p>
>>>    *<p>
>>>      ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:86:
>>> error: tag not allowed here:<ul>
>>>    *<ul>
>>>      ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:95:
>>> error: tag not allowed here:<p>
>>>    *<p>Swing makes use of
>>>      ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:635:
>>> warning: no @return
>>>       public static ActionListener add(ActionListener a, ActionListener b) {
>>>                                    ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:655:
>>> warning: no @return
>>>       public static AdjustmentListener add(AdjustmentListener a,
>>> AdjustmentListener b) {
>>>                                        ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:541:
>>> warning: no @return
>>>       public static ComponentListener add(ComponentListener a,
>>> ComponentListener b) {
>>>                                       ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:551:
>>> warning: no @return
>>>       public static ContainerListener add(ContainerListener a,
>>> ContainerListener b) {
>>>                                       ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:561:
>>> warning: no @return
>>>       public static FocusListener add(FocusListener a, FocusListener b) {
>>>                                   ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:690:
>>> warning: no @return
>>>        public static HierarchyBoundsListener add(HierarchyBoundsListener
>>> a, HierarchyBoundsListener b) {
>>>                                              ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:679:
>>> warning: no @return
>>>        public static HierarchyListener add(HierarchyListener a,
>>> HierarchyListener b) {
>>>                                        ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:668:
>>> warning: no @return
>>>        public static InputMethodListener add(InputMethodListener a,
>>> InputMethodListener b) {
>>>                                          ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:645:
>>> warning: no @return
>>>       public static ItemListener add(ItemListener a, ItemListener b) {
>>>                                  ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:571:
>>> warning: no @return
>>>       public static KeyListener add(KeyListener a, KeyListener b) {
>>>                                 ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:581:
>>> warning: no @return
>>>       public static MouseListener add(MouseListener a, MouseListener b) {
>>>                                   ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:591:
>>> warning: no @return
>>>       public static MouseMotionListener add(MouseMotionListener a,
>>> MouseMotionListener b) {
>>>                                         ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:701:
>>> warning: no @return
>>>       public static MouseWheelListener add(MouseWheelListener a,
>>>                                        ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:624:
>>> warning: no @return
>>>       public static WindowFocusListener add(WindowFocusListener a,
>>>                                         ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:601:
>>> warning: no @return
>>>       public static WindowListener add(WindowListener a, WindowListener b) {
>>>                                    ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:612:
>>> warning: no @return
>>>       public static WindowStateListener add(WindowStateListener a,
>>>                                         ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:888:
>>> warning: no @return
>>>       protected static EventListener addInternal(EventListener a,
>>> EventListener b) {
>>>                                      ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:1022:
>>> warning: no @param for<T>
>>>           getListeners(EventListener l, Class<T>  listenerType)
>>>           ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:806:
>>> warning: no @return
>>>       public static ActionListener remove(ActionListener l,
>>> ActionListener oldl) {
>>>                                    ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:826:
>>> warning: no @return
>>>       public static AdjustmentListener remove(AdjustmentListener l,
>>> AdjustmentListener oldl) {
>>>                                        ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:712:
>>> warning: no @return
>>>       public static ComponentListener remove(ComponentListener l,
>>> ComponentListener oldl) {
>>>                                       ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:722:
>>> warning: no @return
>>>       public static ContainerListener remove(ContainerListener l,
>>> ContainerListener oldl) {
>>>                                       ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:136:
>>> error: tag not allowed here:<p>
>>>        *<p>
>>>          ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:732:
>>> warning: no @return
>>>       public static FocusListener remove(FocusListener l, FocusListener
>>> oldl) {
>>>                                   ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:862:
>>> warning: no @return
>>>       public static HierarchyBoundsListener
>>> remove(HierarchyBoundsListener l, HierarchyBoundsListener oldl) {
>>>                                             ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:850:
>>> warning: no @return
>>>       public static HierarchyListener remove(HierarchyListener l,
>>> HierarchyListener oldl) {
>>>                                       ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:839:
>>> warning: no @return
>>>       public static InputMethodListener remove(InputMethodListener l,
>>> InputMethodListener oldl) {
>>>                                         ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:816:
>>> warning: no @return
>>>       public static ItemListener remove(ItemListener l, ItemListener oldl) {
>>>                                  ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:742:
>>> warning: no @return
>>>       public static KeyListener remove(KeyListener l, KeyListener oldl) {
>>>                                 ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:752:
>>> warning: no @return
>>>       public static MouseListener remove(MouseListener l, MouseListener
>>> oldl) {
>>>                                   ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:762:
>>> warning: no @return
>>>       public static MouseMotionListener remove(MouseMotionListener l,
>>> MouseMotionListener oldl) {
>>>                                         ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:873:
>>> warning: no @return
>>>       public static MouseWheelListener remove(MouseWheelListener l,
>>>                                        ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:795:
>>> warning: no @return
>>>       public static WindowFocusListener remove(WindowFocusListener l,
>>>                                         ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:772:
>>> warning: no @return
>>>       public static WindowListener remove(WindowListener l,
>>> WindowListener oldl) {
>>>                                    ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:783:
>>> warning: no @return
>>>       public static WindowStateListener remove(WindowStateListener l,
>>>                                         ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTEventMulticaster.java:905:
>>> warning: no @return
>>>       protected static EventListener removeInternal(EventListener l,
>>> EventListener oldl) {
>>>                                      ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/TextListener.java:53:
>>> warning: no @param for e
>>>       public void textValueChanged(TextEvent e);
>>>                   ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/ComponentListener.java:58:
>>> warning: no @param for e
>>>       public void componentResized(ComponentEvent e);
>>>                   ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/ComponentListener.java:63:
>>> warning: no @param for e
>>>       public void componentMoved(ComponentEvent e);
>>>                   ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/ComponentListener.java:68:
>>> warning: no @param for e
>>>       public void componentShown(ComponentEvent e);
>>>                   ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/ComponentListener.java:73:
>>> warning: no @param for e
>>>       public void componentHidden(ComponentEvent e);
>>>                   ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/ContainerListener.java:59:
>>> warning: no @param for e
>>>       public void componentAdded(ContainerEvent e);
>>>                   ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/ContainerListener.java:64:
>>> warning: no @param for e
>>>       public void componentRemoved(ContainerEvent e);
>>>                   ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/FocusListener.java:55:
>>> warning: no @param for e
>>>       public void focusGained(FocusEvent e);
>>>                   ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/FocusListener.java:60:
>>> warning: no @param for e
>>>       public void focusLost(FocusEvent e);
>>>                   ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/KeyListener.java:58:
>>> warning: no @param for e
>>>       public void keyTyped(KeyEvent e);
>>>                   ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/KeyListener.java:65:
>>> warning: no @param for e
>>>       public void keyPressed(KeyEvent e);
>>>                   ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/KeyListener.java:72:
>>> warning: no @param for e
>>>       public void keyReleased(KeyEvent e);
>>>                   ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/MouseListener.java:63:
>>> warning: no @param for e
>>>       public void mouseClicked(MouseEvent e);
>>>                   ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/MouseListener.java:68:
>>> warning: no @param for e
>>>       public void mousePressed(MouseEvent e);
>>>                   ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/MouseListener.java:73:
>>> warning: no @param for e
>>>       public void mouseReleased(MouseEvent e);
>>>                   ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/MouseListener.java:78:
>>> warning: no @param for e
>>>       public void mouseEntered(MouseEvent e);
>>>                   ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/MouseListener.java:83:
>>> warning: no @param for e
>>>       public void mouseExited(MouseEvent e);
>>>                   ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/MouseMotionListener.java:63:
>>> error: semicolon missing
>>>        * Due to platform-dependent Drag&Drop implementations,
>>>                                        ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/MouseMotionListener.java:65:
>>> error: semicolon missing
>>>        * Drag&Drop operation.
>>>              ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/MouseMotionListener.java:67:
>>> warning: no @param for e
>>>       public void mouseDragged(MouseEvent e);
>>>                   ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/MouseMotionListener.java:73:
>>> warning: no @param for e
>>>       public void mouseMoved(MouseEvent e);
>>>                   ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/WindowListener.java:55:
>>> warning: no @param for e
>>>       public void windowOpened(WindowEvent e);
>>>                   ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/WindowListener.java:61:
>>> warning: no @param for e
>>>       public void windowClosing(WindowEvent e);
>>>                   ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/WindowListener.java:67:
>>> warning: no @param for e
>>>       public void windowClosed(WindowEvent e);
>>>                   ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/WindowListener.java:76:
>>> warning: no @param for e
>>>       public void windowIconified(WindowEvent e);
>>>                   ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/WindowListener.java:82:
>>> warning: no @param for e
>>>       public void windowDeiconified(WindowEvent e);
>>>                   ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/WindowListener.java:92:
>>> warning: no @param for e
>>>       public void windowActivated(WindowEvent e);
>>>                   ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/WindowListener.java:102:
>>> warning: no @param for e
>>>       public void windowDeactivated(WindowEvent e);
>>>                   ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/WindowStateListener.java:54:
>>> warning: no @param for e
>>>       public void windowStateChanged(WindowEvent e);
>>>                   ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/WindowFocusListener.java:61:
>>> warning: no @param for e
>>>       public void windowGainedFocus(WindowEvent e);
>>>                   ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/WindowFocusListener.java:68:
>>> warning: no @param for e
>>>       public void windowLostFocus(WindowEvent e);
>>>                   ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/ActionListener.java:50:
>>> warning: no @param for e
>>>       public void actionPerformed(ActionEvent e);
>>>                   ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/ItemListener.java:54:
>>> warning: no @param for e
>>>       void itemStateChanged(ItemEvent e);
>>>            ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/AdjustmentListener.java:41:
>>> warning: no @param for e
>>>       public void adjustmentValueChanged(AdjustmentEvent e);
>>>                   ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/InputMethodListener.java:49:
>>> warning: no @param for event
>>>       void inputMethodTextChanged(InputMethodEvent event);
>>>            ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/InputMethodListener.java:54:
>>> warning: no @param for event
>>>       void caretPositionChanged(InputMethodEvent event);
>>>            ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/HierarchyListener.java:56:
>>> warning: no @param for e
>>>       public void hierarchyChanged(HierarchyEvent e);
>>>                   ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/HierarchyBoundsListener.java:56:
>>> warning: no @param for e
>>>       public void ancestorMoved(HierarchyEvent e);
>>>                   ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/HierarchyBoundsListener.java:61:
>>> warning: no @param for e
>>>       public void ancestorResized(HierarchyEvent e);
>>>                   ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/event/MouseWheelListener.java:57:
>>> warning: no @param for e
>>>       public void mouseWheelMoved(MouseWheelEvent e);
>>>                   ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTKeyStroke.java:402:
>>> error: tag not allowed here:<ul>
>>>        * used to specify the key code. For example:<ul>
>>>                                                    ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTKeyStroke.java:407:
>>> error: tag not allowed here:<ul>
>>>        * The modifiers consist of any combination of:<ul>
>>>                                                      ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTKeyStroke.java:414:
>>> error: tag not allowed here:<ul>
>>>        * The old modifiers<ul>
>>>                            ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTKeyStroke.java:352:
>>> error: tag not allowed here:<ul>
>>>        * used to specify the key code. For example:<ul>
>>>                                                    ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTKeyStroke.java:360:
>>> error: tag not allowed here:<ul>
>>>        * The modifiers consist of any combination of:<ul>
>>>                                                      ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTKeyStroke.java:367:
>>> error: tag not allowed here:<ul>
>>>        * The old modifiers<ul>
>>>                            ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTKeyStroke.java:488:
>>> error: bad use of '>'
>>>        *     "INSERT" =>  getAWTKeyStroke(KeyEvent.VK_INSERT, 0);
>>>                        ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTKeyStroke.java:489:
>>> error: bad use of '>'
>>>        *     "control DELETE" =>  getAWTKeyStroke(KeyEvent.VK_DELETE,
>>> InputEvent.CTRL_MASK);
>>>                                ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTKeyStroke.java:490:
>>> error: bad use of '>'
>>>        *     "alt shift X" =>  getAWTKeyStroke(KeyEvent.VK_X,
>>> InputEvent.ALT_MASK | InputEvent.SHIFT_MASK);
>>>                             ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTKeyStroke.java:491:
>>> error: bad use of '>'
>>>        *     "alt shift released X" =>  getAWTKeyStroke(KeyEvent.VK_X,
>>> InputEvent.ALT_MASK | InputEvent.SHIFT_MASK, true);
>>>                                      ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTKeyStroke.java:492:
>>> error: bad use of '>'
>>>        *     "typed a" =>  getAWTKeyStroke('a');
>>>                         ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTKeyStroke.java:803:
>>> warning: no @throws for java.io.ObjectStreamException
>>>       protected Object readResolve() throws java.io.ObjectStreamException {
>>>                        ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTPermission.java:41:
>>> error: tag not allowed here:<P>
>>>    *<P>
>>>      ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTPermission.java:46:
>>> error: tag not allowed here:<P>
>>>    *<P>
>>>      ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/AWTPermission.java:48:
>>> error: tag not allowed here:<table>
>>>    *<table border=1 cellpadding=5 summary="AWTPermission target names,
>>> descriptions, and associated risks.">
>>>      ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/BasicStroke.java:42:
>>> warning: attribute obsolete, use CSS instead: compact
>>>    *<dl compact>
>>>          ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/BorderLayout.java:61:
>>> error: tag not allowed here:<p>
>>>    *<p>
>>>      ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/BorderLayout.java:70:
>>> error: tag not allowed here:<p>
>>>    *<p>
>>>      ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/BorderLayout.java:78:
>>> error: tag not allowed here:<p>
>>>    *<p>
>>>      ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/BorderLayout.java:83:
>>> error: tag not allowed here:<p>
>>>    *<p>
>>>      ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/BorderLayout.java:91:
>>> error: tag not allowed here:<p>
>>>    *<p>
>>>      ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/BorderLayout.java:94:
>>> error: tag not allowed here:<p>
>>>    *<p>
>>>      ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/BorderLayout.java:99:
>>> warning: attribute obsolete, use CSS instead: ALIGN
>>>    * ALIGN=center HSPACE=10 VSPACE=7>
>>>      ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/BorderLayout.java:99:
>>> warning: attribute obsolete, use CSS instead: HSPACE
>>>    * ALIGN=center HSPACE=10 VSPACE=7>
>>>                   ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/BorderLayout.java:99:
>>> warning: attribute obsolete, use CSS instead: VSPACE
>>>    * ALIGN=center HSPACE=10 VSPACE=7>
>>>                             ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/BorderLayout.java:100:
>>> error: tag not allowed here:<p>
>>>    *<p>
>>>      ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/BorderLayout.java:102:
>>> error: tag not allowed here:<p>
>>>    *<p>
>>>      ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/BorderLayout.java:103:
>>> error: tag not allowed here:<hr>
>>>    *<hr><blockquote><pre>
>>>      ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/BorderLayout.java:103:
>>> error: tag not allowed here:<blockquote>
>>>    *<hr><blockquote><pre>
>>>          ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/BorderLayout.java:117:
>>> error: tag not allowed here:<hr>
>>>    *</pre></blockquote><hr>
>>>                         ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/BorderLayout.java:118:
>>> error: tag not allowed here:<p>
>>>    *<p>
>>>      ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/BorderLayout.java:372:
>>> warning: no @return
>>>       public int getHgap() {
>>>                  ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/BorderLayout.java:389:
>>> warning: no @return
>>>       public int getVgap() {
>>>                  ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/BorderLayout.java:795:
>>> error: tag not allowed here:<p>
>>>        *<p>
>>>          ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/LayoutManager2.java:61:
>>> warning: no @param for target
>>>       public Dimension maximumLayoutSize(Container target);
>>>                        ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/LayoutManager2.java:61:
>>> warning: no @return
>>>       public Dimension maximumLayoutSize(Container target);
>>>                        ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/LayoutManager2.java:70:
>>> warning: no @param for target
>>>       public float getLayoutAlignmentX(Container target);
>>>                    ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/LayoutManager2.java:70:
>>> warning: no @return
>>>       public float getLayoutAlignmentX(Container target);
>>>                    ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/awt/LayoutManager2.java:79:
>>> warning: no @param for target
>>>       public float getLayoutAlignmentY(Container target);
>>>                    ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/lang/Object.java:174:
>>> error: tag not allowed here:<p>
>>>        *<p>
>>>          ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/lang/Object.java:185:
>>> error: tag not allowed here:<p>
>>>        *<p>
>>>          ^
>>> /export/users/dh198349/lambda/jdk/src/share/classes/java/lang/Object.java:198:
>>> error: tag not allowed here:<p>
>>>        *<p>
>>>          ^
>>> 100 errors
>>> 100 warnings
>>> make[1]: ***
>>> [/export/users/dh198349/lambda/builds/b00/se-linux-i586-ea/docs/api/index.html]
>>> Error 1
>>> make: *** [docs-only] Error 2
>>>
>>
>>
>
>

From maurizio.cimadamore at oracle.com  Wed Feb  6 05:56:38 2013
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Wed, 06 Feb 2013 13:56:38 +0000
Subject: hg: lambda/lambda/langtools: Enhancement: special case inference to
	infer RuntimeException when throws type-variable has no constraints
Message-ID: <20130206135644.06DE047885@hg.openjdk.java.net>

Changeset: a6b0a257f22a
Author:    mcimadamore
Date:      2013-02-06 13:56 +0000
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/a6b0a257f22a

Enhancement: special case inference to infer RuntimeException when throws type-variable has no constraints

! src/share/classes/com/sun/tools/javac/code/Flags.java
! src/share/classes/com/sun/tools/javac/comp/Infer.java
! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java
! test/tools/javac/generics/6723444/T6723444.java
- test/tools/javac/generics/6723444/T6723444.out
+ test/tools/javac/generics/6723444/T6723444_1.out
+ test/tools/javac/generics/6723444/T6723444_2.out
! test/tools/javac/generics/7015430/T7015430.java
- test/tools/javac/generics/7015430/T7015430.out
+ test/tools/javac/generics/7015430/T7015430_1.out
+ test/tools/javac/generics/7015430/T7015430_2.out
+ test/tools/javac/lambda/TargetType63.java
+ test/tools/javac/lambda/TargetType63.out


From maurizio.cimadamore at oracle.com  Wed Feb  6 05:58:40 2013
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Wed, 06 Feb 2013 13:58:40 +0000
Subject: Inferring Exception type of a lambda body
In-Reply-To: <51114F95.2020207@oracle.com>
References: <CACuKZqHsAonEoi3pPLp-FANC7wAHCJ0rTrPc-2cx7HeU-y_qjA@mail.gmail.com>
	<51114F95.2020207@oracle.com>
Message-ID: <51126190.8080400@oracle.com>

On 05/02/13 18:29, Maurizio Cimadamore wrote:
> On 05/02/13 18:16, Zhong Yu wrote:
>> My suggestion for the inference rule is, very simplistically,
>>
>> If E has not been inferred from previous steps, and E is in the throw
>> clause, and E has an upper constraint E<<X,
>>       if X:>RuntimeException, infer E=RuntimeException
>>       otherwise, infer E=X. (X is an Error or a checked exception)
> Stay tuned - we are evaluating something along these lines
>
> Maurizio
>
I've pushed experimental support for this - the implemented support can 
be used as a reference point for the EG discussion.

Maurizio

From erik.joelsson at oracle.com  Wed Feb  6 00:31:01 2013
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 06 Feb 2013 09:31:01 +0100
Subject: CFR - updated 8001667: Comparator combinators and extension
	methods
In-Reply-To: <5111D34A.4020309@oracle.com>
References: <5111D34A.4020309@oracle.com>
Message-ID: <511214C5.5040300@oracle.com>

The build change looks fine. The new build will not need any changes.

/Erik

On 2013-02-06 04:51, Henry Jen wrote:
> Hi,
>
> This is an update on previous reviewed version, there are two new method
> introduced for Comparators to convert a Comparator into a BinaryOperator
> and corresponding test cases.
>
> As there is one new class, java.util.Comparators for 8001667, so we need
> to have makefile change, thus involve build-infra.
>
> Comparators.java
>
> public static<T>  BinaryOperator<T>  lesserOf(Comparator<? super T>
> comparator);
> public static<T>  BinaryOperator<T>  greaterOf(Comparator<? super T>
> comparator);
>
>
> [1] http://cr.openjdk.java.net/~henryjen/ccc/8001667.3/webrev
>
> Cheers,
> Henry

From jonathan.gibbons at oracle.com  Wed Feb  6 07:50:37 2013
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Wed, 06 Feb 2013 07:50:37 -0800
Subject: Hundreds of errors generating javadoc ??
In-Reply-To: <51115362.1010303@oracle.com>
References: <mailman.8011.1360086344.853.lambda-dev@openjdk.java.net>
	<51115362.1010303@oracle.com>
Message-ID: <51127BCD.1070603@oracle.com>

Fixed in tl/langtools.

-- Jon

On 02/05/2013 10:45 AM, Roger Riggs wrote:
> Hi,
>
> Issue filed with example program:  JDK-8007566.
> (Or just check Applet.java).
>
> Thanks, Roger
>
>> On 02/05/2013 09:06 AM, Roger Riggs wrote:
>>>>   Hi,
>>>>
>>>>   What are the rules for valid tags? Which html schema is being enforced?
>>>>
>>>>   It looks like every<p>  tag must be closed with</p>.
>>>>
>>>>   Unclosed<p>  tags are very common to as paragraph breaks.
>>>>
>>>>   Thanks
>> Something between 3.2 and 4.01 Transitional.
>>
>> <p>  does not require</p>. If you see evidence to the contrary in
>> doclint messages, please let me know or file an issue. For now, we
>> are using tools/javadoc(tool) for doclint issues.
>>
>> -- Jon
>


From paul.sandoz at oracle.com  Wed Feb  6 08:43:41 2013
From: paul.sandoz at oracle.com (paul.sandoz at oracle.com)
Date: Wed, 06 Feb 2013 16:43:41 +0000
Subject: hg: lambda/lambda/jdk: Update to latest version spliterator that has
	characteristics.
Message-ID: <20130206164403.32AF84788E@hg.openjdk.java.net>

Changeset: 54630475f7bd
Author:    psandoz
Date:      2013-02-06 17:43 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/54630475f7bd

Update to latest version spliterator that has characteristics.
(TODO ensure BaseStream.splitertor() returns a spliterator
with characteristics of the pipeline.
Re-think BaseStream.getStreamFlags().)
Contributed-by: Doug Lea <dl at cs.oswego.edu>, Brian Goetz <brian.goetz at oracle.com>, Paul Sandoz <paul.sandoz at oracle.com>

! src/share/classes/java/io/BufferedReader.java
! src/share/classes/java/lang/CharSequence.java
! src/share/classes/java/util/ArrayDeque.java
! src/share/classes/java/util/ArrayList.java
! src/share/classes/java/util/Arrays.java
! src/share/classes/java/util/BitSet.java
! src/share/classes/java/util/Collection.java
! src/share/classes/java/util/HashMap.java
! src/share/classes/java/util/HashSet.java
! src/share/classes/java/util/IdentityHashMap.java
! src/share/classes/java/util/LinkedHashSet.java
! src/share/classes/java/util/List.java
! src/share/classes/java/util/PriorityQueue.java
! src/share/classes/java/util/Set.java
! src/share/classes/java/util/SortedSet.java
! src/share/classes/java/util/Spliterator.java
! src/share/classes/java/util/TreeMap.java
! src/share/classes/java/util/TreeSet.java
! src/share/classes/java/util/Vector.java
! src/share/classes/java/util/WeakHashMap.java
! src/share/classes/java/util/concurrent/ConcurrentHashMap.java
! src/share/classes/java/util/concurrent/ConcurrentSkipListMap.java
! src/share/classes/java/util/concurrent/ConcurrentSkipListSet.java
! src/share/classes/java/util/concurrent/CopyOnWriteArrayList.java
! src/share/classes/java/util/concurrent/CopyOnWriteArraySet.java
! src/share/classes/java/util/concurrent/PriorityBlockingQueue.java
! src/share/classes/java/util/stream/AbstractPipeline.java
! src/share/classes/java/util/stream/AbstractTask.java
! src/share/classes/java/util/stream/NodeUtils.java
! src/share/classes/java/util/stream/Nodes.java
! src/share/classes/java/util/stream/PipelineHelper.java
! src/share/classes/java/util/stream/SliceOp.java
! src/share/classes/java/util/stream/SpinedBuffer.java
! src/share/classes/java/util/stream/Spliterators.java
! src/share/classes/java/util/stream/StreamOpFlag.java
! src/share/classes/java/util/stream/Streams.java
! test-ng/bootlib/java/util/stream/DoubleStreamTestData.java
! test-ng/bootlib/java/util/stream/DoubleStreamTestDataProvider.java
! test-ng/bootlib/java/util/stream/DoubleStreamTestScenario.java
! test-ng/bootlib/java/util/stream/IntStreamTestData.java
! test-ng/bootlib/java/util/stream/IntStreamTestDataProvider.java
! test-ng/bootlib/java/util/stream/IntStreamTestScenario.java
! test-ng/bootlib/java/util/stream/LongStreamTestData.java
! test-ng/bootlib/java/util/stream/LongStreamTestDataProvider.java
! test-ng/bootlib/java/util/stream/LongStreamTestScenario.java
! test-ng/bootlib/java/util/stream/SpliteratorTestHelper.java
! test-ng/bootlib/java/util/stream/StreamTestData.java
! test-ng/bootlib/java/util/stream/StreamTestDataProvider.java
! test-ng/bootlib/java/util/stream/StreamTestScenario.java
! test-ng/boottests/java/util/stream/SpinedBufferTest.java
! test-ng/boottests/java/util/stream/StreamOpFlagsTest.java
! test-ng/tests/org/openjdk/tests/java/util/stream/SortedOpTest.java
! test-ng/tests/org/openjdk/tests/java/util/stream/StreamSpliteratorTest.java
! test/java/util/stream/Stream/IntStreamTest.java


From mike.duigou at oracle.com  Wed Feb  6 12:38:25 2013
From: mike.duigou at oracle.com (mike.duigou at oracle.com)
Date: Wed, 06 Feb 2013 20:38:25 +0000
Subject: hg: lambda/lambda/jdk: Fix import and add unit tests for two methods
	in Comparators.
Message-ID: <20130206203903.EBC1D4789C@hg.openjdk.java.net>

Changeset: 90d16fce304d
Author:    henryjen
Date:      2013-01-31 23:55 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/90d16fce304d

Fix import and add unit tests for two methods in Comparators.

! src/share/classes/java/util/Comparator.java
! src/share/classes/java/util/Comparators.java
! test/java/util/ComparatorsTest.java


From mike.duigou at oracle.com  Wed Feb  6 13:29:26 2013
From: mike.duigou at oracle.com (mike.duigou at oracle.com)
Date: Wed, 06 Feb 2013 21:29:26 +0000
Subject: hg: lambda/lambda/jdk: create a stream from a BitSet
Message-ID: <20130206212939.C6AF94789E@hg.openjdk.java.net>

Changeset: 367b49b72f37
Author:    mduigou
Date:      2013-02-06 13:28 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/367b49b72f37

create a stream from a BitSet
Contributed-by: akhil.arora at oracle.com

! src/share/classes/java/util/BitSet.java
+ test/java/util/BitSet/BitSetStreamTest.java


From scolebourne at joda.org  Wed Feb  6 16:52:02 2013
From: scolebourne at joda.org (Stephen Colebourne)
Date: Thu, 7 Feb 2013 00:52:02 +0000
Subject: Auto inferred static imports
Message-ID: <CACzrW9ABEWMAdHE99u-6NG=8L-STw5-byYxEp2J-VUdczjdzvQ@mail.gmail.com>

I know this is too late, and its probably already been considered, but
I haven't seen it mentioned anywhere. And it might trigger a
thought...

Project Lambda appears to be defining a lot of helper static methods
to go with the Stream API. Such as the Collectors class
http://download.java.net/lambda/b76/docs/api/java/util/stream/Collectors.html

I'm assuming that the plan is to remove the static utility class and
move the methods to the Collector interface (once the verifier is
fixed).

The use of code like this results in a need for lots of
interface-qualified prefixing, or static imports

 someStreamThing.collect( Collectors.groupingBy(...) )
 someStreamThing.collect( groupingBy(...) )   // using a static import

We also have a similar design pattern in JSR-310 on TemporalAdjuster
and TemporalQuery.

<maybe-nice-to-have-language-feature>
It seems that "it would be nice" if the language could do this for us.
Specifically, any static method on a functional interface (or maybe
only @FunctionalInterface) is available for use at any call site that
is target typed to that interface without any need for an explicit
static import.

 someStreamThing.collect( groupingBy(...) )   // no need for a static import

(no static import needed, because the method collect(Collector) takes
a Collector, and the static method is on Collector.

Of course an IDE can eliminate much of this pain anyway, so maybe its
no big deal and not worth a language chaneg. But it does seem like a
potentially useful extension to lambdas/Java. And perhaps it might
stimulate another related idea. Since its too late for JDK 1.8, the
only point I can suggest is a brief check to see if some other
decision has made this an impossible feature.
</maybe-nice-to-have-language-feature>

Stephen

From zhong.j.yu at gmail.com  Wed Feb  6 18:02:27 2013
From: zhong.j.yu at gmail.com (Zhong Yu)
Date: Wed, 6 Feb 2013 20:02:27 -0600
Subject: Auto inferred static imports
In-Reply-To: <CACzrW9ABEWMAdHE99u-6NG=8L-STw5-byYxEp2J-VUdczjdzvQ@mail.gmail.com>
References: <CACzrW9ABEWMAdHE99u-6NG=8L-STw5-byYxEp2J-VUdczjdzvQ@mail.gmail.com>
Message-ID: <CACuKZqFVVEhqSRxGU8D-1Av=KnSFGY9ZP5ak5Hys+B-0fucPcQ@mail.gmail.com>

On Wed, Feb 6, 2013 at 6:52 PM, Stephen Colebourne <scolebourne at joda.org> wrote:
> I know this is too late, and its probably already been considered, but
> I haven't seen it mentioned anywhere. And it might trigger a
> thought...
>
> Project Lambda appears to be defining a lot of helper static methods
> to go with the Stream API. Such as the Collectors class
> http://download.java.net/lambda/b76/docs/api/java/util/stream/Collectors.html
>
> I'm assuming that the plan is to remove the static utility class and
> move the methods to the Collector interface (once the verifier is
> fixed).
>
> The use of code like this results in a need for lots of
> interface-qualified prefixing, or static imports
>
>  someStreamThing.collect( Collectors.groupingBy(...) )
>  someStreamThing.collect( groupingBy(...) )   // using a static import
>

On IntelliJ, when the cursor is inside "()" of a method invocation,

   someStreamThing.collect(|)

press Ctrl-Space will popup public static methods that return the
desire type; in this case, methods of Collectors. So writing the code
isn't much of a problem. Reading is another story - the question of
whether the word `Collectors` is a noise or a signal.

Zhong Yu

> We also have a similar design pattern in JSR-310 on TemporalAdjuster
> and TemporalQuery.
>
> <maybe-nice-to-have-language-feature>
> It seems that "it would be nice" if the language could do this for us.
> Specifically, any static method on a functional interface (or maybe
> only @FunctionalInterface) is available for use at any call site that
> is target typed to that interface without any need for an explicit
> static import.
>
>  someStreamThing.collect( groupingBy(...) )   // no need for a static import
>
> (no static import needed, because the method collect(Collector) takes
> a Collector, and the static method is on Collector.
>
> Of course an IDE can eliminate much of this pain anyway, so maybe its
> no big deal and not worth a language chaneg. But it does seem like a
> potentially useful extension to lambdas/Java. And perhaps it might
> stimulate another related idea. Since its too late for JDK 1.8, the
> only point I can suggest is a brief check to see if some other
> decision has made this an impossible feature.
> </maybe-nice-to-have-language-feature>
>
> Stephen
>

From brian.goetz at oracle.com  Wed Feb  6 20:07:46 2013
From: brian.goetz at oracle.com (brian.goetz at oracle.com)
Date: Thu, 07 Feb 2013 04:07:46 +0000
Subject: hg: lambda/lambda/jdk: 2 new changesets
Message-ID: <20130207040820.EF387478B5@hg.openjdk.java.net>

Changeset: 8c87198684fa
Author:    briangoetz
Date:      2013-02-06 23:06 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/8c87198684fa

Misc cleanups in statistics gathering collectors

! src/share/classes/java/util/stream/Collectors.java
! src/share/classes/java/util/stream/IntStream.java
! src/share/classes/java/util/stream/Stream.java

Changeset: 12e4114be8d9
Author:    briangoetz
Date:      2013-02-06 23:07 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/12e4114be8d9

Garbage-collect dead code

! src/share/classes/java/util/stream/TerminalOp.java


From maurizio.cimadamore at oracle.com  Thu Feb  7 02:58:22 2013
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Thu, 07 Feb 2013 10:58:22 +0000
Subject: hg: lambda/lambda/langtools: Fix: inherited generic functional
	descriptors are merged incorrectly
Message-ID: <20130207105827.AE8D3478D1@hg.openjdk.java.net>

Changeset: 83f0baea37de
Author:    mcimadamore
Date:      2013-02-07 10:58 +0000
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/83f0baea37de

Fix: inherited generic functional descriptors are merged incorrectly

! src/share/classes/com/sun/tools/javac/code/Types.java
+ test/tools/javac/lambda/LambdaConv25.java
+ test/tools/javac/lambda/LambdaConv25.out


From maurizio.cimadamore at oracle.com  Thu Feb  7 04:54:01 2013
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Thu, 07 Feb 2013 12:54:01 +0000
Subject: hg: lambda/lambda/langtools: serialization metafactory protocol
	changes
Message-ID: <20130207125406.6FF79478D7@hg.openjdk.java.net>

Changeset: a159edad6ff3
Author:    mcimadamore
Date:      2013-02-07 12:53 +0000
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/a159edad6ff3

serialization metafactory protocol changes

! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java


From maurizio.cimadamore at oracle.com  Thu Feb  7 04:52:17 2013
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Thu, 07 Feb 2013 12:52:17 +0000
Subject: hg: lambda/lambda/jdk: serialization metafactory protocol changes
Message-ID: <20130207125305.55B65478D6@hg.openjdk.java.net>

Changeset: b8ce179b70fb
Author:    mcimadamore
Date:      2013-02-07 12:51 +0000
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/b8ce179b70fb

serialization metafactory protocol changes

! src/share/classes/java/lang/invoke/LambdaMetafactory.java


From brian.goetz at oracle.com  Thu Feb  7 06:37:14 2013
From: brian.goetz at oracle.com (brian.goetz at oracle.com)
Date: Thu, 07 Feb 2013 14:37:14 +0000
Subject: hg: lambda/lambda/jdk: Spec tweaks for alt metafactory
Message-ID: <20130207143735.29D2E478DD@hg.openjdk.java.net>

Changeset: 83d2ed4895b1
Author:    briangoetz
Date:      2013-02-07 09:36 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/83d2ed4895b1

Spec tweaks for alt metafactory

! src/share/classes/java/lang/invoke/LambdaMetafactory.java


From brian.goetz at oracle.com  Thu Feb  7 06:47:04 2013
From: brian.goetz at oracle.com (brian.goetz at oracle.com)
Date: Thu, 07 Feb 2013 14:47:04 +0000
Subject: hg: lambda/lambda/jdk: Add toString to SerializedLambda;
	add debugging logic for deserialization failures
Message-ID: <20130207144716.178EF478DE@hg.openjdk.java.net>

Changeset: 2628d8ec8d82
Author:    briangoetz
Date:      2013-02-07 09:46 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/2628d8ec8d82

Add toString to SerializedLambda; add debugging logic for deserialization failures

! src/share/classes/java/lang/invoke/MethodHandleInfo.java
! src/share/classes/java/lang/invoke/SerializedLambda.java


From maurizio.cimadamore at oracle.com  Thu Feb  7 07:18:35 2013
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Thu, 07 Feb 2013 15:18:35 +0000
Subject: hg: lambda/lambda/langtools: Remove redundant static int arg from
	alternate metafactory indy call
Message-ID: <20130207151840.1E401478E1@hg.openjdk.java.net>

Changeset: 67254f2726c7
Author:    mcimadamore
Date:      2013-02-07 15:18 +0000
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/67254f2726c7

Remove redundant static int arg from alternate metafactory indy call

! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java


From henry.jen at oracle.com  Thu Feb  7 10:13:57 2013
From: henry.jen at oracle.com (henry.jen at oracle.com)
Date: Thu, 07 Feb 2013 18:13:57 +0000
Subject: hg: lambda/lambda/jdk: 8006884: (fs) Add Files.list, lines and find
Message-ID: <20130207181430.50B1D478E5@hg.openjdk.java.net>

Changeset: 1432662bd29c
Author:    henryjen
Date:      2013-02-07 09:46 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/1432662bd29c

8006884: (fs) Add Files.list, lines and find

! src/share/classes/java/io/BufferedReader.java
! src/share/classes/java/io/UncheckedIOException.java
! src/share/classes/java/nio/file/DirectoryStream.java
+ src/share/classes/java/nio/file/FileTreeIterator.java
! src/share/classes/java/nio/file/Files.java
+ src/share/classes/java/util/stream/CloseableStream.java
+ src/share/classes/java/util/stream/DelegatingStream.java
+ test/java/nio/file/DirectoryStream/Entries.java
+ test/java/nio/file/Files/FaultyFileSystem.java
! test/java/nio/file/Files/PassThroughFileSystem.java
+ test/java/nio/file/Files/StreamTest.java


From maurizio.cimadamore at oracle.com  Thu Feb  7 11:30:41 2013
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Thu, 07 Feb 2013 19:30:41 +0000
Subject: hg: lambda/lambda/langtools: Enhancement: more stable serialized
	lambda names
Message-ID: <20130207193045.C0DCC478E7@hg.openjdk.java.net>

Changeset: 7bffb45844fb
Author:    mcimadamore
Date:      2013-02-07 19:30 +0000
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/7bffb45844fb

Enhancement: more stable serialized lambda names

Serializable lambdas are desugared to methods where name follows following pattern:

  lambda$mmm$kkkk$nnn

where mmm is the method name and kkk is the hashcode of the method signature, and nnn is a sequentially assigned number.  That way, dependencies on lambdas from other methods will be minimized.

! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java
! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java


From brian.goetz at oracle.com  Thu Feb  7 11:37:14 2013
From: brian.goetz at oracle.com (brian.goetz at oracle.com)
Date: Thu, 07 Feb 2013 19:37:14 +0000
Subject: hg: lambda/lambda/jdk: Replace explode() with two forms of flatMap:
	flatMap(T->Stream<U>), and flatMap(FlatMapper<T, U>)
Message-ID: <20130207193737.448A0478E8@hg.openjdk.java.net>

Changeset: 3aed6b4f4d42
Author:    briangoetz
Date:      2013-02-07 14:36 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/3aed6b4f4d42

Replace explode() with two forms of flatMap: flatMap(T->Stream<U>), and flatMap(FlatMapper<T,U>)

! src/share/classes/java/util/stream/DoublePipeline.java
! src/share/classes/java/util/stream/DoubleStream.java
+ src/share/classes/java/util/stream/FlatMapper.java
! src/share/classes/java/util/stream/IntPipeline.java
! src/share/classes/java/util/stream/IntStream.java
! src/share/classes/java/util/stream/LongPipeline.java
! src/share/classes/java/util/stream/LongStream.java
! src/share/classes/java/util/stream/ReferencePipeline.java
! src/share/classes/java/util/stream/Stream.java
! test-ng/bootlib/java/util/stream/LambdaTestHelpers.java
! test-ng/boottests/java/util/stream/SpinedBufferTest.java
! test-ng/tests/org/openjdk/tests/java/util/stream/ExplodeOpTest.java
! test-ng/tests/org/openjdk/tests/java/util/stream/ToArrayOpTest.java
! test/java/util/LambdaUtilities.java
! test/java/util/stream/Stream/EmployeeStreamTest.java
! test/java/util/stream/Stream/IntStreamTest.java
! test/java/util/stream/Stream/IntegerStreamTest.java
! test/java/util/stream/Stream/StringBuilderStreamTest.java
! test/java/util/stream/Streams/BasicTest.java


From pablogrisafi1975 at gmail.com  Thu Feb  7 11:46:20 2013
From: pablogrisafi1975 at gmail.com (Pablo Grisafi)
Date: Thu, 7 Feb 2013 16:46:20 -0300
Subject: Auto inferred static imports
Message-ID: <CAMyd0+yka=BOYEofwmW0UZ6VwV8TeRS6yoDgU9MLgVKE=aNA3w@mail.gmail.com>

I always thought about something like that for enums ...automatic
import for enums only in method calls.
if I have enum Color{ BLUE, RED}
and a method void paint(Color color) in any class
I think it would be nice to make calls
paint(BLUE) instead of paint(Color.BLUE)
compiler can infer the "Color." part, and user can read the code in a
more natural way...sometimes.
I like it because it does not pollute the namespace...but I don't
think we will see that anytime.

>
> ---------- Forwarded message ----------
> From: Stephen Colebourne <scolebourne at joda.org>
> To: lambda-dev <lambda-dev at openjdk.java.net>
> Cc:
> Date: Thu, 7 Feb 2013 00:52:02 +0000
> Subject: Auto inferred static imports
> I know this is too late, and its probably already been considered, but
> I haven't seen it mentioned anywhere. And it might trigger a
> thought...
>
> Project Lambda appears to be defining a lot of helper static methods
> to go with the Stream API. Such as the Collectors class
>
> http://download.java.net/lambda/b76/docs/api/java/util/stream/Collectors.html
>
> I'm assuming that the plan is to remove the static utility class and
> move the methods to the Collector interface (once the verifier is
> fixed).
>
> The use of code like this results in a need for lots of
> interface-qualified prefixing, or static imports
>
>  someStreamThing.collect( Collectors.groupingBy(...) )
>  someStreamThing.collect( groupingBy(...) )   // using a static import
>
> We also have a similar design pattern in JSR-310 on TemporalAdjuster
> and TemporalQuery.
>
> <maybe-nice-to-have-language-feature>
> It seems that "it would be nice" if the language could do this for us.
> Specifically, any static method on a functional interface (or maybe
> only @FunctionalInterface) is available for use at any call site that
> is target typed to that interface without any need for an explicit
> static import.
>
>  someStreamThing.collect( groupingBy(...) )   // no need for a static
> import
>
> (no static import needed, because the method collect(Collector) takes
> a Collector, and the static method is on Collector.
>
> Of course an IDE can eliminate much of this pain anyway, so maybe its
> no big deal and not worth a language chaneg. But it does seem like a
> potentially useful extension to lambdas/Java. And perhaps it might
> stimulate another related idea. Since its too late for JDK 1.8, the
> only point I can suggest is a brief check to see if some other
> decision has made this an impossible feature.
> </maybe-nice-to-have-language-feature>
>
> Stephen
>
>

From ricky.clarkson at gmail.com  Thu Feb  7 11:58:15 2013
From: ricky.clarkson at gmail.com (Ricky Clarkson)
Date: Thu, 7 Feb 2013 16:58:15 -0300
Subject: Auto inferred static imports
In-Reply-To: <CAMyd0+yka=BOYEofwmW0UZ6VwV8TeRS6yoDgU9MLgVKE=aNA3w@mail.gmail.com>
References: <CAMyd0+yka=BOYEofwmW0UZ6VwV8TeRS6yoDgU9MLgVKE=aNA3w@mail.gmail.com>
Message-ID: <CAOBi2H9qu2rAns1+C8dv1xcMV+UKLd+3==S7=DYLCT96Mm8xiQ@mail.gmail.com>

You can already get something very close to that with static imports.  It
would add a small amount of overhead to the compiler.  It would add the
following possible surprise:

Color BLUE = RED;
methodAcceptingColor(BLUE); will that be blue or red?  Either way you will
surprise some users sometimes.  Calling toString() within anonymous classes
is a similar example in current Java in terms of the surprise.

It also negatively affects being able to read code, as you'll have a 'naked
identifier', nothing in the file refers to it apart from your one call,
which increases the dependence on IDEs, makes it harder to read diffs with
or without an IDE, understand online code samples, etc.  Inheritance and *
imports are similar examples from current Java in terms of readability.


On Thu, Feb 7, 2013 at 4:46 PM, Pablo Grisafi <pablogrisafi1975 at gmail.com>wrote:

> I always thought about something like that for enums ...automatic
> import for enums only in method calls.
> if I have enum Color{ BLUE, RED}
> and a method void paint(Color color) in any class
> I think it would be nice to make calls
> paint(BLUE) instead of paint(Color.BLUE)
> compiler can infer the "Color." part, and user can read the code in a
> more natural way...sometimes.
> I like it because it does not pollute the namespace...but I don't
> think we will see that anytime.
>
> >
> > ---------- Forwarded message ----------
> > From: Stephen Colebourne <scolebourne at joda.org>
> > To: lambda-dev <lambda-dev at openjdk.java.net>
> > Cc:
> > Date: Thu, 7 Feb 2013 00:52:02 +0000
> > Subject: Auto inferred static imports
> > I know this is too late, and its probably already been considered, but
> > I haven't seen it mentioned anywhere. And it might trigger a
> > thought...
> >
> > Project Lambda appears to be defining a lot of helper static methods
> > to go with the Stream API. Such as the Collectors class
> >
> >
> http://download.java.net/lambda/b76/docs/api/java/util/stream/Collectors.html
> >
> > I'm assuming that the plan is to remove the static utility class and
> > move the methods to the Collector interface (once the verifier is
> > fixed).
> >
> > The use of code like this results in a need for lots of
> > interface-qualified prefixing, or static imports
> >
> >  someStreamThing.collect( Collectors.groupingBy(...) )
> >  someStreamThing.collect( groupingBy(...) )   // using a static import
> >
> > We also have a similar design pattern in JSR-310 on TemporalAdjuster
> > and TemporalQuery.
> >
> > <maybe-nice-to-have-language-feature>
> > It seems that "it would be nice" if the language could do this for us.
> > Specifically, any static method on a functional interface (or maybe
> > only @FunctionalInterface) is available for use at any call site that
> > is target typed to that interface without any need for an explicit
> > static import.
> >
> >  someStreamThing.collect( groupingBy(...) )   // no need for a static
> > import
> >
> > (no static import needed, because the method collect(Collector) takes
> > a Collector, and the static method is on Collector.
> >
> > Of course an IDE can eliminate much of this pain anyway, so maybe its
> > no big deal and not worth a language chaneg. But it does seem like a
> > potentially useful extension to lambdas/Java. And perhaps it might
> > stimulate another related idea. Since its too late for JDK 1.8, the
> > only point I can suggest is a brief check to see if some other
> > decision has made this an impossible feature.
> > </maybe-nice-to-have-language-feature>
> >
> > Stephen
> >
> >
>
>

From brian.goetz at oracle.com  Thu Feb  7 12:01:35 2013
From: brian.goetz at oracle.com (brian.goetz at oracle.com)
Date: Thu, 07 Feb 2013 20:01:35 +0000
Subject: hg: lambda/lambda/jdk: Fix up DelegatingStream after adding changing
	flatMap
Message-ID: <20130207200147.3D3CF478E9@hg.openjdk.java.net>

Changeset: f23aa7677c34
Author:    briangoetz
Date:      2013-02-07 15:01 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/f23aa7677c34

Fix up DelegatingStream after adding changing flatMap

! src/share/classes/java/util/stream/DelegatingStream.java


From brian.goetz at oracle.com  Thu Feb  7 12:03:19 2013
From: brian.goetz at oracle.com (brian.goetz at oracle.com)
Date: Thu, 07 Feb 2013 20:03:19 +0000
Subject: hg: lambda/lambda/jdk: Refactor Collector to be tuple-of-functions;
	add mapping() Collector combinators
Message-ID: <20130207200331.7A098478EA@hg.openjdk.java.net>

Changeset: 221c5b4f706c
Author:    briangoetz
Date:      2013-02-07 15:03 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/221c5b4f706c

Refactor Collector to be tuple-of-functions; add mapping() Collector combinators

! src/share/classes/java/util/stream/Collector.java
! src/share/classes/java/util/stream/Collectors.java
! src/share/classes/java/util/stream/ConcurrentCollectors.java
! src/share/classes/java/util/stream/DoublePipeline.java
! src/share/classes/java/util/stream/FoldOp.java
! src/share/classes/java/util/stream/IntPipeline.java
! src/share/classes/java/util/stream/LongPipeline.java
! src/share/classes/java/util/stream/ReferencePipeline.java
! test-ng/tests/org/openjdk/tests/java/util/stream/GroupByOpTest.java
! test-ng/tests/org/openjdk/tests/java/util/stream/TabulatorsTest.java


From pbenedict at apache.org  Thu Feb  7 12:28:12 2013
From: pbenedict at apache.org (Paul Benedict)
Date: Thu, 7 Feb 2013 14:28:12 -0600
Subject: Functional interfaces and deprecated methods
Message-ID: <CABLGb9waw6oA7NFsJ3pPQ06cGGgxU8iBKBqBaZcbiKqhhUmZNg@mail.gmail.com>

A @FunctionalInterface has one method. If that method needs replacing, is
it possible to @Deprecate the existing method and introduce a new one? I
know the spec doesn't allow it now. What are your opinions on whether this
should be allowed?

Paul

From brian.goetz at oracle.com  Thu Feb  7 12:26:22 2013
From: brian.goetz at oracle.com (brian.goetz at oracle.com)
Date: Thu, 07 Feb 2013 20:26:22 +0000
Subject: hg: lambda/lambda/jdk: Missing import
Message-ID: <20130207202634.2C0D0478EC@hg.openjdk.java.net>

Changeset: c478b7142b7e
Author:    briangoetz
Date:      2013-02-07 15:26 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/c478b7142b7e

Missing import

! src/share/classes/java/util/stream/IntPipeline.java


From henry.jen at oracle.com  Thu Feb  7 16:15:53 2013
From: henry.jen at oracle.com (Henry Jen)
Date: Thu, 07 Feb 2013 16:15:53 -0800
Subject: Early review on NIO Stream APIs
Message-ID: <511443B9.2060505@oracle.com>

Hi,

While lambda still finalizing the final API for Stream, there are a
couple of streamifaction APIs in nio area, which I would like to start
circling around to get early feedbacks.

Those APIs return a CloseableStream, other than that, there is not much
directly connection to Stream definition.

The specdiff and webrev is available at

http://cr.openjdk.java.net/~henryjen/ccc/8006884.0/

Please include me in the reply as I don't necessary receiving emails
from all aliases.

Cheers,
Henry

From jed at wesleysmith.io  Thu Feb  7 16:27:53 2013
From: jed at wesleysmith.io (Jed Wesley-Smith)
Date: Fri, 8 Feb 2013 11:27:53 +1100
Subject: Functional interfaces and deprecated methods
In-Reply-To: <CABLGb9waw6oA7NFsJ3pPQ06cGGgxU8iBKBqBaZcbiKqhhUmZNg@mail.gmail.com>
References: <CABLGb9waw6oA7NFsJ3pPQ06cGGgxU8iBKBqBaZcbiKqhhUmZNg@mail.gmail.com>
Message-ID: <CAN3nywBfNGq3+RzOU5FPY64LV0_mOi_NWe8TxbrLmGMtmMjK-w@mail.gmail.com>

Why would that be any better than deprecating the entire interface in
favour of a new one?

cheers,
jed

On 8 February 2013 07:28, Paul Benedict <pbenedict at apache.org> wrote:
> A @FunctionalInterface has one method. If that method needs replacing, is
> it possible to @Deprecate the existing method and introduce a new one? I
> know the spec doesn't allow it now. What are your opinions on whether this
> should be allowed?

From zhong.j.yu at gmail.com  Thu Feb  7 18:53:04 2013
From: zhong.j.yu at gmail.com (Zhong Yu)
Date: Thu, 7 Feb 2013 20:53:04 -0600
Subject: Early review on NIO Stream APIs
In-Reply-To: <511443B9.2060505@oracle.com>
References: <511443B9.2060505@oracle.com>
Message-ID: <CACuKZqFFHSwzTn1_h5--e-RSvd+OdE6xTGG0Sw-3a9Q+aXxQ4A@mail.gmail.com>

The find() method uses a

    BiPredicate<Path, BasicFileAttributes> matcher

what about using the existing java.nio.file.PathMatcher interface?
There are already some implementations of PathMatcher both in JDK and
in the wild.

PathMatcher doesn't accept the file attributes though, but that's a
problem for most  Path-based APIs - path alone often isn't enough and
app has to look up attributes in a separate step.

Zhong Yu

On Thu, Feb 7, 2013 at 6:15 PM, Henry Jen <henry.jen at oracle.com> wrote:
> Hi,
>
> While lambda still finalizing the final API for Stream, there are a
> couple of streamifaction APIs in nio area, which I would like to start
> circling around to get early feedbacks.
>
> Those APIs return a CloseableStream, other than that, there is not much
> directly connection to Stream definition.
>
> The specdiff and webrev is available at
>
> http://cr.openjdk.java.net/~henryjen/ccc/8006884.0/
>
> Please include me in the reply as I don't necessary receiving emails
> from all aliases.
>
> Cheers,
> Henry

From pbenedict at apache.org  Thu Feb  7 19:13:18 2013
From: pbenedict at apache.org (Paul Benedict)
Date: Thu, 7 Feb 2013 21:13:18 -0600
Subject: Functional interfaces and deprecated methods
In-Reply-To: <CAN3nywBfNGq3+RzOU5FPY64LV0_mOi_NWe8TxbrLmGMtmMjK-w@mail.gmail.com>
References: <CABLGb9waw6oA7NFsJ3pPQ06cGGgxU8iBKBqBaZcbiKqhhUmZNg@mail.gmail.com>
	<CAN3nywBfNGq3+RzOU5FPY64LV0_mOi_NWe8TxbrLmGMtmMjK-w@mail.gmail.com>
Message-ID: <CABLGb9yeO+24oaLmmPKm3khmj+_AmGaMbNXJ-tgOauS=qtvfKA@mail.gmail.com>

Versioned functional interfaces is an answer too. Swap out a SomethingFunc
for SomethingFunc2 works just as well. If that's the "better" answer,
that's the justification I am seeking.

Paul

On Thu, Feb 7, 2013 at 6:27 PM, Jed Wesley-Smith <jed at wesleysmith.io> wrote:

> Why would that be any better than deprecating the entire interface in
> favour of a new one?
>
> cheers,
> jed
>
> On 8 February 2013 07:28, Paul Benedict <pbenedict at apache.org> wrote:
> > A @FunctionalInterface has one method. If that method needs replacing, is
> > it possible to @Deprecate the existing method and introduce a new one? I
> > know the spec doesn't allow it now. What are your opinions on whether
> this
> > should be allowed?
>

From aruld at acm.org  Thu Feb  7 19:51:33 2013
From: aruld at acm.org (Arul Dhesiaseelan)
Date: Thu, 7 Feb 2013 17:51:33 -1000
Subject: hg: lambda/lambda/jdk: Replace explode() with two forms of
	flatMap: flatMap(T->Stream<U>), and flatMap(FlatMapper<T, U>)
In-Reply-To: <5114063A.3000203@oracle.com>
References: <20130207193737.448A0478E8@hg.openjdk.java.net>
	<5114063A.3000203@oracle.com>
Message-ID: <CAKEXrxkTcJhbOTYr+g8tyDxNXFf1oYngTE4PgapFZ+Y66L=PdA@mail.gmail.com>

FlatMapper turns out to be pretty slick!

List<Track> allTracks = albums.stream()
      .explode((Downstream<Track> downstream, Album element) ->
downstream.send(element.tracks))
      .collect(toList());

to

List<Track> allTracks = albums.stream()
      .flatMap((Album album) -> album.tracks.stream())
      .collect(toList());

This is awesome Brian.

On Thu, Feb 7, 2013 at 9:53 AM, Brian Goetz <brian.goetz at oracle.com> wrote:

> I pushed an update along the lines of what was discussed yesterday, so
> people can take a look.  Summary:
>
>  - Eliminated "Downstream" abstraction
>  - Added FlatMapper type (with nested specializations) in j.u.s.
>  - Added five forms of Stream.flatMap
>    flatMap(Function<T, Stream<U>)
>    flatMap(FlatMapper<T,U>)
>    flatMap(FlatMapper.To{Int,**Long,Double}<T>)
>  - Added one form of flatMap for each primitive stream:
>    {Int,Long,Double}Stream.**flatMap(FlatMapper.{ILD}To{**ILD})
>
> Check it out and see what you think.  Commit message attached.  I think
> this is an improvement.
>
> Bikeshedding on naming can continue :)
>
>
> -------- Original Message --------
> Subject: hg: lambda/lambda/jdk: Replace explode() with two forms of
> flatMap: flatMap(T->Stream<U>), and flatMap(FlatMapper<T, U>)
> Date: Thu, 07 Feb 2013 19:37:14 +0000
> From: brian.goetz at oracle.com
> To: lambda-dev at openjdk.java.net
>
> Changeset: 3aed6b4f4d42
> Author:    briangoetz
> Date:      2013-02-07 14:36 -0500
> URL:       http://hg.openjdk.java.net/**lambda/lambda/jdk/rev/**
> 3aed6b4f4d42<http://hg.openjdk.java.net/lambda/lambda/jdk/rev/3aed6b4f4d42>
>
> Replace explode() with two forms of flatMap: flatMap(T->Stream<U>), and
> flatMap(FlatMapper<T,U>)
>
> ! src/share/classes/java/util/**stream/DoublePipeline.java
> ! src/share/classes/java/util/**stream/DoubleStream.java
> + src/share/classes/java/util/**stream/FlatMapper.java
> ! src/share/classes/java/util/**stream/IntPipeline.java
> ! src/share/classes/java/util/**stream/IntStream.java
> ! src/share/classes/java/util/**stream/LongPipeline.java
> ! src/share/classes/java/util/**stream/LongStream.java
> ! src/share/classes/java/util/**stream/ReferencePipeline.java
> ! src/share/classes/java/util/**stream/Stream.java
> ! test-ng/bootlib/java/util/**stream/LambdaTestHelpers.java
> ! test-ng/boottests/java/util/**stream/SpinedBufferTest.java
> ! test-ng/tests/org/openjdk/**tests/java/util/stream/**ExplodeOpTest.java
> ! test-ng/tests/org/openjdk/**tests/java/util/stream/**ToArrayOpTest.java
> ! test/java/util/**LambdaUtilities.java
> ! test/java/util/stream/Stream/**EmployeeStreamTest.java
> ! test/java/util/stream/Stream/**IntStreamTest.java
> ! test/java/util/stream/Stream/**IntegerStreamTest.java
> ! test/java/util/stream/Stream/**StringBuilderStreamTest.java
> ! test/java/util/stream/Streams/**BasicTest.java
>
>
>
>
>

From brian.goetz at oracle.com  Thu Feb  7 20:06:05 2013
From: brian.goetz at oracle.com (Brian Goetz)
Date: Thu, 07 Feb 2013 23:06:05 -0500
Subject: hg: lambda/lambda/jdk: Replace explode() with two forms of
	flatMap: flatMap(T->Stream<U>), and flatMap(FlatMapper<T, U>)
In-Reply-To: <CAKEXrxkTcJhbOTYr+g8tyDxNXFf1oYngTE4PgapFZ+Y66L=PdA@mail.gmail.com>
References: <20130207193737.448A0478E8@hg.openjdk.java.net>
	<5114063A.3000203@oracle.com>
	<CAKEXrxkTcJhbOTYr+g8tyDxNXFf1oYngTE4PgapFZ+Y66L=PdA@mail.gmail.com>
Message-ID: <511479AD.8050802@oracle.com>

Thanks!  I think it was a good compromise.  But I'm not sure whether to 
be happy or apprehensive about your enthusiasm.  I think probably a 
little of both.  Here's why.

The FlatMapper form -- which is very much like the current form of 
explode that you were happy to get away from (and with good reason, its 
confusing) -- is efficient; there is very little constant overhead per 
input element processed.  If something maps to nothing, it does no work. 
  Otherwise, the elements are produced and fed directly into the 
downstream consumer -- very efficient.

The T -> Stream<U> form *looks* like "hey, that's what I want", because 
it makes the code pretty.  But the performance will range from 
marginally worse (when elements reliably map to largish collections that 
are already instantiated) to much worse.

In the worst case, where an element maps to nothing, you are creating an 
empty collection, wrapping it with a Stream, asking the Stream to 
forEach its elements, which in turn creates a Spliterator (like an 
iterator).  And each of these may have ancillary objects (e.g., an 
ArrayList has an array; a Stream has helper objects, etc.)  So that's an 
awful lot of activity to do what should be zero work for an element that 
maps to nothing.

So, if you care more about code clarity than performance (that's not a 
dig -- the vast majority of code meets this description, or at least 
should, and almost certainly lots more code than its authors think) then 
the new form will make you very happy.  The downside is that it is 
slower than it looks.  Which invariably will lead to "streams are slow" 
lore in a year or two :(


On 2/7/2013 10:51 PM, Arul Dhesiaseelan wrote:
> FlatMapper turns out to be pretty slick!
>
> List<Track> allTracks = albums.stream()
>        .explode((Downstream<Track> downstream, Album element) ->
> downstream.send(element.tracks))
>        .collect(toList());
>
> to
>
> List<Track> allTracks = albums.stream()
>        .flatMap((Album album) -> album.tracks.stream())
>        .collect(toList());
>
> This is awesome Brian.
>
> On Thu, Feb 7, 2013 at 9:53 AM, Brian Goetz <brian.goetz at oracle.com> wrote:
>
>> I pushed an update along the lines of what was discussed yesterday, so
>> people can take a look.  Summary:
>>
>>   - Eliminated "Downstream" abstraction
>>   - Added FlatMapper type (with nested specializations) in j.u.s.
>>   - Added five forms of Stream.flatMap
>>     flatMap(Function<T, Stream<U>)
>>     flatMap(FlatMapper<T,U>)
>>     flatMap(FlatMapper.To{Int,**Long,Double}<T>)
>>   - Added one form of flatMap for each primitive stream:
>>     {Int,Long,Double}Stream.**flatMap(FlatMapper.{ILD}To{**ILD})
>>
>> Check it out and see what you think.  Commit message attached.  I think
>> this is an improvement.
>>
>> Bikeshedding on naming can continue :)
>>
>>
>> -------- Original Message --------
>> Subject: hg: lambda/lambda/jdk: Replace explode() with two forms of
>> flatMap: flatMap(T->Stream<U>), and flatMap(FlatMapper<T, U>)
>> Date: Thu, 07 Feb 2013 19:37:14 +0000
>> From: brian.goetz at oracle.com
>> To: lambda-dev at openjdk.java.net
>>
>> Changeset: 3aed6b4f4d42
>> Author:    briangoetz
>> Date:      2013-02-07 14:36 -0500
>> URL:       http://hg.openjdk.java.net/**lambda/lambda/jdk/rev/**
>> 3aed6b4f4d42<http://hg.openjdk.java.net/lambda/lambda/jdk/rev/3aed6b4f4d42>
>>
>> Replace explode() with two forms of flatMap: flatMap(T->Stream<U>), and
>> flatMap(FlatMapper<T,U>)
>>
>> ! src/share/classes/java/util/**stream/DoublePipeline.java
>> ! src/share/classes/java/util/**stream/DoubleStream.java
>> + src/share/classes/java/util/**stream/FlatMapper.java
>> ! src/share/classes/java/util/**stream/IntPipeline.java
>> ! src/share/classes/java/util/**stream/IntStream.java
>> ! src/share/classes/java/util/**stream/LongPipeline.java
>> ! src/share/classes/java/util/**stream/LongStream.java
>> ! src/share/classes/java/util/**stream/ReferencePipeline.java
>> ! src/share/classes/java/util/**stream/Stream.java
>> ! test-ng/bootlib/java/util/**stream/LambdaTestHelpers.java
>> ! test-ng/boottests/java/util/**stream/SpinedBufferTest.java
>> ! test-ng/tests/org/openjdk/**tests/java/util/stream/**ExplodeOpTest.java
>> ! test-ng/tests/org/openjdk/**tests/java/util/stream/**ToArrayOpTest.java
>> ! test/java/util/**LambdaUtilities.java
>> ! test/java/util/stream/Stream/**EmployeeStreamTest.java
>> ! test/java/util/stream/Stream/**IntStreamTest.java
>> ! test/java/util/stream/Stream/**IntegerStreamTest.java
>> ! test/java/util/stream/Stream/**StringBuilderStreamTest.java
>> ! test/java/util/stream/Streams/**BasicTest.java
>>
>>
>>
>>
>>
>

From henry.jen at oracle.com  Thu Feb  7 20:45:52 2013
From: henry.jen at oracle.com (Henry Jen)
Date: Thu, 7 Feb 2013 20:45:52 -0800
Subject: Early review on NIO Stream APIs
In-Reply-To: <CACuKZqFFHSwzTn1_h5--e-RSvd+OdE6xTGG0Sw-3a9Q+aXxQ4A@mail.gmail.com>
References: <511443B9.2060505@oracle.com>
	<CACuKZqFFHSwzTn1_h5--e-RSvd+OdE6xTGG0Sw-3a9Q+aXxQ4A@mail.gmail.com>
Message-ID: <6BA0AD92-429C-4AC5-909D-57D53326ABA8@oracle.com>

BiPredicate is a intentional choice, as during the walk process, the attribute is read and many times, filtering is based on file attributes.

PathMatcher is basically a Predicate<Path>, developer can easily use that in a filter with walk, which return a Stream<Path>.

Hope that helps.

Cheers,
Henry

On Feb 7, 2013, at 6:53 PM, Zhong Yu <zhong.j.yu at gmail.com> wrote:

> The find() method uses a
> 
>    BiPredicate<Path, BasicFileAttributes> matcher
> 
> what about using the existing java.nio.file.PathMatcher interface?
> There are already some implementations of PathMatcher both in JDK and
> in the wild.
> 
> PathMatcher doesn't accept the file attributes though, but that's a
> problem for most  Path-based APIs - path alone often isn't enough and
> app has to look up attributes in a separate step.
> 
> Zhong Yu
> 
> On Thu, Feb 7, 2013 at 6:15 PM, Henry Jen <henry.jen at oracle.com> wrote:
>> Hi,
>> 
>> While lambda still finalizing the final API for Stream, there are a
>> couple of streamifaction APIs in nio area, which I would like to start
>> circling around to get early feedbacks.
>> 
>> Those APIs return a CloseableStream, other than that, there is not much
>> directly connection to Stream definition.
>> 
>> The specdiff and webrev is available at
>> 
>> http://cr.openjdk.java.net/~henryjen/ccc/8006884.0/
>> 
>> Please include me in the reply as I don't necessary receiving emails
>> from all aliases.
>> 
>> Cheers,
>> Henry


From zhong.j.yu at gmail.com  Thu Feb  7 21:10:30 2013
From: zhong.j.yu at gmail.com (Zhong Yu)
Date: Thu, 7 Feb 2013 23:10:30 -0600
Subject: Early review on NIO Stream APIs
In-Reply-To: <6BA0AD92-429C-4AC5-909D-57D53326ABA8@oracle.com>
References: <511443B9.2060505@oracle.com>
	<CACuKZqFFHSwzTn1_h5--e-RSvd+OdE6xTGG0Sw-3a9Q+aXxQ4A@mail.gmail.com>
	<6BA0AD92-429C-4AC5-909D-57D53326ABA8@oracle.com>
Message-ID: <CACuKZqEgABGD+0=iXAXKtpLHvN8Mq+ySgFEXyd3a1hprFpc2vw@mail.gmail.com>

On Thu, Feb 7, 2013 at 10:45 PM, Henry Jen <henry.jen at oracle.com> wrote:
> BiPredicate is a intentional choice, as during the walk process, the attribute is read and many times, filtering is based on file attributes.
>
> PathMatcher is basically a Predicate<Path>, developer can easily use that in a filter with walk, which return a Stream<Path>.

I see.

It's a pity that we don't have an abstraction for Path+Attributes,
since often applications need both.

> Hope that helps.
>
> Cheers,
> Henry
>
> On Feb 7, 2013, at 6:53 PM, Zhong Yu <zhong.j.yu at gmail.com> wrote:
>
>> The find() method uses a
>>
>>    BiPredicate<Path, BasicFileAttributes> matcher
>>
>> what about using the existing java.nio.file.PathMatcher interface?
>> There are already some implementations of PathMatcher both in JDK and
>> in the wild.
>>
>> PathMatcher doesn't accept the file attributes though, but that's a
>> problem for most  Path-based APIs - path alone often isn't enough and
>> app has to look up attributes in a separate step.
>>
>> Zhong Yu
>>
>> On Thu, Feb 7, 2013 at 6:15 PM, Henry Jen <henry.jen at oracle.com> wrote:
>>> Hi,
>>>
>>> While lambda still finalizing the final API for Stream, there are a
>>> couple of streamifaction APIs in nio area, which I would like to start
>>> circling around to get early feedbacks.
>>>
>>> Those APIs return a CloseableStream, other than that, there is not much
>>> directly connection to Stream definition.
>>>
>>> The specdiff and webrev is available at
>>>
>>> http://cr.openjdk.java.net/~henryjen/ccc/8006884.0/
>>>
>>> Please include me in the reply as I don't necessary receiving emails
>>> from all aliases.
>>>
>>> Cheers,
>>> Henry
>

From aruld at acm.org  Thu Feb  7 22:02:36 2013
From: aruld at acm.org (Arul Dhesiaseelan)
Date: Thu, 7 Feb 2013 20:02:36 -1000
Subject: hg: lambda/lambda/jdk: Replace explode() with two forms of
	flatMap: flatMap(T->Stream<U>), and flatMap(FlatMapper<T, U>)
In-Reply-To: <511479AD.8050802@oracle.com>
References: <20130207193737.448A0478E8@hg.openjdk.java.net>
	<5114063A.3000203@oracle.com>
	<CAKEXrxkTcJhbOTYr+g8tyDxNXFf1oYngTE4PgapFZ+Y66L=PdA@mail.gmail.com>
	<511479AD.8050802@oracle.com>
Message-ID: <CAKEXrxnNaJH4HSbejasBdXuMHMOftcTDyVb0a+FH_d0=h-T_iA@mail.gmail.com>

I am with code clarity when it comes to Collections API, which is more
likely to become popular with Java 8 Streams. We have seen different
versions and the latest attempt could  benefit many for good.

List<Track> allTracks1 = albums.stream()
  .mapMulti((Collector<Track> collector, Album element) ->
collector.yield(element.tracks))
  .into(new ArrayList<Track>());

List<Track> allTracks2 = albums.stream()
  .mapMulti((Downstream<Track> downstream, Album element) ->
downstream.yield(element.tracks))
  .collect(Collectors.<Track>toList());

List<Track> allTracks3 = albums.stream()
  .explode((Downstream<Track> downstream, Album element) ->
downstream.send(element.tracks))
  .collect(toList());

List<Track> allTracks4 = albums.stream()
  .flatMap((Album album) -> album.tracks.stream())
  .collect(toList());




On Thu, Feb 7, 2013 at 6:06 PM, Brian Goetz <brian.goetz at oracle.com> wrote:

> Thanks!  I think it was a good compromise.  But I'm not sure whether to be
> happy or apprehensive about your enthusiasm.  I think probably a little of
> both.  Here's why.
>
> The FlatMapper form -- which is very much like the current form of explode
> that you were happy to get away from (and with good reason, its confusing)
> -- is efficient; there is very little constant overhead per input element
> processed.  If something maps to nothing, it does no work.  Otherwise, the
> elements are produced and fed directly into the downstream consumer -- very
> efficient.
>
> The T -> Stream<U> form *looks* like "hey, that's what I want", because it
> makes the code pretty.  But the performance will range from marginally
> worse (when elements reliably map to largish collections that are already
> instantiated) to much worse.
>
> In the worst case, where an element maps to nothing, you are creating an
> empty collection, wrapping it with a Stream, asking the Stream to forEach
> its elements, which in turn creates a Spliterator (like an iterator).  And
> each of these may have ancillary objects (e.g., an ArrayList has an array;
> a Stream has helper objects, etc.)  So that's an awful lot of activity to
> do what should be zero work for an element that maps to nothing.
>
> So, if you care more about code clarity than performance (that's not a dig
> -- the vast majority of code meets this description, or at least should,
> and almost certainly lots more code than its authors think) then the new
> form will make you very happy.  The downside is that it is slower than it
> looks.  Which invariably will lead to "streams are slow" lore in a year or
> two :(
>
>
>
> On 2/7/2013 10:51 PM, Arul Dhesiaseelan wrote:
>
>> FlatMapper turns out to be pretty slick!
>>
>> List<Track> allTracks = albums.stream()
>>        .explode((Downstream<Track> downstream, Album element) ->
>> downstream.send(element.**tracks))
>>        .collect(toList());
>>
>> to
>>
>> List<Track> allTracks = albums.stream()
>>        .flatMap((Album album) -> album.tracks.stream())
>>        .collect(toList());
>>
>> This is awesome Brian.
>>
>> On Thu, Feb 7, 2013 at 9:53 AM, Brian Goetz <brian.goetz at oracle.com>
>> wrote:
>>
>>  I pushed an update along the lines of what was discussed yesterday, so
>>> people can take a look.  Summary:
>>>
>>>   - Eliminated "Downstream" abstraction
>>>   - Added FlatMapper type (with nested specializations) in j.u.s.
>>>   - Added five forms of Stream.flatMap
>>>     flatMap(Function<T, Stream<U>)
>>>     flatMap(FlatMapper<T,U>)
>>>     flatMap(FlatMapper.To{Int,****Long,Double}<T>)
>>>
>>>   - Added one form of flatMap for each primitive stream:
>>>     {Int,Long,Double}Stream.****flatMap(FlatMapper.{ILD}To{****ILD})
>>>
>>>
>>> Check it out and see what you think.  Commit message attached.  I think
>>> this is an improvement.
>>>
>>> Bikeshedding on naming can continue :)
>>>
>>>
>>> -------- Original Message --------
>>> Subject: hg: lambda/lambda/jdk: Replace explode() with two forms of
>>> flatMap: flatMap(T->Stream<U>), and flatMap(FlatMapper<T, U>)
>>> Date: Thu, 07 Feb 2013 19:37:14 +0000
>>> From: brian.goetz at oracle.com
>>> To: lambda-dev at openjdk.java.net
>>>
>>> Changeset: 3aed6b4f4d42
>>> Author:    briangoetz
>>> Date:      2013-02-07 14:36 -0500
>>> URL:       http://hg.openjdk.java.net/****lambda/lambda/jdk/rev/**<http://hg.openjdk.java.net/**lambda/lambda/jdk/rev/**>
>>> 3aed6b4f4d42<http://hg.**openjdk.java.net/lambda/**
>>> lambda/jdk/rev/3aed6b4f4d42<http://hg.openjdk.java.net/lambda/lambda/jdk/rev/3aed6b4f4d42>
>>> >
>>>
>>>
>>> Replace explode() with two forms of flatMap: flatMap(T->Stream<U>), and
>>> flatMap(FlatMapper<T,U>)
>>>
>>> ! src/share/classes/java/util/****stream/DoublePipeline.java
>>> ! src/share/classes/java/util/****stream/DoubleStream.java
>>> + src/share/classes/java/util/****stream/FlatMapper.java
>>> ! src/share/classes/java/util/****stream/IntPipeline.java
>>> ! src/share/classes/java/util/****stream/IntStream.java
>>> ! src/share/classes/java/util/****stream/LongPipeline.java
>>> ! src/share/classes/java/util/****stream/LongStream.java
>>> ! src/share/classes/java/util/****stream/ReferencePipeline.java
>>> ! src/share/classes/java/util/****stream/Stream.java
>>> ! test-ng/bootlib/java/util/****stream/LambdaTestHelpers.java
>>> ! test-ng/boottests/java/util/****stream/SpinedBufferTest.java
>>> ! test-ng/tests/org/openjdk/****tests/java/util/stream/****
>>> ExplodeOpTest.java
>>> ! test-ng/tests/org/openjdk/****tests/java/util/stream/****
>>> ToArrayOpTest.java
>>> ! test/java/util/****LambdaUtilities.java
>>> ! test/java/util/stream/Stream/****EmployeeStreamTest.java
>>> ! test/java/util/stream/Stream/****IntStreamTest.java
>>> ! test/java/util/stream/Stream/****IntegerStreamTest.java
>>> ! test/java/util/stream/Stream/****StringBuilderStreamTest.java
>>> ! test/java/util/stream/Streams/****BasicTest.java
>>>
>>>
>>>
>>>
>>>
>>>
>>

From robert.field at oracle.com  Thu Feb  7 22:43:31 2013
From: robert.field at oracle.com (robert.field at oracle.com)
Date: Fri, 08 Feb 2013 06:43:31 +0000
Subject: hg: lambda/lambda/langtools: Unify two distinct approaches to type
	signature generation for lambdas.
Message-ID: <20130208064336.131F147930@hg.openjdk.java.net>

Changeset: 36afed07100f
Author:    rfield
Date:      2013-02-07 22:43 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/36afed07100f

Unify two distinct approaches to type signature generation for lambdas.
Eliminate ClassWriter.assembleSig(Type type, ByteBuffer sigbuf) which had sigbug reference / mutual recursion problems.
Expose ClassWriter.typeSig(Type) and add .typeClassSig(Type).

! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java
! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java


From oleksander.demura at gmail.com  Thu Feb  7 23:22:43 2013
From: oleksander.demura at gmail.com (Olexandr Demura)
Date: Fri, 8 Feb 2013 09:22:43 +0200
Subject: Auto inferred static imports
In-Reply-To: <CAOBi2H9qu2rAns1+C8dv1xcMV+UKLd+3==S7=DYLCT96Mm8xiQ@mail.gmail.com>
References: <CAMyd0+yka=BOYEofwmW0UZ6VwV8TeRS6yoDgU9MLgVKE=aNA3w@mail.gmail.com>
	<CAOBi2H9qu2rAns1+C8dv1xcMV+UKLd+3==S7=DYLCT96Mm8xiQ@mail.gmail.com>
Message-ID: <CAJitDuzdkv3_oQPUZnZ3UjWwVkVd+gGnAmXMFfdC7aEWc3Fr0A@mail.gmail.com>

Having special marker, e.g. `@`, with meaning "inferred type of this place"
will not hurt the readability,
but improve it - `setColor(Color.BLUE)` have some semantical noise
comparing to `setColor(@.BLUE)`.
That could be a nice JEP; and have noting to do with lambdas.
That doesn't help in  Stephen Colebourne's original question with inferring
static helper methods either.
Unless helper methods are defined not is helper class but in target class
itself, causing clutter.

2013/2/7 Ricky Clarkson <ricky.clarkson at gmail.com>

> You can already get something very close to that with static imports.  It
> would add a small amount of overhead to the compiler.  It would add the
> following possible surprise:
>
> Color BLUE = RED;
> methodAcceptingColor(BLUE); will that be blue or red?  Either way you will
> surprise some users sometimes.  Calling toString() within anonymous classes
> is a similar example in current Java in terms of the surprise.
>
> It also negatively affects being able to read code, as you'll have a 'naked
> identifier', nothing in the file refers to it apart from your one call,
> which increases the dependence on IDEs, makes it harder to read diffs with
> or without an IDE, understand online code samples, etc.  Inheritance and *
> imports are similar examples from current Java in terms of readability.
>
>
> On Thu, Feb 7, 2013 at 4:46 PM, Pablo Grisafi <pablogrisafi1975 at gmail.com
> >wrote:
>
> > I always thought about something like that for enums ...automatic
> > import for enums only in method calls.
> > if I have enum Color{ BLUE, RED}
> > and a method void paint(Color color) in any class
> > I think it would be nice to make calls
> > paint(BLUE) instead of paint(Color.BLUE)
> > compiler can infer the "Color." part, and user can read the code in a
> > more natural way...sometimes.
> > I like it because it does not pollute the namespace...but I don't
> > think we will see that anytime.
> >
> > >
> > > ---------- Forwarded message ----------
> > > From: Stephen Colebourne <scolebourne at joda.org>
> > > To: lambda-dev <lambda-dev at openjdk.java.net>
> > > Cc:
> > > Date: Thu, 7 Feb 2013 00:52:02 +0000
> > > Subject: Auto inferred static imports
> > > I know this is too late, and its probably already been considered, but
> > > I haven't seen it mentioned anywhere. And it might trigger a
> > > thought...
> > > ...
> > > <maybe-nice-to-have-language-feature>
> > > It seems that "it would be nice" if the language could do this for us.
> > > Specifically, any static method on a functional interface (or maybe
> > > only @FunctionalInterface) is available for use at any call site that
> > > is target typed to that interface without any need for an explicit
> > > static import.
> > >
> > >  someStreamThing.collect( groupingBy(...) )   // no need for a static
> > > import
> > >
> > > (no static import needed, because the method collect(Collector) takes
> > > a Collector, and the static method is on Collector.
> > >
> > > Of course an IDE can eliminate much of this pain anyway, so maybe its
> > > no big deal and not worth a language chaneg. But it does seem like a
> > > potentially useful extension to lambdas/Java. And perhaps it might
> > > stimulate another related idea. Since its too late for JDK 1.8, the
> > > only point I can suggest is a brief check to see if some other
> > > decision has made this an impossible feature.
> > > </maybe-nice-to-have-language-feature>
> > >
> > > Stephen
>

From zhong.j.yu at gmail.com  Fri Feb  8 06:38:05 2013
From: zhong.j.yu at gmail.com (Zhong Yu)
Date: Fri, 8 Feb 2013 08:38:05 -0600
Subject: UncheckedIOException and suppressed exception
In-Reply-To: <5110D53B.9060502@gmail.com>
References: <CACuKZqHn-bSHz0Lc-S0mCC+Zi-8G=BVpnY0P5c_P-DO6_DcdVA@mail.gmail.com>
	<511066E7.1010506@oracle.com>
	<CACuKZqGCyfDWnxxZ45uDBGsBUAfVKn7KPWBNX5AXypMU3MPvYg@mail.gmail.com>
	<511080CD.2020409@oracle.com> <5110D53B.9060502@gmail.com>
Message-ID: <CACuKZqEXmq3Fvfm1Ot5fOfo=WMEyQ7cyVa6gZ=vxMMOaBoj_JQ@mail.gmail.com>

On Tue, Feb 5, 2013 at 3:47 AM, Peter Levart <peter.levart at gmail.com> wrote:

>         try (CloseableStream<Path> = ...) {
>             try {
>                 ... direct Path operations throwing IOException and/or
>                 ... Stream<Path> operations throwing UncheckedIOException
>             }
>             catch (UncheckedIOException uioe) { throw uioe.getCause(); }
>         }
>         catch (EOFException eofe) {
>             // ...
>         }
>         catch (ZipException ze) {
>             // ...
>         }
>         catch (IOException ioe) {
>             //...
>         }


There's a bug - the exception from CloseableStream escapes handling
and creeps away.

Since closing is hidden in a try-with-resource statement, people often
forget about it, therefore close() should throw the same type of
exception as opening. If CloseableStream.close() throws IOException,
the bug won't exist.

I'm still at the position that opening/closing the stream should throw
UncheckedIOException, so that the entire try-with-resource statement
throws a consistent exception type.

    try(stream = openStream())
        using stream
    catch(UncheckedIOException e)
        handle e

I'm not convinced that "using stream" could involve IOException; why
would one call Files.list() to get a Stream<Path>, then turn it into
Iterator<Path> to operate on files "in the open", why he could simply
use the good old Files.newDirectoryStream()?


Zhong Yu

From rliesenfeld at gmail.com  Fri Feb  8 06:42:42 2013
From: rliesenfeld at gmail.com (Rogerio Liesenfeld)
Date: Fri, 8 Feb 2013 12:42:42 -0200
Subject: "default" keyword inconsistency: *before* default methods in
	interfaces, *after* default attributes in annotations
Message-ID: <CAJ=-fx=B+2oeJm79wd1UcScMrVzuGU8HtGO53zUkx=aYUyLWvA@mail.gmail.com>

Hello,

In lambda_b75, I noticed that the ?default? keyword is being used
*before* the method name in default method declarations inside
interfaces.
This contradicts current usage of the same keyword in annotation
types, where it must appear *after* the method name. This is since
Java 5.

For example, consider the following annotation type declaration:

public @interface RequestForEnhancement {
    int    id();
    String engineer() default "[unassigned]";
}

Attributes like ?engineer? above are similar to default methods such as:

public interface RequestForEnhancement {
    int    id();
    default String engineer(){ return "[unassigned]"; }
}

It would be more consistent with ?default? after the method.

From forax at univ-mlv.fr  Fri Feb  8 06:54:20 2013
From: forax at univ-mlv.fr (Remi Forax)
Date: Fri, 08 Feb 2013 15:54:20 +0100
Subject: "default" keyword inconsistency: *before* default methods in
	interfaces, *after* default attributes in annotations
In-Reply-To: <CAJ=-fx=B+2oeJm79wd1UcScMrVzuGU8HtGO53zUkx=aYUyLWvA@mail.gmail.com>
References: <CAJ=-fx=B+2oeJm79wd1UcScMrVzuGU8HtGO53zUkx=aYUyLWvA@mail.gmail.com>
Message-ID: <5115119C.7030801@univ-mlv.fr>

On 02/08/2013 03:42 PM, Rogerio Liesenfeld wrote:
> Hello,
>
> In lambda_b75, I noticed that the ?default? keyword is being used
> *before* the method name in default method declarations inside
> interfaces.
> This contradicts current usage of the same keyword in annotation
> types, where it must appear *after* the method name. This is since
> Java 5.
>
> For example, consider the following annotation type declaration:
>
> public @interface RequestForEnhancement {
>      int    id();
>      String engineer() default "[unassigned]";
> }
>
> Attributes like ?engineer? above are similar to default methods such as:
>
> public interface RequestForEnhancement {
>      int    id();
>      default String engineer(){ return "[unassigned]"; }
> }
>
> It would be more consistent with ?default? after the method.
>

We are well aware of that :)
default after a method in an annotation is for specifying a default 
value and default before is for saying that the method will be used if 
the class doesn't provide one.

So it's not the same semantics, so it should not be 'consistent'.

Now, re-using the same keyword for 2 different concepts is troublesome 
for rookies,
Java has a long tradition of doing that, e.g. final on class and final 
on field,
and it seems we are not able to get that.

R?mi


From ricky.clarkson at gmail.com  Fri Feb  8 07:04:17 2013
From: ricky.clarkson at gmail.com (Ricky Clarkson)
Date: Fri, 8 Feb 2013 12:04:17 -0300
Subject: "default" keyword inconsistency: *before* default methods in
	interfaces, *after* default attributes in annotations
In-Reply-To: <CAJ=-fx=B+2oeJm79wd1UcScMrVzuGU8HtGO53zUkx=aYUyLWvA@mail.gmail.com>
References: <CAJ=-fx=B+2oeJm79wd1UcScMrVzuGU8HtGO53zUkx=aYUyLWvA@mail.gmail.com>
Message-ID: <CAOBi2H_sKR-3Uy9emHwhVwu8edBNDBTycYYogUkaUuJwxCpgyg@mail.gmail.com>

It was as you suggest some months back.  The change was intended to make it
a modifier (like abstract, static, private etc.) and be in the same
position as the other modifiers.


On Fri, Feb 8, 2013 at 11:42 AM, Rogerio Liesenfeld
<rliesenfeld at gmail.com>wrote:

> Hello,
>
> In lambda_b75, I noticed that the ?default? keyword is being used
> *before* the method name in default method declarations inside
> interfaces.
> This contradicts current usage of the same keyword in annotation
> types, where it must appear *after* the method name. This is since
> Java 5.
>
> For example, consider the following annotation type declaration:
>
> public @interface RequestForEnhancement {
>     int    id();
>     String engineer() default "[unassigned]";
> }
>
> Attributes like ?engineer? above are similar to default methods such as:
>
> public interface RequestForEnhancement {
>     int    id();
>     default String engineer(){ return "[unassigned]"; }
> }
>
> It would be more consistent with ?default? after the method.
>
>

From maurizio.cimadamore at oracle.com  Fri Feb  8 07:47:18 2013
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Fri, 08 Feb 2013 15:47:18 +0000
Subject: hg: lambda/lambda/langtools: Fix: Fix case of clash in serialized
	names when method name and signature hashes are identical.
Message-ID: <20130208154723.6DE8E4793F@hg.openjdk.java.net>

Changeset: 406e3b289068
Author:    mcimadamore
Date:      2013-02-08 15:46 +0000
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/406e3b289068

Fix: Fix case of clash in serialized names when method name and signature hashes are identical.

! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java


From brian.goetz at oracle.com  Fri Feb  8 07:53:15 2013
From: brian.goetz at oracle.com (brian.goetz at oracle.com)
Date: Fri, 08 Feb 2013 15:53:15 +0000
Subject: hg: lambda/lambda/jdk: Undo more lambda workarounds after compiler
	bugfixes
Message-ID: <20130208155342.1951F47941@hg.openjdk.java.net>

Changeset: 9bfdceb12adc
Author:    briangoetz
Date:      2013-02-08 10:52 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/9bfdceb12adc

Undo more lambda workarounds after compiler bugfixes

! src/share/classes/java/util/stream/ForEachOp.java


From misterm at gmail.com  Fri Feb  8 08:42:44 2013
From: misterm at gmail.com (Michael Nascimento)
Date: Fri, 8 Feb 2013 14:42:44 -0200
Subject: SortedMap.transformValues?
In-Reply-To: <CAAWA2oVj1QdsBfME7zGS7y=ghCM15MggH9Kr7ATPWTw+2+-PTQ@mail.gmail.com>
References: <CAAWA2oVj1QdsBfME7zGS7y=ghCM15MggH9Kr7ATPWTw+2+-PTQ@mail.gmail.com>
Message-ID: <CAAWA2oWabw=TYtK0sDNf1CGEPWvgUTCR+e0+krMbuBK8kXe_0g@mail.gmail.com>

Any chance of getting an updated version for b76?

On Wed, Jan 16, 2013 at 3:57 PM, Michael Nascimento <misterm at gmail.com> wrote:
> Hi guys,
>
> What is the lambda way of achieving:
>
> http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/collect/Maps.html#transformValues(java.util.SortedMap,
> com.google.common.base.Function)
>
> ?
>
> Regards,
> Michael

From brian.goetz at oracle.com  Fri Feb  8 08:58:49 2013
From: brian.goetz at oracle.com (Brian Goetz)
Date: Fri, 08 Feb 2013 11:58:49 -0500
Subject: SortedMap.transformValues?
In-Reply-To: <CAAWA2oWabw=TYtK0sDNf1CGEPWvgUTCR+e0+krMbuBK8kXe_0g@mail.gmail.com>
References: <CAAWA2oVj1QdsBfME7zGS7y=ghCM15MggH9Kr7ATPWTw+2+-PTQ@mail.gmail.com>
	<CAAWA2oWabw=TYtK0sDNf1CGEPWvgUTCR+e0+krMbuBK8kXe_0g@mail.gmail.com>
Message-ID: <51152EC9.8040801@oracle.com>

// Imperative way:
Map<K,V1> oldMap = ...
Map<K,V2> newMap
   = oldMap.entrySet().stream()
           .forEach(e -> newMap.put(e.getKey(), f.apply(e.getvalue()));

// Collector way (works in parallel!)
Map<K,V2> newMap
   = oldMap.entrySet().stream()
           .collect(joiningWith(k -> f.apply(oldMap.get(k)));


On 2/8/2013 11:42 AM, Michael Nascimento wrote:
> Any chance of getting an updated version for b76?
>
> On Wed, Jan 16, 2013 at 3:57 PM, Michael Nascimento <misterm at gmail.com> wrote:
>> Hi guys,
>>
>> What is the lambda way of achieving:
>>
>> http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/collect/Maps.html#transformValues(java.util.SortedMap,
>> com.google.common.base.Function)
>>
>> ?
>>
>> Regards,
>> Michael
>

From henry.jen at oracle.com  Fri Feb  8 09:25:32 2013
From: henry.jen at oracle.com (Henry Jen)
Date: Fri, 08 Feb 2013 09:25:32 -0800
Subject: Early review on NIO Stream APIs
In-Reply-To: <5114EAF4.8090308@CoSoCo.de>
References: <511443B9.2060505@oracle.com> <5114EAF4.8090308@CoSoCo.de>
Message-ID: <5115350C.4050004@oracle.com>

On 02/08/2013 04:09 AM, Ulf Zibis wrote:
> Am 08.02.2013 01:15, schrieb Henry Jen:

> In Files.lines(...):
> After returned from this method, if an I/O error occurs reading ...
> should be:
> After returned from this method, if an I/O error occurs while reading ...
> 
> In Files.walk(...):
> ... a given staring file...
> should be:
> ... a given starting file...
>

Fixed, thanks.

> Do those streams close automatically from finalize() method, if released
> to GC, e.g. by nulling the referencing variable? ...and if not, why?
> 

The stream doesn't do that, it's transparent to whatever the underlying
Closeable resource's behavior.

Cheers,
Henry


From brian.goetz at oracle.com  Fri Feb  8 09:27:10 2013
From: brian.goetz at oracle.com (Brian Goetz)
Date: Fri, 08 Feb 2013 12:27:10 -0500
Subject: SortedMap.transformValues?
In-Reply-To: <51152EC9.8040801@oracle.com>
References: <CAAWA2oVj1QdsBfME7zGS7y=ghCM15MggH9Kr7ATPWTw+2+-PTQ@mail.gmail.com>
	<CAAWA2oWabw=TYtK0sDNf1CGEPWvgUTCR+e0+krMbuBK8kXe_0g@mail.gmail.com>
	<51152EC9.8040801@oracle.com>
Message-ID: <5115356E.9030800@oracle.com>

Er, the second example should be "keys()" not "entrySet()".  Sorry.

On 2/8/2013 11:58 AM, Brian Goetz wrote:
> // Imperative way:
> Map<K,V1> oldMap = ...
> Map<K,V2> newMap
>     = oldMap.entrySet().stream()
>             .forEach(e -> newMap.put(e.getKey(), f.apply(e.getvalue()));
>
> // Collector way (works in parallel!)
> Map<K,V2> newMap
>     = oldMap.entrySet().stream()
>             .collect(joiningWith(k -> f.apply(oldMap.get(k)));
>
>
> On 2/8/2013 11:42 AM, Michael Nascimento wrote:
>> Any chance of getting an updated version for b76?
>>
>> On Wed, Jan 16, 2013 at 3:57 PM, Michael Nascimento <misterm at gmail.com> wrote:
>>> Hi guys,
>>>
>>> What is the lambda way of achieving:
>>>
>>> http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/collect/Maps.html#transformValues(java.util.SortedMap,
>>> com.google.common.base.Function)
>>>
>>> ?
>>>
>>> Regards,
>>> Michael
>>
>

From misterm at gmail.com  Fri Feb  8 09:59:27 2013
From: misterm at gmail.com (Michael Nascimento)
Date: Fri, 8 Feb 2013 15:59:27 -0200
Subject: SortedMap.transformValues?
In-Reply-To: <5115356E.9030800@oracle.com>
References: <CAAWA2oVj1QdsBfME7zGS7y=ghCM15MggH9Kr7ATPWTw+2+-PTQ@mail.gmail.com>
	<CAAWA2oWabw=TYtK0sDNf1CGEPWvgUTCR+e0+krMbuBK8kXe_0g@mail.gmail.com>
	<51152EC9.8040801@oracle.com> <5115356E.9030800@oracle.com>
Message-ID: <CAAWA2oW03Djew+H1=ej6oRzexsWS-kjg14QPpfp=_L3WJ0jEgg@mail.gmail.com>

Thank you Brian, but this does not return a SortedMap. I can always
construct a new one with the result, but I wonder if that is the best
approach.

Regards,
Michael

On Fri, Feb 8, 2013 at 3:27 PM, Brian Goetz <brian.goetz at oracle.com> wrote:
> Er, the second example should be "keys()" not "entrySet()".  Sorry.
>
>
> On 2/8/2013 11:58 AM, Brian Goetz wrote:
>>
>> // Imperative way:
>> Map<K,V1> oldMap = ...
>> Map<K,V2> newMap
>>     = oldMap.entrySet().stream()
>>             .forEach(e -> newMap.put(e.getKey(), f.apply(e.getvalue()));
>>
>> // Collector way (works in parallel!)
>> Map<K,V2> newMap
>>     = oldMap.entrySet().stream()
>>             .collect(joiningWith(k -> f.apply(oldMap.get(k)));
>>
>>
>> On 2/8/2013 11:42 AM, Michael Nascimento wrote:
>>>
>>> Any chance of getting an updated version for b76?
>>>
>>> On Wed, Jan 16, 2013 at 3:57 PM, Michael Nascimento <misterm at gmail.com>
>>> wrote:
>>>>
>>>> Hi guys,
>>>>
>>>> What is the lambda way of achieving:
>>>>
>>>>
>>>> http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/collect/Maps.html#transformValues(java.util.SortedMap,
>>>> com.google.common.base.Function)
>>>>
>>>> ?
>>>>
>>>> Regards,
>>>> Michael
>>>
>>>
>>
>

From brian.goetz at oracle.com  Fri Feb  8 10:10:49 2013
From: brian.goetz at oracle.com (Brian Goetz)
Date: Fri, 08 Feb 2013 13:10:49 -0500
Subject: SortedMap.transformValues?
In-Reply-To: <CAAWA2oW03Djew+H1=ej6oRzexsWS-kjg14QPpfp=_L3WJ0jEgg@mail.gmail.com>
References: <CAAWA2oVj1QdsBfME7zGS7y=ghCM15MggH9Kr7ATPWTw+2+-PTQ@mail.gmail.com>
	<CAAWA2oWabw=TYtK0sDNf1CGEPWvgUTCR+e0+krMbuBK8kXe_0g@mail.gmail.com>
	<51152EC9.8040801@oracle.com> <5115356E.9030800@oracle.com>
	<CAAWA2oW03Djew+H1=ej6oRzexsWS-kjg14QPpfp=_L3WJ0jEgg@mail.gmail.com>
Message-ID: <51153FA9.7090600@oracle.com>

Well, it would if I wrote it right.  Let's try this again.

  // Imperative way:
  Map<K,V1> oldMap = ...
  Map<K,V2> newMap = new TreeMap<K,V1>();
  oldMap.entrySet().stream()
        .forEach(e -> newMap.put(e.getKey(), f.apply(e.getvalue()));

  // Collect way:
  Map<K,V2> newMap
       = oldMap.entrySet().stream()
               .collect(joiningWith(k -> f.apply(oldMap.get(k)),
                        TreeMap::new);

To which I'll add:
  // Concurrent way:
  Map<K,V1> oldMap = ...
  Map<K,V2> newMap = new ConcurrentSkipListMap<K,V1>();
  oldMap.entrySet().parallelStream()
        .forEach(e -> newMap.put(e.getKey(), f.apply(e.getvalue()));

  // Parallel functional way with map merging:
  Map<K,V2> newMap
       = oldMap.entrySet().parallelStream()
               .collect(joiningWith(k -> f.apply(oldMap.get(k)),
                        TreeMap::new)));


Is that enough choices?  :)

On 2/8/2013 12:59 PM, Michael Nascimento wrote:
> Thank you Brian, but this does not return a SortedMap. I can always
> construct a new one with the result, but I wonder if that is the best
> approach.
>
> Regards,
> Michael
>
> On Fri, Feb 8, 2013 at 3:27 PM, Brian Goetz <brian.goetz at oracle.com> wrote:
>> Er, the second example should be "keys()" not "entrySet()".  Sorry.
>>
>>
>> On 2/8/2013 11:58 AM, Brian Goetz wrote:
>>>
>>> // Imperative way:
>>> Map<K,V1> oldMap = ...
>>> Map<K,V2> newMap
>>>      = oldMap.entrySet().stream()
>>>              .forEach(e -> newMap.put(e.getKey(), f.apply(e.getvalue()));
>>>
>>> // Collector way (works in parallel!)
>>> Map<K,V2> newMap
>>>      = oldMap.entrySet().stream()
>>>              .collect(joiningWith(k -> f.apply(oldMap.get(k)));
>>>
>>>
>>> On 2/8/2013 11:42 AM, Michael Nascimento wrote:
>>>>
>>>> Any chance of getting an updated version for b76?
>>>>
>>>> On Wed, Jan 16, 2013 at 3:57 PM, Michael Nascimento <misterm at gmail.com>
>>>> wrote:
>>>>>
>>>>> Hi guys,
>>>>>
>>>>> What is the lambda way of achieving:
>>>>>
>>>>>
>>>>> http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/collect/Maps.html#transformValues(java.util.SortedMap,
>>>>> com.google.common.base.Function)
>>>>>
>>>>> ?
>>>>>
>>>>> Regards,
>>>>> Michael
>>>>
>>>>
>>>
>>

From henry.jen at oracle.com  Fri Feb  8 10:59:43 2013
From: henry.jen at oracle.com (henry.jen at oracle.com)
Date: Fri, 08 Feb 2013 18:59:43 +0000
Subject: hg: lambda/lambda/jdk: Minor fix for javadoc
Message-ID: <20130208190003.F074947953@hg.openjdk.java.net>

Changeset: 5974b2e7c7f7
Author:    henryjen
Date:      2013-02-08 10:59 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/5974b2e7c7f7

Minor fix for javadoc

! src/share/classes/java/nio/file/Files.java


From Alan.Bateman at oracle.com  Fri Feb  8 11:40:23 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 08 Feb 2013 19:40:23 +0000
Subject: Early review on NIO Stream APIs
In-Reply-To: <5114EAF4.8090308@CoSoCo.de>
References: <511443B9.2060505@oracle.com> <5114EAF4.8090308@CoSoCo.de>
Message-ID: <511554A7.901@oracle.com>

On 08/02/2013 12:09, Ulf Zibis wrote:
> :
>
> Do those streams close automatically from finalize() method, if 
> released to GC, e.g. by nulling the referencing variable? ...and if 
> not, why?
>
> -Ulf
>
We don't use finalizers in this area. Aside from the overhead, the other 
issue here is that file descriptors are a relatively scarce resource so 
if the application is not closing files or channels then you'll often 
run out of file descriptors long before you run out of memory.

In any case, I think try-with-resources should be very useful here.

-Alan.

From brian.goetz at oracle.com  Fri Feb  8 14:33:49 2013
From: brian.goetz at oracle.com (brian.goetz at oracle.com)
Date: Fri, 08 Feb 2013 22:33:49 +0000
Subject: hg: lambda/lambda/jdk: Add Javadoc; minor cleanups
Message-ID: <20130208223418.8BE994795F@hg.openjdk.java.net>

Changeset: ec40da9cc7af
Author:    briangoetz
Date:      2013-02-08 17:33 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/ec40da9cc7af

Add Javadoc; minor cleanups

! src/share/classes/java/util/function/package-info.java
! src/share/classes/java/util/stream/AbstractShortCircuitTask.java
! src/share/classes/java/util/stream/AbstractSpinedBuffer.java
! src/share/classes/java/util/stream/AbstractTask.java
! src/share/classes/java/util/stream/Nodes.java
! src/share/classes/java/util/stream/Ops.java
! src/share/classes/java/util/stream/PipelineHelper.java
! src/share/classes/java/util/stream/Sink.java
! src/share/classes/java/util/stream/SliceOp.java
! src/share/classes/java/util/stream/SpinedBuffer.java
! src/share/classes/java/util/stream/TerminalSink.java
! src/share/classes/java/util/stream/Tripwire.java
! src/share/classes/java/util/stream/package-info.java
! test-ng/bootlib/java/util/stream/DoubleStreamTestData.java
! test-ng/bootlib/java/util/stream/IntStreamTestData.java
! test-ng/bootlib/java/util/stream/LongStreamTestData.java
! test-ng/bootlib/java/util/stream/StreamTestData.java


From brian.goetz at oracle.com  Fri Feb  8 15:45:58 2013
From: brian.goetz at oracle.com (brian.goetz at oracle.com)
Date: Fri, 08 Feb 2013 23:45:58 +0000
Subject: hg: lambda/lambda/jdk: Refactor Ops into AbstractPipeline;
	eliminate indirection through pipeline() and outputShape() when
	chaining stateless intermediate ops
Message-ID: <20130208234611.1E18F47962@hg.openjdk.java.net>

Changeset: 154a145cdfad
Author:    briangoetz
Date:      2013-02-08 18:45 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/154a145cdfad

Refactor Ops into AbstractPipeline; eliminate indirection through pipeline() and outputShape() when chaining stateless intermediate ops

! src/share/classes/java/util/stream/AbstractPipeline.java
! src/share/classes/java/util/stream/DoublePipeline.java
! src/share/classes/java/util/stream/IntPipeline.java
! src/share/classes/java/util/stream/LongPipeline.java
- src/share/classes/java/util/stream/Ops.java
! src/share/classes/java/util/stream/ReferencePipeline.java
! src/share/classes/java/util/stream/SliceOp.java
! test-ng/boottests/java/util/stream/SpinedBufferTest.java


From brian.goetz at oracle.com  Fri Feb  8 16:24:59 2013
From: brian.goetz at oracle.com (brian.goetz at oracle.com)
Date: Sat, 09 Feb 2013 00:24:59 +0000
Subject: hg: lambda/lambda/jdk: Refactor StreamShape back down to an enum
Message-ID: <20130209002512.D834347964@hg.openjdk.java.net>

Changeset: dbc2965de83d
Author:    briangoetz
Date:      2013-02-08 19:24 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/dbc2965de83d

Refactor StreamShape back down to an enum

! src/share/classes/java/util/stream/SliceOp.java
! src/share/classes/java/util/stream/StreamShape.java


From peter.levart at gmail.com  Sat Feb  9 07:47:51 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Sat, 09 Feb 2013 16:47:51 +0100
Subject: UncheckedIOException and suppressed exception
In-Reply-To: <CACuKZqEXmq3Fvfm1Ot5fOfo=WMEyQ7cyVa6gZ=vxMMOaBoj_JQ@mail.gmail.com>
References: <CACuKZqHn-bSHz0Lc-S0mCC+Zi-8G=BVpnY0P5c_P-DO6_DcdVA@mail.gmail.com>
	<511066E7.1010506@oracle.com>
	<CACuKZqGCyfDWnxxZ45uDBGsBUAfVKn7KPWBNX5AXypMU3MPvYg@mail.gmail.com>
	<511080CD.2020409@oracle.com> <5110D53B.9060502@gmail.com>
	<CACuKZqEXmq3Fvfm1Ot5fOfo=WMEyQ7cyVa6gZ=vxMMOaBoj_JQ@mail.gmail.com>
Message-ID: <51166FA7.6050206@gmail.com>


On 02/08/2013 03:38 PM, Zhong Yu wrote:
> On Tue, Feb 5, 2013 at 3:47 AM, Peter Levart<peter.levart at gmail.com>  wrote:
>
>>          try (CloseableStream<Path> = ...) {
>>              try {
>>                  ... direct Path operations throwing IOException and/or
>>                  ... Stream<Path> operations throwing UncheckedIOException
>>              }
>>              catch (UncheckedIOException uioe) { throw uioe.getCause(); }
>>          }
>>          catch (EOFException eofe) {
>>              // ...
>>          }
>>          catch (ZipException ze) {
>>              // ...
>>          }
>>          catch (IOException ioe) {
>>              //...
>>          }
> There's a bug - the exception from CloseableStream escapes handling
> and creeps away.
>
> Since closing is hidden in a try-with-resource statement, people often
> forget about it, therefore close() should throw the same type of
> exception as opening. If CloseableStream.close() throws IOException,
> the bug won't exist.

Hi Zhong,

That's true. And that would be dangerous for AutoCloseable resources 
that "buffer" output and "flush" it when closed. But Stream<Path> or any 
potential CloseableStream seems to be an inherently "input" resource. Is 
it really possible that closing an open directory fails on any OS? I 
think that CloseableStream could thrown an IOError in that case, 
indicating that there is really something wrong with the platform logic 
or the state of OS. The linux closedir specifies the following for example:

RETURN VALUE
        The closedir() function returns 0 on success.  On error, -1 is 
returned, and errno is set appropriately.

ERRORS
        EBADF  Invalid directory stream descriptor dirp.

...such error should really not occur...

> I'm still at the position that opening/closing the stream should throw
> UncheckedIOException, so that the entire try-with-resource statement
> throws a consistent exception type.
>
>      try(stream = openStream())
>          using stream
>      catch(UncheckedIOException e)
>          handle e
>
> I'm not convinced that "using stream" could involve IOException; why
> would one call Files.list() to get a Stream<Path>, then turn it into
> Iterator<Path> to operate on files "in the open", why he could simply
> use the good old Files.newDirectoryStream()?

Might be just to filter the files using lambdas? But I agree that most 
of the times the processing of Paths would be done inside the Streams 
API too. I would do it that way...

If all IOExceptions were consistently wrapped with UncheckedIOExceptions 
then when one wanted to deal with several IOException subtypes, (s)he 
would have to do the unwrapping in the handler at the end of 
try-with-resources, like for example the following:

         try (CloseableStream<Path> = ...) {
                 ... Stream<Path> operations throwing UncheckedIOException
         }
         catch (UncheckedIOException uioe) {
             try {
                 throw uioe.getCause();
             }
             catch (EOFException eofe) {
                 // ...
             }
             catch (ZipException ze) {
                 // ...
             }
             catch (IOException ioe) {
                 //...
             }
         }

Not bad but not any better either. Only when it doesn't matter which 
kind of IOException is thrown, the consistent wrapping with 
UncheckedIOException simplifies things. I think it would be necessary to 
try to write some real-world examples, like you proposed, to establish 
the right attitude.

Regards, Peter

> Zhong Yu


From peter.levart at gmail.com  Sat Feb  9 09:05:28 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Sat, 09 Feb 2013 18:05:28 +0100
Subject: hg: lambda/lambda/langtools: Enhancement: more stable serialized
	lambda names
In-Reply-To: <20130207193045.C0DCC478E7@hg.openjdk.java.net>
References: <20130207193045.C0DCC478E7@hg.openjdk.java.net>
Message-ID: <511681D8.5060009@gmail.com>


On 02/07/2013 08:30 PM, maurizio.cimadamore at oracle.com wrote:
> Changeset: 7bffb45844fb
> Author:    mcimadamore
> Date:      2013-02-07 19:30 +0000
> URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/7bffb45844fb
>
> Enhancement: more stable serialized lambda names
>
> Serializable lambdas are desugared to methods where name follows following pattern:
>
>    lambda$mmm$kkkk$nnn
>
> where mmm is the method name and kkk is the hashcode of the method signature, and nnn is a sequentially assigned number.  That way, dependencies on lambdas from other methods will be minimized.

Hi Maurizio,

Could the hashCodes of the signatures of two overloaded methods clash? 
For example, these two methods:

     void m(Aa a) { }

     void m(BB b) { }

have method descriptor signatures with same hashCodes.

One way to avoid generating name clashes in such contrived examples is 
to have 'serializableLambdaCounts' Map being keyed by method's declaring 
class + hashCode of method's signature. String.hash32() could also help 
avoid clashes.

Otherwise, is there some rule that disallows synthetic method names 
using full ASCII set of chars? Why couldn't the generated method name be 
composed of the unchanged method signature?

Regards, Peter

> ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java
> ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java
>
>


From peter.levart at gmail.com  Sat Feb  9 09:13:16 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Sat, 09 Feb 2013 18:13:16 +0100
Subject: hg: lambda/lambda/langtools: Enhancement: more stable serialized
	lambda names
In-Reply-To: <511681D8.5060009@gmail.com>
References: <20130207193045.C0DCC478E7@hg.openjdk.java.net>
	<511681D8.5060009@gmail.com>
Message-ID: <511683AC.4020601@gmail.com>


On 02/09/2013 06:05 PM, Peter Levart wrote:
>
> On 02/07/2013 08:30 PM, maurizio.cimadamore at oracle.com wrote:
>> Changeset: 7bffb45844fb
>> Author:    mcimadamore
>> Date:      2013-02-07 19:30 +0000
>> URL:http://hg.openjdk.java.net/lambda/lambda/langtools/rev/7bffb45844fb
>>
>> Enhancement: more stable serialized lambda names
>>
>> Serializable lambdas are desugared to methods where name follows following pattern:
>>
>>    lambda$mmm$kkkk$nnn
>>
>> where mmm is the method name and kkk is the hashcode of the method signature, and nnn is a sequentially assigned number.  That way, dependencies on lambdas from other methods will be minimized.
>
> Hi Maurizio,
>
> Could the hashCodes of the signatures of two overloaded methods clash? 
> For example, these two methods:
>
>     void m(Aa a) { }
>
>     void m(BB b) { }
>
> have method descriptor signatures with same hashCodes.
>
> One way to avoid generating name clashes in such contrived examples is 
> to have 'serializableLambdaCounts' Map being keyed by method's 
> declaring class + hashCode of method's signature. 

Or better, being keyed by "lambda$mmm$kkkk" prefix of generated method 
name, whatever it is...

> String.hash32() could also help avoid clashes.
>
> Otherwise, is there some rule that disallows synthetic method names 
> using full ASCII set of chars? Why couldn't the generated method name 
> be composed of the unchanged method signature?
>
> Regards, Peter
>
>> ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java
>> ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java
>>
>>
>


From brian.goetz at oracle.com  Sat Feb  9 10:09:50 2013
From: brian.goetz at oracle.com (Brian Goetz)
Date: Sat, 09 Feb 2013 13:09:50 -0500
Subject: hg: lambda/lambda/langtools: Enhancement: more stable serialized
	lambda names
In-Reply-To: <511681D8.5060009@gmail.com>
References: <20130207193045.C0DCC478E7@hg.openjdk.java.net>
	<511681D8.5060009@gmail.com>
Message-ID: <511690EE.4000203@oracle.com>

Yes, they could, but this patch addresses that.  It keeps the numbering 
going in that case.

More generally, the goal here is not any sort of "absolute stability"; 
but instead to avoid gratuitous instability.



On 2/9/2013 12:05 PM, Peter Levart wrote:
>
> On 02/07/2013 08:30 PM, maurizio.cimadamore at oracle.com wrote:
>> Changeset: 7bffb45844fb
>> Author:    mcimadamore
>> Date:      2013-02-07 19:30 +0000
>> URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/7bffb45844fb
>>
>> Enhancement: more stable serialized lambda names
>>
>> Serializable lambdas are desugared to methods where name follows following pattern:
>>
>>     lambda$mmm$kkkk$nnn
>>
>> where mmm is the method name and kkk is the hashcode of the method signature, and nnn is a sequentially assigned number.  That way, dependencies on lambdas from other methods will be minimized.
>
> Hi Maurizio,
>
> Could the hashCodes of the signatures of two overloaded methods clash?
> For example, these two methods:
>
>       void m(Aa a) { }
>
>       void m(BB b) { }
>
> have method descriptor signatures with same hashCodes.
>
> One way to avoid generating name clashes in such contrived examples is
> to have 'serializableLambdaCounts' Map being keyed by method's declaring
> class + hashCode of method's signature. String.hash32() could also help
> avoid clashes.
>
> Otherwise, is there some rule that disallows synthetic method names
> using full ASCII set of chars? Why couldn't the generated method name be
> composed of the unchanged method signature?
>
> Regards, Peter
>
>> ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java
>> ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java
>>
>>
>
>

From misterm at gmail.com  Sat Feb  9 14:23:39 2013
From: misterm at gmail.com (Michael Nascimento)
Date: Sat, 9 Feb 2013 20:23:39 -0200
Subject: SortedMap.transformValues?
In-Reply-To: <51153FA9.7090600@oracle.com>
References: <CAAWA2oVj1QdsBfME7zGS7y=ghCM15MggH9Kr7ATPWTw+2+-PTQ@mail.gmail.com>
	<CAAWA2oWabw=TYtK0sDNf1CGEPWvgUTCR+e0+krMbuBK8kXe_0g@mail.gmail.com>
	<51152EC9.8040801@oracle.com> <5115356E.9030800@oracle.com>
	<CAAWA2oW03Djew+H1=ej6oRzexsWS-kjg14QPpfp=_L3WJ0jEgg@mail.gmail.com>
	<51153FA9.7090600@oracle.com>
Message-ID: <CAAWA2oWsf4cogKaLQ0i0+Edxx=rq_VCbcBn8JLv99eF1XnJwGQ@mail.gmail.com>

Thanks a lot Brian for the prompt response. I do still have a question
though: if I got it right,  the constructor will be invoked potentially
several times. That being true, wouldn't using HashMap::new and wrapping
the return in a TreeMap as a final step likely be better performant?

Regards,
Michael
On 8 Feb 2013 16:10, "Brian Goetz" <brian.goetz at oracle.com> wrote:

> Well, it would if I wrote it right.  Let's try this again.
>
>  // Imperative way:
>  Map<K,V1> oldMap = ...
>  Map<K,V2> newMap = new TreeMap<K,V1>();
>  oldMap.entrySet().stream()
>        .forEach(e -> newMap.put(e.getKey(), f.apply(e.getvalue()));
>
>  // Collect way:
>  Map<K,V2> newMap
>       = oldMap.entrySet().stream()
>               .collect(joiningWith(k -> f.apply(oldMap.get(k)),
>                        TreeMap::new);
>
> To which I'll add:
>  // Concurrent way:
>  Map<K,V1> oldMap = ...
>  Map<K,V2> newMap = new ConcurrentSkipListMap<K,V1>();
>  oldMap.entrySet().**parallelStream()
>        .forEach(e -> newMap.put(e.getKey(), f.apply(e.getvalue()));
>
>  // Parallel functional way with map merging:
>  Map<K,V2> newMap
>       = oldMap.entrySet().**parallelStream()
>               .collect(joiningWith(k -> f.apply(oldMap.get(k)),
>                        TreeMap::new)));
>
>
> Is that enough choices?  :)
>
> On 2/8/2013 12:59 PM, Michael Nascimento wrote:
>
>> Thank you Brian, but this does not return a SortedMap. I can always
>> construct a new one with the result, but I wonder if that is the best
>> approach.
>>
>> Regards,
>> Michael
>>
>> On Fri, Feb 8, 2013 at 3:27 PM, Brian Goetz <brian.goetz at oracle.com>
>> wrote:
>>
>>> Er, the second example should be "keys()" not "entrySet()".  Sorry.
>>>
>>>
>>> On 2/8/2013 11:58 AM, Brian Goetz wrote:
>>>
>>>>
>>>> // Imperative way:
>>>> Map<K,V1> oldMap = ...
>>>> Map<K,V2> newMap
>>>>      = oldMap.entrySet().stream()
>>>>              .forEach(e -> newMap.put(e.getKey(),
>>>> f.apply(e.getvalue()));
>>>>
>>>> // Collector way (works in parallel!)
>>>> Map<K,V2> newMap
>>>>      = oldMap.entrySet().stream()
>>>>              .collect(joiningWith(k -> f.apply(oldMap.get(k)));
>>>>
>>>>
>>>> On 2/8/2013 11:42 AM, Michael Nascimento wrote:
>>>>
>>>>>
>>>>> Any chance of getting an updated version for b76?
>>>>>
>>>>> On Wed, Jan 16, 2013 at 3:57 PM, Michael Nascimento <misterm at gmail.com
>>>>> >
>>>>> wrote:
>>>>>
>>>>>>
>>>>>> Hi guys,
>>>>>>
>>>>>> What is the lambda way of achieving:
>>>>>>
>>>>>>
>>>>>> http://docs.guava-libraries.**googlecode.com/git/javadoc/**
>>>>>> com/google/common/collect/**Maps.html#transformValues(**
>>>>>> java.util.SortedMap<http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/collect/Maps.html#transformValues(java.util.SortedMap>
>>>>>> ,
>>>>>> com.google.common.base.**Function)
>>>>>>
>>>>>> ?
>>>>>>
>>>>>> Regards,
>>>>>> Michael
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>

From brian.goetz at oracle.com  Sat Feb  9 15:03:53 2013
From: brian.goetz at oracle.com (Brian Goetz)
Date: Sat, 09 Feb 2013 18:03:53 -0500
Subject: SortedMap.transformValues?
In-Reply-To: <CAAWA2oWsf4cogKaLQ0i0+Edxx=rq_VCbcBn8JLv99eF1XnJwGQ@mail.gmail.com>
References: <CAAWA2oVj1QdsBfME7zGS7y=ghCM15MggH9Kr7ATPWTw+2+-PTQ@mail.gmail.com>
	<CAAWA2oWabw=TYtK0sDNf1CGEPWvgUTCR+e0+krMbuBK8kXe_0g@mail.gmail.com>
	<51152EC9.8040801@oracle.com> <5115356E.9030800@oracle.com>
	<CAAWA2oW03Djew+H1=ej6oRzexsWS-kjg14QPpfp=_L3WJ0jEgg@mail.gmail.com>
	<51153FA9.7090600@oracle.com>
	<CAAWA2oWsf4cogKaLQ0i0+Edxx=rq_VCbcBn8JLv99eF1XnJwGQ@mail.gmail.com>
Message-ID: <5116D5D9.6070809@oracle.com>

For the "imperative" and "sequential collect" way, the ctor will be 
invoked once, because both are sequential.

For the "concurrent" way, again there is only one map; multiple threads 
blast values into the thread-safe map and we hope that the map's 
internal contention management makes that a win.

For the "parallel functional" way, yes, you are right, but the ability 
to use a different ctor for root and leaves would complicate the API 
quite a bit.

On 2/9/2013 5:23 PM, Michael Nascimento wrote:
> Thanks a lot Brian for the prompt response. I do still have a question
> though: if I got it right,  the constructor will be invoked potentially
> several times. That being true, wouldn't using HashMap::new and wrapping
> the return in a TreeMap as a final step likely be better performant?
>
> Regards,
> Michael
>
> On 8 Feb 2013 16:10, "Brian Goetz" <brian.goetz at oracle.com
> <mailto:brian.goetz at oracle.com>> wrote:
>
>     Well, it would if I wrote it right.  Let's try this again.
>
>       // Imperative way:
>       Map<K,V1> oldMap = ...
>       Map<K,V2> newMap = new TreeMap<K,V1>();
>       oldMap.entrySet().stream()
>             .forEach(e -> newMap.put(e.getKey(), f.apply(e.getvalue()));
>
>       // Collect way:
>       Map<K,V2> newMap
>            = oldMap.entrySet().stream()
>                    .collect(joiningWith(k -> f.apply(oldMap.get(k)),
>                             TreeMap::new);
>
>     To which I'll add:
>       // Concurrent way:
>       Map<K,V1> oldMap = ...
>       Map<K,V2> newMap = new ConcurrentSkipListMap<K,V1>();
>       oldMap.entrySet().__parallelStream()
>             .forEach(e -> newMap.put(e.getKey(), f.apply(e.getvalue()));
>
>       // Parallel functional way with map merging:
>       Map<K,V2> newMap
>            = oldMap.entrySet().__parallelStream()
>                    .collect(joiningWith(k -> f.apply(oldMap.get(k)),
>                             TreeMap::new)));
>
>
>     Is that enough choices?  :)
>
>     On 2/8/2013 12:59 PM, Michael Nascimento wrote:
>
>         Thank you Brian, but this does not return a SortedMap. I can always
>         construct a new one with the result, but I wonder if that is the
>         best
>         approach.
>
>         Regards,
>         Michael
>
>         On Fri, Feb 8, 2013 at 3:27 PM, Brian Goetz
>         <brian.goetz at oracle.com <mailto:brian.goetz at oracle.com>> wrote:
>
>             Er, the second example should be "keys()" not "entrySet()".
>               Sorry.
>
>
>             On 2/8/2013 11:58 AM, Brian Goetz wrote:
>
>
>                 // Imperative way:
>                 Map<K,V1> oldMap = ...
>                 Map<K,V2> newMap
>                       = oldMap.entrySet().stream()
>                               .forEach(e -> newMap.put(e.getKey(),
>                 f.apply(e.getvalue()));
>
>                 // Collector way (works in parallel!)
>                 Map<K,V2> newMap
>                       = oldMap.entrySet().stream()
>                               .collect(joiningWith(k ->
>                 f.apply(oldMap.get(k)));
>
>
>                 On 2/8/2013 11:42 AM, Michael Nascimento wrote:
>
>
>                     Any chance of getting an updated version for b76?
>
>                     On Wed, Jan 16, 2013 at 3:57 PM, Michael Nascimento
>                     <misterm at gmail.com <mailto:misterm at gmail.com>>
>                     wrote:
>
>
>                         Hi guys,
>
>                         What is the lambda way of achieving:
>
>
>                         http://docs.guava-libraries.__googlecode.com/git/javadoc/__com/google/common/collect/__Maps.html#transformValues(__java.util.SortedMap
>                         <http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/collect/Maps.html#transformValues(java.util.SortedMap>,
>                         com.google.common.base.__Function)
>
>                         ?
>
>                         Regards,
>                         Michael
>
>
>
>
>

From misterm at gmail.com  Sat Feb  9 16:34:05 2013
From: misterm at gmail.com (Michael Nascimento)
Date: Sat, 9 Feb 2013 22:34:05 -0200
Subject: Round 2 feedback
In-Reply-To: <CAAWA2oW235ZLRF=euit3L4Xbo=i64V4+E1GyGhvx1SOzY5y-Lw@mail.gmail.com>
References: <CAAWA2oUVMVhx_xaEG1vFn3ueRJ7VM=D10WV3Y+0X-+-kxjWwtw@mail.gmail.com>
	<CAAWA2oU3PEC5jHD8aqgd3VSZU+-kUgqz-ALQo0d7+S6z4Hn0RA@mail.gmail.com>
	<CAAWA2oW235ZLRF=euit3L4Xbo=i64V4+E1GyGhvx1SOzY5y-Lw@mail.gmail.com>
Message-ID: <CAAWA2oVi9dM9F6KHhyTr33uKhbBrJbjrkLSP_zM35aLwv96ajQ@mail.gmail.com>

Hi guys,

So I've updated my code to b76. Some unstructured feedback:

- We use many Maps here, with many transformations. It is still painful to
do operations like transformValues, because it usually involves using other
lambdas and then type inference fails, still requiring specificying the
actual type parameters - and this might require many parameters sometimes;
- At least here, even simple transformations such as
myCollection.parallelStream().map(Functions.string()).collect(Collectors.<String>toList())
requires the explicit types;
- groupingBy that returns a Map keyed by the Stream type is completely
unintuitive. If not by the suggestion from the mailing list, I would never
think of it as being applicable to my use case. A better name is certainly
desirable;
- It seems odd to have collect and collectUnordered when some Collectors
are naturally unordered, such as toSet. Can't it be changed to be a
property of the Collector somehow?;
- computeIfAbsent is useful, but for most Guava cases I wanted to lambdify
I actually needed a method that returns an Optional instead. Can it be
added?;
- Here is my greatest concern so far: parallel streams in their current
form will cause Java EE applications to fail miserably. In such
environments, threads cannot be freely created and all types of leaks and
exceptions can happen if one calls a method in a non-container managed
thread. Since calling parallelStream is cheap, I guess people will do it
often and it will be hard for Java EE developers to find out if any
third-party Java SE 8 code is safe to call or not - and enterprise
developers unaware of such restrictions, which are unfortunately the
majority, will be puzzled by never seen exceptions or erratic behaviour in
production. My suggestion would be to add a parameter to parallelStream and
parallel which is an abstraction to thread management,  forcing people to
think about it. Then one can construct a wrapper over the
container-specific API for now and Java EE 8 can provide the standardized
one;
- Some throw-away Javadoc could be added, especially to Collectors, only
with sample code for a Person class so developers can understand what
methods are supposed to do.

I would like to congratulate you all for the fast responses.

Regards,
Michael

From zhong.j.yu at gmail.com  Sat Feb  9 18:32:07 2013
From: zhong.j.yu at gmail.com (Zhong Yu)
Date: Sat, 9 Feb 2013 20:32:07 -0600
Subject: UncheckedIOException and suppressed exception
In-Reply-To: <51166FA7.6050206@gmail.com>
References: <CACuKZqHn-bSHz0Lc-S0mCC+Zi-8G=BVpnY0P5c_P-DO6_DcdVA@mail.gmail.com>
	<511066E7.1010506@oracle.com>
	<CACuKZqGCyfDWnxxZ45uDBGsBUAfVKn7KPWBNX5AXypMU3MPvYg@mail.gmail.com>
	<511080CD.2020409@oracle.com> <5110D53B.9060502@gmail.com>
	<CACuKZqEXmq3Fvfm1Ot5fOfo=WMEyQ7cyVa6gZ=vxMMOaBoj_JQ@mail.gmail.com>
	<51166FA7.6050206@gmail.com>
Message-ID: <CACuKZqESw+0ewPWaiFqYy9xANLEXM+Up=VLDk1aTCq6cWT75pw@mail.gmail.com>

On Sat, Feb 9, 2013 at 9:47 AM, Peter Levart <peter.levart at gmail.com> wrote:
>
> On 02/08/2013 03:38 PM, Zhong Yu wrote:
>
> On Tue, Feb 5, 2013 at 3:47 AM, Peter Levart <peter.levart at gmail.com> wrote:
>
>         try (CloseableStream<Path> = ...) {
>             try {
>                 ... direct Path operations throwing IOException and/or
>                 ... Stream<Path> operations throwing UncheckedIOException
>             }
>             catch (UncheckedIOException uioe) { throw uioe.getCause(); }
>         }
>         catch (EOFException eofe) {
>             // ...
>         }
>         catch (ZipException ze) {
>             // ...
>         }
>         catch (IOException ioe) {
>             //...
>         }
>
> There's a bug - the exception from CloseableStream escapes handling
> and creeps away.
>
> Since closing is hidden in a try-with-resource statement, people often
> forget about it, therefore close() should throw the same type of
> exception as opening. If CloseableStream.close() throws IOException,
> the bug won't exist.
>
>
> Hi Zhong,
>
> That's true. And that would be dangerous for AutoCloseable resources that
> "buffer" output and "flush" it when closed. But Stream<Path> or any
> potential CloseableStream seems to be an inherently "input" resource. Is it

One could open a FileChannel for read/write, first write something to
it, then wrap it as a CloseableStream<String>, relying on
CloseableStream.close() to trigger FileChannel.close() to persist the
file. So a read-only stream isn't necessarily based on a read-only
resource.

Zhong Yu


> really possible that closing an open directory fails on any OS? I think that
> CloseableStream could thrown an IOError in that case, indicating that there
> is really something wrong with the platform logic or the state of OS. The
> linux closedir specifies the following for example:
>
> RETURN VALUE
>        The closedir() function returns 0 on success.  On error, -1 is
> returned, and errno is set appropriately.
>
> ERRORS
>        EBADF  Invalid directory stream descriptor dirp.
>
> ...such error should really not occur...
>
>
> I'm still at the position that opening/closing the stream should throw
> UncheckedIOException, so that the entire try-with-resource statement
> throws a consistent exception type.
>
>     try(stream = openStream())
>         using stream
>     catch(UncheckedIOException e)
>         handle e
>
> I'm not convinced that "using stream" could involve IOException; why
> would one call Files.list() to get a Stream<Path>, then turn it into
> Iterator<Path> to operate on files "in the open", why he could simply
> use the good old Files.newDirectoryStream()?
>
>
> Might be just to filter the files using lambdas? But I agree that most of
> the times the processing of Paths would be done inside the Streams API too.
> I would do it that way...
>
> If all IOExceptions were consistently wrapped with UncheckedIOExceptions
> then when one wanted to deal with several IOException subtypes, (s)he would
> have to do the unwrapping in the handler at the end of try-with-resources,
> like for example the following:
>
>
>         try (CloseableStream<Path> = ...) {
>                 ... Stream<Path> operations throwing UncheckedIOException
>         }
>         catch (UncheckedIOException uioe) {
>             try {
>                 throw uioe.getCause();
>             }
>             catch (EOFException eofe) {
>
>                 // ...
>             }
>             catch (ZipException ze) {
>                 // ...
>             }
>             catch (IOException ioe) {
>                 //...
>             }
>         }
>
> Not bad but not any better either. Only when it doesn't matter which kind of
> IOException is thrown, the consistent wrapping with UncheckedIOException
> simplifies things. I think it would be necessary to try to write some
> real-world examples, like you proposed, to establish the right attitude.
>
> Regards, Peter
>
> Zhong Yu
>
>

From martinrb at google.com  Sat Feb  9 23:49:39 2013
From: martinrb at google.com (Martin Buchholz)
Date: Sat, 9 Feb 2013 23:49:39 -0800
Subject: [7u-dev] Request for approval for JDK-7175464 - entrySetView
	field is never updated in NavigableSubMap
In-Reply-To: <CA+kOe0-1w=sqJBx-3O5Mv8jh6-rwhTZjnq0Jw6r8fhPhhFDdfA@mail.gmail.com>
References: <718E9936-939D-4D0F-941F-6B8696772F4F@oracle.com>
	<51155565.9070800@cs.oswego.edu>
	<D87E31E8-A48A-4499-8BD9-300C421934A4@oracle.com>
	<CA+kOe09q5G+OX5Vu0dgM+bxAE3LRxG3qiYtwXqMDo2y+tKkVCw@mail.gmail.com>
	<CA+kOe0-1w=sqJBx-3O5Mv8jh6-rwhTZjnq0Jw6r8fhPhhFDdfA@mail.gmail.com>
Message-ID: <CA+kOe09f14dHxxBFtBP=Uog_VWJ1uRX6zKNyprfgMKGJjrkY=A@mail.gmail.com>

[adding lambda-dev]

Here's another refinement to the test case, which shows that a serial clone
of Collections.reverseOrder in lambda8 creates a new instance of a new
class with the opposite order (which I can't explain):

When run against latest lambda-b76, it gives this output:

x=java.util.Collections$ReverseComparator at 3710b205
y=java.util.Collections$ReverseComparator2 at e9b8b810
x: 1 -1
y: -1 1

import java.util.*;
import java.io.*;

public class ReverseOrder {
    public static void main(String[] args) throws Throwable {
        Comparator x = Collections.reverseOrder();
        Comparator y = serialClone(x);
        System.out.printf("x=%s%n", x);
        System.out.printf("y=%s%n", y);
        System.out.printf("x: %d %d%n", x.compare(0,1), x.compare(1,0));
        System.out.printf("y: %d %d%n", y.compare(0,1), y.compare(1,0));
    }

    static byte[] serialBytes(Object o) {
        try {
            ByteArrayOutputStream bos = new ByteArrayOutputStream();
            ObjectOutputStream oos = new ObjectOutputStream(bos);
            oos.writeObject(o);
            oos.flush();
            oos.close();
            return bos.toByteArray();
        } catch (Throwable t) {
            throw new Error(t);
        }
    }

    @SuppressWarnings("unchecked")
    static <T> T serialClone(T o) {
        try {
            ObjectInputStream ois = new ObjectInputStream
                (new ByteArrayInputStream(serialBytes(o)));
            T clone = (T) ois.readObject();
            return clone;
        } catch (Throwable t) {
            throw new Error(t);
        }
    }
}


On Sat, Feb 9, 2013 at 3:31 PM, Martin Buchholz <martinrb at google.com> wrote:

>
>
> On Sat, Feb 9, 2013 at 3:09 PM, Martin Buchholz <martinrb at google.com>wrote:
>
>> It looks to me like Collections.reverseOrder no longer deserializes to
>> the same object.  It also looks like the definition for that in
>> Collections.java hasn't changed recently.  So I suspect that there has been
>> some serious incompatible change to deserialization itself.
>> (It's another matter whether that could break TreeSet).
>> (I have long lobbied for more cross-jdk testing focused on seriallization)
>>
>> The program below demonstrates the different behavior between jdk7 and
>> jdk8:
>>
>>
> Oops - correction - this is not a difference between jdk7 and jdk8, but
> between jdk8 and lambda8, More specifically, lambda-8-b74 fails,
> while jdk8-b74 succeeds.  Have lambdadukes messed with serialization?
>
>
>
>> import java.util.*;
>> import java.io.*;
>>
>> public class ReverseOrder {
>>     public static void main(String[] args) throws Throwable {
>>         Comparator c = Collections.reverseOrder();
>>         if (c != serialClone(c))
>>             throw new Error(String.format("c=%s clone=%s",
>>                                           c, serialClone(c)));
>>     }
>>
>>      static byte[] serialBytes(Object o) {
>>         try {
>>             ByteArrayOutputStream bos = new ByteArrayOutputStream();
>>             ObjectOutputStream oos = new ObjectOutputStream(bos);
>>             oos.writeObject(o);
>>             oos.flush();
>>             oos.close();
>>             return bos.toByteArray();
>>         } catch (Throwable t) {
>>             throw new Error(t);
>>         }
>>     }
>>
>>     @SuppressWarnings("unchecked")
>>     static <T> T serialClone(T o) {
>>         try {
>>             ObjectInputStream ois = new ObjectInputStream
>>                 (new ByteArrayInputStream(serialBytes(o)));
>>             T clone = (T) ois.readObject();
>>             return clone;
>>         } catch (Throwable t) {
>>             throw new Error(t);
>>          }
>>     }
>> }
>>
>>
>> On Fri, Feb 8, 2013 at 3:16 PM, Mike Duigou <mike.duigou at oracle.com>wrote:
>>
>>> Thank you for catching this Doug. I missed your original post on this
>>> topic during my Christmas vacation. (
>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-December/013127.htmlfor those following along at home)
>>>
>>> I will definitely hold off and follow up on the potentially bad patch to
>>> Java 8. I have created an issue to resolve the test breakage, JDK-8007889
>>>
>>> Mike
>>>
>>> On Feb 8 2013, at 11:43 , Doug Lea wrote:
>>>
>>> > On 02/08/13 14:33, Mike Duigou wrote:
>>> >> Hello all;
>>> >>
>>> >> I would like to backport this change from Java 8. It has been baking
>>> in JDK8 for about two months with no problems.
>>> >>
>>> >
>>> > I think it may have problems.
>>> > As I mentioned in a post a few months ago, it seems
>>> > to be responsible for breakage in a TCK/JCK test;
>>> > One derived from a jsr166 tck test at
>>> >
>>> http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/test/tck/TreeSubSetTest.java?view=log
>>> >
>>> > You need the file for context, but it looks like:
>>> >
>>> >    public void testDescendingSerialization() throws Exception {
>>> >        NavigableSet x = dset5();
>>> >        NavigableSet y = serialClone(x);
>>> >
>>> >        assertTrue(x != y);
>>> >        assertEquals(x.size(), y.size());
>>> >        assertEquals(x.toString(), y.toString());
>>> >        assertEquals(x, y);
>>> >        assertEquals(y, x);
>>> >        while (!x.isEmpty()) {
>>> >            assertFalse(y.isEmpty());
>>> >            assertEquals(x.pollFirst(), y.pollFirst());
>>> >        }
>>> >        assertTrue(y.isEmpty());
>>> >    }
>>> >
>>> >
>>> >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7175464
>>> >>
>>> >> http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/bf6ceb6b8f80
>>> >>
>>> >> The change was previously reviewed by Alan Bateman, Paul Sandoz and
>>> David Holmes before going in to Java 8.
>>> >>
>>> >> Mike
>>> >>
>>> >
>>>
>>>
>>
>

From peter.levart at gmail.com  Sun Feb 10 02:37:40 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Sun, 10 Feb 2013 11:37:40 +0100
Subject: [7u-dev] Request for approval for JDK-7175464 - entrySetView
	field is never updated in NavigableSubMap
In-Reply-To: <CA+kOe09f14dHxxBFtBP=Uog_VWJ1uRX6zKNyprfgMKGJjrkY=A@mail.gmail.com>
References: <718E9936-939D-4D0F-941F-6B8696772F4F@oracle.com>
	<51155565.9070800@cs.oswego.edu>
	<D87E31E8-A48A-4499-8BD9-300C421934A4@oracle.com>
	<CA+kOe09q5G+OX5Vu0dgM+bxAE3LRxG3qiYtwXqMDo2y+tKkVCw@mail.gmail.com>
	<CA+kOe0-1w=sqJBx-3O5Mv8jh6-rwhTZjnq0Jw6r8fhPhhFDdfA@mail.gmail.com>
	<CA+kOe09f14dHxxBFtBP=Uog_VWJ1uRX6zKNyprfgMKGJjrkY=A@mail.gmail.com>
Message-ID: <51177874.4030609@gmail.com>

Hi Martin,

It seems that adding a default method Comparator.reverseOrder() had an 
impact on the code in Collections.

In he following code in Collections:

     private static class ReverseComparator
         implements Comparator<Comparable<Object>>, Serializable {

         private static final long serialVersionUID = 7207038068494060240L;

         static final ReverseComparator REVERSE_ORDER
             = new ReverseComparator();

         public int compare(Comparable<Object> c1, Comparable<Object> c2) {
             return c2.compareTo(c1);
         }

         private Object readResolve() { return reverseOrder(); }
     }

...the method readResolve() now calls default Comparator.reverseOrder(), 
but previously it called the static Collections.reverseOrder()....


Regards, Peter

On 02/10/2013 08:49 AM, Martin Buchholz wrote:
> [adding lambda-dev]
>
> Here's another refinement to the test case, which shows that a serial clone
> of Collections.reverseOrder in lambda8 creates a new instance of a new
> class with the opposite order (which I can't explain):
>
> When run against latest lambda-b76, it gives this output:
>
> x=java.util.Collections$ReverseComparator at 3710b205
> y=java.util.Collections$ReverseComparator2 at e9b8b810
> x: 1 -1
> y: -1 1
>
> import java.util.*;
> import java.io.*;
>
> public class ReverseOrder {
>      public static void main(String[] args) throws Throwable {
>          Comparator x = Collections.reverseOrder();
>          Comparator y = serialClone(x);
>          System.out.printf("x=%s%n", x);
>          System.out.printf("y=%s%n", y);
>          System.out.printf("x: %d %d%n", x.compare(0,1), x.compare(1,0));
>          System.out.printf("y: %d %d%n", y.compare(0,1), y.compare(1,0));
>      }
>
>      static byte[] serialBytes(Object o) {
>          try {
>              ByteArrayOutputStream bos = new ByteArrayOutputStream();
>              ObjectOutputStream oos = new ObjectOutputStream(bos);
>              oos.writeObject(o);
>              oos.flush();
>              oos.close();
>              return bos.toByteArray();
>          } catch (Throwable t) {
>              throw new Error(t);
>          }
>      }
>
>      @SuppressWarnings("unchecked")
>      static <T> T serialClone(T o) {
>          try {
>              ObjectInputStream ois = new ObjectInputStream
>                  (new ByteArrayInputStream(serialBytes(o)));
>              T clone = (T) ois.readObject();
>              return clone;
>          } catch (Throwable t) {
>              throw new Error(t);
>          }
>      }
> }
>
>
> On Sat, Feb 9, 2013 at 3:31 PM, Martin Buchholz <martinrb at google.com> wrote:
>
>> On Sat, Feb 9, 2013 at 3:09 PM, Martin Buchholz <martinrb at google.com>wrote:
>>
>>> It looks to me like Collections.reverseOrder no longer deserializes to
>>> the same object.  It also looks like the definition for that in
>>> Collections.java hasn't changed recently.  So I suspect that there has been
>>> some serious incompatible change to deserialization itself.
>>> (It's another matter whether that could break TreeSet).
>>> (I have long lobbied for more cross-jdk testing focused on seriallization)
>>>
>>> The program below demonstrates the different behavior between jdk7 and
>>> jdk8:
>>>
>>>
>> Oops - correction - this is not a difference between jdk7 and jdk8, but
>> between jdk8 and lambda8, More specifically, lambda-8-b74 fails,
>> while jdk8-b74 succeeds.  Have lambdadukes messed with serialization?
>>
>>
>>
>>> import java.util.*;
>>> import java.io.*;
>>>
>>> public class ReverseOrder {
>>>      public static void main(String[] args) throws Throwable {
>>>          Comparator c = Collections.reverseOrder();
>>>          if (c != serialClone(c))
>>>              throw new Error(String.format("c=%s clone=%s",
>>>                                            c, serialClone(c)));
>>>      }
>>>
>>>       static byte[] serialBytes(Object o) {
>>>          try {
>>>              ByteArrayOutputStream bos = new ByteArrayOutputStream();
>>>              ObjectOutputStream oos = new ObjectOutputStream(bos);
>>>              oos.writeObject(o);
>>>              oos.flush();
>>>              oos.close();
>>>              return bos.toByteArray();
>>>          } catch (Throwable t) {
>>>              throw new Error(t);
>>>          }
>>>      }
>>>
>>>      @SuppressWarnings("unchecked")
>>>      static <T> T serialClone(T o) {
>>>          try {
>>>              ObjectInputStream ois = new ObjectInputStream
>>>                  (new ByteArrayInputStream(serialBytes(o)));
>>>              T clone = (T) ois.readObject();
>>>              return clone;
>>>          } catch (Throwable t) {
>>>              throw new Error(t);
>>>           }
>>>      }
>>> }
>>>
>>>
>>> On Fri, Feb 8, 2013 at 3:16 PM, Mike Duigou <mike.duigou at oracle.com>wrote:
>>>
>>>> Thank you for catching this Doug. I missed your original post on this
>>>> topic during my Christmas vacation. (
>>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-December/013127.htmlfor those following along at home)
>>>>
>>>> I will definitely hold off and follow up on the potentially bad patch to
>>>> Java 8. I have created an issue to resolve the test breakage, JDK-8007889
>>>>
>>>> Mike
>>>>
>>>> On Feb 8 2013, at 11:43 , Doug Lea wrote:
>>>>
>>>>> On 02/08/13 14:33, Mike Duigou wrote:
>>>>>> Hello all;
>>>>>>
>>>>>> I would like to backport this change from Java 8. It has been baking
>>>> in JDK8 for about two months with no problems.
>>>>> I think it may have problems.
>>>>> As I mentioned in a post a few months ago, it seems
>>>>> to be responsible for breakage in a TCK/JCK test;
>>>>> One derived from a jsr166 tck test at
>>>>>
>>>> http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/test/tck/TreeSubSetTest.java?view=log
>>>>> You need the file for context, but it looks like:
>>>>>
>>>>>     public void testDescendingSerialization() throws Exception {
>>>>>         NavigableSet x = dset5();
>>>>>         NavigableSet y = serialClone(x);
>>>>>
>>>>>         assertTrue(x != y);
>>>>>         assertEquals(x.size(), y.size());
>>>>>         assertEquals(x.toString(), y.toString());
>>>>>         assertEquals(x, y);
>>>>>         assertEquals(y, x);
>>>>>         while (!x.isEmpty()) {
>>>>>             assertFalse(y.isEmpty());
>>>>>             assertEquals(x.pollFirst(), y.pollFirst());
>>>>>         }
>>>>>         assertTrue(y.isEmpty());
>>>>>     }
>>>>>
>>>>>
>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7175464
>>>>>>
>>>>>> http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/bf6ceb6b8f80
>>>>>>
>>>>>> The change was previously reviewed by Alan Bateman, Paul Sandoz and
>>>> David Holmes before going in to Java 8.
>>>>>> Mike
>>>>>>


From forax at univ-mlv.fr  Sun Feb 10 04:13:48 2013
From: forax at univ-mlv.fr (Remi Forax)
Date: Sun, 10 Feb 2013 13:13:48 +0100
Subject: Round 2 feedback
In-Reply-To: <CAAWA2oVi9dM9F6KHhyTr33uKhbBrJbjrkLSP_zM35aLwv96ajQ@mail.gmail.com>
References: <CAAWA2oUVMVhx_xaEG1vFn3ueRJ7VM=D10WV3Y+0X-+-kxjWwtw@mail.gmail.com>
	<CAAWA2oU3PEC5jHD8aqgd3VSZU+-kUgqz-ALQo0d7+S6z4Hn0RA@mail.gmail.com>
	<CAAWA2oW235ZLRF=euit3L4Xbo=i64V4+E1GyGhvx1SOzY5y-Lw@mail.gmail.com>
	<CAAWA2oVi9dM9F6KHhyTr33uKhbBrJbjrkLSP_zM35aLwv96ajQ@mail.gmail.com>
Message-ID: <51178EFC.1040909@univ-mlv.fr>

On 02/10/2013 01:34 AM, Michael Nascimento wrote:
> Hi guys,

Hi Mickael,

>
> So I've updated my code to b76. Some unstructured feedback:
>
> - We use many Maps here, with many transformations. It is still painful to
> do operations like transformValues, because it usually involves using other
> lambdas and then type inference fails, still requiring specificying the
> actual type parameters - and this might require many parameters sometimes;
> - At least here, even simple transformations such as
> myCollection.parallelStream().map(Functions.string()).collect(Collectors.<String>toList())
> requires the explicit types;

Weird,
this works for me:
   import static java.util.stream.Collectors.*;

   static class Functions {
     static Function<Object, String> string() {
       return Object::toString;
     }
   }

   public static void main(String[] args) {
     Arrays.stream(args).map(Functions.string()).collect(toList());
   }

how Functions.string() is defined ?

> - groupingBy that returns a Map keyed by the Stream type is completely
> unintuitive. If not by the suggestion from the mailing list, I would never
> think of it as being applicable to my use case. A better name is certainly
> desirable;
> - It seems odd to have collect and collectUnordered when some Collectors
> are naturally unordered, such as toSet. Can't it be changed to be a
> property of the Collector somehow?;
> - computeIfAbsent is useful, but for most Guava cases I wanted to lambdify
> I actually needed a method that returns an Optional instead. Can it be
> added?;
> - Here is my greatest concern so far: parallel streams in their current
> form will cause Java EE applications to fail miserably. In such
> environments, threads cannot be freely created and all types of leaks and
> exceptions can happen if one calls a method in a non-container managed
> thread. Since calling parallelStream is cheap, I guess people will do it
> often and it will be hard for Java EE developers to find out if any
> third-party Java SE 8 code is safe to call or not - and enterprise
> developers unaware of such restrictions, which are unfortunately the
> majority, will be puzzled by never seen exceptions or erratic behaviour in
> production. My suggestion would be to add a parameter to parallelStream and
> parallel which is an abstraction to thread management,  forcing people to
> think about it. Then one can construct a wrapper over the
> container-specific API for now and Java EE 8 can provide the standardized
> one;

yes, the issue is even more complex than that when people will start to 
use parallelStream() inside library codes because the library will work 
in Java SE and not with Java EE.
The real question seems to be how JEE container can support the common 
ForkJoinPool.

> - Some throw-away Javadoc could be added, especially to Collectors, only
> with sample code for a Person class so developers can understand what
> methods are supposed to do.
>
> I would like to congratulate you all for the fast responses.
>
> Regards,
> Michael
>

cheers,
R?mi


From martinrb at google.com  Sun Feb 10 19:52:13 2013
From: martinrb at google.com (Martin Buchholz)
Date: Sun, 10 Feb 2013 19:52:13 -0800
Subject: [7u-dev] Request for approval for JDK-7175464 - entrySetView
	field is never updated in NavigableSubMap
In-Reply-To: <51177C6E.1060203@oracle.com>
References: <718E9936-939D-4D0F-941F-6B8696772F4F@oracle.com>
	<51155565.9070800@cs.oswego.edu>
	<D87E31E8-A48A-4499-8BD9-300C421934A4@oracle.com>
	<CA+kOe09q5G+OX5Vu0dgM+bxAE3LRxG3qiYtwXqMDo2y+tKkVCw@mail.gmail.com>
	<CA+kOe0-1w=sqJBx-3O5Mv8jh6-rwhTZjnq0Jw6r8fhPhhFDdfA@mail.gmail.com>
	<51177C6E.1060203@oracle.com>
Message-ID: <CA+kOe08CN7Sutb7f4M2qNT4z9be0ru3JLugaM1rJjrmHBptwtQ@mail.gmail.com>

Alright, now that the problem (if not the solution) is well understood, I
leave it to you.

Martin

On Sun, Feb 10, 2013 at 2:54 AM, Alan Bateman <Alan.Bateman at oracle.com>wrote:

> On 09/02/2013 23:31, Martin Buchholz wrote:
>
>> On Sat, Feb 9, 2013 at 3:09 PM, Martin Buchholz<martinrb at google.com>
>>  wrote:
>>
>>  It looks to me like Collections.reverseOrder no longer deserializes to
>>> the
>>> same object.  It also looks like the definition for that in
>>> Collections.java hasn't changed recently.  So I suspect that there has
>>> been
>>> some serious incompatible change to deserialization itself.
>>> (It's another matter whether that could break TreeSet).
>>> (I have long lobbied for more cross-jdk testing focused on
>>> seriallization)
>>>
>>> The program below demonstrates the different behavior between jdk7 and
>>> jdk8:
>>>
>>>
>>>  Oops - correction - this is not a difference between jdk7 and jdk8, but
>> between jdk8 and lambda8, More specifically, lambda-8-b74 fails,
>> while jdk8-b74 succeeds.  Have lambdadukes messed with serialization?
>>
>>  Collections.ReverseComparator'**s readResolve is:
>
>
> private Object readResolve() { return reverseOrder(); }
>
> so I assume it's the new Comparator.reverseOrder() that is used now rather
> than Collections.reverseOrder() as before. Ha, this means it's returning a
> compator to reverse itself.
>
> This one aside, this is another issue with serialization that has come
> about because of default methods and because declared methods are used in
> the computation of the default serial version UID. Mike and Stuart are
> looking into that one (I think it came up on the lambda-dev list recently).
>
> -Alan
>
>
>
>

From mike.duigou at oracle.com  Sun Feb 10 21:03:31 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Sun, 10 Feb 2013 21:03:31 -0800
Subject: [7u-dev] Request for approval for JDK-7175464 - entrySetView
	field is never updated in NavigableSubMap
In-Reply-To: <CA+kOe08CN7Sutb7f4M2qNT4z9be0ru3JLugaM1rJjrmHBptwtQ@mail.gmail.com>
References: <718E9936-939D-4D0F-941F-6B8696772F4F@oracle.com>
	<51155565.9070800@cs.oswego.edu>
	<D87E31E8-A48A-4499-8BD9-300C421934A4@oracle.com>
	<CA+kOe09q5G+OX5Vu0dgM+bxAE3LRxG3qiYtwXqMDo2y+tKkVCw@mail.gmail.com>
	<CA+kOe0-1w=sqJBx-3O5Mv8jh6-rwhTZjnq0Jw6r8fhPhhFDdfA@mail.gmail.com>
	<51177C6E.1060203@oracle.com>
	<CA+kOe08CN7Sutb7f4M2qNT4z9be0ru3JLugaM1rJjrmHBptwtQ@mail.gmail.com>
Message-ID: <EAC8F489-5218-4BD8-A7D0-2191354AD720@oracle.com>

Thank you Doug, Martin, Peter and Alan for efforts your in tracking this down. Even though it's not implicated, I am going to hold off on the OpenJDK7u-dev push of 7175464 for a few days to allow for some additional testing.

Mike

On Feb 10 2013, at 19:52 , Martin Buchholz wrote:

> Alright, now that the problem (if not the solution) is well understood, I leave it to you.
> 
> Martin
> 
> On Sun, Feb 10, 2013 at 2:54 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> On 09/02/2013 23:31, Martin Buchholz wrote:
> On Sat, Feb 9, 2013 at 3:09 PM, Martin Buchholz<martinrb at google.com>  wrote:
> 
> It looks to me like Collections.reverseOrder no longer deserializes to the
> same object.  It also looks like the definition for that in
> Collections.java hasn't changed recently.  So I suspect that there has been
> some serious incompatible change to deserialization itself.
> (It's another matter whether that could break TreeSet).
> (I have long lobbied for more cross-jdk testing focused on seriallization)
> 
> The program below demonstrates the different behavior between jdk7 and
> jdk8:
> 
> 
> Oops - correction - this is not a difference between jdk7 and jdk8, but
> between jdk8 and lambda8, More specifically, lambda-8-b74 fails,
> while jdk8-b74 succeeds.  Have lambdadukes messed with serialization?
> 
> Collections.ReverseComparator's readResolve is:
> 
> 
> private Object readResolve() { return reverseOrder(); }
> 
> so I assume it's the new Comparator.reverseOrder() that is used now rather than Collections.reverseOrder() as before. Ha, this means it's returning a compator to reverse itself.
> 
> This one aside, this is another issue with serialization that has come about because of default methods and because declared methods are used in the computation of the default serial version UID. Mike and Stuart are looking into that one (I think it came up on the lambda-dev list recently).
> 
> -Alan
> 
> 
> 
> 


From paul.sandoz at oracle.com  Mon Feb 11 02:00:56 2013
From: paul.sandoz at oracle.com (paul.sandoz at oracle.com)
Date: Mon, 11 Feb 2013 10:00:56 +0000
Subject: hg: lambda/lambda/jdk: Change the split until null into a stack-based
	implementation
Message-ID: <20130211100153.0F3E64799E@hg.openjdk.java.net>

Changeset: 8cd24eef2793
Author:    psandoz
Date:      2013-02-11 11:00 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/8cd24eef2793

Change the split until null into a stack-based implementation
to avoid potential overflows, if the split returns an estimate
of 0 or trySplit return null then traverse.

! src/share/classes/java/util/stream/Streams.java
! test-ng/bootlib/java/util/stream/SpliteratorTestHelper.java


From paul.sandoz at oracle.com  Mon Feb 11 02:56:59 2013
From: paul.sandoz at oracle.com (paul.sandoz at oracle.com)
Date: Mon, 11 Feb 2013 10:56:59 +0000
Subject: hg: lambda/lambda/jdk: Remove OfPrimitive abstraction from
	Spliterator and Node.
Message-ID: <20130211105733.D408B479A0@hg.openjdk.java.net>

Changeset: 0c66562ea3f1
Author:    psandoz
Date:      2013-02-11 11:54 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/0c66562ea3f1

Remove OfPrimitive abstraction from Spliterator and Node.

! src/share/classes/java/util/Spliterator.java
! src/share/classes/java/util/stream/AbstractPipeline.java
! src/share/classes/java/util/stream/DoublePipeline.java
! src/share/classes/java/util/stream/DoubleStream.java
! src/share/classes/java/util/stream/IntPipeline.java
! src/share/classes/java/util/stream/IntStream.java
! src/share/classes/java/util/stream/LongPipeline.java
! src/share/classes/java/util/stream/LongStream.java
! src/share/classes/java/util/stream/Node.java
! src/share/classes/java/util/stream/NodeUtils.java
! src/share/classes/java/util/stream/Nodes.java
! src/share/classes/java/util/stream/SortedOp.java
! src/share/classes/java/util/stream/SpinedBuffer.java
! src/share/classes/java/util/stream/Spliterators.java
! src/share/classes/java/util/stream/StreamShape.java
! src/share/classes/java/util/stream/Streams.java
! test-ng/bootlib/java/util/stream/DoubleStreamTestData.java
! test-ng/bootlib/java/util/stream/DoubleStreamTestDataProvider.java
! test-ng/bootlib/java/util/stream/DoubleStreamTestScenario.java
! test-ng/bootlib/java/util/stream/IntStreamTestData.java
! test-ng/bootlib/java/util/stream/IntStreamTestDataProvider.java
! test-ng/bootlib/java/util/stream/IntStreamTestScenario.java
! test-ng/bootlib/java/util/stream/LongStreamTestData.java
! test-ng/bootlib/java/util/stream/LongStreamTestDataProvider.java
! test-ng/bootlib/java/util/stream/LongStreamTestScenario.java
! test-ng/bootlib/java/util/stream/SpliteratorTestHelper.java
! test-ng/boottests/java/util/stream/DoubleNodeTest.java
! test-ng/boottests/java/util/stream/IntNodeTest.java
! test-ng/boottests/java/util/stream/LongNodeTest.java
! test-ng/boottests/java/util/stream/NodeBuilderTest.java
! test-ng/boottests/java/util/stream/SpinedBufferTest.java
! test-ng/tests/org/openjdk/tests/java/util/stream/SpliteratorTest.java
! test-ng/tests/org/openjdk/tests/java/util/stream/StreamSpliteratorTest.java


From dmitry.bessonov at oracle.com  Mon Feb 11 05:10:27 2013
From: dmitry.bessonov at oracle.com (Dmitry Bessonov)
Date: Mon, 11 Feb 2013 17:10:27 +0400
Subject: minor issue: Optional.empty().orElseThrow() - no message
Message-ID: <5118EDC3.1050905@oracle.com>

Method

j.u.Optional.orElseThrow(Class<V> exceptionClass)

says

"Exception will be thrown with the message "No value present"."

However thrown exception contains no message.

The same thing with OptionalDouble, OptionalInt, OptionalLong

-Dmitry


From paul.sandoz at oracle.com  Mon Feb 11 08:52:05 2013
From: paul.sandoz at oracle.com (paul.sandoz at oracle.com)
Date: Mon, 11 Feb 2013 16:52:05 +0000
Subject: hg: lambda/lambda/jdk: 3 new changesets
Message-ID: <20130211165251.11671479A7@hg.openjdk.java.net>

Changeset: 8f502b92afb8
Author:    psandoz
Date:      2013-02-11 16:43 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/8f502b92afb8

Move StreamShape.forEachWithCancel to AbstractPipeline, and expose
with PipelineHelper.intoWrappedWithCancel.

! src/share/classes/java/util/stream/AbstractPipeline.java
! src/share/classes/java/util/stream/DoublePipeline.java
! src/share/classes/java/util/stream/IntPipeline.java
! src/share/classes/java/util/stream/LongPipeline.java
! src/share/classes/java/util/stream/Nodes.java
! src/share/classes/java/util/stream/PipelineHelper.java
! src/share/classes/java/util/stream/ReferencePipeline.java
! src/share/classes/java/util/stream/SliceOp.java
! src/share/classes/java/util/stream/StreamShape.java
! test-ng/bootlib/java/util/stream/OpTestCase.java

Changeset: 12f46813722c
Author:    psandoz
Date:      2013-02-11 17:00 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/12f46813722c

Remove StreamOp and IntermediateOp.evaluateSequential.
Move StreamShape methods to AbstractPipeline.

! src/share/classes/java/util/stream/AbstractPipeline.java
! src/share/classes/java/util/stream/DoublePipeline.java
! src/share/classes/java/util/stream/IntPipeline.java
! src/share/classes/java/util/stream/IntermediateOp.java
! src/share/classes/java/util/stream/LongPipeline.java
! src/share/classes/java/util/stream/Nodes.java
! src/share/classes/java/util/stream/ReferencePipeline.java
! src/share/classes/java/util/stream/SliceOp.java
! src/share/classes/java/util/stream/SortedOp.java
! src/share/classes/java/util/stream/StatefulOp.java
- src/share/classes/java/util/stream/StreamOp.java
! src/share/classes/java/util/stream/StreamShape.java
! src/share/classes/java/util/stream/TerminalOp.java
! test-ng/bootlib/java/util/stream/CollectorOps.java

Changeset: 7ab253f0022b
Author:    psandoz
Date:      2013-02-11 17:00 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/7ab253f0022b

Tidy up adapt methods and only use when required.

! src/share/classes/java/util/stream/DoublePipeline.java
! src/share/classes/java/util/stream/IntPipeline.java
! src/share/classes/java/util/stream/LongPipeline.java
! src/share/classes/java/util/stream/Spliterators.java


From brian.goetz at oracle.com  Mon Feb 11 13:22:09 2013
From: brian.goetz at oracle.com (brian.goetz at oracle.com)
Date: Mon, 11 Feb 2013 21:22:09 +0000
Subject: hg: lambda/lambda/jdk: Move truncate code out of Node and into
	SliceOp, its only consumer
Message-ID: <20130211212230.664A7479B4@hg.openjdk.java.net>

Changeset: 830af530db9c
Author:    briangoetz
Date:      2013-02-11 16:21 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/830af530db9c

Move truncate code out of Node and into SliceOp, its only consumer

! src/share/classes/java/util/stream/Node.java
! src/share/classes/java/util/stream/SliceOp.java


From henry.jen at oracle.com  Mon Feb 11 13:35:51 2013
From: henry.jen at oracle.com (henry.jen at oracle.com)
Date: Mon, 11 Feb 2013 21:35:51 +0000
Subject: hg: lambda/lambda/jdk: Fix a serialization regression caused by
	Comparator default method reverseOrder
Message-ID: <20130211213603.85066479B6@hg.openjdk.java.net>

Changeset: ffe9f459d921
Author:    henryjen
Date:      2013-02-11 13:35 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/ffe9f459d921

Fix a serialization regression caused by Comparator default method reverseOrder

! src/share/classes/java/util/Collections.java
! test/java/util/Collections/ReverseOrder.java


From brian.goetz at oracle.com  Mon Feb 11 14:06:06 2013
From: brian.goetz at oracle.com (Brian Goetz)
Date: Mon, 11 Feb 2013 17:06:06 -0500
Subject: Round 2 feedback
In-Reply-To: <CAAWA2oVi9dM9F6KHhyTr33uKhbBrJbjrkLSP_zM35aLwv96ajQ@mail.gmail.com>
References: <CAAWA2oUVMVhx_xaEG1vFn3ueRJ7VM=D10WV3Y+0X-+-kxjWwtw@mail.gmail.com>
	<CAAWA2oU3PEC5jHD8aqgd3VSZU+-kUgqz-ALQo0d7+S6z4Hn0RA@mail.gmail.com>
	<CAAWA2oW235ZLRF=euit3L4Xbo=i64V4+E1GyGhvx1SOzY5y-Lw@mail.gmail.com>
	<CAAWA2oVi9dM9F6KHhyTr33uKhbBrJbjrkLSP_zM35aLwv96ajQ@mail.gmail.com>
Message-ID: <51196B4E.6010606@oracle.com>

> - We use many Maps here, with many transformations. It is still painful to
> do operations like transformValues, because it usually involves using other
> lambdas and then type inference fails, still requiring specificying the
> actual type parameters - and this might require many parameters sometimes;

Can you provide some examples?  I think we've worked out most of the 
type inference failures.  Its possible we missed something, and its also 
simply possible that b76 does not have all the latest and greatest bits. 
  If you provide some examples, either we can say "works in latest" (in 
which case you're happy) or it may become the basis of a useful bug 
report.

> - At least here, even simple transformations such as
> myCollection.parallelStream().map(Functions.string()).collect(Collectors.<String>toList())
> requires the explicit types;

This compiles fine without explicit types using the tip.

> - groupingBy that returns a Map keyed by the Stream type is completely
> unintuitive. If not by the suggestion from the mailing list, I would never
> think of it as being applicable to my use case. A better name is certainly
> desirable;

groupingBy returns a Map keyed by an inferred type.  For example, if you 
want to group people by city, the map is keyed by City:

   Map<City, Collection<Person>>
      byCity = people.collect(groupingBy(Person::getCity)));

Seems intuitive to me -- what am I missing?

> - It seems odd to have collect and collectUnordered when some Collectors
> are naturally unordered, such as toSet. Can't it be changed to be a
> property of the Collector somehow?;

Still searching for the right way to present this one without 
overloading the user with the umpteen intersecting considerations 
(concurrent target vs not; ordered source vs not; ordered destination vs 
not; whether order is relevant to the user; etc etc).

For now I'll just note that cases like collecting to toSet() represent a 
small percentage of the cases when order is not relevant; we *can* 
detect this but that doesn't relieve us of the need to provide a way for 
the user to say whether he cares/doesn't care about encounter order.

> - computeIfAbsent is useful, but for most Guava cases I wanted to lambdify
> I actually needed a method that returns an Optional instead. Can it be
> added?;

You mean, if the factory function returns Optional.empty(), don't insert 
a mapping?  Just return null when you mean "don't create a mapping".

> - Here is my greatest concern so far: parallel streams in their current
> form will cause Java EE applications to fail miserably. In such
> environments, threads cannot be freely created and all types of leaks and
> exceptions can happen if one calls a method in a non-container managed
> thread. Since calling parallelStream is cheap, I guess people will do it
> often and it will be hard for Java EE developers to find out if any
> third-party Java SE 8 code is safe to call or not - and enterprise
> developers unaware of such restrictions, which are unfortunately the
> majority, will be puzzled by never seen exceptions or erratic behaviour in
> production. My suggestion would be to add a parameter to parallelStream and
> parallel which is an abstraction to thread management,  forcing people to
> think about it.

The problem is valid one, but I do not believe the proposed solution is 
the right one.  (Developers will make all the same mistakes as they 
currently make with choosing parameters like the pool size for a 
fixed-sized thread pool.  They pick a number that makes sense on their 
developer workstation, hardcode that, and then everyone is screwed when 
it hits production.)  Much better to provide the EE container with the 
tools to set these on a policy basis.  We're working with the EE folks 
to figure out what our options are.  The right answer may well be to 
fall back to sequential in some cases.

> Then one can construct a wrapper over the
> container-specific API for now and Java EE 8 can provide the standardized
> one;
> - Some throw-away Javadoc could be added, especially to Collectors, only
> with sample code for a Person class so developers can understand what
> methods are supposed to do.

Documentation?  What's that?


From paul.sandoz at oracle.com  Tue Feb 12 01:39:58 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 12 Feb 2013 10:39:58 +0100
Subject: Round 2 feedback
In-Reply-To: <51178EFC.1040909@univ-mlv.fr>
References: <CAAWA2oUVMVhx_xaEG1vFn3ueRJ7VM=D10WV3Y+0X-+-kxjWwtw@mail.gmail.com>
	<CAAWA2oU3PEC5jHD8aqgd3VSZU+-kUgqz-ALQo0d7+S6z4Hn0RA@mail.gmail.com>
	<CAAWA2oW235ZLRF=euit3L4Xbo=i64V4+E1GyGhvx1SOzY5y-Lw@mail.gmail.com>
	<CAAWA2oVi9dM9F6KHhyTr33uKhbBrJbjrkLSP_zM35aLwv96ajQ@mail.gmail.com>
	<51178EFC.1040909@univ-mlv.fr>
Message-ID: <379D98CB-9745-4CCA-8E4F-474E5EA4AC3B@oracle.com>

On Feb 10, 2013, at 1:13 PM, Remi Forax <forax at univ-mlv.fr> wrote:
>> - Here is my greatest concern so far: parallel streams in their current
>> form will cause Java EE applications to fail miserably. In such
>> environments, threads cannot be freely created and all types of leaks and
>> exceptions can happen if one calls a method in a non-container managed
>> thread. Since calling parallelStream is cheap, I guess people will do it
>> often and it will be hard for Java EE developers to find out if any
>> third-party Java SE 8 code is safe to call or not - and enterprise
>> developers unaware of such restrictions, which are unfortunately the
>> majority, will be puzzled by never seen exceptions or erratic behaviour in
>> production. My suggestion would be to add a parameter to parallelStream and
>> parallel which is an abstraction to thread management,  forcing people to
>> think about it. Then one can construct a wrapper over the
>> container-specific API for now and Java EE 8 can provide the standardized
>> one;
> 
> yes, the issue is even more complex than that when people will start to 
> use parallelStream() inside library codes because the library will work 
> in Java SE and not with Java EE.
> The real question seems to be how JEE container can support the common 
> ForkJoinPool.
> 

Currently the stream impl provides nothing special in this regard, if the current thread is an instance of ForkJoinWorkerThread the common pool will be used.

So one obvious solution is for the thread of the web app to be an instance of ForkJoinWorkerThread that holds a ForkJoinPool for the web app, but i am not sure if that is really the right solution for EE.

Paul.

From paul.sandoz at oracle.com  Tue Feb 12 01:44:03 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 12 Feb 2013 10:44:03 +0100
Subject: Round 2 feedback
In-Reply-To: <379D98CB-9745-4CCA-8E4F-474E5EA4AC3B@oracle.com>
References: <CAAWA2oUVMVhx_xaEG1vFn3ueRJ7VM=D10WV3Y+0X-+-kxjWwtw@mail.gmail.com>
	<CAAWA2oU3PEC5jHD8aqgd3VSZU+-kUgqz-ALQo0d7+S6z4Hn0RA@mail.gmail.com>
	<CAAWA2oW235ZLRF=euit3L4Xbo=i64V4+E1GyGhvx1SOzY5y-Lw@mail.gmail.com>
	<CAAWA2oVi9dM9F6KHhyTr33uKhbBrJbjrkLSP_zM35aLwv96ajQ@mail.gmail.com>
	<51178EFC.1040909@univ-mlv.fr>
	<379D98CB-9745-4CCA-8E4F-474E5EA4AC3B@oracle.com>
Message-ID: <25DDAD86-21F5-44DD-BEAF-2D28D4B92B39@oracle.com>


On Feb 12, 2013, at 10:39 AM, Paul Sandoz <Paul.Sandoz at oracle.com> wrote:

> On Feb 10, 2013, at 1:13 PM, Remi Forax <forax at univ-mlv.fr> wrote:
>>> - Here is my greatest concern so far: parallel streams in their current
>>> form will cause Java EE applications to fail miserably. In such
>>> environments, threads cannot be freely created and all types of leaks and
>>> exceptions can happen if one calls a method in a non-container managed
>>> thread. Since calling parallelStream is cheap, I guess people will do it
>>> often and it will be hard for Java EE developers to find out if any
>>> third-party Java SE 8 code is safe to call or not - and enterprise
>>> developers unaware of such restrictions, which are unfortunately the
>>> majority, will be puzzled by never seen exceptions or erratic behaviour in
>>> production. My suggestion would be to add a parameter to parallelStream and
>>> parallel which is an abstraction to thread management,  forcing people to
>>> think about it. Then one can construct a wrapper over the
>>> container-specific API for now and Java EE 8 can provide the standardized
>>> one;
>> 
>> yes, the issue is even more complex than that when people will start to 
>> use parallelStream() inside library codes because the library will work 
>> in Java SE and not with Java EE.
>> The real question seems to be how JEE container can support the common 
>> ForkJoinPool.
>> 
> 
> Currently the stream impl provides nothing special in this regard, if the current thread is an instance of ForkJoinWorkerThread the common pool will be used.

I meant to say " is *not* an instance of ForkJoinWorkerThread".

Paul.

> 
> So one obvious solution is for the thread of the web app to be an instance of ForkJoinWorkerThread that holds a ForkJoinPool for the web app, but i am not sure if that is really the right solution for EE.
> 
> Paul.
> 


From maurizio.cimadamore at oracle.com  Tue Feb 12 04:25:37 2013
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Tue, 12 Feb 2013 12:25:37 +0000
Subject: Round 2 feedback
In-Reply-To: <CAAWA2oVi9dM9F6KHhyTr33uKhbBrJbjrkLSP_zM35aLwv96ajQ@mail.gmail.com>
References: <CAAWA2oUVMVhx_xaEG1vFn3ueRJ7VM=D10WV3Y+0X-+-kxjWwtw@mail.gmail.com>
	<CAAWA2oU3PEC5jHD8aqgd3VSZU+-kUgqz-ALQo0d7+S6z4Hn0RA@mail.gmail.com>
	<CAAWA2oW235ZLRF=euit3L4Xbo=i64V4+E1GyGhvx1SOzY5y-Lw@mail.gmail.com>
	<CAAWA2oVi9dM9F6KHhyTr33uKhbBrJbjrkLSP_zM35aLwv96ajQ@mail.gmail.com>
Message-ID: <511A34C1.3000504@oracle.com>

On 10/02/13 00:34, Michael Nascimento wrote:
> - At least here, even simple transformations such as
> myCollection.parallelStream().map(Functions.string()).collect(Collectors.<String>toList())
> requires the explicit types;
b76 contains the very latest inference changes that went in lambda 
repository; so I would expect most of the inference failures to be gone 
(modulo bugs of course).

This program compiles from me (using b76):

import java.util.*;
import java.util.function.*;
import java.util.stream.*;

class Test {
     void test(Collection<Integer> myCollection) {
myCollection.parallelStream().map(Functions.string()).collect(Collectors.<String>toList());
     }
}

What is the type of your variable called 'myCollection' ? Is it possible 
we are missing something here?

Maurizio


From maurizio.cimadamore at oracle.com  Tue Feb 12 04:31:41 2013
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Tue, 12 Feb 2013 12:31:41 +0000
Subject: Round 2 feedback
In-Reply-To: <511A34C1.3000504@oracle.com>
References: <CAAWA2oUVMVhx_xaEG1vFn3ueRJ7VM=D10WV3Y+0X-+-kxjWwtw@mail.gmail.com>
	<CAAWA2oU3PEC5jHD8aqgd3VSZU+-kUgqz-ALQo0d7+S6z4Hn0RA@mail.gmail.com>
	<CAAWA2oW235ZLRF=euit3L4Xbo=i64V4+E1GyGhvx1SOzY5y-Lw@mail.gmail.com>
	<CAAWA2oVi9dM9F6KHhyTr33uKhbBrJbjrkLSP_zM35aLwv96ajQ@mail.gmail.com>
	<511A34C1.3000504@oracle.com>
Message-ID: <511A362D.70003@oracle.com>

On 12/02/13 12:25, Maurizio Cimadamore wrote:
> On 10/02/13 00:34, Michael Nascimento wrote:
>> - At least here, even simple transformations such as
>> myCollection.parallelStream().map(Functions.string()).collect(Collectors.<String>toList())
>> requires the explicit types;
> b76 contains the very latest inference changes that went in lambda
> repository; so I would expect most of the inference failures to be gone
> (modulo bugs of course).
>
> This program compiles from me (using b76):
>
> import java.util.*;
> import java.util.function.*;
> import java.util.stream.*;
>
> class Test {
>       void test(Collection<Integer> myCollection) {
> myCollection.parallelStream().map(Functions.string()).collect(Collectors.<String>toList());
>       }
> }
I meant - this compiles w/o explicit type parameters too with b76

Maurizio
>
> What is the type of your variable called 'myCollection' ? Is it possible
> we are missing something here?
>
> Maurizio
>
>


From paul.sandoz at oracle.com  Tue Feb 12 05:34:59 2013
From: paul.sandoz at oracle.com (paul.sandoz at oracle.com)
Date: Tue, 12 Feb 2013 13:34:59 +0000
Subject: hg: lambda/lambda/jdk: - fork the left child (or prefix) and compute
	with the right (or remaining).
Message-ID: <20130212133521.4A093479D7@hg.openjdk.java.net>

Changeset: add7a96e56d3
Author:    psandoz
Date:      2013-02-12 14:29 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/add7a96e56d3

- fork the left child (or prefix) and compute with the right (or remaining).
This works better for spliterators that are right balanced such as
an iterator from a spliterator, a spliterator from a ConcurrentLinkedQueue,
a spliterator from a Node that can mirror the tree of a source spliterator.
- for AbstractTask compute right children in a loop rather than recursively to avoid
potential stack overflows for right-balanced (or degenerate) trees.
Contributed-by: Doug Lea <dl at cs.oswego.edu>, Paul Sandoz <Paul.Sandoz at oracle.com>
- fix forEachUtil test to avoid potential resource issues such as OOME and
non-termination.

! src/share/classes/java/util/stream/AbstractShortCircuitTask.java
! src/share/classes/java/util/stream/AbstractTask.java
! test-ng/tests/org/openjdk/tests/java/util/stream/ForEachOpTest.java


From paul.sandoz at oracle.com  Tue Feb 12 06:18:49 2013
From: paul.sandoz at oracle.com (paul.sandoz at oracle.com)
Date: Tue, 12 Feb 2013 14:18:49 +0000
Subject: hg: lambda/lambda/jdk: Change UNIFORM to SUBSIZED,
	which is limited to uniformity of SIZE for
Message-ID: <20130212141901.E9CAE479DA@hg.openjdk.java.net>

Changeset: 9aeaf9baf327
Author:    psandoz
Date:      2013-02-12 15:02 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/9aeaf9baf327

Change UNIFORM to SUBSIZED, which is limited to uniformity of SIZE for
all splits.
Contributed-by: Doug Lea <dl at cs.oswego.edu>, Brian Goetz <brian.goetz at Oracle.COM>, Paul Sandoz <paul.sandoz at oracle.com>

! src/share/classes/java/lang/CharSequence.java
! src/share/classes/java/util/ArrayDeque.java
! src/share/classes/java/util/ArrayList.java
! src/share/classes/java/util/BitSet.java
! src/share/classes/java/util/PriorityQueue.java
! src/share/classes/java/util/Spliterator.java
! src/share/classes/java/util/concurrent/CopyOnWriteArrayList.java
! src/share/classes/java/util/concurrent/PriorityBlockingQueue.java
! src/share/classes/java/util/stream/NodeUtils.java
! src/share/classes/java/util/stream/SpinedBuffer.java
! src/share/classes/java/util/stream/Spliterators.java
! src/share/classes/java/util/stream/Streams.java
! test-ng/bootlib/java/util/stream/SpliteratorTestHelper.java
! test-ng/boottests/java/util/stream/StreamOpFlagsTest.java
! test-ng/tests/org/openjdk/tests/java/util/stream/StreamSpliteratorTest.java


From maurizio.cimadamore at oracle.com  Tue Feb 12 06:32:26 2013
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Tue, 12 Feb 2013 14:32:26 +0000
Subject: hg: lambda/lambda/langtools: 8007535: Compiler crashes on
	@FunctionalInterface used on interface with two inherited
	methods with same signatures
Message-ID: <20130212143230.DA90B479DC@hg.openjdk.java.net>

Changeset: 6b0bcbdcabf3
Author:    mcimadamore
Date:      2013-02-12 14:32 +0000
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/6b0bcbdcabf3

8007535: Compiler crashes on @FunctionalInterface used on interface with two inherited methods with same signatures

! src/share/classes/com/sun/tools/javac/code/Types.java
+ test/tools/javac/lambda/FunctionalInterfaceAnno02.java


From robert.field at oracle.com  Tue Feb 12 07:23:20 2013
From: robert.field at oracle.com (Robert Field)
Date: Tue, 12 Feb 2013 07:23:20 -0800
Subject: [8] Review request for 8004970, 8004971,
	and 8006817: implement serialization
	in lambda metafactory and metafactory fix
Message-ID: <511A5E68.4070805@oracle.com>

Please review the fixes for CRs:

       http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004970

       http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004971

       http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8006817



Webrev:

       http://cr.openjdk.java.net/~rfield/8004970

Thank,
Robert


From robert.field at oracle.com  Tue Feb 12 08:40:54 2013
From: robert.field at oracle.com (robert.field at oracle.com)
Date: Tue, 12 Feb 2013 16:40:54 +0000
Subject: hg: lambda/lambda/langtools: Separate side-effecting ClassWriter
	signature generation from lambda signature generation
Message-ID: <20130212164059.AE5F8479E0@hg.openjdk.java.net>

Changeset: 75c44a392d90
Author:    rfield
Date:      2013-02-12 08:40 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/75c44a392d90

Separate side-effecting ClassWriter signature generation from lambda signature generation

! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java
! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java


From paul.sandoz at oracle.com  Tue Feb 12 09:35:03 2013
From: paul.sandoz at oracle.com (paul.sandoz at oracle.com)
Date: Tue, 12 Feb 2013 17:35:03 +0000
Subject: hg: lambda/lambda/jdk: Update internal comment to the correct
	Spliterator
Message-ID: <20130212173606.E4660479E5@hg.openjdk.java.net>

Changeset: f40dcaab038f
Author:    psandoz
Date:      2013-02-12 18:34 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/f40dcaab038f

Update internal comment to the correct Spliterator
characteristic.

! src/share/classes/java/util/stream/StreamOpFlag.java


From dmitry.bessonov at oracle.com  Tue Feb 12 09:53:23 2013
From: dmitry.bessonov at oracle.com (Dmitry Bessonov)
Date: Tue, 12 Feb 2013 21:53:23 +0400
Subject: peek().iterator().hasNext() pre-consumes elements?
Message-ID: <511A8193.2080402@oracle.com>

Hello,

The following line prints out the first element, "1"

   Arrays.asList(1, 2, 
3).stream().peek(System.err::println).iterator().hasNext()

Is it really an expected behavior?

-Dmitry



From forax at univ-mlv.fr  Tue Feb 12 09:56:01 2013
From: forax at univ-mlv.fr (Remi Forax)
Date: Tue, 12 Feb 2013 18:56:01 +0100
Subject: peek().iterator().hasNext() pre-consumes elements?
In-Reply-To: <511A8193.2080402@oracle.com>
References: <511A8193.2080402@oracle.com>
Message-ID: <511A8231.4040509@univ-mlv.fr>

On 02/12/2013 06:53 PM, Dmitry Bessonov wrote:
> Hello,
>
> The following line prints out the first element, "1"
>
>     Arrays.asList(1, 2,
> 3).stream().peek(System.err::println).iterator().hasNext()
>
> Is it really an expected behavior?
>
> -Dmitry
>
>
>
no, it's not.

R?mi


From brian.goetz at oracle.com  Tue Feb 12 10:16:25 2013
From: brian.goetz at oracle.com (Brian Goetz)
Date: Tue, 12 Feb 2013 13:16:25 -0500
Subject: peek().iterator().hasNext() pre-consumes elements?
In-Reply-To: <511A8193.2080402@oracle.com>
References: <511A8193.2080402@oracle.com>
Message-ID: <511A86F9.6010609@oracle.com>

The answer here is complicated, but in general, calling hasNext may well 
require consuming an element -- there's often no way to know whether a 
source would produce an element without asking it to do so.  So it is a 
common practice in implementing iterators to do this (one of many 
reasons why we did not build Streams on Iterator.)

Because the elements are coming from an array, it might be possible to 
know simply based on how many elements have gone by that the stream is 
not yet exhausted.  But in the general case (such as when the stream 
source is an IO channel), it is not possible to know without actually 
consuming and buffering some input.  So I would put this in the category 
of "acceptable" behavior.  We might someday do some work to take 
advantage of the fact that the source has the SIZED characteristic and 
the pipeline stages are size-preserving to make this case behave 
"better", but that would be an implementation quality issue, not a spec 
issue.  The behavior you observe is allowable by the spec.

On 2/12/2013 12:53 PM, Dmitry Bessonov wrote:
> Hello,
>
> The following line prints out the first element, "1"
>
>     Arrays.asList(1, 2,
> 3).stream().peek(System.err::println).iterator().hasNext()
>
> Is it really an expected behavior?
>
> -Dmitry
>
>
>

From maurizio.cimadamore at oracle.com  Tue Feb 12 10:17:32 2013
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Tue, 12 Feb 2013 18:17:32 +0000
Subject: hg: lambda/lambda/langtools: More fixes:; ...
Message-ID: <20130212181738.6D51C479E9@hg.openjdk.java.net>

Changeset: dcbc4e56eeb9
Author:    mcimadamore
Date:      2013-02-12 18:17 +0000
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/dcbc4e56eeb9

More fixes:
8006763: super in method reference used in anonymous class
8006749: compiler does not allow Object protected methods to be used in lambda

! src/share/classes/com/sun/tools/javac/code/Types.java
! src/share/classes/com/sun/tools/javac/comp/Check.java
! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java
+ test/tools/javac/lambda/LambdaConv26.java
+ test/tools/javac/lambda/MethodReference61.java


From forax at univ-mlv.fr  Tue Feb 12 11:01:01 2013
From: forax at univ-mlv.fr (Remi Forax)
Date: Tue, 12 Feb 2013 20:01:01 +0100
Subject: peek().iterator().hasNext() pre-consumes elements?
In-Reply-To: <511A86F9.6010609@oracle.com>
References: <511A8193.2080402@oracle.com> <511A86F9.6010609@oracle.com>
Message-ID: <511A916D.3080005@univ-mlv.fr>

On 02/12/2013 07:16 PM, Brian Goetz wrote:
> The answer here is complicated, but in general, calling hasNext may well
> require consuming an element -- there's often no way to know whether a
> source would produce an element without asking it to do so.  So it is a
> common practice in implementing iterators to do this (one of many
> reasons why we did not build Streams on Iterator.)
>
> Because the elements are coming from an array, it might be possible to
> know simply based on how many elements have gone by that the stream is
> not yet exhausted.  But in the general case (such as when the stream
> source is an IO channel), it is not possible to know without actually
> consuming and buffering some input.  So I would put this in the category
> of "acceptable" behavior.  We might someday do some work to take
> advantage of the fact that the source has the SIZED characteristic and
> the pipeline stages are size-preserving to make this case behave
> "better", but that would be an implementation quality issue, not a spec
> issue.  The behavior you observe is allowable by the spec.

while I a stream may have to do some buffering, peek should always be 
transparent and an iterator on an array doesn't need any buffering but I 
agree that this is an implementation issue.

R?mi

>
> On 2/12/2013 12:53 PM, Dmitry Bessonov wrote:
>> Hello,
>>
>> The following line prints out the first element, "1"
>>
>>      Arrays.asList(1, 2,
>> 3).stream().peek(System.err::println).iterator().hasNext()
>>
>> Is it really an expected behavior?
>>
>> -Dmitry
>>
>>
>>


From peter.levart at gmail.com  Tue Feb 12 11:10:34 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Tue, 12 Feb 2013 20:10:34 +0100
Subject: [8] Review request for 8004970, 8004971, and 8006817: implement
	serialization in lambda metafactory and metafactory fix
In-Reply-To: <511A5E68.4070805@oracle.com>
References: <511A5E68.4070805@oracle.com>
Message-ID: <511A93AA.4090300@gmail.com>

Hi Robert,

Just a minor note on ClassLoaders.

In SerializedLambda.readResolve(), the capturingClass is resolved from 
it's name using the current thread's context ClassLoader. I don't know 
if this is the right thing to do. ObjectInputStream has it's own 
(pluggable) mechanism for resolving classes, which by default uses the 
so called "latest user defined loader" (see 
ObjectInputStream.resolveClass()). It would be better if 
SerializedLambda kept a reference to j.l.Class object representing 
capturingClass and leave to the serialization infrastructure do the 
resolving. But there is a SerializedLambda constructor that only takes a 
String, hm...

I guess other classes that are resolved inside the capturingClass' 
$deserializeLambda$ method are using the caprutingClass' class loader, 
which is ok.

Regards, Peter

On 02/12/2013 04:23 PM, Robert Field wrote:
> Please review the fixes for CRs:
>
>         http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004970
>
>         http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004971
>
>         http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8006817
>
>
>
> Webrev:
>
>         http://cr.openjdk.java.net/~rfield/8004970
>
> Thank,
> Robert
>
>


From brian.goetz at oracle.com  Tue Feb 12 11:38:44 2013
From: brian.goetz at oracle.com (brian.goetz at oracle.com)
Date: Tue, 12 Feb 2013 19:38:44 +0000
Subject: hg: lambda/lambda/jdk: More javadoc and tweaks based on review
Message-ID: <20130212193925.A0902479EC@hg.openjdk.java.net>

Changeset: 6c8b5b0b1cad
Author:    briangoetz
Date:      2013-02-12 14:38 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/6c8b5b0b1cad

More javadoc and tweaks based on review

! src/share/classes/java/util/function/Functions.java
! src/share/classes/java/util/stream/AbstractShortCircuitTask.java
! src/share/classes/java/util/stream/AbstractSpinedBuffer.java
! src/share/classes/java/util/stream/AbstractTask.java
! src/share/classes/java/util/stream/Collector.java
! src/share/classes/java/util/stream/FindOp.java
! src/share/classes/java/util/stream/FlatMapper.java
! src/share/classes/java/util/stream/Sink.java
! src/share/classes/java/util/stream/StreamShape.java
! src/share/classes/java/util/stream/Tripwire.java


From gregg at wonderly.org  Tue Feb 12 11:43:07 2013
From: gregg at wonderly.org (Gregg Wonderly)
Date: Tue, 12 Feb 2013 13:43:07 -0600
Subject: [8] Review request for 8004970, 8004971, and 8006817: implement
	serialization in lambda metafactory and metafactory fix
In-Reply-To: <511A93AA.4090300@gmail.com>
References: <511A5E68.4070805@oracle.com> <511A93AA.4090300@gmail.com>
Message-ID: <511A9B4B.2010806@wonderly.org>

The context class loader is a powerful and flexible way to allow calling code, 
to "switch out" the class loading mechanism at appropriate spots so that 
modularization inside of an application can result in the right isolation for 
the application.   I don't think that the context class loader "mechanisms" are 
always the best though, and it would be really nice to have lamda support for 
specifying a class loader to use as the context class loader, only during a 
particular call. Currently, people do things like

ClassLoader old = Thread.currentThread().getContextClassLoader();
try {
     Thread.currentThread().setContextClassLoader( someOtherLoader );
} finally {
     Thread.currentThread().setContextClassLoader( old );
}

to make the switch in and back out.  It would be nice if there was a way to wrap 
this kind of logic into a lambda expression.

Gregg Wonderly

On 2/12/2013 1:10 PM, Peter Levart wrote:
> Hi Robert,
>
> Just a minor note on ClassLoaders.
>
> In SerializedLambda.readResolve(), the capturingClass is resolved from
> it's name using the current thread's context ClassLoader. I don't know
> if this is the right thing to do. ObjectInputStream has it's own
> (pluggable) mechanism for resolving classes, which by default uses the
> so called "latest user defined loader" (see
> ObjectInputStream.resolveClass()). It would be better if
> SerializedLambda kept a reference to j.l.Class object representing
> capturingClass and leave to the serialization infrastructure do the
> resolving. But there is a SerializedLambda constructor that only takes a
> String, hm...
>
> I guess other classes that are resolved inside the capturingClass'
> $deserializeLambda$ method are using the caprutingClass' class loader,
> which is ok.
>
> Regards, Peter
>
> On 02/12/2013 04:23 PM, Robert Field wrote:
>> Please review the fixes for CRs:
>>
>>          http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004970
>>
>>          http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004971
>>
>>          http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8006817
>>
>>
>>
>> Webrev:
>>
>>          http://cr.openjdk.java.net/~rfield/8004970
>>
>> Thank,
>> Robert
>>
>>
>
>


From maurice at morninglight.co.uk  Tue Feb 12 15:26:06 2013
From: maurice at morninglight.co.uk (Maurice Naftalin)
Date: Tue, 12 Feb 2013 23:26:06 +0000
Subject: Pipeline debugging problem
Message-ID: <511ACF8E.1090805@morninglight.co.uk>

Any attempt to debug into a ReferencePipeline method using
IntelliJ 12.0.3 produces an IncompatibleClassChangeError on
b77, with the message

"Class java.lang.invoke.ConstantCallSite does not implement
   the requested interface java.util.stream.Stream
   at foo.Bar.main(Bar.java:37)"

The same programs run (not in debug mode) without problems.
Might be an IntelliJ problem, obviously.

Maurice

From mike.duigou at oracle.com  Tue Feb 12 16:36:28 2013
From: mike.duigou at oracle.com (mike.duigou at oracle.com)
Date: Wed, 13 Feb 2013 00:36:28 +0000
Subject: hg: lambda/lambda: 8006595: Use jdk/test/Makefile targets in
	preference to local definitions
Message-ID: <20130213003628.C4808479F6@hg.openjdk.java.net>

Changeset: 00b58813fc7a
Author:    mduigou
Date:      2013-02-06 11:12 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/rev/00b58813fc7a

8006595: Use jdk/test/Makefile targets in preference to local definitions
Reviewed-by: alanb

! common/makefiles/Main.gmk
! test/Makefile


From mike.duigou at oracle.com  Tue Feb 12 16:36:28 2013
From: mike.duigou at oracle.com (mike.duigou at oracle.com)
Date: Wed, 13 Feb 2013 00:36:28 +0000
Subject: hg: lambda/lambda/jdk: 3 new changesets
Message-ID: <20130213003704.AAB88479F7@hg.openjdk.java.net>

Changeset: 637022abc23c
Author:    ksrini
Date:      2013-02-10 08:49 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/637022abc23c

8007902: [unpack200] incorrect BootstrapMethods attribute
Reviewed-by: jjh

! src/share/native/com/sun/java/util/jar/pack/unpack.cpp
! test/tools/pack200/Pack200Test.java

Changeset: 162edc31d214
Author:    ksrini
Date:      2013-02-10 08:07 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/162edc31d214

8007519: [unpack200] produces bad class files when producing BootstrapMethods attribute
Reviewed-by: alanb

! test/ProblemList.txt

Changeset: a83a1ea08bb6
Author:    mduigou
Date:      2013-02-06 11:28 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/a83a1ea08bb6

8006594: Add jdk_core target to jdk/test/Makefile
Reviewed-by: alanb

! make/jprt.properties
! test/Makefile
! test/ProblemList.txt


From robert.field at oracle.com  Tue Feb 12 18:23:09 2013
From: robert.field at oracle.com (robert.field at oracle.com)
Date: Wed, 13 Feb 2013 02:23:09 +0000
Subject: hg: lambda/lambda/jdk: Changes per Brian Goetz code review comments
	(partial):
Message-ID: <20130213022341.502A547A03@hg.openjdk.java.net>

Changeset: 5866f890cf6e
Author:    rfield
Date:      2013-02-12 18:22 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/5866f890cf6e

Changes per Brian Goetz code review comments (partial):
Changed user-visible error messages from SAM to "functional interface".
In much of javadoc, changed from "SAM" to "functional interface".
Remove try-catch in readResolve.
Javadoc fixes.
In ICLM, add @throws for LambdaConversionException.
Added test for functional interface being interface.
Move consistency tests and support to AbstractValidatingLambdaMetafactory.
Collapsed overlapping normal/alt MF constructors.
Fleshed out the text of "complex bridging situation".
Remove unused and decaying MethodHandleProxyLambdaMetafactory.

! src/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java
! src/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java
! src/share/classes/java/lang/invoke/LambdaMetafactory.java
- src/share/classes/java/lang/invoke/MethodHandleProxyLambdaMetafactory.java
! src/share/classes/java/lang/invoke/SerializedLambda.java
+ test/java/lang/invoke/lambda/LambdaSerialization.java


From robert.field at oracle.com  Tue Feb 12 19:33:10 2013
From: robert.field at oracle.com (robert.field at oracle.com)
Date: Wed, 13 Feb 2013 03:33:10 +0000
Subject: hg: lambda/lambda/langtools: Add abstract general type signature
	generator to Types. Use it in lambdaToMethod and ClassWriter.
Message-ID: <20130213033315.19C4147A07@hg.openjdk.java.net>

Changeset: 6cf4a0c63a42
Author:    rfield
Date:      2013-02-12 19:32 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/6cf4a0c63a42

Add abstract general type signature generator to Types.  Use it in lambdaToMethod and ClassWriter.

! src/share/classes/com/sun/tools/javac/code/Types.java
! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java
! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java
! src/share/classes/com/sun/tools/javac/jvm/UninitializedType.java


From brian.goetz at oracle.com  Tue Feb 12 21:07:32 2013
From: brian.goetz at oracle.com (brian.goetz at oracle.com)
Date: Wed, 13 Feb 2013 05:07:32 +0000
Subject: hg: lambda/lambda/jdk: More Javadoc
Message-ID: <20130213050754.39CCC47A0D@hg.openjdk.java.net>

Changeset: 1b46fa3494eb
Author:    briangoetz
Date:      2013-02-13 00:07 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/1b46fa3494eb

More Javadoc

! src/share/classes/java/util/stream/Node.java


From paul.sandoz at oracle.com  Wed Feb 13 02:07:27 2013
From: paul.sandoz at oracle.com (paul.sandoz at oracle.com)
Date: Wed, 13 Feb 2013 10:07:27 +0000
Subject: hg: lambda/lambda/jdk: Improve documentation/spec of Node and
	NodeFactory.
Message-ID: <20130213100753.EB6B447A15@hg.openjdk.java.net>

Changeset: 9624dfb9d1ec
Author:    psandoz
Date:      2013-02-13 11:05 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/9624dfb9d1ec

Improve documentation/spec of Node and NodeFactory.

! src/share/classes/java/util/stream/Node.java
! src/share/classes/java/util/stream/NodeFactory.java
! src/share/classes/java/util/stream/Nodes.java


From paul.sandoz at oracle.com  Wed Feb 13 02:15:25 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 13 Feb 2013 11:15:25 +0100
Subject: Pipeline debugging problem
In-Reply-To: <511ACF8E.1090805@morninglight.co.uk>
References: <511ACF8E.1090805@morninglight.co.uk>
Message-ID: <1FA7E509-E2CA-4FFA-BEF9-ED8F9D7D1FF2@oracle.com>


On Feb 13, 2013, at 12:26 AM, Maurice Naftalin <maurice at morninglight.co.uk> wrote:

> Any attempt to debug into a ReferencePipeline method using
> IntelliJ 12.0.3 produces an IncompatibleClassChangeError on
> b77, with the message
> 
> "Class java.lang.invoke.ConstantCallSite does not implement
>   the requested interface java.util.stream.Stream
>   at foo.Bar.main(Bar.java:37)"
> 
> The same programs run (not in debug mode) without problems.
> Might be an IntelliJ problem, obviously.
> 

I suspect it is an issue debugging related to a lambda expressions. That class java.lang.invoke.ConstantCallSite is associated with invokedynamic instructions.

Perhaps you could try using jdb and see what that does?

Paul.

From misterm at gmail.com  Wed Feb 13 06:25:19 2013
From: misterm at gmail.com (Michael Nascimento)
Date: Wed, 13 Feb 2013 12:25:19 -0200
Subject: Round 2 feedback
In-Reply-To: <CAMUF1Sn04CwH-MBJDneycZ2TbeLLN3XUUaVGWwGiL_m6AgCx_Q@mail.gmail.com>
References: <CAAWA2oUVMVhx_xaEG1vFn3ueRJ7VM=D10WV3Y+0X-+-kxjWwtw@mail.gmail.com>
	<CAAWA2oU3PEC5jHD8aqgd3VSZU+-kUgqz-ALQo0d7+S6z4Hn0RA@mail.gmail.com>
	<CAAWA2oW235ZLRF=euit3L4Xbo=i64V4+E1GyGhvx1SOzY5y-Lw@mail.gmail.com>
	<CAAWA2oVi9dM9F6KHhyTr33uKhbBrJbjrkLSP_zM35aLwv96ajQ@mail.gmail.com>
	<CAMUF1Sn04CwH-MBJDneycZ2TbeLLN3XUUaVGWwGiL_m6AgCx_Q@mail.gmail.com>
Message-ID: <CAAWA2oUw_oeY5arwAkuKneh7d-jhpfHgKCpkXN=LoU=ucmkoHw@mail.gmail.com>

On Sat, Feb 9, 2013 at 11:41 PM, Sam Pullara <sam at sampullara.com> wrote:
> On Sat, Feb 9, 2013 at 4:34 PM, Michael Nascimento <misterm at gmail.com> wrote:
>> - We use many Maps here, with many transformations. It is still painful to
>> do operations like transformValues, because it usually involves using other
>> lambdas and then type inference fails, still requiring specificying the
>> actual type parameters - and this might require many parameters sometimes;

Ok, NetBeans is actually to blame here, sorry for that:

https://netbeans.org/bugzilla/show_bug.cgi?id=226063

>> - At least here, even simple transformations such as
>> myCollection.parallelStream().map(Functions.string()).collect(Collectors.<String>toList())
>> requires the explicit types;

Same issue as above.

>> - groupingBy that returns a Map keyed by the Stream type is completely
>> unintuitive. If not by the suggestion from the mailing list, I would never
>> think of it as being applicable to my use case. A better name is certainly
>> desirable;

Sorry again, I meant joiningWith... I wrote this without having access
to the actual code I've written...

>> - It seems odd to have collect and collectUnordered when some Collectors
>> are naturally unordered, such as toSet. Can't it be changed to be a
>> property of the Collector somehow?;
>
> I think this is something that you need to tell it for the case where
> you don't care. You might be able to optimize those cases where it is
> obvious but this mostly if you don't care about the ordering of an
> ordered one.

Please correct me if I am wrong, but the toSet collector is not
order-preserving for an ordered stream, right? That's why I think
having collectUnordered as a different method feels odd. Some
collectors are order-preserving, some are not and with some you can
choose, but I think the choice should be made as you create the
collector, not in the method call in Stream.

>> - computeIfAbsent is useful, but for most Guava cases I wanted to lambdify
>> I actually needed a method that returns an Optional instead. Can it be
>> added?;
>
> This works:
>
>         numbers.computeIfAbsent("six", (k) -> null);
>         assertFalse(numbers.containsKey("six"));
>
> From the javadoc:
>
> "If the function returns {@code null} no mapping is recorded."
>
> Is that sufficient?

No, what I want is something like:

numbers.optionalGet("six").orElse(0);

You need something this concise to use maps in lambda expressions.

Regards,
Michael

From paul.sandoz at oracle.com  Wed Feb 13 06:24:06 2013
From: paul.sandoz at oracle.com (paul.sandoz at oracle.com)
Date: Wed, 13 Feb 2013 14:24:06 +0000
Subject: hg: lambda/lambda/jdk: Updated documentation.
Message-ID: <20130213142454.EE5AB47A1D@hg.openjdk.java.net>

Changeset: 46f47f60602b
Author:    psandoz
Date:      2013-02-13 15:22 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/46f47f60602b

Updated documentation.

! src/share/classes/java/util/stream/StreamOpFlag.java


From misterm at gmail.com  Wed Feb 13 06:27:41 2013
From: misterm at gmail.com (Michael Nascimento)
Date: Wed, 13 Feb 2013 12:27:41 -0200
Subject: Round 2 feedback
In-Reply-To: <51178EFC.1040909@univ-mlv.fr>
References: <CAAWA2oUVMVhx_xaEG1vFn3ueRJ7VM=D10WV3Y+0X-+-kxjWwtw@mail.gmail.com>
	<CAAWA2oU3PEC5jHD8aqgd3VSZU+-kUgqz-ALQo0d7+S6z4Hn0RA@mail.gmail.com>
	<CAAWA2oW235ZLRF=euit3L4Xbo=i64V4+E1GyGhvx1SOzY5y-Lw@mail.gmail.com>
	<CAAWA2oVi9dM9F6KHhyTr33uKhbBrJbjrkLSP_zM35aLwv96ajQ@mail.gmail.com>
	<51178EFC.1040909@univ-mlv.fr>
Message-ID: <CAAWA2oWrmAr+3tNdrXKv2vD2CWcRJaJU7ttetJ1r1Ou=pEhV0A@mail.gmail.com>

On Sun, Feb 10, 2013 at 10:13 AM, Remi Forax <forax at univ-mlv.fr> wrote:
> Weird,
> this works for me:
>    import static java.util.stream.Collectors.*;
>
>    static class Functions {
>      static Function<Object, String> string() {
>        return Object::toString;
>      }
>    }
>
>    public static void main(String[] args) {
>      Arrays.stream(args).map(Functions.string()).collect(toList());
>    }
>

NetBeans to blame, sorry for that.

>> - Here is my greatest concern so far: parallel streams in their current
>> form will cause Java EE applications to fail miserably. In such
>> environments, threads cannot be freely created and all types of leaks and
>> exceptions can happen if one calls a method in a non-container managed
>> thread. Since calling parallelStream is cheap, I guess people will do it
>> often and it will be hard for Java EE developers to find out if any
>> third-party Java SE 8 code is safe to call or not - and enterprise
>> developers unaware of such restrictions, which are unfortunately the
>> majority, will be puzzled by never seen exceptions or erratic behaviour in
>> production. My suggestion would be to add a parameter to parallelStream and
>> parallel which is an abstraction to thread management,  forcing people to
>> think about it. Then one can construct a wrapper over the
>> container-specific API for now and Java EE 8 can provide the standardized
>> one;
>
> yes, the issue is even more complex than that when people will start to
> use parallelStream() inside library codes because the library will work
> in Java SE and not with Java EE.
> The real question seems to be how JEE container can support the common
> ForkJoinPool.

I guess if Java EE containers were willing to support threads created
somewhere else, they would have done it long ago and we wouldn't be
getting JSR-236 in Java EE 7 instead:

http://jcp.org/en/jsr/detail?id=236

Regards,
Michael

From misterm at gmail.com  Wed Feb 13 06:29:10 2013
From: misterm at gmail.com (Michael Nascimento)
Date: Wed, 13 Feb 2013 12:29:10 -0200
Subject: Round 2 feedback
In-Reply-To: <CAFn-HvsfAubpKNaU18ZGMNsJqRGbXtW5ZmVEYPQSL3gmtb_XAg@mail.gmail.com>
References: <CAAWA2oUVMVhx_xaEG1vFn3ueRJ7VM=D10WV3Y+0X-+-kxjWwtw@mail.gmail.com>
	<CAAWA2oU3PEC5jHD8aqgd3VSZU+-kUgqz-ALQo0d7+S6z4Hn0RA@mail.gmail.com>
	<CAAWA2oW235ZLRF=euit3L4Xbo=i64V4+E1GyGhvx1SOzY5y-Lw@mail.gmail.com>
	<CAAWA2oVi9dM9F6KHhyTr33uKhbBrJbjrkLSP_zM35aLwv96ajQ@mail.gmail.com>
	<CAFn-HvsfAubpKNaU18ZGMNsJqRGbXtW5ZmVEYPQSL3gmtb_XAg@mail.gmail.com>
Message-ID: <CAAWA2oV4gZAx634Zc-Mmy9AyBKXB=qeUkON05GFZsDUm9jLf3g@mail.gmail.com>

On Sun, Feb 10, 2013 at 10:42 AM, Patrick Wright <pdoubleya at gmail.com> wrote:
>> - Here is my greatest concern so far: parallel streams in their current
>> form will cause Java EE applications to fail miserably. In such
>> environments, threads cannot be freely created and all types of leaks and
>> exceptions can happen if one calls a method in a non-container managed
>> thread. Since calling parallelStream is cheap, I guess people will do it
>> often and it will be hard for Java EE developers to find out if any
>> third-party Java SE 8 code is safe to call or not - and enterprise
>> developers unaware of such restrictions, which are unfortunately the
>> majority, will be puzzled by never seen exceptions or erratic behaviour in
>> production. My suggestion would be to add a parameter to parallelStream
>> and
>> parallel which is an abstraction to thread management,  forcing people to
>> think about it. Then one can construct a wrapper over the
>> container-specific API for now and Java EE 8 can provide the standardized
>> one;
>
>
> It seems this is rather an ideal use for a Checkstyle rule or similar
> style-enforcer, e.g. to find calls to .parallelXXX and forbid them?

Well, not really since it can be in an "innocent" library somewhere or
in the future even inside the VM library code itself.

Regards,
Michael

From misterm at gmail.com  Wed Feb 13 06:35:28 2013
From: misterm at gmail.com (Michael Nascimento)
Date: Wed, 13 Feb 2013 12:35:28 -0200
Subject: Round 2 feedback
In-Reply-To: <51196B4E.6010606@oracle.com>
References: <CAAWA2oUVMVhx_xaEG1vFn3ueRJ7VM=D10WV3Y+0X-+-kxjWwtw@mail.gmail.com>
	<CAAWA2oU3PEC5jHD8aqgd3VSZU+-kUgqz-ALQo0d7+S6z4Hn0RA@mail.gmail.com>
	<CAAWA2oW235ZLRF=euit3L4Xbo=i64V4+E1GyGhvx1SOzY5y-Lw@mail.gmail.com>
	<CAAWA2oVi9dM9F6KHhyTr33uKhbBrJbjrkLSP_zM35aLwv96ajQ@mail.gmail.com>
	<51196B4E.6010606@oracle.com>
Message-ID: <CAAWA2oUDSRdqQO0pKVRarWzOVf0z91X7prM9fToyJPsOWA5fFg@mail.gmail.com>

On Mon, Feb 11, 2013 at 8:06 PM, Brian Goetz <brian.goetz at oracle.com> wrote:
>> - We use many Maps here, with many transformations. It is still painful to
>> do operations like transformValues, because it usually involves using
>> other
>> lambdas and then type inference fails, still requiring specificying the
>> actual type parameters - and this might require many parameters sometimes;
>
>
> Can you provide some examples?

NetBeans to blame, sorry for that.

>> - groupingBy that returns a Map keyed by the Stream type is completely
>> unintuitive. If not by the suggestion from the mailing list, I would never
>> think of it as being applicable to my use case. A better name is certainly
>> desirable;
>
>
> groupingBy returns a Map keyed by an inferred type.  For example, if you
> want to group people by city, the map is keyed by City:
>
>   Map<City, Collection<Person>>
>      byCity = people.collect(groupingBy(Person::getCity)));
>
> Seems intuitive to me -- what am I missing?

I meant joiningWith, sorry for the confusion.

>> - It seems odd to have collect and collectUnordered when some Collectors
>> are naturally unordered, such as toSet. Can't it be changed to be a
>> property of the Collector somehow?;
>
>
> Still searching for the right way to present this one without overloading
> the user with the umpteen intersecting considerations (concurrent target vs
> not; ordered source vs not; ordered destination vs not; whether order is
> relevant to the user; etc etc).
>
> For now I'll just note that cases like collecting to toSet() represent a
> small percentage of the cases when order is not relevant; we *can* detect
> this but that doesn't relieve us of the need to provide a way for the user
> to say whether he cares/doesn't care about encounter order.

Great to hear that.

>
>> I actually needed a method that returns an Optional instead. Can it be
>> added?;
>
>
> You mean, if the factory function returns Optional.empty(), don't insert a
> mapping?  Just return null when you mean "don't create a mapping".

No, I mean:

myMap.optionalGet(key).orElse(0);

This is the most common idiom I would use in my lambdas if it existed.

>> - Here is my greatest concern so far: parallel streams in their current
>> form will cause Java EE applications to fail miserably. In such
>> environments, threads cannot be freely created and all types of leaks and
>> exceptions can happen if one calls a method in a non-container managed
>> thread. Since calling parallelStream is cheap, I guess people will do it
>> often and it will be hard for Java EE developers to find out if any
>> third-party Java SE 8 code is safe to call or not - and enterprise
>> developers unaware of such restrictions, which are unfortunately the
>> majority, will be puzzled by never seen exceptions or erratic behaviour in
>> production. My suggestion would be to add a parameter to parallelStream
>> and
>> parallel which is an abstraction to thread management,  forcing people to
>> think about it.
>
>
> The problem is valid one, but I do not believe the proposed solution is the
> right one.  (Developers will make all the same mistakes as they currently
> make with choosing parameters like the pool size for a fixed-sized thread
> pool.  They pick a number that makes sense on their developer workstation,
> hardcode that, and then everyone is screwed when it hits production.)  Much
> better to provide the EE container with the tools to set these on a policy
> basis.  We're working with the EE folks to figure out what our options are.
> The right answer may well be to fall back to sequential in some cases.

The idea is not that developers should set parameters like this,
Brian. In fact, the API would be something like:

@Inject
@Named("myConfiguredPool")
private ForkJoinPool myConfiguredPool;

private Collection<Something> myMethod() {
   myCollection.parallelStream(myConfiguredPool).map(x ->
x.something()).collect(toList());
}

So Java EE 8 provides a way to assign one pool per module or so, as it
is expected in a multi-tenant environment.

Regards,
Michael

From pdoubleya at gmail.com  Wed Feb 13 06:47:51 2013
From: pdoubleya at gmail.com (Patrick Wright)
Date: Wed, 13 Feb 2013 15:47:51 +0100
Subject: Round 2 feedback
In-Reply-To: <CAAWA2oV4gZAx634Zc-Mmy9AyBKXB=qeUkON05GFZsDUm9jLf3g@mail.gmail.com>
References: <CAAWA2oUVMVhx_xaEG1vFn3ueRJ7VM=D10WV3Y+0X-+-kxjWwtw@mail.gmail.com>
	<CAAWA2oU3PEC5jHD8aqgd3VSZU+-kUgqz-ALQo0d7+S6z4Hn0RA@mail.gmail.com>
	<CAAWA2oW235ZLRF=euit3L4Xbo=i64V4+E1GyGhvx1SOzY5y-Lw@mail.gmail.com>
	<CAAWA2oVi9dM9F6KHhyTr33uKhbBrJbjrkLSP_zM35aLwv96ajQ@mail.gmail.com>
	<CAFn-HvsfAubpKNaU18ZGMNsJqRGbXtW5ZmVEYPQSL3gmtb_XAg@mail.gmail.com>
	<CAAWA2oV4gZAx634Zc-Mmy9AyBKXB=qeUkON05GFZsDUm9jLf3g@mail.gmail.com>
Message-ID: <CAFn-HvvUBfZzn7rYCGheKFvH-5CNR6fEjU5k1gr3ubankMjQNQ@mail.gmail.com>

As long as there are clearly defined entry points to the parallel/threaded
methods in the JDK, they can be identified by an automated process. If you
are using a framework such as JEE where using that sort of feature would be
in violation of framework contracts, then build a wrapper to sniff such
libraries out and reject them at build time. The same goes for others, like
GAE, which may have these restrictions. I don't think that methods in the
JDK should be altered to reduce the perceived risks to one part of the
community - the JEE developers - as long as there is a reasonable
workaround, especially one that can be automated.

Cheers,
Patrick


On Wed, Feb 13, 2013 at 3:29 PM, Michael Nascimento <misterm at gmail.com>wrote:

> On Sun, Feb 10, 2013 at 10:42 AM, Patrick Wright <pdoubleya at gmail.com>
> wrote:
> >> - Here is my greatest concern so far: parallel streams in their current
> >> form will cause Java EE applications to fail miserably. In such
> >> environments, threads cannot be freely created and all types of leaks
> and
> >> exceptions can happen if one calls a method in a non-container managed
> >> thread. Since calling parallelStream is cheap, I guess people will do it
> >> often and it will be hard for Java EE developers to find out if any
> >> third-party Java SE 8 code is safe to call or not - and enterprise
> >> developers unaware of such restrictions, which are unfortunately the
> >> majority, will be puzzled by never seen exceptions or erratic behaviour
> in
> >> production. My suggestion would be to add a parameter to parallelStream
> >> and
> >> parallel which is an abstraction to thread management,  forcing people
> to
> >> think about it. Then one can construct a wrapper over the
> >> container-specific API for now and Java EE 8 can provide the
> standardized
> >> one;
> >
> >
> > It seems this is rather an ideal use for a Checkstyle rule or similar
> > style-enforcer, e.g. to find calls to .parallelXXX and forbid them?
>
> Well, not really since it can be in an "innocent" library somewhere or
> in the future even inside the VM library code itself.
>
> Regards,
> Michael
>

From misterm at gmail.com  Wed Feb 13 06:50:55 2013
From: misterm at gmail.com (Michael Nascimento)
Date: Wed, 13 Feb 2013 12:50:55 -0200
Subject: Round 2 feedback
In-Reply-To: <CAFn-HvvUBfZzn7rYCGheKFvH-5CNR6fEjU5k1gr3ubankMjQNQ@mail.gmail.com>
References: <CAAWA2oUVMVhx_xaEG1vFn3ueRJ7VM=D10WV3Y+0X-+-kxjWwtw@mail.gmail.com>
	<CAAWA2oU3PEC5jHD8aqgd3VSZU+-kUgqz-ALQo0d7+S6z4Hn0RA@mail.gmail.com>
	<CAAWA2oW235ZLRF=euit3L4Xbo=i64V4+E1GyGhvx1SOzY5y-Lw@mail.gmail.com>
	<CAAWA2oVi9dM9F6KHhyTr33uKhbBrJbjrkLSP_zM35aLwv96ajQ@mail.gmail.com>
	<CAFn-HvsfAubpKNaU18ZGMNsJqRGbXtW5ZmVEYPQSL3gmtb_XAg@mail.gmail.com>
	<CAAWA2oV4gZAx634Zc-Mmy9AyBKXB=qeUkON05GFZsDUm9jLf3g@mail.gmail.com>
	<CAFn-HvvUBfZzn7rYCGheKFvH-5CNR6fEjU5k1gr3ubankMjQNQ@mail.gmail.com>
Message-ID: <CAAWA2oWBGsh=8ynvexxqsG8_K3YuhNTQ=At=MpEK7q4y=++c+A@mail.gmail.com>

On Wed, Feb 13, 2013 at 12:47 PM, Patrick Wright <pdoubleya at gmail.com> wrote:
> As long as there are clearly defined entry points to the parallel/threaded
> methods in the JDK, they can be identified by an automated process. If you
> are using a framework such as JEE where using that sort of feature would be
> in violation of framework contracts, then build a wrapper to sniff such
> libraries out and reject them at build time.

I guess the main problem is most library authors are not even going to
be aware that their shining, performant Java SE 8 code is not going to
be useful to Java EE developers anymore just because they called
parallelStream() somewhere. Having a parameter there with clear
Javadoc will make everyone aware.

Regards,
Michael

From brian.goetz at oracle.com  Wed Feb 13 06:59:11 2013
From: brian.goetz at oracle.com (Brian Goetz)
Date: Wed, 13 Feb 2013 09:59:11 -0500
Subject: Round 2 feedback
In-Reply-To: <CAAWA2oUw_oeY5arwAkuKneh7d-jhpfHgKCpkXN=LoU=ucmkoHw@mail.gmail.com>
References: <CAAWA2oUVMVhx_xaEG1vFn3ueRJ7VM=D10WV3Y+0X-+-kxjWwtw@mail.gmail.com>
	<CAAWA2oU3PEC5jHD8aqgd3VSZU+-kUgqz-ALQo0d7+S6z4Hn0RA@mail.gmail.com>
	<CAAWA2oW235ZLRF=euit3L4Xbo=i64V4+E1GyGhvx1SOzY5y-Lw@mail.gmail.com>
	<CAAWA2oVi9dM9F6KHhyTr33uKhbBrJbjrkLSP_zM35aLwv96ajQ@mail.gmail.com>
	<CAMUF1Sn04CwH-MBJDneycZ2TbeLLN3XUUaVGWwGiL_m6AgCx_Q@mail.gmail.com>
	<CAAWA2oUw_oeY5arwAkuKneh7d-jhpfHgKCpkXN=LoU=ucmkoHw@mail.gmail.com>
Message-ID: <511BAA3F.1090103@oracle.com>

>>> - groupingBy that returns a Map keyed by the Stream type is completely
>>> unintuitive. If not by the suggestion from the mailing list, I would never
>>> think of it as being applicable to my use case. A better name is certainly
>>> desirable;
>
> Sorry again, I meant joiningWith... I wrote this without having access
> to the actual code I've written...

So, the idea is you take a Stream<T> and a function T->U and you get a 
Map<T,U>.  If we had tuples, this would be stream.map(t -> (t, f(t))).

> Please correct me if I am wrong, but the toSet collector is not
> order-preserving for an ordered stream, right?

It is not order-preserving, but in a way the Stream library doesn't know 
about.

> That's why I think
> having collectUnordered as a different method feels odd.

Different sense of ordered/unordered.  More docs needed.  But 
collectUnordered is there for the cases that the library can't possibly 
figure out automatically.  Like you've provided an associative but not 
commutative combining function.  Or you just don't care about order. 
(The reason its even exposed is there are some significant optimizations 
that are possible if ordering is not a requirement.

> Some
> collectors are order-preserving, some are not and with some you can
> choose, but I think the choice should be made as you create the
> collector, not in the method call in Stream.

And that's a tiny sliver of the cases where ordering comes into play.

>> Is that sufficient?
>
> No, what I want is something like:
>
> numbers.optionalGet("six").orElse(0);
>
> You need something this concise to use maps in lambda expressions.

Can you post a more complete example?

From misterm at gmail.com  Wed Feb 13 07:19:44 2013
From: misterm at gmail.com (Michael Nascimento)
Date: Wed, 13 Feb 2013 13:19:44 -0200
Subject: Round 2 feedback
In-Reply-To: <511BAA3F.1090103@oracle.com>
References: <CAAWA2oUVMVhx_xaEG1vFn3ueRJ7VM=D10WV3Y+0X-+-kxjWwtw@mail.gmail.com>
	<CAAWA2oU3PEC5jHD8aqgd3VSZU+-kUgqz-ALQo0d7+S6z4Hn0RA@mail.gmail.com>
	<CAAWA2oW235ZLRF=euit3L4Xbo=i64V4+E1GyGhvx1SOzY5y-Lw@mail.gmail.com>
	<CAAWA2oVi9dM9F6KHhyTr33uKhbBrJbjrkLSP_zM35aLwv96ajQ@mail.gmail.com>
	<CAMUF1Sn04CwH-MBJDneycZ2TbeLLN3XUUaVGWwGiL_m6AgCx_Q@mail.gmail.com>
	<CAAWA2oUw_oeY5arwAkuKneh7d-jhpfHgKCpkXN=LoU=ucmkoHw@mail.gmail.com>
	<511BAA3F.1090103@oracle.com>
Message-ID: <CAAWA2oV1XanPcKY3f+JyjNhQdxwNt3VPsvssTU=xLOZ2Mk9AKQ@mail.gmail.com>

On Wed, Feb 13, 2013 at 12:59 PM, Brian Goetz <brian.goetz at oracle.com> wrote:
>> Sorry again, I meant joiningWith... I wrote this without having access
>> to the actual code I've written...
>
> So, the idea is you take a Stream<T> and a function T->U and you get a
> Map<T,U>.  If we had tuples, this would be stream.map(t -> (t, f(t))).

Yes, I had understood how it works already, especially given the
example provided by you in the SortedMap thread. The problem is the
method name is completely unintuitive here. And yes, I wish I had some
suggestions... :-(

>> That's why I think
>> having collectUnordered as a different method feels odd.
>
>
> Different sense of ordered/unordered.  More docs needed.  But
> collectUnordered is there for the cases that the library can't possibly
> figure out automatically.  Like you've provided an associative but not
> commutative combining function.  Or you just don't care about order. (The
> reason its even exposed is there are some significant optimizations that are
> possible if ordering is not a requirement.

I understand it is there because of optimizations and that is
precisely why I feel it is odd to allow one to call collect(toSet())
when you, the library designer, could somehow change the design so
only the most effective combination is allowed here.

>> No, what I want is something like:
>>
>> numbers.optionalGet("six").orElse(0);
>>
>> You need something this concise to use maps in lambda expressions.
>
>
> Can you post a more complete example?

Sure. Imagine you have a Set<String> representing some cities in a
business application. You call your business layer, that invokes a
query and retuns a Map<String, Long> to you, based on a query that was
run. You are going to use this map more than once; for some uses, it
matters whether the city was found in the database or not, for others,
you want non-found cities to contain zero. So to create the new Map
you will do:

Map<String, Long> totalByCityForEveryCity =
cities.stream().collectUnordered(joiningWith(city ->
totalByCity.optionalGet(city).orElse(0L));

This is the simplest case, I have others in which I need to create a
nested singleton map, for instance. This is a fairly common scenario
in this code base, which is heavily collection-based.

Hope this helps.

Regards,
Michael

From brian.goetz at oracle.com  Wed Feb 13 07:37:15 2013
From: brian.goetz at oracle.com (Brian Goetz)
Date: Wed, 13 Feb 2013 10:37:15 -0500
Subject: Round 2 feedback
In-Reply-To: <CAAWA2oV1XanPcKY3f+JyjNhQdxwNt3VPsvssTU=xLOZ2Mk9AKQ@mail.gmail.com>
References: <CAAWA2oUVMVhx_xaEG1vFn3ueRJ7VM=D10WV3Y+0X-+-kxjWwtw@mail.gmail.com>
	<CAAWA2oU3PEC5jHD8aqgd3VSZU+-kUgqz-ALQo0d7+S6z4Hn0RA@mail.gmail.com>
	<CAAWA2oW235ZLRF=euit3L4Xbo=i64V4+E1GyGhvx1SOzY5y-Lw@mail.gmail.com>
	<CAAWA2oVi9dM9F6KHhyTr33uKhbBrJbjrkLSP_zM35aLwv96ajQ@mail.gmail.com>
	<CAMUF1Sn04CwH-MBJDneycZ2TbeLLN3XUUaVGWwGiL_m6AgCx_Q@mail.gmail.com>
	<CAAWA2oUw_oeY5arwAkuKneh7d-jhpfHgKCpkXN=LoU=ucmkoHw@mail.gmail.com>
	<511BAA3F.1090103@oracle.com>
	<CAAWA2oV1XanPcKY3f+JyjNhQdxwNt3VPsvssTU=xLOZ2Mk9AKQ@mail.gmail.com>
Message-ID: <511BB32B.7000702@oracle.com>

>> So, the idea is you take a Stream<T> and a function T->U and you get a
>> Map<T,U>.  If we had tuples, this would be stream.map(t -> (t, f(t))).
>
> Yes, I had understood how it works already, especially given the
> example provided by you in the SortedMap thread. The problem is the
> method name is completely unintuitive here. And yes, I wish I had some
> suggestions... :-(

It previously was called mappingTo.

> Sure. Imagine you have a Set<String> representing some cities in a
> business application. You call your business layer, that invokes a
> query and retuns a Map<String, Long> to you, based on a query that was
> run. You are going to use this map more than once; for some uses, it
> matters whether the city was found in the database or not, for others,
> you want non-found cities to contain zero. So to create the new Map
> you will do:
>
> Map<String, Long> totalByCityForEveryCity =
> cities.stream().collectUnordered(joiningWith(city ->
> totalByCity.optionalGet(city).orElse(0L));
>
> This is the simplest case, I have others in which I need to create a
> nested singleton map, for instance. This is a fairly common scenario
> in this code base, which is heavily collection-based.
>
> Hope this helps.

So, a static method:

   static<K,V> V getOrElse(Map<K,V> m, K k, V alt) {
     return map.containsKey(k) ? map.get(k) : alt;
   }


will do what you want in the meantime?

   cities.stream().collect(joiningWith(c -> getOrElse(totalByCity, city, 
0));

(The unordered is not adding any value here.)

Can simplify by wrapping:

   Function<K,V> totalOrZero = k -> getOrElse(totalByCity, k, 0);
   cities.stream().collect(joiningWith(totalOrZero)));

From misterm at gmail.com  Wed Feb 13 07:46:39 2013
From: misterm at gmail.com (Michael Nascimento)
Date: Wed, 13 Feb 2013 13:46:39 -0200
Subject: Round 2 feedback
In-Reply-To: <511BB32B.7000702@oracle.com>
References: <CAAWA2oUVMVhx_xaEG1vFn3ueRJ7VM=D10WV3Y+0X-+-kxjWwtw@mail.gmail.com>
	<CAAWA2oU3PEC5jHD8aqgd3VSZU+-kUgqz-ALQo0d7+S6z4Hn0RA@mail.gmail.com>
	<CAAWA2oW235ZLRF=euit3L4Xbo=i64V4+E1GyGhvx1SOzY5y-Lw@mail.gmail.com>
	<CAAWA2oVi9dM9F6KHhyTr33uKhbBrJbjrkLSP_zM35aLwv96ajQ@mail.gmail.com>
	<CAMUF1Sn04CwH-MBJDneycZ2TbeLLN3XUUaVGWwGiL_m6AgCx_Q@mail.gmail.com>
	<CAAWA2oUw_oeY5arwAkuKneh7d-jhpfHgKCpkXN=LoU=ucmkoHw@mail.gmail.com>
	<511BAA3F.1090103@oracle.com>
	<CAAWA2oV1XanPcKY3f+JyjNhQdxwNt3VPsvssTU=xLOZ2Mk9AKQ@mail.gmail.com>
	<511BB32B.7000702@oracle.com>
Message-ID: <CAAWA2oXaqFxGLAzxN6bhy488M8R5GiOK5PJPwcWDUQU9jXv8HA@mail.gmail.com>

On Wed, Feb 13, 2013 at 1:37 PM, Brian Goetz <brian.goetz at oracle.com> wrote:
> It previously was called mappingTo.

Hmm, I still wouldn't be able to tell what it does, but I would take a
look at the signature and the Javadoc, so I guess it is better.

> So, a static method:
>
>   static<K,V> V getOrElse(Map<K,V> m, K k, V alt) {
>     return map.containsKey(k) ? map.get(k) : alt;
>   }
>
>
> will do what you want in the meantime?
>
>   cities.stream().collect(joiningWith(c -> getOrElse(totalByCity, city, 0));

Sure it would, but I would expect Map to have such a method now :-)
Returning an Optional makes it more generic though, I only migrated
part of the application so far, so it might be useful even in my code
base.

> (The unordered is not adding any value here.)

Even if the implementation is a LinkedHashSet?

Regards,
Michael

From gregg at wonderly.org  Wed Feb 13 07:51:48 2013
From: gregg at wonderly.org (Gregg Wonderly)
Date: Wed, 13 Feb 2013 09:51:48 -0600
Subject: Round 2 feedback
In-Reply-To: <CAAWA2oV1XanPcKY3f+JyjNhQdxwNt3VPsvssTU=xLOZ2Mk9AKQ@mail.gmail.com>
References: <CAAWA2oUVMVhx_xaEG1vFn3ueRJ7VM=D10WV3Y+0X-+-kxjWwtw@mail.gmail.com>
	<CAAWA2oU3PEC5jHD8aqgd3VSZU+-kUgqz-ALQo0d7+S6z4Hn0RA@mail.gmail.com>
	<CAAWA2oW235ZLRF=euit3L4Xbo=i64V4+E1GyGhvx1SOzY5y-Lw@mail.gmail.com>
	<CAAWA2oVi9dM9F6KHhyTr33uKhbBrJbjrkLSP_zM35aLwv96ajQ@mail.gmail.com>
	<CAMUF1Sn04CwH-MBJDneycZ2TbeLLN3XUUaVGWwGiL_m6AgCx_Q@mail.gmail.com>
	<CAAWA2oUw_oeY5arwAkuKneh7d-jhpfHgKCpkXN=LoU=ucmkoHw@mail.gmail.com>
	<511BAA3F.1090103@oracle.com>
	<CAAWA2oV1XanPcKY3f+JyjNhQdxwNt3VPsvssTU=xLOZ2Mk9AKQ@mail.gmail.com>
Message-ID: <511BB694.9000405@wonderly.org>

On 2/13/2013 9:19 AM, Michael Nascimento wrote:
> On Wed, Feb 13, 2013 at 12:59 PM, Brian Goetz <brian.goetz at oracle.com> wrote:
>>> Sorry again, I meant joiningWith... I wrote this without having access
>>> to the actual code I've written...
>> So, the idea is you take a Stream<T> and a function T->U and you get a
>> Map<T,U>.  If we had tuples, this would be stream.map(t -> (t, f(t))).
> Yes, I had understood how it works already, especially given the
> example provided by you in the SortedMap thread. The problem is the
> method name is completely unintuitive here. And yes, I wish I had some
> suggestions... :-(
>
>>> That's why I think
>>> having collectUnordered as a different method feels odd.
>>
>> Different sense of ordered/unordered.  More docs needed.  But
>> collectUnordered is there for the cases that the library can't possibly
>> figure out automatically.  Like you've provided an associative but not
>> commutative combining function.  Or you just don't care about order. (The
>> reason its even exposed is there are some significant optimizations that are
>> possible if ordering is not a requirement.
> I understand it is there because of optimizations and that is
> precisely why I feel it is odd to allow one to call collect(toSet())
> when you, the library designer, could somehow change the design so
> only the most effective combination is allowed here.
>
>>> No, what I want is something like:
>>>
>>> numbers.optionalGet("six").orElse(0);
>>>
>>> You need something this concise to use maps in lambda expressions.
>>
>> Can you post a more complete example?
> Sure. Imagine you have a Set<String> representing some cities in a
> business application. You call your business layer, that invokes a
> query and retuns a Map<String, Long> to you, based on a query that was
> run. You are going to use this map more than once; for some uses, it
> matters whether the city was found in the database or not, for others,
> you want non-found cities to contain zero. So to create the new Map
> you will do:
>
> Map<String, Long> totalByCityForEveryCity =
> cities.stream().collectUnordered(joiningWith(city ->
> totalByCity.optionalGet(city).orElse(0L));
This is similar in effect to a "left outer join" in SQL.  There are lots of good 
reasons to be able to do this, so that data is regular, and algorithms are 
plagued with missing data checks.   Being able to provide the default value, 
instead of "nul" is very nice.

Gregg Wonderly

From brian.goetz at oracle.com  Wed Feb 13 08:06:11 2013
From: brian.goetz at oracle.com (Brian Goetz)
Date: Wed, 13 Feb 2013 11:06:11 -0500
Subject: Round 2 feedback
In-Reply-To: <511BB694.9000405@wonderly.org>
References: <CAAWA2oUVMVhx_xaEG1vFn3ueRJ7VM=D10WV3Y+0X-+-kxjWwtw@mail.gmail.com>
	<CAAWA2oU3PEC5jHD8aqgd3VSZU+-kUgqz-ALQo0d7+S6z4Hn0RA@mail.gmail.com>
	<CAAWA2oW235ZLRF=euit3L4Xbo=i64V4+E1GyGhvx1SOzY5y-Lw@mail.gmail.com>
	<CAAWA2oVi9dM9F6KHhyTr33uKhbBrJbjrkLSP_zM35aLwv96ajQ@mail.gmail.com>
	<CAMUF1Sn04CwH-MBJDneycZ2TbeLLN3XUUaVGWwGiL_m6AgCx_Q@mail.gmail.com>
	<CAAWA2oUw_oeY5arwAkuKneh7d-jhpfHgKCpkXN=LoU=ucmkoHw@mail.gmail.com>
	<511BAA3F.1090103@oracle.com>
	<CAAWA2oV1XanPcKY3f+JyjNhQdxwNt3VPsvssTU=xLOZ2Mk9AKQ@mail.gmail.com>
	<511BB694.9000405@wonderly.org>
Message-ID: <511BB9F3.7020701@oracle.com>

>> Map<String, Long> totalByCityForEveryCity =
>> cities.stream().collectUnordered(joiningWith(city ->
>> totalByCity.optionalGet(city).orElse(0L));
> This is similar in effect to a "left outer join" in SQL.  There are lots
> of good reasons to be able to do this, so that data is regular, and
> algorithms are plagued with missing data checks.   Being able to provide
> the default value, instead of "nul" is very nice.

In which case a more appropriate place to put this support is in the 
joiningWith Collector, not Map.



From misterm at gmail.com  Wed Feb 13 08:08:21 2013
From: misterm at gmail.com (Michael Nascimento)
Date: Wed, 13 Feb 2013 14:08:21 -0200
Subject: Round 2 feedback
In-Reply-To: <511BB9F3.7020701@oracle.com>
References: <CAAWA2oUVMVhx_xaEG1vFn3ueRJ7VM=D10WV3Y+0X-+-kxjWwtw@mail.gmail.com>
	<CAAWA2oU3PEC5jHD8aqgd3VSZU+-kUgqz-ALQo0d7+S6z4Hn0RA@mail.gmail.com>
	<CAAWA2oW235ZLRF=euit3L4Xbo=i64V4+E1GyGhvx1SOzY5y-Lw@mail.gmail.com>
	<CAAWA2oVi9dM9F6KHhyTr33uKhbBrJbjrkLSP_zM35aLwv96ajQ@mail.gmail.com>
	<CAMUF1Sn04CwH-MBJDneycZ2TbeLLN3XUUaVGWwGiL_m6AgCx_Q@mail.gmail.com>
	<CAAWA2oUw_oeY5arwAkuKneh7d-jhpfHgKCpkXN=LoU=ucmkoHw@mail.gmail.com>
	<511BAA3F.1090103@oracle.com>
	<CAAWA2oV1XanPcKY3f+JyjNhQdxwNt3VPsvssTU=xLOZ2Mk9AKQ@mail.gmail.com>
	<511BB694.9000405@wonderly.org> <511BB9F3.7020701@oracle.com>
Message-ID: <CAAWA2oXPYUiQpVxVE0EMkyu-mqEZM8JbHm1_SLcP3LU_2eW17A@mail.gmail.com>

On Wed, Feb 13, 2013 at 2:06 PM, Brian Goetz <brian.goetz at oracle.com> wrote:
>> This is similar in effect to a "left outer join" in SQL.  There are lots
>> of good reasons to be able to do this, so that data is regular, and
>> algorithms are plagued with missing data checks.   Being able to provide
>> the default value, instead of "nul" is very nice.
>
>
> In which case a more appropriate place to put this support is in the
> joiningWith Collector, not Map.

In non-stream based code, this is still needed.

Regards,
Michael

From robert.field at oracle.com  Wed Feb 13 08:10:38 2013
From: robert.field at oracle.com (robert.field at oracle.com)
Date: Wed, 13 Feb 2013 16:10:38 +0000
Subject: hg: lambda/lambda/jdk: Change the API of SerializableLambda to
	prevent the return of a mutable array
Message-ID: <20130213161059.8451447A2A@hg.openjdk.java.net>

Changeset: 80ab2a544fcb
Author:    rfield
Date:      2013-02-13 08:10 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/80ab2a544fcb

Change the API of SerializableLambda to prevent the return of a mutable array

! src/share/classes/java/lang/invoke/LambdaMetafactory.java
! src/share/classes/java/lang/invoke/SerializedLambda.java


From robert.field at oracle.com  Wed Feb 13 08:12:12 2013
From: robert.field at oracle.com (robert.field at oracle.com)
Date: Wed, 13 Feb 2013 16:12:12 +0000
Subject: hg: lambda/lambda/langtools: javac: Adjust to the change of the API
	of SerializableLambda to prevent the return of a mutable array
Message-ID: <20130213161217.858CB47A2B@hg.openjdk.java.net>

Changeset: feb64970437d
Author:    rfield
Date:      2013-02-13 08:11 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/feb64970437d

javac: Adjust to the change of the API of SerializableLambda to prevent the return of a mutable array

! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java


From paul.sandoz at oracle.com  Wed Feb 13 09:02:35 2013
From: paul.sandoz at oracle.com (paul.sandoz at oracle.com)
Date: Wed, 13 Feb 2013 17:02:35 +0000
Subject: hg: lambda/lambda/jdk: 2 new changesets
Message-ID: <20130213170317.6B1E947A2E@hg.openjdk.java.net>

Changeset: b4aae69c6356
Author:    psandoz
Date:      2013-02-13 16:58 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/b4aae69c6356

Modify split until null test to bomb out if explicit stack reaches
a certain size in memory, that most surely indicates a bad
spliterator.

! test-ng/bootlib/java/util/stream/SpliteratorTestHelper.java

Changeset: 0c3944834879
Author:    psandoz
Date:      2013-02-13 18:02 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/0c3944834879

Automated merge with http://hg.openjdk.java.net/lambda/lambda//jdk



From paul.sandoz at oracle.com  Wed Feb 13 09:36:07 2013
From: paul.sandoz at oracle.com (paul.sandoz at oracle.com)
Date: Wed, 13 Feb 2013 17:36:07 +0000
Subject: hg: lambda/lambda/jdk: - Remove NodeFactory and have shape-based
	switching static methods
Message-ID: <20130213173629.E65DE47A33@hg.openjdk.java.net>

Changeset: a1258221db82
Author:    psandoz
Date:      2013-02-13 18:30 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/a1258221db82

- Remove NodeFactory and have shape-based switching static methods
in Nodes for emptyNode and concNode.
- Replace PipelineHelper.getNodeFactory with makeNodeBuilder
- Move private SliceOp.truncateNode to static method on Nodes.

! src/share/classes/java/util/stream/AbstractPipeline.java
! src/share/classes/java/util/stream/DoublePipeline.java
! src/share/classes/java/util/stream/IntPipeline.java
! src/share/classes/java/util/stream/LongPipeline.java
- src/share/classes/java/util/stream/NodeFactory.java
! src/share/classes/java/util/stream/Nodes.java
! src/share/classes/java/util/stream/PipelineHelper.java
! src/share/classes/java/util/stream/ReferencePipeline.java
! src/share/classes/java/util/stream/SliceOp.java


From brian.goetz at oracle.com  Wed Feb 13 13:09:18 2013
From: brian.goetz at oracle.com (brian.goetz at oracle.com)
Date: Wed, 13 Feb 2013 21:09:18 +0000
Subject: hg: lambda/lambda/jdk: More Javadoc
Message-ID: <20130213210942.CAA3C47A4A@hg.openjdk.java.net>

Changeset: d094d12b3a61
Author:    briangoetz
Date:      2013-02-13 16:08 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/d094d12b3a61

More Javadoc

! src/share/classes/java/util/stream/PipelineHelper.java
! src/share/classes/java/util/stream/Stream.java
! src/share/classes/java/util/stream/StreamOpFlag.java
! src/share/classes/java/util/stream/package-info.java


From misterm at gmail.com  Wed Feb 13 15:31:17 2013
From: misterm at gmail.com (Michael Nascimento)
Date: Wed, 13 Feb 2013 21:31:17 -0200
Subject: Another groupingReduce overload
Message-ID: <CAAWA2oULskP7tgZ1Na4eOvg0pnNH68XOkF92pf7cv+7dHZNLCw@mail.gmail.com>

Hi guys,

Guava's uniqueIndex methods are pervasive in the code base I am using
to evaluate lambda:

http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/collect/Maps.html#uniqueIndex(java.lang.Iterable,
com.google.common.base.Function)

A groupingReduce overload like this would be very handy:

    public static <T, K> Collector<T, Map<K,T>>
groupingReduce(Function<? super T, ? extends K> classifier) {
        return groupingReduce(classifier, HashMap::new,
Functions.identity(), throwingMerger());
    }

Is it possible to have it? Please? :-)

Regards,
Michael

From brian.goetz at oracle.com  Wed Feb 13 15:37:24 2013
From: brian.goetz at oracle.com (Brian Goetz)
Date: Wed, 13 Feb 2013 18:37:24 -0500
Subject: Another groupingReduce overload
In-Reply-To: <CAAWA2oULskP7tgZ1Na4eOvg0pnNH68XOkF92pf7cv+7dHZNLCw@mail.gmail.com>
References: <CAAWA2oULskP7tgZ1Na4eOvg0pnNH68XOkF92pf7cv+7dHZNLCw@mail.gmail.com>
Message-ID: <511C23B4.10200@oracle.com>

Write it!

While we regrettably cannot publish the Op APIs (to make stream 
pipelines extensible) yet, we will public Collector, and the Collectors 
we've already got are only a few lines of code each.  So you should be 
able to write this collector yourself, and have it play nicely with the 
pre-baked collectors.



On 2/13/2013 6:31 PM, Michael Nascimento wrote:
> Hi guys,
>
> Guava's uniqueIndex methods are pervasive in the code base I am using
> to evaluate lambda:
>
> http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/collect/Maps.html#uniqueIndex(java.lang.Iterable,
> com.google.common.base.Function)
>
> A groupingReduce overload like this would be very handy:
>
>      public static <T, K> Collector<T, Map<K,T>>
> groupingReduce(Function<? super T, ? extends K> classifier) {
>          return groupingReduce(classifier, HashMap::new,
> Functions.identity(), throwingMerger());
>      }
>
> Is it possible to have it? Please? :-)
>
> Regards,
> Michael
>

From misterm at gmail.com  Wed Feb 13 15:46:54 2013
From: misterm at gmail.com (Michael Nascimento)
Date: Wed, 13 Feb 2013 21:46:54 -0200
Subject: Another groupingReduce overload
In-Reply-To: <511C23B4.10200@oracle.com>
References: <CAAWA2oULskP7tgZ1Na4eOvg0pnNH68XOkF92pf7cv+7dHZNLCw@mail.gmail.com>
	<511C23B4.10200@oracle.com>
Message-ID: <CAAWA2oUTKbO=TXHm88O17aXd2gsvzFKM-75ErPbQTU+r04dGmw@mail.gmail.com>

Hi Brian,

I know I can write it myself, but the fact a method has made it into
Guava is already an evidence of wide usage. And I can tell in my code
base, it is the only groupingReduce overload I would need and I guess
it is true for many business applications as well.

If we get to the write it argument, one would only need the most
complex overloaded version. I am just trying to provide some feedback
here on what is needed in real world business projects or not. I guess
not many people are going to provide feedback if that's the answer for
every suggestion...

Regards,
Michael

On Wed, Feb 13, 2013 at 9:37 PM, Brian Goetz <brian.goetz at oracle.com> wrote:
> Write it!
>
> While we regrettably cannot publish the Op APIs (to make stream pipelines
> extensible) yet, we will public Collector, and the Collectors we've already
> got are only a few lines of code each.  So you should be able to write this
> collector yourself, and have it play nicely with the pre-baked collectors.
>
>
>
>
> On 2/13/2013 6:31 PM, Michael Nascimento wrote:
>>
>> Hi guys,
>>
>> Guava's uniqueIndex methods are pervasive in the code base I am using
>> to evaluate lambda:
>>
>>
>> http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/collect/Maps.html#uniqueIndex(java.lang.Iterable,
>> com.google.common.base.Function)
>>
>> A groupingReduce overload like this would be very handy:
>>
>>      public static <T, K> Collector<T, Map<K,T>>
>> groupingReduce(Function<? super T, ? extends K> classifier) {
>>          return groupingReduce(classifier, HashMap::new,
>> Functions.identity(), throwingMerger());
>>      }
>>
>> Is it possible to have it? Please? :-)
>>
>> Regards,
>> Michael
>>
>

From mike.duigou at oracle.com  Wed Feb 13 15:54:51 2013
From: mike.duigou at oracle.com (mike.duigou at oracle.com)
Date: Wed, 13 Feb 2013 23:54:51 +0000
Subject: hg: lambda/lambda: 8007524: build-infra: Incremental build of
	tools.jar broken
Message-ID: <20130213235451.38B0E47A5F@hg.openjdk.java.net>

Changeset: 4beaca4a3201
Author:    erikj
Date:      2013-02-05 16:50 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/rev/4beaca4a3201

8007524: build-infra: Incremental build of tools.jar broken
Reviewed-by: tbell

! common/makefiles/JavaCompilation.gmk


From brian.goetz at oracle.com  Wed Feb 13 16:25:43 2013
From: brian.goetz at oracle.com (brian.goetz at oracle.com)
Date: Thu, 14 Feb 2013 00:25:43 +0000
Subject: hg: lambda/lambda/jdk: More Javadoc
Message-ID: <20130214002601.848A847A60@hg.openjdk.java.net>

Changeset: 076eba2ba95c
Author:    briangoetz
Date:      2013-02-13 19:25 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/076eba2ba95c

More Javadoc

! src/share/classes/java/util/stream/AbstractPipeline.java
! src/share/classes/java/util/stream/IntermediateOp.java
! src/share/classes/java/util/stream/StreamShape.java


From misterm at gmail.com  Wed Feb 13 16:39:35 2013
From: misterm at gmail.com (Michael Nascimento)
Date: Wed, 13 Feb 2013 22:39:35 -0200
Subject: Efficient way of mapping T to Map<X, Double>?
Message-ID: <CAAWA2oVkB6knrKTGm5-sJOf=kvNvDqX3Z5SwXFyOVuZFeBuOHA@mail.gmail.com>

Hi guys,

What is an efficient way of, given a Stream<T>, obtain a Map<X,
Double> (notice X is not the same type as T) given T is to be
converted to the Double type by calling a method that returns double
and is to be summed?

So far what I have is:

stream.collect(groupingReduce(d -> d.getX(), d -> d.getTotal(), Double::sum));

but this results in some boxing I wish I could avoid.

Regards,
Michael

From mike.duigou at oracle.com  Wed Feb 13 17:07:46 2013
From: mike.duigou at oracle.com (mike.duigou at oracle.com)
Date: Thu, 14 Feb 2013 01:07:46 +0000
Subject: hg: lambda/lambda/jdk: sync copyrights with TL and minor javadoc
	corrections.
Message-ID: <20130214010759.53FB447A62@hg.openjdk.java.net>

Changeset: dad2ec70090f
Author:    mduigou
Date:      2013-02-13 17:07 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/dad2ec70090f

sync copyrights with TL and minor javadoc corrections.

! src/share/classes/java/util/function/BiPredicate.java
! src/share/classes/java/util/function/BinaryOperator.java
! src/share/classes/java/util/function/DoubleBinaryOperator.java
! src/share/classes/java/util/function/DoubleFunction.java
! src/share/classes/java/util/function/DoubleSupplier.java
! src/share/classes/java/util/function/DoubleUnaryOperator.java
! src/share/classes/java/util/function/Function.java
! src/share/classes/java/util/function/IntBinaryOperator.java
! src/share/classes/java/util/function/IntFunction.java
! src/share/classes/java/util/function/IntPredicate.java
! src/share/classes/java/util/function/IntSupplier.java
! src/share/classes/java/util/function/IntUnaryOperator.java
! src/share/classes/java/util/function/LongBinaryOperator.java
! src/share/classes/java/util/function/LongFunction.java
! src/share/classes/java/util/function/LongSupplier.java
! src/share/classes/java/util/function/LongUnaryOperator.java
! src/share/classes/java/util/function/Predicate.java
! src/share/classes/java/util/function/Supplier.java
! src/share/classes/java/util/function/UnaryOperator.java


From brian.goetz at oracle.com  Wed Feb 13 18:06:02 2013
From: brian.goetz at oracle.com (Brian Goetz)
Date: Wed, 13 Feb 2013 21:06:02 -0500
Subject: Efficient way of mapping T to Map<X, Double>?
In-Reply-To: <CAAWA2oVkB6knrKTGm5-sJOf=kvNvDqX3Z5SwXFyOVuZFeBuOHA@mail.gmail.com>
References: <CAAWA2oVkB6knrKTGm5-sJOf=kvNvDqX3Z5SwXFyOVuZFeBuOHA@mail.gmail.com>
Message-ID: <511C468A.3020102@oracle.com>

Take a look at what happens when you do:

   groupingBy(Foo::getKey, mapping(Foo::getAmount, toIntStatistics());

This ends up functioning as a fused map-reduce.  You might find this a 
useful model.

On 2/13/2013 7:39 PM, Michael Nascimento wrote:
> Hi guys,
>
> What is an efficient way of, given a Stream<T>, obtain a Map<X,
> Double> (notice X is not the same type as T) given T is to be
> converted to the Double type by calling a method that returns double
> and is to be summed?
>
> So far what I have is:
>
> stream.collect(groupingReduce(d -> d.getX(), d -> d.getTotal(), Double::sum));
>
> but this results in some boxing I wish I could avoid.
>
> Regards,
> Michael
>

From henry.jen at oracle.com  Wed Feb 13 18:38:52 2013
From: henry.jen at oracle.com (henry.jen at oracle.com)
Date: Thu, 14 Feb 2013 02:38:52 +0000
Subject: hg: lambda/lambda/jdk: Correct copyright years
Message-ID: <20130214023912.AB80A47A65@hg.openjdk.java.net>

Changeset: e8f0df769883
Author:    henryjen
Date:      2013-02-13 18:37 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/e8f0df769883

Correct copyright years

! src/share/classes/java/io/BufferedReader.java
! src/share/classes/java/io/UncheckedIOException.java
! src/share/classes/java/nio/file/DirectoryStream.java
! src/share/classes/java/nio/file/Files.java
! test/java/nio/file/Files/PassThroughFileSystem.java


From misterm at gmail.com  Wed Feb 13 19:19:19 2013
From: misterm at gmail.com (Michael Nascimento)
Date: Thu, 14 Feb 2013 01:19:19 -0200
Subject: Round 1 feedback
In-Reply-To: <50ED9711.30005@oracle.com>
References: <CAAWA2oWBSROv6mejwoc60=T0tOQ2WjxOJjZgkxRZHFBqP3NXwg@mail.gmail.com>
	<50ED8455.6070006@oracle.com>
	<188235E9-619C-43E8-A9C0-AA6DD581DA69@oracle.com>
	<CAAWA2oWwMcOdpHF74dK_7j7MVmmKwVciOAC3T5OQeaoReyWO3A@mail.gmail.com>
	<50ED9711.30005@oracle.com>
Message-ID: <CAAWA2oXxHo7r3KZu25XNM4y9CaYLbNVHt4bAiRsE-2vwa5fStw@mail.gmail.com>

On Wed, Jan 9, 2013 at 2:13 PM, Brian Goetz <brian.goetz at oracle.com> wrote:
> What we did in 8 is add {Map,ConcurrentMap}.computeIfAbsent.  This
> eliminates 80% of the pain of simulating a multimap with a
> Map<K,Collection<V>>.  To wit:
>
> void add(K k, V v) {
>   map.computeIfAbsent(k, ArrayList::new).add(v);
> }

Going back to this one, this doesn't work as computeIfAbsent requires
a Function whose first argument is the key :-(

Is there any chance such conversions with method references are
possible, i.e., when their arity is less than the functional interface
method arity?

Regards,
Michael

From brian.goetz at oracle.com  Wed Feb 13 20:05:58 2013
From: brian.goetz at oracle.com (Brian Goetz)
Date: Wed, 13 Feb 2013 23:05:58 -0500
Subject: Round 1 feedback
In-Reply-To: <CAAWA2oXxHo7r3KZu25XNM4y9CaYLbNVHt4bAiRsE-2vwa5fStw@mail.gmail.com>
References: <CAAWA2oWBSROv6mejwoc60=T0tOQ2WjxOJjZgkxRZHFBqP3NXwg@mail.gmail.com>
	<50ED8455.6070006@oracle.com>
	<188235E9-619C-43E8-A9C0-AA6DD581DA69@oracle.com>
	<CAAWA2oWwMcOdpHF74dK_7j7MVmmKwVciOAC3T5OQeaoReyWO3A@mail.gmail.com>
	<50ED9711.30005@oracle.com>
	<CAAWA2oXxHo7r3KZu25XNM4y9CaYLbNVHt4bAiRsE-2vwa5fStw@mail.gmail.com>
Message-ID: <511C62A6.5030304@oracle.com>

> Going back to this one, this doesn't work as computeIfAbsent requires
> a Function whose first argument is the key :-(

Ah, right; you want

   k -> new ArrayList<>()

instead.

> Is there any chance such conversions with method references are
> possible, i.e., when their arity is less than the functional interface
> method arity?

This seems harmless, but would hurt you worse in the end.  The more 
automatic adaptation we try and do here, the harder it is to do overload 
resolution correctly.

For example, if you have a function:

   foo(Supplier<List<T>>)

you can call it with

   foo(TreeSet::new)

and the compiler will eliminate all the other constructor candidates 
because it knows the target type is () -> List<T>.  (Remember, it 
doens't know which TreeSet constructor you are asking for, and there are 
more than one, so it has to do overload selection.)  If we allowed fuzzy 
matching, then its ability to prune the "obviously wrong" choices 
necessarily goes down.

So rather than try to make method ref matching magic, we just use a 
lambda, which allows you more control.


From misterm at gmail.com  Wed Feb 13 20:32:13 2013
From: misterm at gmail.com (Michael Nascimento)
Date: Thu, 14 Feb 2013 02:32:13 -0200
Subject: Round 1 feedback
In-Reply-To: <50ED9711.30005@oracle.com>
References: <CAAWA2oWBSROv6mejwoc60=T0tOQ2WjxOJjZgkxRZHFBqP3NXwg@mail.gmail.com>
	<50ED8455.6070006@oracle.com>
	<188235E9-619C-43E8-A9C0-AA6DD581DA69@oracle.com>
	<CAAWA2oWwMcOdpHF74dK_7j7MVmmKwVciOAC3T5OQeaoReyWO3A@mail.gmail.com>
	<50ED9711.30005@oracle.com>
Message-ID: <CAAWA2oXr4nsgCMOZQ5b=W5aaQxYk_a_QfXh9CUZ7bm0A7RsbQg@mail.gmail.com>

On Wed, Jan 9, 2013 at 2:13 PM, Brian Goetz <brian.goetz at oracle.com> wrote:
> What we did in 8 is add {Map,ConcurrentMap}.computeIfAbsent.  This
> eliminates 80% of the pain of simulating a multimap with a
> Map<K,Collection<V>>.  To wit:
>
> void add(K k, V v) {
>   map.computeIfAbsent(k, ArrayList::new).add(v);
> }
>
> This is only slightly worse than
>   multimap.add(k, v);
>
> and certainly way less pain than doing it today.
>
> With this tweak, I think the argument in favor of adding Multimap to the JDK
> loses about 80% of its steam.

Ok, now to a different point of the Multimap discussion. Turning this:

Collection<Foo<Bar>> values = fooBySomething.values();

into this:

Collection<Foo<Bar>> values =
fooBySomething.values().stream().<Foo<Bar>>explode((d, foos) ->
d.send(foos)).collectUnordered(toList());

is pretty ugly, isn't it? Or is there a better way?

Regards,
Michael

From howard.lovatt at gmail.com  Wed Feb 13 22:34:23 2013
From: howard.lovatt at gmail.com (Howard Lovatt)
Date: Thu, 14 Feb 2013 17:34:23 +1100
Subject: Numerical Stream code
Message-ID: <CACR_FB41DwO6HBohqAMYdH3DMnUhS=PoqKZjb0tp-8WWw1qQtQ@mail.gmail.com>

Hi,

I have been trying out lambdas on:

openjdk version "1.8.0-ea"
OpenJDK Runtime Environment (build
1.8.0-ea-lambda-nightly-h3307-20130211-b77-b00)
OpenJDK 64-Bit Server VM (build 25.0-b15, mixed mode)

To see if scientific type numerical code can use Streams. I wrote a
synthetic benchmark that applies a kernel repeatedly over time and space to
solve a diffusion equation in 1 D, e.g. heat diffusing into a metal rod
from either end. The core of the code is:

  private enum Styles implements Style {
    CLike {
      @Override public double run() {
        uM1[0] = uT0; // t = 0
        for (int xi = 1; xi < numXs - 1; xi++) { uM1[xi] = u0X; }
        uM1[numXs - 1] = uT1;
        for (int ti = 1; ti < numTs; ti++, uTemp = uM1, uM1 = u0, u0 =
uTemp) { // t > 0
          u0[0] = uT0; // x = 0
          for (int xi = 1; xi < numXs - 1; xi++) { u0[xi] =
explicitFDM.u00(uM1[xi - 1], uM1[xi], uM1[xi + 1]); } // 0 < x < 1
          u0[numXs - 1] = uT1; // x = 1
        }
        double sum = 0; // Calculate average of last us
        for (final double u : uM1) { sum += u; }
        return sum / numXs;
      }
    },

    SerialStream {
      @Override public double run() {
        Arrays.indices(uM1).forEach(this::t0);
        for (int ti = 1; ti < numTs; ti++, uTemp = uM1, uM1 = u0, u0 =
uTemp) { // t > 0
          Arrays.indices(uM1).forEach(this::tg0);
        }
        return Arrays.stream(uM1).average().getAsDouble(); // Really slow!
      }
    },

    ParallelStream {
      @Override public double run() {
        Arrays.indices(uM1).parallel().forEach(this::t0);
        for (int ti = 1; ti < numTs; ti++, uTemp = uM1, uM1 = u0, u0 =
uTemp) { // t > 0
          Arrays.indices(uM1).parallel().forEach(this::tg0);
        }
        return Arrays.stream(uM1).parallel().average().getAsDouble(); //
Really really slow!!
      }
    };

    double[] u0 = new double[numXs];
    double[] uM1 = new double[numXs];
    double[] uTemp = null;

    void t0(final int xi) {
      if (xi == 0) { uM1[0] = uT0; }
      else if (xi == numXs - 1) { uM1[numXs - 1] = uT1; }
      else { uM1[xi] = u0X; }
    }

    void tg0(final int xi) {
      if (xi == 0) { u0[0] = uT0; }
      else if (xi == numXs - 1) { u0[numXs - 1] = uT1; }
      else { u0[xi] = explicitFDM.u00(uM1[xi - 1], uM1[xi], uM1[xi + 1]); }
    }
  }

And when run it produces:

CLike: time = 2351 ms, result = 99.99581170383331
SerialStream: time = 20532 ms, result = 99.99581170383331
ParallelStream: time = 131317 ms, result = 99.99581170383331

The slowness is a pity because the coding comes out quite well!

I wasn't particularly expecting the Stream implementation to be fast,
because they are a work in progress after all. However a factor of almost
10 for the serial case and over 50 for the parallel case seems excessive. I
therefore suspect that I am doing something wrong.

Can anyone enlighten me?

Thanks,

  -- Howard.

From aruld at acm.org  Thu Feb 14 00:20:54 2013
From: aruld at acm.org (Arul Dhesiaseelan)
Date: Wed, 13 Feb 2013 22:20:54 -1000
Subject: Round 1 feedback
In-Reply-To: <CAAWA2oXr4nsgCMOZQ5b=W5aaQxYk_a_QfXh9CUZ7bm0A7RsbQg@mail.gmail.com>
References: <CAAWA2oWBSROv6mejwoc60=T0tOQ2WjxOJjZgkxRZHFBqP3NXwg@mail.gmail.com>
	<50ED8455.6070006@oracle.com>
	<188235E9-619C-43E8-A9C0-AA6DD581DA69@oracle.com>
	<CAAWA2oWwMcOdpHF74dK_7j7MVmmKwVciOAC3T5OQeaoReyWO3A@mail.gmail.com>
	<50ED9711.30005@oracle.com>
	<CAAWA2oXr4nsgCMOZQ5b=W5aaQxYk_a_QfXh9CUZ7bm0A7RsbQg@mail.gmail.com>
Message-ID: <CAKEXrxmRG0LSF80E1F4FERf61OjX-1=c_F2TNQuckzSvoS6zvw@mail.gmail.com>

With b77, you can make this pretty :-)

fooBySomething.values().stream().flatMap(Collection::stream).collectUnordered(toList());

-Arul


On Wed, Feb 13, 2013 at 6:32 PM, Michael Nascimento <misterm at gmail.com>wrote:

> On Wed, Jan 9, 2013 at 2:13 PM, Brian Goetz <brian.goetz at oracle.com>
> wrote:
> > What we did in 8 is add {Map,ConcurrentMap}.computeIfAbsent.  This
> > eliminates 80% of the pain of simulating a multimap with a
> > Map<K,Collection<V>>.  To wit:
> >
> > void add(K k, V v) {
> >   map.computeIfAbsent(k, ArrayList::new).add(v);
> > }
> >
> > This is only slightly worse than
> >   multimap.add(k, v);
> >
> > and certainly way less pain than doing it today.
> >
> > With this tweak, I think the argument in favor of adding Multimap to the
> JDK
> > loses about 80% of its steam.
>
> Ok, now to a different point of the Multimap discussion. Turning this:
>
> Collection<Foo<Bar>> values = fooBySomething.values();
>
> into this:
>
> Collection<Foo<Bar>> values =
> fooBySomething.values().stream().<Foo<Bar>>explode((d, foos) ->
> d.send(foos)).collectUnordered(toList());
>
> is pretty ugly, isn't it? Or is there a better way?
>
> Regards,
> Michael
>
>

From paul.sandoz at oracle.com  Thu Feb 14 02:31:51 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 14 Feb 2013 11:31:51 +0100
Subject: Round 1 feedback
In-Reply-To: <CAKEXrxmRG0LSF80E1F4FERf61OjX-1=c_F2TNQuckzSvoS6zvw@mail.gmail.com>
References: <CAAWA2oWBSROv6mejwoc60=T0tOQ2WjxOJjZgkxRZHFBqP3NXwg@mail.gmail.com>
	<50ED8455.6070006@oracle.com>
	<188235E9-619C-43E8-A9C0-AA6DD581DA69@oracle.com>
	<CAAWA2oWwMcOdpHF74dK_7j7MVmmKwVciOAC3T5OQeaoReyWO3A@mail.gmail.com>
	<50ED9711.30005@oracle.com>
	<CAAWA2oXr4nsgCMOZQ5b=W5aaQxYk_a_QfXh9CUZ7bm0A7RsbQg@mail.gmail.com>
	<CAKEXrxmRG0LSF80E1F4FERf61OjX-1=c_F2TNQuckzSvoS6zvw@mail.gmail.com>
Message-ID: <0BD71A39-381C-4F6C-95F1-3F3A7BC34632@oracle.com>

Here is an alternative using Collectors, which is less general than flat map but achieves the same thing for a terminal flat map->collect->toList pattern.

Not generally recommending this approach. It's useful for educational purposes but could be useful to make things more concise for certain common patterns.

Paul.

import java.util.ArrayList;
import java.util.Arrays;
import java.util.List;
import java.util.function.BiConsumer;
import java.util.function.BinaryOperator;
import java.util.function.Supplier;
import java.util.stream.Collector;

public class Test {

    public static void main(String[] args) {
        List<List<List<String>>> llls = Arrays.asList(
                Arrays.asList(
                        Arrays.asList("1-1"),
                        Arrays.asList("1-2"),
                        Arrays.asList("1-3")
                ),
                Arrays.asList(
                        Arrays.asList("2-1"),
                        Arrays.asList("2-2"),
                        Arrays.asList("2-3")
                ),
                Arrays.asList(
                        Arrays.asList("3-1"),
                        Arrays.asList("3-2"),
                        Arrays.asList("3-3")));

        List<String> ls = llls.stream().collect(toFlatList());
        // Could also do
        // List<String> ls = llls.stream().collect(ArrayList::new, (r, t) -> t.forEach(r::addAll), List::addAll);
        System.out.println(ls);
    }

    static Collector<List<List<String>>, List<String>> toFlatList() {
        return new FlatListCollector();
    }

    static class FlatListCollector implements Collector<List<List<String>>, List<String>> {
        @Override
        public Supplier<List<String>> resultSupplier() {
            return ArrayList::new;
        }

        @Override
        public BiConsumer<List<String>, List<List<String>>> accumulator() {
            return (r, t) -> t.forEach(r::addAll);
        }

        @Override
        public BinaryOperator<List<String>> combiner() {
            return (l, r)-> { l.addAll(r); return l; };
        }
    }
}

On Feb 14, 2013, at 9:20 AM, Arul Dhesiaseelan <aruld at acm.org> wrote:

> With b77, you can make this pretty :-)
> 
> fooBySomething.values().stream().flatMap(Collection::stream).collectUnordered(toList());
> 
> -Arul
> 
> 
> On Wed, Feb 13, 2013 at 6:32 PM, Michael Nascimento <misterm at gmail.com>wrote:
> 
>> On Wed, Jan 9, 2013 at 2:13 PM, Brian Goetz <brian.goetz at oracle.com>
>> wrote:
>>> What we did in 8 is add {Map,ConcurrentMap}.computeIfAbsent.  This
>>> eliminates 80% of the pain of simulating a multimap with a
>>> Map<K,Collection<V>>.  To wit:
>>> 
>>> void add(K k, V v) {
>>>  map.computeIfAbsent(k, ArrayList::new).add(v);
>>> }
>>> 
>>> This is only slightly worse than
>>>  multimap.add(k, v);
>>> 
>>> and certainly way less pain than doing it today.
>>> 
>>> With this tweak, I think the argument in favor of adding Multimap to the
>> JDK
>>> loses about 80% of its steam.
>> 
>> Ok, now to a different point of the Multimap discussion. Turning this:
>> 
>> Collection<Foo<Bar>> values = fooBySomething.values();
>> 
>> into this:
>> 
>> Collection<Foo<Bar>> values =
>> fooBySomething.values().stream().<Foo<Bar>>explode((d, foos) ->
>> d.send(foos)).collectUnordered(toList());
>> 
>> is pretty ugly, isn't it? Or is there a better way?
>> 
>> Regards,
>> Michael
>> 
>> 
> 


From jin.phd at gmail.com  Thu Feb 14 03:57:01 2013
From: jin.phd at gmail.com (Jin Mingjian)
Date: Thu, 14 Feb 2013 19:57:01 +0800
Subject: Numerical Stream code
In-Reply-To: <CACR_FB41DwO6HBohqAMYdH3DMnUhS=PoqKZjb0tp-8WWw1qQtQ@mail.gmail.com>
References: <CACR_FB41DwO6HBohqAMYdH3DMnUhS=PoqKZjb0tp-8WWw1qQtQ@mail.gmail.com>
Message-ID: <CAHrJpRrx-UsZ4-AorD3y+c-ytfGgyf14s-3ZTph8aSNXLaEDrQ@mail.gmail.com>

Hi, Howward,

the price for convenience is the performance:) The specialization version
of stream has much mitigated the stress numerical computing, I guess.
 After quickly scanning the sources, the DoubleStatistics does more things.
So, one of my suggestions is to use the direct average(like sum/length
) rather than use the default average() to see if there is some
improvement. And the benchmark is always a tricky stuff. You should warm up
your bench codes enough at least.

best regards,
Jin Mingjian


On Thu, Feb 14, 2013 at 2:34 PM, Howard Lovatt <howard.lovatt at gmail.com>wrote:

> Hi,
>
> I have been trying out lambdas on:
>
> openjdk version "1.8.0-ea"
> OpenJDK Runtime Environment (build
> 1.8.0-ea-lambda-nightly-h3307-20130211-b77-b00)
> OpenJDK 64-Bit Server VM (build 25.0-b15, mixed mode)
>
> To see if scientific type numerical code can use Streams. I wrote a
> synthetic benchmark that applies a kernel repeatedly over time and space to
> solve a diffusion equation in 1 D, e.g. heat diffusing into a metal rod
> from either end. The core of the code is:
>
>   private enum Styles implements Style {
>     CLike {
>       @Override public double run() {
>         uM1[0] = uT0; // t = 0
>         for (int xi = 1; xi < numXs - 1; xi++) { uM1[xi] = u0X; }
>         uM1[numXs - 1] = uT1;
>         for (int ti = 1; ti < numTs; ti++, uTemp = uM1, uM1 = u0, u0 =
> uTemp) { // t > 0
>           u0[0] = uT0; // x = 0
>           for (int xi = 1; xi < numXs - 1; xi++) { u0[xi] =
> explicitFDM.u00(uM1[xi - 1], uM1[xi], uM1[xi + 1]); } // 0 < x < 1
>           u0[numXs - 1] = uT1; // x = 1
>         }
>         double sum = 0; // Calculate average of last us
>         for (final double u : uM1) { sum += u; }
>         return sum / numXs;
>       }
>     },
>
>     SerialStream {
>       @Override public double run() {
>         Arrays.indices(uM1).forEach(this::t0);
>         for (int ti = 1; ti < numTs; ti++, uTemp = uM1, uM1 = u0, u0 =
> uTemp) { // t > 0
>           Arrays.indices(uM1).forEach(this::tg0);
>         }
>         return Arrays.stream(uM1).average().getAsDouble(); // Really slow!
>       }
>     },
>
>     ParallelStream {
>       @Override public double run() {
>         Arrays.indices(uM1).parallel().forEach(this::t0);
>         for (int ti = 1; ti < numTs; ti++, uTemp = uM1, uM1 = u0, u0 =
> uTemp) { // t > 0
>           Arrays.indices(uM1).parallel().forEach(this::tg0);
>         }
>         return Arrays.stream(uM1).parallel().average().getAsDouble(); //
> Really really slow!!
>       }
>     };
>
>     double[] u0 = new double[numXs];
>     double[] uM1 = new double[numXs];
>     double[] uTemp = null;
>
>     void t0(final int xi) {
>       if (xi == 0) { uM1[0] = uT0; }
>       else if (xi == numXs - 1) { uM1[numXs - 1] = uT1; }
>       else { uM1[xi] = u0X; }
>     }
>
>     void tg0(final int xi) {
>       if (xi == 0) { u0[0] = uT0; }
>       else if (xi == numXs - 1) { u0[numXs - 1] = uT1; }
>       else { u0[xi] = explicitFDM.u00(uM1[xi - 1], uM1[xi], uM1[xi + 1]); }
>     }
>   }
>
> And when run it produces:
>
> CLike: time = 2351 ms, result = 99.99581170383331
> SerialStream: time = 20532 ms, result = 99.99581170383331
> ParallelStream: time = 131317 ms, result = 99.99581170383331
>
> The slowness is a pity because the coding comes out quite well!
>
> I wasn't particularly expecting the Stream implementation to be fast,
> because they are a work in progress after all. However a factor of almost
> 10 for the serial case and over 50 for the parallel case seems excessive. I
> therefore suspect that I am doing something wrong.
>
> Can anyone enlighten me?
>
> Thanks,
>
>   -- Howard.
>
>

From maurizio.cimadamore at oracle.com  Thu Feb 14 04:17:11 2013
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Thu, 14 Feb 2013 12:17:11 +0000
Subject: hg: lambda/lambda/langtools: More fixes:; ...
Message-ID: <20130214121718.D3BB247A73@hg.openjdk.java.net>

Changeset: 89bc9300b5e5
Author:    mcimadamore
Date:      2013-02-14 12:16 +0000
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/89bc9300b5e5

More fixes:
8007285: AbstractMethodError instead of compile-time error when method reference with super and abstract
8007427: Annotation element as '_' gives compiler error instead of a warning

! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/parser/JavacParser.java
+ test/tools/javac/lambda/IdentifierTest.java
+ test/tools/javac/lambda/IdentifierTest.out
+ test/tools/javac/lambda/MethodReference62.java
+ test/tools/javac/lambda/MethodReference62.out


From paul.sandoz at oracle.com  Thu Feb 14 06:05:45 2013
From: paul.sandoz at oracle.com (paul.sandoz at oracle.com)
Date: Thu, 14 Feb 2013 14:05:45 +0000
Subject: hg: lambda/lambda/jdk: JavaDoc.
Message-ID: <20130214140608.B311247A80@hg.openjdk.java.net>

Changeset: 41511221ac77
Author:    psandoz
Date:      2013-02-14 15:05 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/41511221ac77

JavaDoc.

! src/share/classes/java/util/stream/NodeUtils.java
! src/share/classes/java/util/stream/Nodes.java
! src/share/classes/java/util/stream/PipelineHelper.java


From brian.goetz at oracle.com  Thu Feb 14 06:37:55 2013
From: brian.goetz at oracle.com (Brian Goetz)
Date: Thu, 14 Feb 2013 09:37:55 -0500
Subject: Numerical Stream code
In-Reply-To: <CACR_FB41DwO6HBohqAMYdH3DMnUhS=PoqKZjb0tp-8WWw1qQtQ@mail.gmail.com>
References: <CACR_FB41DwO6HBohqAMYdH3DMnUhS=PoqKZjb0tp-8WWw1qQtQ@mail.gmail.com>
Message-ID: <511CF6C3.8000709@oracle.com>

Some things here:

seq stream vs c-style: You've manually inlined to() in your C style 
version, whereas you're dispatching through a lambda in the stream 
version.  Not quite a fair comparison now, is it?  (Though the VM will 
probably still at this time have an easier time inlining through the C 
version of a fairer comparison.)

average() is doing a lot more work (~4x) than just averaging.  See the 
source code.

The parallel version is almost certainly suffering false cache line 
sharing when adjacent tasks are writing to the shared arrays u0, etc. 
Nothing to do with streams, just a standard parallelism gotcha.



On 2/14/2013 1:34 AM, Howard Lovatt wrote:
> Hi,
>
> I have been trying out lambdas on:
>
> openjdk version "1.8.0-ea"
> OpenJDK Runtime Environment (build
> 1.8.0-ea-lambda-nightly-h3307-20130211-b77-b00)
> OpenJDK 64-Bit Server VM (build 25.0-b15, mixed mode)
>
> To see if scientific type numerical code can use Streams. I wrote a
> synthetic benchmark that applies a kernel repeatedly over time and space to
> solve a diffusion equation in 1 D, e.g. heat diffusing into a metal rod
> from either end. The core of the code is:
>
>    private enum Styles implements Style {
>      CLike {
>        @Override public double run() {
>          uM1[0] = uT0; // t = 0
>          for (int xi = 1; xi < numXs - 1; xi++) { uM1[xi] = u0X; }
>          uM1[numXs - 1] = uT1;
>          for (int ti = 1; ti < numTs; ti++, uTemp = uM1, uM1 = u0, u0 =
> uTemp) { // t > 0
>            u0[0] = uT0; // x = 0
>            for (int xi = 1; xi < numXs - 1; xi++) { u0[xi] =
> explicitFDM.u00(uM1[xi - 1], uM1[xi], uM1[xi + 1]); } // 0 < x < 1
>            u0[numXs - 1] = uT1; // x = 1
>          }
>          double sum = 0; // Calculate average of last us
>          for (final double u : uM1) { sum += u; }
>          return sum / numXs;
>        }
>      },
>
>      SerialStream {
>        @Override public double run() {
>          Arrays.indices(uM1).forEach(this::t0);
>          for (int ti = 1; ti < numTs; ti++, uTemp = uM1, uM1 = u0, u0 =
> uTemp) { // t > 0
>            Arrays.indices(uM1).forEach(this::tg0);
>          }
>          return Arrays.stream(uM1).average().getAsDouble(); // Really slow!
>        }
>      },
>
>      ParallelStream {
>        @Override public double run() {
>          Arrays.indices(uM1).parallel().forEach(this::t0);
>          for (int ti = 1; ti < numTs; ti++, uTemp = uM1, uM1 = u0, u0 =
> uTemp) { // t > 0
>            Arrays.indices(uM1).parallel().forEach(this::tg0);
>          }
>          return Arrays.stream(uM1).parallel().average().getAsDouble(); //
> Really really slow!!
>        }
>      };
>
>      double[] u0 = new double[numXs];
>      double[] uM1 = new double[numXs];
>      double[] uTemp = null;
>
>      void t0(final int xi) {
>        if (xi == 0) { uM1[0] = uT0; }
>        else if (xi == numXs - 1) { uM1[numXs - 1] = uT1; }
>        else { uM1[xi] = u0X; }
>      }
>
>      void tg0(final int xi) {
>        if (xi == 0) { u0[0] = uT0; }
>        else if (xi == numXs - 1) { u0[numXs - 1] = uT1; }
>        else { u0[xi] = explicitFDM.u00(uM1[xi - 1], uM1[xi], uM1[xi + 1]); }
>      }
>    }
>
> And when run it produces:
>
> CLike: time = 2351 ms, result = 99.99581170383331
> SerialStream: time = 20532 ms, result = 99.99581170383331
> ParallelStream: time = 131317 ms, result = 99.99581170383331
>
> The slowness is a pity because the coding comes out quite well!
>
> I wasn't particularly expecting the Stream implementation to be fast,
> because they are a work in progress after all. However a factor of almost
> 10 for the serial case and over 50 for the parallel case seems excessive. I
> therefore suspect that I am doing something wrong.
>
> Can anyone enlighten me?
>
> Thanks,
>
>    -- Howard.
>

From dmitry.bessonov at oracle.com  Thu Feb 14 06:38:55 2013
From: dmitry.bessonov at oracle.com (Dmitry Bessonov)
Date: Thu, 14 Feb 2013 18:38:55 +0400
Subject: bumped into a compiler NPE when replaced lambda with an anonymous
	class
Message-ID: <511CF6FF.8020701@oracle.com>

Attempt to compile with b77 a minimized (to some extent) code:

--------------------------------------------------------------
public class CompilerError {

     public static void main(String[] args) {
         Bar bar = a -> a.aMethod((ClassB) () -> new ClassB() {
             public void bMethod() {
             }
         });
     }

     public static interface Bar {
         void barMethod(ClassA a);
     }

     public interface ClassA {
         public void aMethod(Object t);
     }

     public interface ClassB {
         public void bMethod();
     }

}
--------------------------------------------------------------

leads to

java.lang.NullPointerException
         at com.sun.tools.javac.jvm.Code.emitop0(Code.java:538)
         at com.sun.tools.javac.jvm.Items$SelfItem.load(Items.java:367)
         at com.sun.tools.javac.jvm.Gen.genArgs(Gen.java:912)
         at com.sun.tools.javac.jvm.Gen.visitNewClass(Gen.java:1831)
         at 
com.sun.tools.javac.tree.JCTree$JCNewClass.accept(JCTree.java:1491)
         at com.sun.tools.javac.jvm.Gen.genExpr(Gen.java:893)
         at com.sun.tools.javac.jvm.Gen.visitExec(Gen.java:1697)
         at 
com.sun.tools.javac.tree.JCTree$JCExpressionStatement.accept(JCTree.java:1271)
         at com.sun.tools.javac.jvm.Gen.genDef(Gen.java:683)
         at com.sun.tools.javac.jvm.Gen.genStat(Gen.java:718)
         at com.sun.tools.javac.jvm.Gen.genStat(Gen.java:704)
         at com.sun.tools.javac.jvm.Gen.genStats(Gen.java:755)
         at com.sun.tools.javac.jvm.Gen.visitBlock(Gen.java:1093)
         at com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:884)
         at com.sun.tools.javac.jvm.Gen.genDef(Gen.java:683)
         at com.sun.tools.javac.jvm.Gen.genStat(Gen.java:718)
         at com.sun.tools.javac.jvm.Gen.genMethod(Gen.java:968)
         at com.sun.tools.javac.jvm.Gen.visitMethodDef(Gen.java:941)
         at 
com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(JCTree.java:771)
         at com.sun.tools.javac.jvm.Gen.genDef(Gen.java:683)
         at com.sun.tools.javac.jvm.Gen.genClass(Gen.java:2355)
         at 
com.sun.tools.javac.main.JavaCompiler.genCode(JavaCompiler.java:751)
         at 
com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1545)
         at 
com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1509)
         at 
com.sun.tools.javac.main.JavaCompiler.compile2(JavaCompiler.java:907)
         at 
com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:866)
         at com.sun.tools.javac.main.Main.compile(Main.java:505)
         at com.sun.tools.javac.main.Main.compile(Main.java:365)
         at com.sun.tools.javac.main.Main.compile(Main.java:354)
         at com.sun.tools.javac.main.Main.compile(Main.java:345)
         at com.sun.tools.javac.Main.compile(Main.java:76)
         at com.sun.tools.javac.Main.main(Main.java:61)


-Dmitry


From paul.sandoz at oracle.com  Thu Feb 14 06:43:18 2013
From: paul.sandoz at oracle.com (paul.sandoz at oracle.com)
Date: Thu, 14 Feb 2013 14:43:18 +0000
Subject: hg: lambda/lambda/jdk: Rename UniqOp to DistinctOp.
Message-ID: <20130214144339.3859847A83@hg.openjdk.java.net>

Changeset: d2982a5d8327
Author:    psandoz
Date:      2013-02-14 15:42 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/d2982a5d8327

Rename UniqOp to DistinctOp.

+ src/share/classes/java/util/stream/DistinctOp.java
! src/share/classes/java/util/stream/ReferencePipeline.java
- src/share/classes/java/util/stream/UniqOp.java


From brian.goetz at oracle.com  Thu Feb 14 06:45:10 2013
From: brian.goetz at oracle.com (Brian Goetz)
Date: Thu, 14 Feb 2013 09:45:10 -0500
Subject: Numerical Stream code
In-Reply-To: <511CF6C3.8000709@oracle.com>
References: <CACR_FB41DwO6HBohqAMYdH3DMnUhS=PoqKZjb0tp-8WWw1qQtQ@mail.gmail.com>
	<511CF6C3.8000709@oracle.com>
Message-ID: <511CF876.1000003@oracle.com>

> The parallel version is almost certainly suffering false cache line
> sharing when adjacent tasks are writing to the shared arrays u0, etc.
> Nothing to do with streams, just a standard parallelism gotcha.

Cure: don't write to shared arrays from parallel tasks.


From maurizio.cimadamore at oracle.com  Thu Feb 14 06:57:07 2013
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Thu, 14 Feb 2013 14:57:07 +0000
Subject: bumped into a compiler NPE when replaced lambda with an anonymous
	class
In-Reply-To: <511CF6FF.8020701@oracle.com>
References: <511CF6FF.8020701@oracle.com>
Message-ID: <511CFB43.6060309@oracle.com>

This will do:

class CompilerError {

      public static void main(String[] args) {
          SAM s = ()-> { SAM s2 = ()->{ new Object() { }; }; };
      }

      interface SAM {
          void m();
      }
}


 From the stack trace it looks like the the translator is missing that 
the anon class occurs in a static context and therefore no 'enclosing 
this' should be added.

Maurizio

On 14/02/13 14:38, Dmitry Bessonov wrote:
> class CompilerError {
>
>       public static void main(String[] args) {
>           Bar bar = a -> a.aMethod((ClassB) () -> new ClassB() {
>               public void bMethod() {
>               }
>           });
>       }
>
>       public static interface Bar {
>           void barMethod(ClassA a);
>       }
>
>       public interface ClassA {
>           public void aMethod(Object t);
>       }
>
>       public interface ClassB {
>           public void bMethod();
>       }
>
> }


From peter.levart at gmail.com  Thu Feb 14 07:56:45 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 14 Feb 2013 16:56:45 +0100
Subject: Numerical Stream code
In-Reply-To: <511CF876.1000003@oracle.com>
References: <CACR_FB41DwO6HBohqAMYdH3DMnUhS=PoqKZjb0tp-8WWw1qQtQ@mail.gmail.com>
	<511CF6C3.8000709@oracle.com> <511CF876.1000003@oracle.com>
Message-ID: <511D093D.5010608@gmail.com>

On 02/14/2013 03:45 PM, Brian Goetz wrote:
>> The parallel version is almost certainly suffering false cache line
>> sharing when adjacent tasks are writing to the shared arrays u0, etc.
>> Nothing to do with streams, just a standard parallelism gotcha.
> Cure: don't write to shared arrays from parallel tasks.
>
>
Hi,

I would like to discuss this a little bit (hence the cc: 
concurrency-interest - the conversation can continue on this list only).

Is it really important to avoid writing to shared arrays from multiple 
threads (of course without synchronization, not even volatile 
writes/reads) when indexes are not shared (each thread writes/reads it's 
own disjunct subset).

Do element sizes matter (byte vs. short vs. int  vs. long)?

I had a (false?) feeling that cache lines are not invalidated when 
writes are performed without fences.

Also I don't know how short (byte, char) writes are combined into memory 
words on the hardware when they come from different cores and whether 
this is connected to any performance issues.

Thanks,

Peter


From brian.goetz at oracle.com  Thu Feb 14 08:06:04 2013
From: brian.goetz at oracle.com (Brian Goetz)
Date: Thu, 14 Feb 2013 11:06:04 -0500
Subject: Numerical Stream code
In-Reply-To: <511D093D.5010608@gmail.com>
References: <CACR_FB41DwO6HBohqAMYdH3DMnUhS=PoqKZjb0tp-8WWw1qQtQ@mail.gmail.com>
	<511CF6C3.8000709@oracle.com> <511CF876.1000003@oracle.com>
	<511D093D.5010608@gmail.com>
Message-ID: <511D0B6C.6080408@oracle.com>

As with all things, the answer is ... it depends.

But, this code, where each task is reading and writing from a shared 
array, is at high risk for "cache-line ping-pong".  Especially because 
the first thing each thread does is write to the first and last element 
of its chunk.  If the partitions don't perfectly line up with cache line 
boundaries, now you've got two threads both wanting to write to the same 
cache line.  Which works, but is slow.  Slower than sequential, usually.

Bottom line, you need to think about locality when writing code like 
this.  "Don't write to shared arrays" is simply an approximation for 
"let the library think about locality for you."

On 2/14/2013 10:56 AM, Peter Levart wrote:
> On 02/14/2013 03:45 PM, Brian Goetz wrote:
>>> The parallel version is almost certainly suffering false cache line
>>> sharing when adjacent tasks are writing to the shared arrays u0, etc.
>>> Nothing to do with streams, just a standard parallelism gotcha.
>> Cure: don't write to shared arrays from parallel tasks.
>>
>>
> Hi,
>
> I would like to discuss this a little bit (hence the cc:
> concurrency-interest - the conversation can continue on this list only).
>
> Is it really important to avoid writing to shared arrays from multiple
> threads (of course without synchronization, not even volatile
> writes/reads) when indexes are not shared (each thread writes/reads it's
> own disjunct subset).
>
> Do element sizes matter (byte vs. short vs. int  vs. long)?
>
> I had a (false?) feeling that cache lines are not invalidated when
> writes are performed without fences.
>
> Also I don't know how short (byte, char) writes are combined into memory
> words on the hardware when they come from different cores and whether
> this is connected to any performance issues.
>
> Thanks,
>
> Peter
>
>

From brian.goetz at oracle.com  Thu Feb 14 08:24:52 2013
From: brian.goetz at oracle.com (brian.goetz at oracle.com)
Date: Thu, 14 Feb 2013 16:24:52 +0000
Subject: hg: lambda/lambda/jdk: Doc typos.
Message-ID: <20130214162513.D23FE47A8F@hg.openjdk.java.net>

Changeset: 9335085d6529
Author:    briangoetz
Date:      2013-02-14 11:24 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/9335085d6529

Doc typos.
Contributed-by: david.holmes at oracle.com

! src/share/classes/java/util/stream/StreamOpFlag.java


From benjamin.john.evans at gmail.com  Thu Feb 14 08:29:58 2013
From: benjamin.john.evans at gmail.com (Ben Evans)
Date: Thu, 14 Feb 2013 16:29:58 +0000
Subject: Compiler crash (& first draft of a Regex patch)
Message-ID: <CABKW8RinKwSfwRLJz6WT4m8uvpcpLwotMvLwUxZQgz_==fFz=A@mail.gmail.com>

Hi,

This block of code, when added to java.util.regex.Pattern, causes an
NPE in the compiler:

    public Predicate<String> asPredicate(){
        return s -> this.matcher(s).find();
    }

    public <T extends CharSequence> Stream<CharSequence>
splitAsStream(T input) {
		class CharSeqIterator implements Iterator<CharSequence> {
			int cur = 0; // Position in the input string
			Matcher curMatcher = null;

	        public boolean hasNext() {
				// true iff we match on the remaining substring
				if (curMatcher == null)
					curMatcher = Pattern.this.matcher(input.subSequence(cur, input.length()));
				return curMatcher.find();
	        }

	        public CharSequence next() {
	            if (hasNext()) {
					CharSequence tmpCs = input.subSequence(cur, curMatcher.start() - 1);
					cur = curMatcher.end();
					curMatcher = null;
	                return tmpCs;
				} else {
	                throw new NoSuchElementException();		
				}
	        }

	        public void forEach(java.util.function.Block<? super
CharSequence> block) {
				while (cur < input.length()) {
	                block.accept(next());
	            }
	        }
		}
	
		return Streams.stream(() -> Streams.spliteratorUnknownSize(new
CharSeqIterator()), StreamOpFlag.IS_ORDERED);
    }

An exception has occurred in the compiler (1.8.0-internal). Please
file a bug at the Java Developer Connection
(http://java.sun.com/webapps/bugreport)  after checking the Bug Parade
for duplicates. Include your program and the following diagnostic in
your report.  Thank you.
java.lang.NullPointerException
	at com.sun.tools.javac.jvm.Code.emitop0(Code.java:540)
	at com.sun.tools.javac.jvm.Items$LocalItem.load(Items.java:397)
	at com.sun.tools.javac.jvm.Gen.genArgs(Gen.java:911)
	at com.sun.tools.javac.jvm.Gen.visitNewClass(Gen.java:1788)
	at com.sun.tools.javac.tree.JCTree$JCNewClass.accept(JCTree.java:1462)
	at com.sun.tools.javac.jvm.Gen.genExpr(Gen.java:892)
	at com.sun.tools.javac.jvm.Gen.genArgs(Gen.java:911)
	at com.sun.tools.javac.jvm.Gen.visitApply(Gen.java:1745)
	at com.sun.tools.javac.tree.JCTree$JCMethodInvocation.accept(JCTree.java:1410)
	at com.sun.tools.javac.jvm.Gen.genExpr(Gen.java:892)
	at com.sun.tools.javac.jvm.Gen.visitReturn(Gen.java:1714)
	at com.sun.tools.javac.tree.JCTree$JCReturn.accept(JCTree.java:1328)
	at com.sun.tools.javac.jvm.Gen.genDef(Gen.java:682)
	at com.sun.tools.javac.jvm.Gen.genStat(Gen.java:717)
	at com.sun.tools.javac.jvm.Gen.genStat(Gen.java:703)
	at com.sun.tools.javac.jvm.Gen.genStats(Gen.java:754)
	at com.sun.tools.javac.jvm.Gen.visitBlock(Gen.java:1089)
	at com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:852)
	at com.sun.tools.javac.jvm.Gen.genDef(Gen.java:682)
	at com.sun.tools.javac.jvm.Gen.genStat(Gen.java:717)
	at com.sun.tools.javac.jvm.Gen.genMethod(Gen.java:967)
	at com.sun.tools.javac.jvm.Gen.visitMethodDef(Gen.java:940)
	at com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(JCTree.java:736)
	at com.sun.tools.javac.jvm.Gen.genDef(Gen.java:682)
	at com.sun.tools.javac.jvm.Gen.genClass(Gen.java:2309)
	at com.sun.tools.javac.main.JavaCompiler.genCode(JavaCompiler.java:752)
	at com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1522)
	at com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1486)
	at com.sun.tools.javac.main.JavaCompiler.compile2(JavaCompiler.java:908)
	at com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:867)
	at com.sun.tools.javac.main.Main.compile(Main.java:482)
	at com.sun.tools.javac.main.Main.compile(Main.java:363)
	at com.sun.tools.javac.main.Main.compile(Main.java:352)
	at com.sun.tools.javac.main.Main.compile(Main.java:343)
	at com.sun.tools.javac.Main.compile(Main.java:76)
	at com.sun.tools.javac.Main.main(Main.java:61)

Comments on the approach I'm taking in the patch also very welcome. I
haven't actually got this to build successfully yet, so haven't been
able to test it.

Thanks,

Ben

From maurizio.cimadamore at oracle.com  Thu Feb 14 08:42:49 2013
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Thu, 14 Feb 2013 16:42:49 +0000
Subject: Compiler crash (& first draft of a Regex patch)
In-Reply-To: <CABKW8RinKwSfwRLJz6WT4m8uvpcpLwotMvLwUxZQgz_==fFz=A@mail.gmail.com>
References: <CABKW8RinKwSfwRLJz6WT4m8uvpcpLwotMvLwUxZQgz_==fFz=A@mail.gmail.com>
Message-ID: <511D1409.9030407@oracle.com>

I'm 99% sure that this is is caused by the local inner class that you 
define and then use inside the lambda. This is a known problem.

Thanks for the report.

Maurizio

On 14/02/13 16:29, Ben Evans wrote:
> Hi,
>
> This block of code, when added to java.util.regex.Pattern, causes an
> NPE in the compiler:
>
>      public Predicate<String> asPredicate(){
>          return s -> this.matcher(s).find();
>      }
>
>      public <T extends CharSequence> Stream<CharSequence>
> splitAsStream(T input) {
> 		class CharSeqIterator implements Iterator<CharSequence> {
> 			int cur = 0; // Position in the input string
> 			Matcher curMatcher = null;
>
> 	        public boolean hasNext() {
> 				// true iff we match on the remaining substring
> 				if (curMatcher == null)
> 					curMatcher = Pattern.this.matcher(input.subSequence(cur, input.length()));
> 				return curMatcher.find();
> 	        }
>
> 	        public CharSequence next() {
> 	            if (hasNext()) {
> 					CharSequence tmpCs = input.subSequence(cur, curMatcher.start() - 1);
> 					cur = curMatcher.end();
> 					curMatcher = null;
> 	                return tmpCs;
> 				} else {
> 	                throw new NoSuchElementException();		
> 				}
> 	        }
>
> 	        public void forEach(java.util.function.Block<? super
> CharSequence> block) {
> 				while (cur < input.length()) {
> 	                block.accept(next());
> 	            }
> 	        }
> 		}
> 	
> 		return Streams.stream(() -> Streams.spliteratorUnknownSize(new
> CharSeqIterator()), StreamOpFlag.IS_ORDERED);
>      }
>
> An exception has occurred in the compiler (1.8.0-internal). Please
> file a bug at the Java Developer Connection
> (http://java.sun.com/webapps/bugreport)  after checking the Bug Parade
> for duplicates. Include your program and the following diagnostic in
> your report.  Thank you.
> java.lang.NullPointerException
> 	at com.sun.tools.javac.jvm.Code.emitop0(Code.java:540)
> 	at com.sun.tools.javac.jvm.Items$LocalItem.load(Items.java:397)
> 	at com.sun.tools.javac.jvm.Gen.genArgs(Gen.java:911)
> 	at com.sun.tools.javac.jvm.Gen.visitNewClass(Gen.java:1788)
> 	at com.sun.tools.javac.tree.JCTree$JCNewClass.accept(JCTree.java:1462)
> 	at com.sun.tools.javac.jvm.Gen.genExpr(Gen.java:892)
> 	at com.sun.tools.javac.jvm.Gen.genArgs(Gen.java:911)
> 	at com.sun.tools.javac.jvm.Gen.visitApply(Gen.java:1745)
> 	at com.sun.tools.javac.tree.JCTree$JCMethodInvocation.accept(JCTree.java:1410)
> 	at com.sun.tools.javac.jvm.Gen.genExpr(Gen.java:892)
> 	at com.sun.tools.javac.jvm.Gen.visitReturn(Gen.java:1714)
> 	at com.sun.tools.javac.tree.JCTree$JCReturn.accept(JCTree.java:1328)
> 	at com.sun.tools.javac.jvm.Gen.genDef(Gen.java:682)
> 	at com.sun.tools.javac.jvm.Gen.genStat(Gen.java:717)
> 	at com.sun.tools.javac.jvm.Gen.genStat(Gen.java:703)
> 	at com.sun.tools.javac.jvm.Gen.genStats(Gen.java:754)
> 	at com.sun.tools.javac.jvm.Gen.visitBlock(Gen.java:1089)
> 	at com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:852)
> 	at com.sun.tools.javac.jvm.Gen.genDef(Gen.java:682)
> 	at com.sun.tools.javac.jvm.Gen.genStat(Gen.java:717)
> 	at com.sun.tools.javac.jvm.Gen.genMethod(Gen.java:967)
> 	at com.sun.tools.javac.jvm.Gen.visitMethodDef(Gen.java:940)
> 	at com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(JCTree.java:736)
> 	at com.sun.tools.javac.jvm.Gen.genDef(Gen.java:682)
> 	at com.sun.tools.javac.jvm.Gen.genClass(Gen.java:2309)
> 	at com.sun.tools.javac.main.JavaCompiler.genCode(JavaCompiler.java:752)
> 	at com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1522)
> 	at com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1486)
> 	at com.sun.tools.javac.main.JavaCompiler.compile2(JavaCompiler.java:908)
> 	at com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:867)
> 	at com.sun.tools.javac.main.Main.compile(Main.java:482)
> 	at com.sun.tools.javac.main.Main.compile(Main.java:363)
> 	at com.sun.tools.javac.main.Main.compile(Main.java:352)
> 	at com.sun.tools.javac.main.Main.compile(Main.java:343)
> 	at com.sun.tools.javac.Main.compile(Main.java:76)
> 	at com.sun.tools.javac.Main.main(Main.java:61)
>
> Comments on the approach I'm taking in the patch also very welcome. I
> haven't actually got this to build successfully yet, so haven't been
> able to test it.
>
> Thanks,
>
> Ben
>


From brian.goetz at oracle.com  Thu Feb 14 08:56:01 2013
From: brian.goetz at oracle.com (Brian Goetz)
Date: Thu, 14 Feb 2013 11:56:01 -0500
Subject: Compiler crash (& first draft of a Regex patch)
In-Reply-To: <CABKW8RinKwSfwRLJz6WT4m8uvpcpLwotMvLwUxZQgz_==fFz=A@mail.gmail.com>
References: <CABKW8RinKwSfwRLJz6WT4m8uvpcpLwotMvLwUxZQgz_==fFz=A@mail.gmail.com>
Message-ID: <511D1721.9000807@oracle.com>

On our list to fix :)  It happens when you try and capture local 
classes.  The workaround is to refactor the local class to a private 
class outside the method.

On 2/14/2013 11:29 AM, Ben Evans wrote:
> Hi,
>
> This block of code, when added to java.util.regex.Pattern, causes an
> NPE in the compiler:
>
>      public Predicate<String> asPredicate(){
>          return s -> this.matcher(s).find();
>      }
>
>      public <T extends CharSequence> Stream<CharSequence>
> splitAsStream(T input) {
> 		class CharSeqIterator implements Iterator<CharSequence> {
> 			int cur = 0; // Position in the input string
> 			Matcher curMatcher = null;
>
> 	        public boolean hasNext() {
> 				// true iff we match on the remaining substring
> 				if (curMatcher == null)
> 					curMatcher = Pattern.this.matcher(input.subSequence(cur, input.length()));
> 				return curMatcher.find();
> 	        }
>
> 	        public CharSequence next() {
> 	            if (hasNext()) {
> 					CharSequence tmpCs = input.subSequence(cur, curMatcher.start() - 1);
> 					cur = curMatcher.end();
> 					curMatcher = null;
> 	                return tmpCs;
> 				} else {
> 	                throw new NoSuchElementException();		
> 				}
> 	        }
>
> 	        public void forEach(java.util.function.Block<? super
> CharSequence> block) {
> 				while (cur < input.length()) {
> 	                block.accept(next());
> 	            }
> 	        }
> 		}
> 	
> 		return Streams.stream(() -> Streams.spliteratorUnknownSize(new
> CharSeqIterator()), StreamOpFlag.IS_ORDERED);
>      }
>
> An exception has occurred in the compiler (1.8.0-internal). Please
> file a bug at the Java Developer Connection
> (http://java.sun.com/webapps/bugreport)  after checking the Bug Parade
> for duplicates. Include your program and the following diagnostic in
> your report.  Thank you.
> java.lang.NullPointerException
> 	at com.sun.tools.javac.jvm.Code.emitop0(Code.java:540)
> 	at com.sun.tools.javac.jvm.Items$LocalItem.load(Items.java:397)
> 	at com.sun.tools.javac.jvm.Gen.genArgs(Gen.java:911)
> 	at com.sun.tools.javac.jvm.Gen.visitNewClass(Gen.java:1788)
> 	at com.sun.tools.javac.tree.JCTree$JCNewClass.accept(JCTree.java:1462)
> 	at com.sun.tools.javac.jvm.Gen.genExpr(Gen.java:892)
> 	at com.sun.tools.javac.jvm.Gen.genArgs(Gen.java:911)
> 	at com.sun.tools.javac.jvm.Gen.visitApply(Gen.java:1745)
> 	at com.sun.tools.javac.tree.JCTree$JCMethodInvocation.accept(JCTree.java:1410)
> 	at com.sun.tools.javac.jvm.Gen.genExpr(Gen.java:892)
> 	at com.sun.tools.javac.jvm.Gen.visitReturn(Gen.java:1714)
> 	at com.sun.tools.javac.tree.JCTree$JCReturn.accept(JCTree.java:1328)
> 	at com.sun.tools.javac.jvm.Gen.genDef(Gen.java:682)
> 	at com.sun.tools.javac.jvm.Gen.genStat(Gen.java:717)
> 	at com.sun.tools.javac.jvm.Gen.genStat(Gen.java:703)
> 	at com.sun.tools.javac.jvm.Gen.genStats(Gen.java:754)
> 	at com.sun.tools.javac.jvm.Gen.visitBlock(Gen.java:1089)
> 	at com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:852)
> 	at com.sun.tools.javac.jvm.Gen.genDef(Gen.java:682)
> 	at com.sun.tools.javac.jvm.Gen.genStat(Gen.java:717)
> 	at com.sun.tools.javac.jvm.Gen.genMethod(Gen.java:967)
> 	at com.sun.tools.javac.jvm.Gen.visitMethodDef(Gen.java:940)
> 	at com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(JCTree.java:736)
> 	at com.sun.tools.javac.jvm.Gen.genDef(Gen.java:682)
> 	at com.sun.tools.javac.jvm.Gen.genClass(Gen.java:2309)
> 	at com.sun.tools.javac.main.JavaCompiler.genCode(JavaCompiler.java:752)
> 	at com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1522)
> 	at com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1486)
> 	at com.sun.tools.javac.main.JavaCompiler.compile2(JavaCompiler.java:908)
> 	at com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:867)
> 	at com.sun.tools.javac.main.Main.compile(Main.java:482)
> 	at com.sun.tools.javac.main.Main.compile(Main.java:363)
> 	at com.sun.tools.javac.main.Main.compile(Main.java:352)
> 	at com.sun.tools.javac.main.Main.compile(Main.java:343)
> 	at com.sun.tools.javac.Main.compile(Main.java:76)
> 	at com.sun.tools.javac.Main.main(Main.java:61)
>
> Comments on the approach I'm taking in the patch also very welcome. I
> haven't actually got this to build successfully yet, so haven't been
> able to test it.
>
> Thanks,
>
> Ben
>

From maurizio.cimadamore at oracle.com  Thu Feb 14 09:29:44 2013
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Thu, 14 Feb 2013 17:29:44 +0000
Subject: bumped into a compiler NPE when replaced lambda with an anonymous
	class
In-Reply-To: <511CFB43.6060309@oracle.com>
References: <511CF6FF.8020701@oracle.com> <511CFB43.6060309@oracle.com>
Message-ID: <511D1F08.9040107@oracle.com>

On 14/02/13 14:57, Maurizio Cimadamore wrote:
> This will do:
>
> class CompilerError {
>
>        public static void main(String[] args) {
>            SAM s = ()-> { SAM s2 = ()->{ new Object() { }; }; };
>        }
>
>        interface SAM {
>            void m();
>        }
> }
Fixed in tip

Maurizio
>
>
>   From the stack trace it looks like the the translator is missing that
> the anon class occurs in a static context and therefore no 'enclosing
> this' should be added.
>
> Maurizio
>
> On 14/02/13 14:38, Dmitry Bessonov wrote:
>> class CompilerError {
>>
>>        public static void main(String[] args) {
>>            Bar bar = a -> a.aMethod((ClassB) () -> new ClassB() {
>>                public void bMethod() {
>>                }
>>            });
>>        }
>>
>>        public static interface Bar {
>>            void barMethod(ClassA a);
>>        }
>>
>>        public interface ClassA {
>>            public void aMethod(Object t);
>>        }
>>
>>        public interface ClassB {
>>            public void bMethod();
>>        }
>>
>> }
>


From maurizio.cimadamore at oracle.com  Thu Feb 14 09:29:21 2013
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Thu, 14 Feb 2013 17:29:21 +0000
Subject: hg: lambda/lambda/langtools: 8008227: Mixing lambdas with anonymous
	classes leads to NPE thrown by compiler
Message-ID: <20130214172934.7094947A92@hg.openjdk.java.net>

Changeset: dae2aede7f35
Author:    mcimadamore
Date:      2013-02-14 17:28 +0000
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/dae2aede7f35

8008227: Mixing lambdas with anonymous classes leads to NPE thrown by compiler

! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java
+ test/tools/javac/lambda/LambdaConv27.java


From mike.duigou at oracle.com  Thu Feb 14 12:27:22 2013
From: mike.duigou at oracle.com (mike.duigou at oracle.com)
Date: Thu, 14 Feb 2013 20:27:22 +0000
Subject: hg: lambda/lambda/jdk: many javadoc nit updates
Message-ID: <20130214202734.8152E47A9B@hg.openjdk.java.net>

Changeset: 381122300995
Author:    mduigou
Date:      2013-02-14 12:27 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/381122300995

many javadoc nit updates

! src/share/classes/java/util/function/BiConsumer.java
! src/share/classes/java/util/function/BiFunction.java
! src/share/classes/java/util/function/BiPredicate.java
! src/share/classes/java/util/function/BinaryOperator.java
! src/share/classes/java/util/function/Consumer.java
! src/share/classes/java/util/function/DoubleBinaryOperator.java
! src/share/classes/java/util/function/DoubleFunction.java
! src/share/classes/java/util/function/DoublePredicate.java
! src/share/classes/java/util/function/Function.java
! src/share/classes/java/util/function/IntFunction.java
! src/share/classes/java/util/function/IntPredicate.java
! src/share/classes/java/util/function/IntUnaryOperator.java
! src/share/classes/java/util/function/LongFunction.java
! src/share/classes/java/util/function/LongPredicate.java
! src/share/classes/java/util/function/ObjDoubleConsumer.java
! src/share/classes/java/util/function/ObjIntConsumer.java
! src/share/classes/java/util/function/ObjLongConsumer.java
! src/share/classes/java/util/function/Predicate.java
! src/share/classes/java/util/function/ToDoubleBiFunction.java
! src/share/classes/java/util/function/ToDoubleFunction.java
! src/share/classes/java/util/function/UnaryOperator.java


From brian.goetz at oracle.com  Thu Feb 14 12:47:37 2013
From: brian.goetz at oracle.com (brian.goetz at oracle.com)
Date: Thu, 14 Feb 2013 20:47:37 +0000
Subject: hg: lambda/lambda/jdk: 2 new changesets
Message-ID: <20130214204803.640C147A9E@hg.openjdk.java.net>

Changeset: 3cdc9b98ad98
Author:    briangoetz
Date:      2013-02-14 15:47 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/3cdc9b98ad98

Add bug numbers to workaround comments

! src/share/classes/java/util/stream/DistinctOp.java
! src/share/classes/java/util/stream/FoldOp.java
! src/share/classes/java/util/stream/Stream.java
+ test-ng/tests/lambda/TestPrivateCtorRef.java

Changeset: 771e9cf11949
Author:    briangoetz
Date:      2013-02-14 15:47 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/771e9cf11949

Merge



From misterm at gmail.com  Thu Feb 14 13:56:16 2013
From: misterm at gmail.com (Michael Nascimento)
Date: Thu, 14 Feb 2013 19:56:16 -0200
Subject: Round 1 feedback
In-Reply-To: <CAAWA2oXr4nsgCMOZQ5b=W5aaQxYk_a_QfXh9CUZ7bm0A7RsbQg@mail.gmail.com>
References: <CAAWA2oWBSROv6mejwoc60=T0tOQ2WjxOJjZgkxRZHFBqP3NXwg@mail.gmail.com>
	<50ED8455.6070006@oracle.com>
	<188235E9-619C-43E8-A9C0-AA6DD581DA69@oracle.com>
	<CAAWA2oWwMcOdpHF74dK_7j7MVmmKwVciOAC3T5OQeaoReyWO3A@mail.gmail.com>
	<50ED9711.30005@oracle.com>
	<CAAWA2oXr4nsgCMOZQ5b=W5aaQxYk_a_QfXh9CUZ7bm0A7RsbQg@mail.gmail.com>
Message-ID: <CAAWA2oW53HT8dPdO+T7iFp6=EPgf1FCZ+ns2VPhzz7q=dq1Fag@mail.gmail.com>

On Thu, Feb 14, 2013 at 2:32 AM, Michael Nascimento <misterm at gmail.com> wrote:
> Ok, now to a different point of the Multimap discussion. Turning this:
>
> Collection<Foo<Bar>> values = fooBySomething.values();
>
> into this:
>
> Collection<Foo<Bar>> values =
> fooBySomething.values().stream().<Foo<Bar>>explode((d, foos) ->
> d.send(foos)).collectUnordered(toList());
>
> is pretty ugly

...

And it required the explicit parameters above to compile, I know
realized I haven't highlighted this point.

Regards,
Michael

From maurizio.cimadamore at oracle.com  Thu Feb 14 14:15:32 2013
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Thu, 14 Feb 2013 22:15:32 +0000
Subject: Round 1 feedback
In-Reply-To: <CAAWA2oW53HT8dPdO+T7iFp6=EPgf1FCZ+ns2VPhzz7q=dq1Fag@mail.gmail.com>
References: <CAAWA2oWBSROv6mejwoc60=T0tOQ2WjxOJjZgkxRZHFBqP3NXwg@mail.gmail.com>
	<50ED8455.6070006@oracle.com>
	<188235E9-619C-43E8-A9C0-AA6DD581DA69@oracle.com>
	<CAAWA2oWwMcOdpHF74dK_7j7MVmmKwVciOAC3T5OQeaoReyWO3A@mail.gmail.com>
	<50ED9711.30005@oracle.com>
	<CAAWA2oXr4nsgCMOZQ5b=W5aaQxYk_a_QfXh9CUZ7bm0A7RsbQg@mail.gmail.com>
	<CAAWA2oW53HT8dPdO+T7iFp6=EPgf1FCZ+ns2VPhzz7q=dq1Fag@mail.gmail.com>
Message-ID: <511D6204.4080909@oracle.com>

On 14/02/13 21:56, Michael Nascimento wrote:
> On Thu, Feb 14, 2013 at 2:32 AM, Michael Nascimento <misterm at gmail.com> wrote:
>> Ok, now to a different point of the Multimap discussion. Turning this:
>>
>> Collection<Foo<Bar>> values = fooBySomething.values();
>>
>> into this:
>>
>> Collection<Foo<Bar>> values =
>> fooBySomething.values().stream().<Foo<Bar>>explode((d, foos) ->
>> d.send(foos)).collectUnordered(toList());
>>
>> is pretty ugly
> ...
>
> And it required the explicit parameters above to compile, I know
> realized I haven't highlighted this point.
I guess that's because explode is not the last node in the chain, so it 
'cannot' use info from the target type (it has o target-type).

Maurizio
>
> Regards,
> Michael
>


From mike.duigou at oracle.com  Thu Feb 14 15:39:35 2013
From: mike.duigou at oracle.com (mike.duigou at oracle.com)
Date: Thu, 14 Feb 2013 23:39:35 +0000
Subject: hg: lambda/lambda/jdk: many more javadoc nits.
Message-ID: <20130214233947.2D53A47AA5@hg.openjdk.java.net>

Changeset: f2ea4fe7261f
Author:    mduigou
Date:      2013-02-14 15:37 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/f2ea4fe7261f

many more javadoc nits.

! src/share/classes/java/util/function/BiConsumer.java
! src/share/classes/java/util/function/BiFunction.java
! src/share/classes/java/util/function/BiPredicate.java
! src/share/classes/java/util/function/BinaryOperator.java
! src/share/classes/java/util/function/BooleanSupplier.java
! src/share/classes/java/util/function/Consumer.java
! src/share/classes/java/util/function/DoubleBinaryOperator.java
! src/share/classes/java/util/function/DoubleConsumer.java
! src/share/classes/java/util/function/DoubleFunction.java
! src/share/classes/java/util/function/DoublePredicate.java
! src/share/classes/java/util/function/DoubleSupplier.java
! src/share/classes/java/util/function/DoubleUnaryOperator.java
! src/share/classes/java/util/function/IntBinaryOperator.java
! src/share/classes/java/util/function/IntConsumer.java
! src/share/classes/java/util/function/IntFunction.java
! src/share/classes/java/util/function/IntPredicate.java
! src/share/classes/java/util/function/IntSupplier.java
! src/share/classes/java/util/function/IntUnaryOperator.java
! src/share/classes/java/util/function/LongBinaryOperator.java
! src/share/classes/java/util/function/LongConsumer.java
! src/share/classes/java/util/function/LongFunction.java
! src/share/classes/java/util/function/LongPredicate.java
! src/share/classes/java/util/function/LongSupplier.java
! src/share/classes/java/util/function/LongUnaryOperator.java
! src/share/classes/java/util/function/ObjDoubleConsumer.java
! src/share/classes/java/util/function/ObjIntConsumer.java
! src/share/classes/java/util/function/ObjLongConsumer.java
! src/share/classes/java/util/function/Predicate.java
! src/share/classes/java/util/function/ToDoubleBiFunction.java
! src/share/classes/java/util/function/ToDoubleFunction.java
! src/share/classes/java/util/function/ToIntBiFunction.java
! src/share/classes/java/util/function/ToIntFunction.java
! src/share/classes/java/util/function/ToLongBiFunction.java
! src/share/classes/java/util/function/ToLongFunction.java
! src/share/classes/java/util/function/UnaryOperator.java


From brian.goetz at oracle.com  Thu Feb 14 15:50:58 2013
From: brian.goetz at oracle.com (brian.goetz at oracle.com)
Date: Thu, 14 Feb 2013 23:50:58 +0000
Subject: hg: lambda/lambda/jdk: Javadoc for IntermediateOp, StatefulOp,
	TerminalOp, OpUtils, ForEachOp
Message-ID: <20130214235110.6F75647AA6@hg.openjdk.java.net>

Changeset: ee1fce80ec31
Author:    briangoetz
Date:      2013-02-14 18:50 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/ee1fce80ec31

Javadoc for IntermediateOp,StatefulOp,TerminalOp,OpUtils,ForEachOp

! src/share/classes/java/util/stream/ForEachOp.java
! src/share/classes/java/util/stream/IntermediateOp.java
! src/share/classes/java/util/stream/OpUtils.java
! src/share/classes/java/util/stream/StatefulOp.java
! src/share/classes/java/util/stream/TerminalOp.java


From maurizio.cimadamore at oracle.com  Fri Feb 15 06:57:40 2013
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Fri, 15 Feb 2013 14:57:40 +0000
Subject: hg: lambda/lambda/langtools: Bug fixes:; ...
Message-ID: <20130215145743.6B11B47AE8@hg.openjdk.java.net>

Changeset: 5868b9c53cfd
Author:    mcimadamore
Date:      2013-02-15 14:57 +0000
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/5868b9c53cfd

Bug fixes:
8008276: assertion error in com.sun.tools.javac.comp.TransTypes.visitApply
8005183: Missing accessor for constructor reference pointing to private inner class ctor
8008293: Declared bounds not considered when functional interface containing unbound wildcards is instantiated

! src/share/classes/com/sun/tools/javac/code/Types.java
! src/share/classes/com/sun/tools/javac/comp/DeferredAttr.java
! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java
! src/share/classes/com/sun/tools/javac/util/JCDiagnostic.java
+ test/tools/javac/lambda/MethodReference63.java
+ test/tools/javac/lambda/TargetType64.java
+ test/tools/javac/lambda/speculative/MissingError.java
+ test/tools/javac/lambda/speculative/MissingError.out


From brian.goetz at oracle.com  Fri Feb 15 08:23:32 2013
From: brian.goetz at oracle.com (brian.goetz at oracle.com)
Date: Fri, 15 Feb 2013 16:23:32 +0000
Subject: hg: lambda/lambda/jdk: Revert workarounds for bug jdk-8008256 (method
	refs to private members of nest-mate classes)
Message-ID: <20130215162356.D915547AEB@hg.openjdk.java.net>

Changeset: 2a79ed17cf49
Author:    briangoetz
Date:      2013-02-15 11:23 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/2a79ed17cf49

Revert workarounds for bug jdk-8008256 (method refs to private members of nest-mate classes)

! src/share/classes/java/util/stream/DistinctOp.java


From paul.sandoz at oracle.com  Fri Feb 15 09:27:47 2013
From: paul.sandoz at oracle.com (paul.sandoz at oracle.com)
Date: Fri, 15 Feb 2013 17:27:47 +0000
Subject: hg: lambda/lambda/jdk: - ensure PH.intoWrappedWithCancel conforms to
	the sink.begin, sink.accept*, 
Message-ID: <20130215172759.2D97947AF9@hg.openjdk.java.net>

Changeset: a213c0b55d76
Author:    psandoz
Date:      2013-02-15 18:18 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/a213c0b55d76

- ensure PH.intoWrappedWithCancel conforms to the sink.begin, sink.accept*,
sink.end protocol.
- fix OpUtils.evaluateSequential to use intoWrappedWithCancel if the op
short-circuits
- SliceOp defers to OpUtils.evaluateSequential.

! src/share/classes/java/util/stream/AbstractPipeline.java
! src/share/classes/java/util/stream/OpUtils.java
! src/share/classes/java/util/stream/SliceOp.java


From brian.goetz at oracle.com  Fri Feb 15 10:43:51 2013
From: brian.goetz at oracle.com (brian.goetz at oracle.com)
Date: Fri, 15 Feb 2013 18:43:51 +0000
Subject: hg: lambda/lambda/jdk: Javadoc for terminal ops
Message-ID: <20130215184412.66CDA47AFF@hg.openjdk.java.net>

Changeset: ada7f01b90c9
Author:    briangoetz
Date:      2013-02-15 13:43 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/ada7f01b90c9

Javadoc for terminal ops

! src/share/classes/java/util/stream/FindOp.java
! src/share/classes/java/util/stream/FoldOp.java
! src/share/classes/java/util/stream/ForEachOp.java
! src/share/classes/java/util/stream/ForEachUntilOp.java
! src/share/classes/java/util/stream/MatchOp.java


From mike.duigou at oracle.com  Fri Feb 15 12:13:57 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Fri, 15 Feb 2013 12:13:57 -0800
Subject: RFR (M) : JDK-8004561 : Addition Functional Interfaces for Lambda
	Libraries
Message-ID: <2CB90323-8862-4735-BC75-7A1EB3C8276B@oracle.com>

Hello All;

This patch introduces a number of new functional interfaces for use by the lambda libraries. Also included are some name changes following JSR-225 EG review. The new interfaces are:

BiConsumer
BiFunction
BiPredicate
BooleanSupplier
DoublePredicate
IntPredicate
LongPredicate
ObjDoubleConsumer
ObjIntConsumer
ObjLongConsumer
ToDoubleBiFunction
ToDoubleFunction
ToIntBiFunction
ToIntFunction
ToLongBiFunction
ToLongFunction

Renames:

Block -> Consumer
BiBlock -> BiConsumer
IntBlock -> IntConsumer
DoubleBlock -> LongConsumer
LongBlock -> LongConsumer
UnaryOperator.operate -> UnaryOperator.apply
LongUnaryOperator.operateAsLong -> LongUnaryOperator.applyAsLong
DoubleUnaryOperator.operateAsDouble -> DoubleUnaryOperator.applyAsDouble
IntUnaryOperator.operateAsInt -> IntUnaryOperator.applyAsInt
LongBinaryOperator.operateAsLong -> LongBinaryOperator.applyAsLong
DoubleBinaryOperator.operateAsDouble -> DoubleBinaryOperator.applyAsDouble
IntBinaryOperator.operateAsInt -> IntBinaryOperator.applyAsInt

All of the changes outside the java.util.function package are made to accommodate these renamings.

The webrev is located at:

http://cr.openjdk.java.net/~mduigou/JDK-8004561/1/webrev/

and specdiff for the java.util.function package is at:

http://cr.openjdk.java.net/~mduigou/JDK-8004561/1/specdiff/

Thanks!

Mike


From howard.lovatt at gmail.com  Fri Feb 15 12:26:09 2013
From: howard.lovatt at gmail.com (Howard Lovatt)
Date: Sat, 16 Feb 2013 06:26:09 +1000
Subject: [concurrency-interest] Numerical Stream code
In-Reply-To: <CAEJX8oozMKoTiE_-rwF_d48cc9ySwK4RUqa8itO2OeFTivHkuQ@mail.gmail.com>
References: <CACR_FB41DwO6HBohqAMYdH3DMnUhS=PoqKZjb0tp-8WWw1qQtQ@mail.gmail.com>
	<511CF6C3.8000709@oracle.com> <511CF876.1000003@oracle.com>
	<511D093D.5010608@gmail.com> <511D1E24.7070700@oracle.com>
	<CAEJX8oozMKoTiE_-rwF_d48cc9ySwK4RUqa8itO2OeFTivHkuQ@mail.gmail.com>
Message-ID: <7F8A8604-06CA-44A3-A190-1F4C814D2164@gmail.com>

Hi,

Thanks for all the replies. This is largely a holding email. I am travelling with work and don't have my laptop. When get home I will post some more code. 

@Jin: I did warm up the code, but I do agree that benchmarks are tricky. As I said I was expecting some overhead but was surprised at how much. 

@Brian: The reason I factored t0 and tg0 out into methods is that they are common between the serial and parallel versions and I thought the code read better. I don't think it makes any difference, but I will check. 

@Others: To avoid writing over an old array I will have to allocate each time round the t loop. I will give this a try and see if it helps. The discussion about the parallel problems is interesting, but how come the serial version is so slow? Could a problem with the Stream code in general be the underlying problem with the parallel version?

Sent from my iPad

On 15/02/2013, at 3:48 AM, Stanimir Simeonoff <stanimir at riflexo.com> wrote:

> 
>> > Do element sizes matter (byte vs. short vs. int  vs. long)? 
>> 
>> I don't think so.  All of this assumes that the proper instruction is used.  For example, if 2 threads are writing to adjacent bytes, then the "mov" instruction has to only write the byte.  If the compiler, decides to read 32-bits, mask in the 8-bits and write 32-bits then the data will be corrupted. 
> JLS mandates no corruption for neighbor writes.
>  
>> I believe that HotSpot will only generate the write byte mov instruction.
> That would be the correct one. The case affects only boolean[]/byte[]/short[]/char[]  as simple primitive fields are always at least 32bits.
> 
> Stanimir
> 
>  
>> Nathan Reynolds | Architect | 602.333.9091
>> Oracle PSR Engineering | Server Technology
>> On 2/14/2013 8:56 AM, Peter Levart wrote:
>>> On 02/14/2013 03:45 PM, Brian Goetz wrote: 
>>>>> The parallel version is almost certainly suffering false cache line 
>>>>> sharing when adjacent tasks are writing to the shared arrays u0, etc. 
>>>>> Nothing to do with streams, just a standard parallelism gotcha.
>>>> Cure: don't write to shared arrays from parallel tasks.
>>> Hi, 
>>> 
>>> I would like to discuss this a little bit (hence the cc: concurrency-interest - the conversation can continue on this list only). 
>>> 
>>> Is it really important to avoid writing to shared arrays from multiple threads (of course without synchronization, not even volatile writes/reads) when indexes are not shared (each thread writes/reads it's own disjunct subset). 
>>> 
>>> Do element sizes matter (byte vs. short vs. int  vs. long)? 
>>> 
>>> I had a (false?) feeling that cache lines are not invalidated when writes are performed without fences. 
>>> 
>>> Also I don't know how short (byte, char) writes are combined into memory words on the hardware when they come from different cores and whether this is connected to any performance issues. 
>>> 
>>> Thanks, 
>>> 
>>> Peter 
>>> 
>>> _______________________________________________ 
>>> Concurrency-interest mailing list 
>>> Concurrency-interest at cs.oswego.edu 
>>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>> 
>> 
>> _______________________________________________
>> Concurrency-interest mailing list
>> Concurrency-interest at cs.oswego.edu
>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
> 
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest

From brian.goetz at oracle.com  Fri Feb 15 13:13:44 2013
From: brian.goetz at oracle.com (Brian Goetz)
Date: Fri, 15 Feb 2013 16:13:44 -0500
Subject: [concurrency-interest] Numerical Stream code
In-Reply-To: <7F8A8604-06CA-44A3-A190-1F4C814D2164@gmail.com>
References: <CACR_FB41DwO6HBohqAMYdH3DMnUhS=PoqKZjb0tp-8WWw1qQtQ@mail.gmail.com>
	<511CF6C3.8000709@oracle.com> <511CF876.1000003@oracle.com>
	<511D093D.5010608@gmail.com> <511D1E24.7070700@oracle.com>
	<CAEJX8oozMKoTiE_-rwF_d48cc9ySwK4RUqa8itO2OeFTivHkuQ@mail.gmail.com>
	<7F8A8604-06CA-44A3-A190-1F4C814D2164@gmail.com>
Message-ID: <511EA508.3080202@oracle.com>

Try computing average as:

   int[] collected = stream.collect(() -> new int[2],
            (arr, i) -> { arr[0] += i; arr[1]++; }
            (a1, a2) -> { a1[0] += a2[0]; a1[1] += a2[1] });
   double avg = (collected[1] == 0)
              ? 0
              : (double) collected[0]/collected[1];

since the current implementation of average() is doing way more work 
than you need.

On 2/15/2013 3:26 PM, Howard Lovatt wrote:
> Hi,
>
> Thanks for all the replies. This is largely a holding email. I am
> travelling with work and don't have my laptop. When get home I will post
> some more code.
>
> @Jin: I did warm up the code, but I do agree that benchmarks are tricky.
> As I said I was expecting some overhead but was surprised at how much.
>
> @Brian: The reason I factored t0 and tg0 out into methods is that they
> are common between the serial and parallel versions and I thought the
> code read better. I don't think it makes any difference, but I will check.
>
> @Others: To avoid writing over an old array I will have to allocate each
> time round the t loop. I will give this a try and see if it helps. The
> discussion about the parallel problems is interesting, but how come the
> serial version is so slow? Could a problem with the Stream code in
> general be the underlying problem with the parallel version?
>
> Sent from my iPad
>
> On 15/02/2013, at 3:48 AM, Stanimir Simeonoff <stanimir at riflexo.com
> <mailto:stanimir at riflexo.com>> wrote:
>
>>
>>     > Do element sizes matter (byte vs. short vs. int  vs. long)?
>>
>>     I don't think so.  All of this assumes that the proper instruction
>>     is used.  For example, if 2 threads are writing to adjacent bytes,
>>     then the "mov" instruction has to only write the byte.  If the
>>     compiler, decides to read 32-bits, mask in the 8-bits and write
>>     32-bits then the data will be corrupted.
>>
>> JLS mandates no corruption for neighbor writes.
>>
>>     I believe that HotSpot will only generate the write byte mov
>>     instruction.
>>
>> That would be the correct one. The case affects only
>> boolean[]/byte[]/short[]/char[]  as simple primitive fields are always
>> at least 32bits.
>>
>> Stanimir
>>
>>
>>     Nathan Reynolds
>>     <http://psr.us.oracle.com/wiki/index.php/User:Nathan_Reynolds> |
>>     Architect | 602.333.9091 <tel:602.333.9091>
>>     Oracle PSR Engineering <http://psr.us.oracle.com/> | Server Technology
>>     On 2/14/2013 8:56 AM, Peter Levart wrote:
>>>     On 02/14/2013 03:45 PM, Brian Goetz wrote:
>>>>>     The parallel version is almost certainly suffering false cache
>>>>>     line
>>>>>     sharing when adjacent tasks are writing to the shared arrays
>>>>>     u0, etc.
>>>>>     Nothing to do with streams, just a standard parallelism gotcha.
>>>>     Cure: don't write to shared arrays from parallel tasks.
>>>>
>>>>
>>>     Hi,
>>>
>>>     I would like to discuss this a little bit (hence the cc:
>>>     concurrency-interest - the conversation can continue on this list
>>>     only).
>>>
>>>     Is it really important to avoid writing to shared arrays from
>>>     multiple threads (of course without synchronization, not even
>>>     volatile writes/reads) when indexes are not shared (each thread
>>>     writes/reads it's own disjunct subset).
>>>
>>>     Do element sizes matter (byte vs. short vs. int  vs. long)?
>>>
>>>     I had a (false?) feeling that cache lines are not invalidated
>>>     when writes are performed without fences.
>>>
>>>     Also I don't know how short (byte, char) writes are combined into
>>>     memory words on the hardware when they come from different cores
>>>     and whether this is connected to any performance issues.
>>>
>>>     Thanks,
>>>
>>>     Peter
>>>
>>>     _______________________________________________
>>>     Concurrency-interest mailing list
>>>     Concurrency-interest at cs.oswego.edu
>>>     <mailto:Concurrency-interest at cs.oswego.edu>
>>>     http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>
>>
>>     _______________________________________________
>>     Concurrency-interest mailing list
>>     Concurrency-interest at cs.oswego.edu
>>     <mailto:Concurrency-interest at cs.oswego.edu>
>>     http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>
>>
>> _______________________________________________
>> Concurrency-interest mailing list
>> Concurrency-interest at cs.oswego.edu
>> <mailto:Concurrency-interest at cs.oswego.edu>
>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest

From brian.goetz at oracle.com  Fri Feb 15 14:13:35 2013
From: brian.goetz at oracle.com (brian.goetz at oracle.com)
Date: Fri, 15 Feb 2013 22:13:35 +0000
Subject: hg: lambda/lambda/jdk: Javadoc for Stream
Message-ID: <20130215221358.25D0147B14@hg.openjdk.java.net>

Changeset: 9167f345439c
Author:    briangoetz
Date:      2013-02-15 17:13 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/9167f345439c

Javadoc for Stream

! src/share/classes/java/util/stream/ForEachUntilOp.java
! src/share/classes/java/util/stream/Stream.java
! src/share/classes/java/util/stream/package-info.java


From brian.goetz at oracle.com  Fri Feb 15 14:42:26 2013
From: brian.goetz at oracle.com (brian.goetz at oracle.com)
Date: Fri, 15 Feb 2013 22:42:26 +0000
Subject: hg: lambda/lambda/jdk: Javadoc for Stream
Message-ID: <20130215224238.8DF4F47B16@hg.openjdk.java.net>

Changeset: f578ef474c19
Author:    briangoetz
Date:      2013-02-15 17:42 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/f578ef474c19

Javadoc for Stream

! src/share/classes/java/util/stream/BaseStream.java
! src/share/classes/java/util/stream/IntStream.java
! src/share/classes/java/util/stream/Stream.java


From forax at univ-mlv.fr  Fri Feb 15 15:40:48 2013
From: forax at univ-mlv.fr (Remi Forax)
Date: Sat, 16 Feb 2013 00:40:48 +0100
Subject: [8] Review request for 8004970, 8004971, and 8006817: implement
	serialization in lambda metafactory and metafactory fix
In-Reply-To: <511A5E68.4070805@oracle.com>
References: <511A5E68.4070805@oracle.com>
Message-ID: <511EC780.1030403@univ-mlv.fr>

On 02/12/2013 04:23 PM, Robert Field wrote:
> Please review the fixes for CRs:
>
>         http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004970
>
>         http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004971
>
>         http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8006817
>
>
>
> Webrev:
>
>         http://cr.openjdk.java.net/~rfield/8004970
>
> Thank,
> Robert
>
>

Hi Robert,
few comments,

in MethodHandleInfo:
  - getReferenceKindString should not be public, it's a detail of 
implementation.

in InnerClassLambdaMetaFactory:
  - spinInnerClass() should return a simple Class<?>.
  - generateWriteReplace: there is still a mv.dup() that should be 
replaced by
mv.visitInsn(DUP);

in AbstractValidatingLambdaMetafactory:
   - field markerInterfaces should be declared as Class<?>[]
     (you can replace all Class by Class<?>)

in SerializedLambda:
   - I think it should declare a serialUID, so you don't need a ad-hoc 
versioning.
     (to answer to the question line 235)
   - Also does the constructor
SerializedLambda(Class ,MethodHandle,MethodHandle,MethodType,Object[])
     still used ?

in TypeConvertingMethodAdapter:
   - at the end, load/dup/areturn/getfield should be replaced by their 
corresponding
     code inlined. I don't see a real interest to these too small method.
     Only iconst is really complex so worth a dedicated method.

cheers,
R?mi




From brian.goetz at oracle.com  Fri Feb 15 16:00:12 2013
From: brian.goetz at oracle.com (Brian Goetz)
Date: Fri, 15 Feb 2013 19:00:12 -0500
Subject: [8] Review request for 8004970, 8004971, and 8006817: implement
	serialization in lambda metafactory and metafactory fix
In-Reply-To: <511EC780.1030403@univ-mlv.fr>
References: <511A5E68.4070805@oracle.com> <511EC780.1030403@univ-mlv.fr>
Message-ID: <511ECC0C.6000401@oracle.com>

> in MethodHandleInfo:
>    - getReferenceKindString should not be public, it's a detail of
> implementation.

The purpose of this call is so that clients who use MHI to crack an MH 
can turn it into an accurate string representation, such as what javap 
does when dumping constant pools with MH constants in it.  Otherwise, 
everyone has to write their own switch based on what is in the JLS.

> in SerializedLambda:
>     - I think it should declare a serialUID, so you don't need a ad-hoc
> versioning.

Agreed.

>       (to answer to the question line 235)
>     - Also does the constructor
> SerializedLambda(Class ,MethodHandle,MethodHandle,MethodType,Object[])
>       still used ?

Not in the JDK.  Robert, what about compiler-generated code?  If not 
used, we should remove it.

From forax at univ-mlv.fr  Fri Feb 15 17:30:47 2013
From: forax at univ-mlv.fr (Remi Forax)
Date: Sat, 16 Feb 2013 02:30:47 +0100
Subject: [8] Review request for 8004970, 8004971, and 8006817: implement
	serialization in lambda metafactory and metafactory fix
In-Reply-To: <511ECC0C.6000401@oracle.com>
References: <511A5E68.4070805@oracle.com> <511EC780.1030403@univ-mlv.fr>
	<511ECC0C.6000401@oracle.com>
Message-ID: <511EE147.9050307@univ-mlv.fr>

On 02/16/2013 01:00 AM, Brian Goetz wrote:
>> in MethodHandleInfo:
>>    - getReferenceKindString should not be public, it's a detail of
>> implementation.
>
> The purpose of this call is so that clients who use MHI to crack an MH 
> can turn it into an accurate string representation, such as what javap 
> does when dumping constant pools with MH constants in it.  Otherwise, 
> everyone has to write their own switch based on what is in the JLS.

Everyone that want a string representation of a constant method handle 
stored in the constant pool will have to write it's own switch based on 
the JVM spec ...
Moreover, at some point in the future, the JSR 292 EG may decide to 
extend that class to reflect more method handles that only constant ones 
and requiring to provide a stable name for those non constant method 
handles is constraint I would like to avoid.

>
>> in SerializedLambda:
>>     - I think it should declare a serialUID, so you don't need a ad-hoc
>> versioning.
>
> Agreed.
>
>>       (to answer to the question line 235)
>>     - Also does the constructor
>> SerializedLambda(Class ,MethodHandle,MethodHandle,MethodType,Object[])
>>       still used ?
>
> Not in the JDK.  Robert, what about compiler-generated code?  If not 
> used, we should remove it.

R?mi


From mike.duigou at oracle.com  Fri Feb 15 18:03:30 2013
From: mike.duigou at oracle.com (mike.duigou at oracle.com)
Date: Sat, 16 Feb 2013 02:03:30 +0000
Subject: hg: lambda/lambda/jdk: 3 new changesets
Message-ID: <20130216020405.D032347B1E@hg.openjdk.java.net>

Changeset: 5e5e9f1bed16
Author:    mduigou
Date:      2013-02-14 17:15 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/5e5e9f1bed16

javadoc nits
Contributed-by: brian.goetz at oracle.com

! src/share/classes/java/util/function/BiFunction.java
! src/share/classes/java/util/function/BinaryOperator.java
! src/share/classes/java/util/function/ToLongFunction.java

Changeset: 86f7db98577e
Author:    mduigou
Date:      2013-02-15 17:17 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/86f7db98577e

cleanups prior to review phase.

! src/share/classes/java/util/Optional.java

Changeset: 07984401133f
Author:    mduigou
Date:      2013-02-15 17:30 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/07984401133f

cleanups prior to review phase. Remove some limited value functionality. Some moved to more natural home.

! src/share/classes/java/util/Objects.java
! src/share/classes/java/util/function/Functions.java
! src/share/classes/java/util/function/Predicates.java


From forax at univ-mlv.fr  Fri Feb 15 18:27:11 2013
From: forax at univ-mlv.fr (Remi Forax)
Date: Sat, 16 Feb 2013 03:27:11 +0100
Subject: hg: lambda/lambda/jdk: 3 new changesets
In-Reply-To: <20130216020405.D032347B1E@hg.openjdk.java.net>
References: <20130216020405.D032347B1E@hg.openjdk.java.net>
Message-ID: <511EEE7F.2010300@univ-mlv.fr>

Hi Mike,
isNull and nonNull doesn't need to declare a type variable T, using 
Object is enough.

R?mi

On 02/16/2013 03:03 AM, mike.duigou at oracle.com wrote:
> Changeset: 5e5e9f1bed16
> Author:    mduigou
> Date:      2013-02-14 17:15 -0800
> URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/5e5e9f1bed16
>
> javadoc nits
> Contributed-by: brian.goetz at oracle.com
>
> ! src/share/classes/java/util/function/BiFunction.java
> ! src/share/classes/java/util/function/BinaryOperator.java
> ! src/share/classes/java/util/function/ToLongFunction.java
>
> Changeset: 86f7db98577e
> Author:    mduigou
> Date:      2013-02-15 17:17 -0800
> URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/86f7db98577e
>
> cleanups prior to review phase.
>
> ! src/share/classes/java/util/Optional.java
>
> Changeset: 07984401133f
> Author:    mduigou
> Date:      2013-02-15 17:30 -0800
> URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/07984401133f
>
> cleanups prior to review phase. Remove some limited value functionality. Some moved to more natural home.
>
> ! src/share/classes/java/util/Objects.java
> ! src/share/classes/java/util/function/Functions.java
> ! src/share/classes/java/util/function/Predicates.java
>
>


From robert.field at oracle.com  Fri Feb 15 19:53:03 2013
From: robert.field at oracle.com (robert.field at oracle.com)
Date: Sat, 16 Feb 2013 03:53:03 +0000
Subject: hg: lambda/lambda/langtools: Sync with changes per review comment on
	TL commit
Message-ID: <20130216035306.96C2047B24@hg.openjdk.java.net>

Changeset: a2b6e71c5b62
Author:    rfield
Date:      2013-02-15 19:52 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/a2b6e71c5b62

 Sync with changes per review comment on TL commit

! src/share/classes/com/sun/tools/javac/code/Symtab.java
! src/share/classes/com/sun/tools/javac/code/Types.java
! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java
! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java
! src/share/classes/com/sun/tools/javac/jvm/UninitializedType.java
+ test/tools/javac/lambda/LambdaInnerTypeVarArgsSerialize.java


From robert.field at oracle.com  Fri Feb 15 20:40:16 2013
From: robert.field at oracle.com (Robert Field)
Date: Fri, 15 Feb 2013 20:40:16 -0800
Subject: [8] Review request for 8004970, 8004971, and 8006817: implement
	serialization in lambda metafactory and metafactory fix
In-Reply-To: <511EC780.1030403@univ-mlv.fr>
References: <511A5E68.4070805@oracle.com> <511EC780.1030403@univ-mlv.fr>
Message-ID: <511F0DB0.8040100@oracle.com>

On 02/15/13 15:40, Remi Forax wrote:
> On 02/12/2013 04:23 PM, Robert Field wrote:
>> Please review the fixes for CRs:
>>
>>          http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004970
>>
>>          http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004971
>>
>>          http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8006817
>>
>>
>>
>> Webrev:
>>
>>          http://cr.openjdk.java.net/~rfield/8004970
>>
>> Thank,
>> Robert
>>
>>
> Hi Robert,
> few comments,

Thanks much, R?mi, for the review.

>
> in MethodHandleInfo:
>    - getReferenceKindString should not be public, it's a detail of
> implementation.

Query to the JSR-292 lead in process.

>
> in InnerClassLambdaMetaFactory:
>    - spinInnerClass() should return a simple Class<?>.

Yep.

>    - generateWriteReplace: there is still a mv.dup() that should be
> replaced by
> mv.visitInsn(DUP);

Yep.

>
> in AbstractValidatingLambdaMetafactory:
>     - field markerInterfaces should be declared as Class<?>[]

Yep
>       (you can replace all Class by Class<?>)

Will scan.

>
> in SerializedLambda:
>     - I think it should declare a serialUID, so you don't need a ad-hoc
> versioning.
>       (to answer to the question line 235)

Will do.

>     - Also does the constructor
> SerializedLambda(Class ,MethodHandle,MethodHandle,MethodType,Object[])
>       still used ?

Nope.  It's history.

>
> in TypeConvertingMethodAdapter:
>     - at the end, load/dup/areturn/getfield should be replaced by their
> corresponding
>       code inlined. I don't see a real interest to these too small method.
>       Only iconst is really complex so worth a dedicated method.

I find that it makes the code more readable, but there are too few uses 
to justify, and I will defer to you on this score.

Thanks again,
Robert

>
> cheers,
> R?mi
>
>
>
>


From robert.field at oracle.com  Sat Feb 16 12:46:57 2013
From: robert.field at oracle.com (Robert Field)
Date: Sat, 16 Feb 2013 12:46:57 -0800
Subject: [8] Review request for 8004970, 8004971, and 8006817: implement
	serialization in lambda metafactory and metafactory fix
In-Reply-To: <511F0DB0.8040100@oracle.com>
References: <511A5E68.4070805@oracle.com> <511EC780.1030403@univ-mlv.fr>
	<511F0DB0.8040100@oracle.com>
Message-ID: <511FF041.1010100@oracle.com>

I have pushed these changes.
Awaiting a response from the JSR-292 lead I have, without prejudice, 
removed "public" from MethodHandleInfo and 
MethodHandleInfo.getReferenceKindString.

-Robert


On 02/15/13 20:40, Robert Field wrote:
> On 02/15/13 15:40, Remi Forax wrote:
>> On 02/12/2013 04:23 PM, Robert Field wrote:
>>> Please review the fixes for CRs:
>>>
>>>           http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004970
>>>
>>>           http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004971
>>>
>>>           http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8006817
>>>
>>>
>>>
>>> Webrev:
>>>
>>>           http://cr.openjdk.java.net/~rfield/8004970
>>>
>>> Thank,
>>> Robert
>>>
>>>
>> Hi Robert,
>> few comments,
> Thanks much, R?mi, for the review.
>
>> in MethodHandleInfo:
>>     - getReferenceKindString should not be public, it's a detail of
>> implementation.
> Query to the JSR-292 lead in process.
>
>> in InnerClassLambdaMetaFactory:
>>     - spinInnerClass() should return a simple Class<?>.
> Yep.
>
>>     - generateWriteReplace: there is still a mv.dup() that should be
>> replaced by
>> mv.visitInsn(DUP);
> Yep.
>
>> in AbstractValidatingLambdaMetafactory:
>>      - field markerInterfaces should be declared as Class<?>[]
> Yep
>>        (you can replace all Class by Class<?>)
> Will scan.
>
>> in SerializedLambda:
>>      - I think it should declare a serialUID, so you don't need a ad-hoc
>> versioning.
>>        (to answer to the question line 235)
> Will do.
>
>>      - Also does the constructor
>> SerializedLambda(Class ,MethodHandle,MethodHandle,MethodType,Object[])
>>        still used ?
> Nope.  It's history.
>
>> in TypeConvertingMethodAdapter:
>>      - at the end, load/dup/areturn/getfield should be replaced by their
>> corresponding
>>        code inlined. I don't see a real interest to these too small method.
>>        Only iconst is really complex so worth a dedicated method.
> I find that it makes the code more readable, but there are too few uses
> to justify, and I will defer to you on this score.
>
> Thanks again,
> Robert
>
>> cheers,
>> R?mi
>>
>>
>>
>>
>


From boaznahum at gmail.com  Sun Feb 17 03:41:21 2013
From: boaznahum at gmail.com (Boaz Nahum)
Date: Sun, 17 Feb 2013 13:41:21 +0200
Subject: Streams.concat for primitives
Message-ID: <CAB_DFWaptEg6q1hXwqOtUepEJSDQ2jnZSi8wJDdvFQ6unVe3Cg@mail.gmail.com>

Any plans to implement Streams.concat in case of IntStream ?

Another question, why concat is not  member of stream ?

Thanks
Boaz

From brian.goetz at oracle.com  Sun Feb 17 11:57:01 2013
From: brian.goetz at oracle.com (Brian Goetz)
Date: Sun, 17 Feb 2013 14:57:01 -0500
Subject: Streams.concat for primitives
In-Reply-To: <CAB_DFWaptEg6q1hXwqOtUepEJSDQ2jnZSi8wJDdvFQ6unVe3Cg@mail.gmail.com>
References: <CAB_DFWaptEg6q1hXwqOtUepEJSDQ2jnZSi8wJDdvFQ6unVe3Cg@mail.gmail.com>
Message-ID: <5121360D.2000501@oracle.com>

> Any plans to implement Streams.concat in case of IntStream ?

Not currently.

> Another question, why concat is not  member of stream ?

It was, until we changed it.

If you look at all the other methods of Stream, all the arguments to 
their methods are stateless.  Stream would have been an exception (so 
was into(collection)) and would have caused problems for defining stream 
pipelines as functions separate from their source (what we sometimes 
called "detached pipelines", were you would define the computational 
process X.filter(...).map(...).reduce(...) separate form its source, so 
it would be a function from Stream to the reduction result, and 
therefore could amortize the pipeline setup over multiple uses (enabling 
further optimizations that are impractical for one-shot pipelines.))

Further, the value of defining concat() as a stream method (and 
therefore make it eligible for chaining) is low, since you still have to 
set up the other pipeline and that often doesn't chain so well anyway.


From aleksey.shipilev at oracle.com  Mon Feb 18 00:48:56 2013
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Mon, 18 Feb 2013 12:48:56 +0400
Subject: Regular sync-ups from the upstream?
Message-ID: <5121EAF8.80608@oracle.com>

Hi guys,

It seems the lambda/lambda is the frontier of concurrency development
these days. Both Doug had locked jsr166 to be compilable with the latest
lambda/lambda, and me as well locked java-concurrency-torture to be
compilable with the latest promoted build of jdk8-ea-lambda. (These
address compilation of all these fancy lambda-enabled APIs).

With the headlines like that, I'm going to ask regular sync-ups with the
upstream to bring more goodness from regular channels, including
non-lambda-specific j.u.c.*/HotSpot changes. Many of j.u.c. changes are
pushed directly into jdk8.

Example: @Contended already accessible in jdk8-b75 (promoted Jan 31),
but not accessible in jdk8-lambda-b76 (promoted Feb 05?),
jdk8-lambda-b77 (promoted Feb 11?).

Maybe I'm missing some part of the plan to integrate lambda/lambda to
upstream jdk8 completely, which will move the development back to
mainline, and the whole issue would be nilled out.

Thanks!
-Aleksey.


From boaznahum at gmail.com  Mon Feb 18 03:29:41 2013
From: boaznahum at gmail.com (Boaz Nahum)
Date: Mon, 18 Feb 2013 13:29:41 +0200
Subject: Streams.concat for primitives
In-Reply-To: <5121360D.2000501@oracle.com>
References: <CAB_DFWaptEg6q1hXwqOtUepEJSDQ2jnZSi8wJDdvFQ6unVe3Cg@mail.gmail.com>
	<5121360D.2000501@oracle.com>
Message-ID: <CAB_DFWYqraPs17vqdmwNzjdeXiy9gzdXrHgj+4ygtDXu8Ae=YA@mail.gmail.com>

It explains. Many thanks.

On Sun, Feb 17, 2013 at 9:57 PM, Brian Goetz <brian.goetz at oracle.com> wrote:

> Any plans to implement Streams.concat in case of IntStream ?
>>
>
> Not currently.
>
>
>  Another question, why concat is not  member of stream ?
>>
>
> It was, until we changed it.
>
> If you look at all the other methods of Stream, all the arguments to their
> methods are stateless.  Stream would have been an exception (so was
> into(collection)) and would have caused problems for defining stream
> pipelines as functions separate from their source (what we sometimes called
> "detached pipelines", were you would define the computational process
> X.filter(...).map(...).reduce(**...) separate form its source, so it
> would be a function from Stream to the reduction result, and therefore
> could amortize the pipeline setup over multiple uses (enabling further
> optimizations that are impractical for one-shot pipelines.))
>
> Further, the value of defining concat() as a stream method (and therefore
> make it eligible for chaining) is low, since you still have to set up the
> other pipeline and that often doesn't chain so well anyway.
>
>

From paul.sandoz at oracle.com  Mon Feb 18 06:10:38 2013
From: paul.sandoz at oracle.com (paul.sandoz at oracle.com)
Date: Mon, 18 Feb 2013 14:10:38 +0000
Subject: hg: lambda/lambda/jdk: Modify the conc-Node spliterator forEach and
	tryAdvance from using the call
Message-ID: <20130218141113.13E1347B5D@hg.openjdk.java.net>

Changeset: 66c0dd07e288
Author:    psandoz
Date:      2013-02-18 15:09 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/66c0dd07e288

Modify the conc-Node spliterator forEach and tryAdvance from using the call
stack to using an explicit (Deque) stack and a depth first search to
find leaf nodes. This avoids stack overflow expceptions with tryAdvance
and forEach for right-balanced or degenerate treess. This also avoids
the internal creation of n spliterators when using tryAdvance, where n is the
depth of the tree.

! src/share/classes/java/util/stream/Nodes.java


From paul.sandoz at oracle.com  Mon Feb 18 07:55:55 2013
From: paul.sandoz at oracle.com (paul.sandoz at oracle.com)
Date: Mon, 18 Feb 2013 15:55:55 +0000
Subject: hg: lambda/lambda/jdk: Fix the suggestTargetSize.
Message-ID: <20130218155618.0D4FB47B63@hg.openjdk.java.net>

Changeset: cc01521c9211
Author:    psandoz
Date:      2013-02-18 16:55 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/cc01521c9211

Fix the suggestTargetSize.
Contributed-by: Doug Lea <dl at cs.oswego.edu>

! src/share/classes/java/util/stream/AbstractTask.java


From brian.goetz at oracle.com  Mon Feb 18 08:36:24 2013
From: brian.goetz at oracle.com (brian.goetz at oracle.com)
Date: Mon, 18 Feb 2013 16:36:24 +0000
Subject: hg: lambda/lambda/jdk: Rename Flatmapper.explodeInto to flattenInto
Message-ID: <20130218163645.5349C47B67@hg.openjdk.java.net>

Changeset: 4da590a550a5
Author:    briangoetz
Date:      2013-02-18 11:36 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/4da590a550a5

Rename Flatmapper.explodeInto to flattenInto

! src/share/classes/java/util/stream/DoublePipeline.java
! src/share/classes/java/util/stream/FlatMapper.java
! src/share/classes/java/util/stream/IntPipeline.java
! src/share/classes/java/util/stream/LongPipeline.java
! src/share/classes/java/util/stream/ReferencePipeline.java


From benjamin.john.evans at gmail.com  Mon Feb 18 10:29:05 2013
From: benjamin.john.evans at gmail.com (Ben Evans)
Date: Mon, 18 Feb 2013 13:29:05 -0500
Subject: Regular sync-ups from the upstream?
In-Reply-To: <5121EAF8.80608@oracle.com>
References: <5121EAF8.80608@oracle.com>
Message-ID: <CABKW8RgFZN9QXL1Jew2t6LePdPUaMBEW1obGdQZ8NF1XQSxSfA@mail.gmail.com>

I'd like to echo this.

I'm trying to write a patch to java.util.regex.Pattern, which
implements methods for use with lambda expressions, to make using
regexps easy in Java 8.

Unfortunately, I have a couple of problems:

1) The lambdas repo doesn't currently support Mac.

2) The JDK 8 repo (which is what we've cloned to github for the Adopt
OpenJDK project) doesn't support the current implementation of lambdas
- it's a couple of versions behind.

If we could get the build changes into lambda, so it will build on
Mac, I would be a happy man.

Thanks,

Ben

On Mon, Feb 18, 2013 at 3:48 AM, Aleksey Shipilev
<aleksey.shipilev at oracle.com> wrote:
> Hi guys,
>
> It seems the lambda/lambda is the frontier of concurrency development
> these days. Both Doug had locked jsr166 to be compilable with the latest
> lambda/lambda, and me as well locked java-concurrency-torture to be
> compilable with the latest promoted build of jdk8-ea-lambda. (These
> address compilation of all these fancy lambda-enabled APIs).
>
> With the headlines like that, I'm going to ask regular sync-ups with the
> upstream to bring more goodness from regular channels, including
> non-lambda-specific j.u.c.*/HotSpot changes. Many of j.u.c. changes are
> pushed directly into jdk8.
>
> Example: @Contended already accessible in jdk8-b75 (promoted Jan 31),
> but not accessible in jdk8-lambda-b76 (promoted Feb 05?),
> jdk8-lambda-b77 (promoted Feb 11?).
>
> Maybe I'm missing some part of the plan to integrate lambda/lambda to
> upstream jdk8 completely, which will move the development back to
> mainline, and the whole issue would be nilled out.
>
> Thanks!
> -Aleksey.
>
>

From brian.goetz at oracle.com  Mon Feb 18 10:40:35 2013
From: brian.goetz at oracle.com (Brian Goetz)
Date: Mon, 18 Feb 2013 13:40:35 -0500
Subject: Regular sync-ups from the upstream?
In-Reply-To: <CABKW8RgFZN9QXL1Jew2t6LePdPUaMBEW1obGdQZ8NF1XQSxSfA@mail.gmail.com>
References: <5121EAF8.80608@oracle.com>
	<CABKW8RgFZN9QXL1Jew2t6LePdPUaMBEW1obGdQZ8NF1XQSxSfA@mail.gmail.com>
Message-ID: <512275A3.10901@oracle.com>

> 1) The lambdas repo doesn't currently support Mac.

This can't be true.  Half of the lambda dev team uses macs.  Are you 
trying to use the old build infra?  We build using the new build.


From Gary.Frost at amd.com  Mon Feb 18 10:42:02 2013
From: Gary.Frost at amd.com (Frost, Gary)
Date: Mon, 18 Feb 2013 18:42:02 +0000
Subject: Regular sync-ups from the upstream?
In-Reply-To: <CABKW8RgFZN9QXL1Jew2t6LePdPUaMBEW1obGdQZ8NF1XQSxSfA@mail.gmail.com>
References: <5121EAF8.80608@oracle.com>
	<CABKW8RgFZN9QXL1Jew2t6LePdPUaMBEW1obGdQZ8NF1XQSxSfA@mail.gmail.com>
Message-ID: <D9528E88318AAA4CAFEDC539E48436E33E597ACB@sausexdag01.amd.com>

I built the lambda tree just last night from MacOSX 

Gary

-----Original Message-----
From: lambda-dev-bounces at openjdk.java.net [mailto:lambda-dev-bounces at openjdk.java.net] On Behalf Of Ben Evans
Sent: Monday, February 18, 2013 12:29 PM
To: Aleksey Shipilev
Cc: lambda-dev
Subject: Re: Regular sync-ups from the upstream?

I'd like to echo this.

I'm trying to write a patch to java.util.regex.Pattern, which implements methods for use with lambda expressions, to make using regexps easy in Java 8.

Unfortunately, I have a couple of problems:

1) The lambdas repo doesn't currently support Mac.

2) The JDK 8 repo (which is what we've cloned to github for the Adopt OpenJDK project) doesn't support the current implementation of lambdas
- it's a couple of versions behind.

If we could get the build changes into lambda, so it will build on Mac, I would be a happy man.

Thanks,

Ben

On Mon, Feb 18, 2013 at 3:48 AM, Aleksey Shipilev <aleksey.shipilev at oracle.com> wrote:
> Hi guys,
>
> It seems the lambda/lambda is the frontier of concurrency development 
> these days. Both Doug had locked jsr166 to be compilable with the 
> latest lambda/lambda, and me as well locked java-concurrency-torture 
> to be compilable with the latest promoted build of jdk8-ea-lambda. 
> (These address compilation of all these fancy lambda-enabled APIs).
>
> With the headlines like that, I'm going to ask regular sync-ups with 
> the upstream to bring more goodness from regular channels, including 
> non-lambda-specific j.u.c.*/HotSpot changes. Many of j.u.c. changes 
> are pushed directly into jdk8.
>
> Example: @Contended already accessible in jdk8-b75 (promoted Jan 31), 
> but not accessible in jdk8-lambda-b76 (promoted Feb 05?),
> jdk8-lambda-b77 (promoted Feb 11?).
>
> Maybe I'm missing some part of the plan to integrate lambda/lambda to 
> upstream jdk8 completely, which will move the development back to 
> mainline, and the whole issue would be nilled out.
>
> Thanks!
> -Aleksey.
>
>




From edharned at gmail.com  Mon Feb 18 10:44:24 2013
From: edharned at gmail.com (Edward Harned)
Date: Mon, 18 Feb 2013 13:44:24 -0500
Subject: hg: lambda/lambda/jdk: Modify the conc-Node spliterator forEach
	and tryAdvance from using the call
In-Reply-To: <20130218141113.13E1347B5D@hg.openjdk.java.net>
References: <20130218141113.13E1347B5D@hg.openjdk.java.net>
Message-ID: <CALNbAKyf3uOAmiUeUUzHyJ1TajH=Q8zk49DT+WD4T9HmEQNfuQ@mail.gmail.com>

Is the stack problem for serial, parallel or both?

Do you have an example for where the problem lies? (a little stack trace
maybe)


On Mon, Feb 18, 2013 at 9:10 AM, <paul.sandoz at oracle.com> wrote:

> Changeset: 66c0dd07e288
> Author:    psandoz
> Date:      2013-02-18 15:09 +0100
> URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/66c0dd07e288
>
> Modify the conc-Node spliterator forEach and tryAdvance from using the call
> stack to using an explicit (Deque) stack and a depth first search to
> find leaf nodes. This avoids stack overflow expceptions with tryAdvance
> and forEach for right-balanced or degenerate treess. This also avoids
> the internal creation of n spliterators when using tryAdvance, where n is
> the
> depth of the tree.
>
> ! src/share/classes/java/util/stream/Nodes.java
>
>
>

From mike.duigou at oracle.com  Mon Feb 18 10:47:18 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Mon, 18 Feb 2013 10:47:18 -0800
Subject: Regular sync-ups from the upstream?
In-Reply-To: <CABKW8RgFZN9QXL1Jew2t6LePdPUaMBEW1obGdQZ8NF1XQSxSfA@mail.gmail.com>
References: <5121EAF8.80608@oracle.com>
	<CABKW8RgFZN9QXL1Jew2t6LePdPUaMBEW1obGdQZ8NF1XQSxSfA@mail.gmail.com>
Message-ID: <F7EE3950-FA46-4D08-A42D-C14160FCAD7A@oracle.com>


On Feb 18 2013, at 10:29 , Ben Evans wrote:

> I'd like to echo this.
> 
> I'm trying to write a patch to java.util.regex.Pattern, which
> implements methods for use with lambda expressions, to make using
> regexps easy in Java 8.
> 
> Unfortunately, I have a couple of problems:
> 
> 1) The lambdas repo doesn't currently support Mac.

What problems are you running into on Mac? (and where were the problems reported)

We haven't seen any recent problems with the new build on Mac. There are a few known problems with image rebuilds but those aren't mac specific.

Mike


From benjamin.john.evans at gmail.com  Mon Feb 18 11:07:13 2013
From: benjamin.john.evans at gmail.com (Ben Evans)
Date: Mon, 18 Feb 2013 14:07:13 -0500
Subject: Regular sync-ups from the upstream?
In-Reply-To: <F7EE3950-FA46-4D08-A42D-C14160FCAD7A@oracle.com>
References: <5121EAF8.80608@oracle.com>
	<CABKW8RgFZN9QXL1Jew2t6LePdPUaMBEW1obGdQZ8NF1XQSxSfA@mail.gmail.com>
	<F7EE3950-FA46-4D08-A42D-C14160FCAD7A@oracle.com>
Message-ID: <CABKW8Ri2BydLB76KhH+427mN8scmoZBS9u9YQiaQNS-x8Vk+=Q@mail.gmail.com>

On Mon, Feb 18, 2013 at 1:47 PM, Mike Duigou <mike.duigou at oracle.com> wrote:
> On Feb 18 2013, at 10:29 , Ben Evans wrote:
>
>> I'd like to echo this.
>>
>> I'm trying to write a patch to java.util.regex.Pattern, which
>> implements methods for use with lambda expressions, to make using
>> regexps easy in Java 8.
>>
>> Unfortunately, I have a couple of problems:
>>
>> 1) The lambdas repo doesn't currently support Mac.
>
> What problems are you running into on Mac? (and where were the problems reported)
>
> We haven't seen any recent problems with the new build on Mac. There are a few known problems with image rebuilds but those aren't mac specific.

I've seen a chain of problems, most of which I was able to work around
- issues with lint flags, other make issues which I needed to hand
coax, etc, etc.

The current failure is:

## Starting images
make[2]: *** No rule to make target `)', needed by
`/Users/boxcat/projects/lambda-old/build/macosx-x86_64-normal-server-release/images/lib/JObjC.jar'.
 Stop.
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [images] Error 2
make: *** [images-only] Error 2

A re-pull a few days ago didn't help matters, but I can try another
re-pull & rebuild, given that everyone is pretty sure that this should
work.

Will let you know how I get on,

Ben

From brian.goetz at oracle.com  Mon Feb 18 12:23:56 2013
From: brian.goetz at oracle.com (brian.goetz at oracle.com)
Date: Mon, 18 Feb 2013 20:23:56 +0000
Subject: hg: lambda/lambda/jdk: More Stream javadoc
Message-ID: <20130218202426.0E27647B70@hg.openjdk.java.net>

Changeset: dca8cf166b2a
Author:    briangoetz
Date:      2013-02-18 15:23 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/dca8cf166b2a

More Stream javadoc

! src/share/classes/java/util/stream/Stream.java
! src/share/classes/java/util/stream/StreamShape.java


From benjamin.john.evans at gmail.com  Mon Feb 18 12:38:24 2013
From: benjamin.john.evans at gmail.com (Ben Evans)
Date: Mon, 18 Feb 2013 15:38:24 -0500
Subject: Regular sync-ups from the upstream?
In-Reply-To: <CABKW8Ri2BydLB76KhH+427mN8scmoZBS9u9YQiaQNS-x8Vk+=Q@mail.gmail.com>
References: <5121EAF8.80608@oracle.com>
	<CABKW8RgFZN9QXL1Jew2t6LePdPUaMBEW1obGdQZ8NF1XQSxSfA@mail.gmail.com>
	<F7EE3950-FA46-4D08-A42D-C14160FCAD7A@oracle.com>
	<CABKW8Ri2BydLB76KhH+427mN8scmoZBS9u9YQiaQNS-x8Vk+=Q@mail.gmail.com>
Message-ID: <CABKW8Rjsi52BqfGB3abS_t=02B5EtehnTDMinayBL_5+vn0uTw@mail.gmail.com>

Fixed.

My install was not pulling correctly from hg - due to reasons which
seem to be related to this issue:

http://mail.openjdk.java.net/pipermail/build-dev/2012-August/006588.html

Which is still not fixed :(

Ben

On Mon, Feb 18, 2013 at 2:07 PM, Ben Evans
<benjamin.john.evans at gmail.com> wrote:
> On Mon, Feb 18, 2013 at 1:47 PM, Mike Duigou <mike.duigou at oracle.com> wrote:
>> On Feb 18 2013, at 10:29 , Ben Evans wrote:
>>
>>> I'd like to echo this.
>>>
>>> I'm trying to write a patch to java.util.regex.Pattern, which
>>> implements methods for use with lambda expressions, to make using
>>> regexps easy in Java 8.
>>>
>>> Unfortunately, I have a couple of problems:
>>>
>>> 1) The lambdas repo doesn't currently support Mac.
>>
>> What problems are you running into on Mac? (and where were the problems reported)
>>
>> We haven't seen any recent problems with the new build on Mac. There are a few known problems with image rebuilds but those aren't mac specific.
>
> I've seen a chain of problems, most of which I was able to work around
> - issues with lint flags, other make issues which I needed to hand
> coax, etc, etc.
>
> The current failure is:
>
> ## Starting images
> make[2]: *** No rule to make target `)', needed by
> `/Users/boxcat/projects/lambda-old/build/macosx-x86_64-normal-server-release/images/lib/JObjC.jar'.
>  Stop.
> make[2]: *** Waiting for unfinished jobs....
> make[1]: *** [images] Error 2
> make: *** [images-only] Error 2
>
> A re-pull a few days ago didn't help matters, but I can try another
> re-pull & rebuild, given that everyone is pretty sure that this should
> work.
>
> Will let you know how I get on,
>
> Ben

From brian.goetz at oracle.com  Mon Feb 18 13:11:27 2013
From: brian.goetz at oracle.com (brian.goetz at oracle.com)
Date: Mon, 18 Feb 2013 21:11:27 +0000
Subject: hg: lambda/lambda/jdk: Spec for order-preservation and
	short-circuiting in Stream
Message-ID: <20130218211150.BD0CF47B73@hg.openjdk.java.net>

Changeset: c42ae1b08f91
Author:    briangoetz
Date:      2013-02-18 16:11 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/c42ae1b08f91

Spec for order-preservation and short-circuiting in Stream

! src/share/classes/java/util/stream/Stream.java
! src/share/classes/java/util/stream/package-info.java


From mike.duigou at oracle.com  Mon Feb 18 13:45:01 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Mon, 18 Feb 2013 13:45:01 -0800
Subject: Regular sync-ups from the upstream?
In-Reply-To: <CABKW8Rjsi52BqfGB3abS_t=02B5EtehnTDMinayBL_5+vn0uTw@mail.gmail.com>
References: <5121EAF8.80608@oracle.com>
	<CABKW8RgFZN9QXL1Jew2t6LePdPUaMBEW1obGdQZ8NF1XQSxSfA@mail.gmail.com>
	<F7EE3950-FA46-4D08-A42D-C14160FCAD7A@oracle.com>
	<CABKW8Ri2BydLB76KhH+427mN8scmoZBS9u9YQiaQNS-x8Vk+=Q@mail.gmail.com>
	<CABKW8Rjsi52BqfGB3abS_t=02B5EtehnTDMinayBL_5+vn0uTw@mail.gmail.com>
Message-ID: <603C947A-5459-420D-9550-E8DD3D21BA8F@oracle.com>

Good to hear that you got it working.

The forest extension has turned out to be unsuitable because it's not longer maintained. The current alternative is the get_sources.sh script in the root repo. (Which is actually faster than forest). I believe Kelly's latest OpenJDK README-build has eliminated mention of forest extension.

There has been work exploring alternatives to forest but to my knowledge not have yet progressed to an actual alternative.

The inability to generate webrevs for multi repo patches is the only real problem arising from lack of the forest extension.

Mike

On Feb 18 2013, at 12:38 , Ben Evans wrote:

> Fixed.
> 
> My install was not pulling correctly from hg - due to reasons which
> seem to be related to this issue:
> 
> http://mail.openjdk.java.net/pipermail/build-dev/2012-August/006588.html
> 
> Which is still not fixed :(
> 
> Ben
> 
> On Mon, Feb 18, 2013 at 2:07 PM, Ben Evans
> <benjamin.john.evans at gmail.com> wrote:
>> On Mon, Feb 18, 2013 at 1:47 PM, Mike Duigou <mike.duigou at oracle.com> wrote:
>>> On Feb 18 2013, at 10:29 , Ben Evans wrote:
>>> 
>>>> I'd like to echo this.
>>>> 
>>>> I'm trying to write a patch to java.util.regex.Pattern, which
>>>> implements methods for use with lambda expressions, to make using
>>>> regexps easy in Java 8.
>>>> 
>>>> Unfortunately, I have a couple of problems:
>>>> 
>>>> 1) The lambdas repo doesn't currently support Mac.
>>> 
>>> What problems are you running into on Mac? (and where were the problems reported)
>>> 
>>> We haven't seen any recent problems with the new build on Mac. There are a few known problems with image rebuilds but those aren't mac specific.
>> 
>> I've seen a chain of problems, most of which I was able to work around
>> - issues with lint flags, other make issues which I needed to hand
>> coax, etc, etc.
>> 
>> The current failure is:
>> 
>> ## Starting images
>> make[2]: *** No rule to make target `)', needed by
>> `/Users/boxcat/projects/lambda-old/build/macosx-x86_64-normal-server-release/images/lib/JObjC.jar'.
>> Stop.
>> make[2]: *** Waiting for unfinished jobs....
>> make[1]: *** [images] Error 2
>> make: *** [images-only] Error 2
>> 
>> A re-pull a few days ago didn't help matters, but I can try another
>> re-pull & rebuild, given that everyone is pretty sure that this should
>> work.
>> 
>> Will let you know how I get on,
>> 
>> Ben


From benjamin.john.evans at gmail.com  Mon Feb 18 13:59:14 2013
From: benjamin.john.evans at gmail.com (Ben Evans)
Date: Mon, 18 Feb 2013 16:59:14 -0500
Subject: Regular sync-ups from the upstream?
In-Reply-To: <603C947A-5459-420D-9550-E8DD3D21BA8F@oracle.com>
References: <5121EAF8.80608@oracle.com>
	<CABKW8RgFZN9QXL1Jew2t6LePdPUaMBEW1obGdQZ8NF1XQSxSfA@mail.gmail.com>
	<F7EE3950-FA46-4D08-A42D-C14160FCAD7A@oracle.com>
	<CABKW8Ri2BydLB76KhH+427mN8scmoZBS9u9YQiaQNS-x8Vk+=Q@mail.gmail.com>
	<CABKW8Rjsi52BqfGB3abS_t=02B5EtehnTDMinayBL_5+vn0uTw@mail.gmail.com>
	<603C947A-5459-420D-9550-E8DD3D21BA8F@oracle.com>
Message-ID: <CABKW8Rh7NkSoDcR9V831Gt+DqXLo6Lt4u+s5sTiJZP2ZaMMkUQ@mail.gmail.com>

OK, thanks for letting me know. There are still a bunch of extant
references to forest in some of the docs on wikis, so I'll purge all
the ones I have write access to.

Ben

On Mon, Feb 18, 2013 at 4:45 PM, Mike Duigou <mike.duigou at oracle.com> wrote:
> Good to hear that you got it working.
>
> The forest extension has turned out to be unsuitable because it's not longer maintained. The current alternative is the get_sources.sh script in the root repo. (Which is actually faster than forest). I believe Kelly's latest OpenJDK README-build has eliminated mention of forest extension.
>
> There has been work exploring alternatives to forest but to my knowledge not have yet progressed to an actual alternative.
>
> The inability to generate webrevs for multi repo patches is the only real problem arising from lack of the forest extension.
>
> Mike
>
> On Feb 18 2013, at 12:38 , Ben Evans wrote:
>
>> Fixed.
>>
>> My install was not pulling correctly from hg - due to reasons which
>> seem to be related to this issue:
>>
>> http://mail.openjdk.java.net/pipermail/build-dev/2012-August/006588.html
>>
>> Which is still not fixed :(
>>
>> Ben
>>
>> On Mon, Feb 18, 2013 at 2:07 PM, Ben Evans
>> <benjamin.john.evans at gmail.com> wrote:
>>> On Mon, Feb 18, 2013 at 1:47 PM, Mike Duigou <mike.duigou at oracle.com> wrote:
>>>> On Feb 18 2013, at 10:29 , Ben Evans wrote:
>>>>
>>>>> I'd like to echo this.
>>>>>
>>>>> I'm trying to write a patch to java.util.regex.Pattern, which
>>>>> implements methods for use with lambda expressions, to make using
>>>>> regexps easy in Java 8.
>>>>>
>>>>> Unfortunately, I have a couple of problems:
>>>>>
>>>>> 1) The lambdas repo doesn't currently support Mac.
>>>>
>>>> What problems are you running into on Mac? (and where were the problems reported)
>>>>
>>>> We haven't seen any recent problems with the new build on Mac. There are a few known problems with image rebuilds but those aren't mac specific.
>>>
>>> I've seen a chain of problems, most of which I was able to work around
>>> - issues with lint flags, other make issues which I needed to hand
>>> coax, etc, etc.
>>>
>>> The current failure is:
>>>
>>> ## Starting images
>>> make[2]: *** No rule to make target `)', needed by
>>> `/Users/boxcat/projects/lambda-old/build/macosx-x86_64-normal-server-release/images/lib/JObjC.jar'.
>>> Stop.
>>> make[2]: *** Waiting for unfinished jobs....
>>> make[1]: *** [images] Error 2
>>> make: *** [images-only] Error 2
>>>
>>> A re-pull a few days ago didn't help matters, but I can try another
>>> re-pull & rebuild, given that everyone is pretty sure that this should
>>> work.
>>>
>>> Will let you know how I get on,
>>>
>>> Ben
>

From brian.goetz at oracle.com  Mon Feb 18 14:02:34 2013
From: brian.goetz at oracle.com (brian.goetz at oracle.com)
Date: Mon, 18 Feb 2013 22:02:34 +0000
Subject: hg: lambda/lambda/jdk: Push iterator() default down into Stream;
	misc cleanups
Message-ID: <20130218220257.246B047B74@hg.openjdk.java.net>

Changeset: 8ebd78d84253
Author:    briangoetz
Date:      2013-02-18 17:02 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/8ebd78d84253

Push iterator() default down into Stream; misc cleanups

! src/share/classes/java/util/stream/AbstractPipeline.java
! src/share/classes/java/util/stream/BaseStream.java
! src/share/classes/java/util/stream/Nodes.java
! src/share/classes/java/util/stream/Stream.java


From david.holmes at oracle.com  Mon Feb 18 21:29:19 2013
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 19 Feb 2013 15:29:19 +1000
Subject: RFR (M) : JDK-8004561 : Addition Functional Interfaces for Lambda
	Libraries
In-Reply-To: <2CB90323-8862-4735-BC75-7A1EB3C8276B@oracle.com>
References: <2CB90323-8862-4735-BC75-7A1EB3C8276B@oracle.com>
Message-ID: <51230DAF.7030402@oracle.com>

Hi Mike,

In BinaryOperator.java this sentence doesn't read correctly:

+ * An operation upon two operands yielding a result. This is a 
specialization of
+ * {@code BiFunction} for the operands and the result are all being of 
the same
+ * type.

suggestions:

{@code BiFunction} for the case where the operands and the result are 
all of the same type.

{@code BiFunction} where the operands and the result are all of the same 
type.

---

DoubleUnaryOperator.java - this changed wording seems more awkward than 
the original:

      /**
-     * Returns the {@code double} result of the operation upon the
+     * Returns a {@code double} value result of the operation upon the
       * {@code double} operand.

---

Function.java

+ * @param <R> the type of result of the {@code apply} operation.

Either "the type of the result of the ...", or "the type of result from 
the ..."

---

General comment regarding specializations of Function. If we have 
Function<T, R> where R is the result type, then in the specializations 
which specialize the input type (T) then we should use R for the 
remaining type variable eg IntFunction<R> rather than IntFunction<T>

---

In LongFunction:

+     * @param l the input value

why use l as the parameter name? I presume for "long" but why? I thought 
the "i" parameter in IntFunction was so named for "input". I would much 
rather see a common parameter naming scheme being used (i, t, val, arg - 
any of these).

---

UnaryOperator.java

This sentence doesn't read right:

+ * result are of the same type. This is a specialization of {@code 
Function} for
+ * the operand and the result of the same type.

suggest:

"This is a specialization of {@code Function} for the case where the 
operand and result are of the same type."

---

package-info.java

I've flagged this elsewhere but you may not have seen it:

+ *     Predicate&lt;String>

If we use &lt; then we should also use &gt;.

---

BiFunction:

+ * is the two-arity specialization of {@link Consummer}

typo: Consummer

+ * @param <R> the type of output objects from {@code apply} operation.

from -> from the

----

The *BiXXX types are not consistently documented. For example:

BiFunction has:

+ * @param <T> the type of input objects provided to the {@code apply} 
operation.
+ * @param <U> the type of input objects provided to the {@code apply} 
operation.

while BiPredicate has:

+ * @param <T> the type of the first argument to {@code test}.
+ * @param <U> the type of the second argument to {@code test}.

I prefer the BiPredicate form.

---

DoublePredicate.java

+ * Determines if the {@code long} input value matches some criteria. 
This is the
+ * {@code double}-consuming primitive type specialization of {@link 
Predicate}.

The first "long" should be "double".

---

ToIntBiFunction.java

+ * Apply a function to the input argument,

argument -> arguments

---


Aside: it would be much easier to maintain consistent style if we used a 
"template" to define the main outline of each family of interfaces and 
generated the specializations from that (similar to how we generate the 
various bytebuffer classes).

Cheers,
David
------



On 16/02/2013 6:13 AM, Mike Duigou wrote:
> Hello All;
>
> This patch introduces a number of new functional interfaces for use by the lambda libraries. Also included are some name changes following JSR-225 EG review. The new interfaces are:
>
> BiConsumer
> BiFunction
> BiPredicate
> BooleanSupplier
> DoublePredicate
> IntPredicate
> LongPredicate
> ObjDoubleConsumer
> ObjIntConsumer
> ObjLongConsumer
> ToDoubleBiFunction
> ToDoubleFunction
> ToIntBiFunction
> ToIntFunction
> ToLongBiFunction
> ToLongFunction
>
> Renames:
>
> Block -> Consumer
> BiBlock -> BiConsumer
> IntBlock -> IntConsumer
> DoubleBlock -> LongConsumer
> LongBlock -> LongConsumer
> UnaryOperator.operate -> UnaryOperator.apply
> LongUnaryOperator.operateAsLong -> LongUnaryOperator.applyAsLong
> DoubleUnaryOperator.operateAsDouble -> DoubleUnaryOperator.applyAsDouble
> IntUnaryOperator.operateAsInt -> IntUnaryOperator.applyAsInt
> LongBinaryOperator.operateAsLong -> LongBinaryOperator.applyAsLong
> DoubleBinaryOperator.operateAsDouble -> DoubleBinaryOperator.applyAsDouble
> IntBinaryOperator.operateAsInt -> IntBinaryOperator.applyAsInt
>
> All of the changes outside the java.util.function package are made to accommodate these renamings.
>
> The webrev is located at:
>
> http://cr.openjdk.java.net/~mduigou/JDK-8004561/1/webrev/
>
> and specdiff for the java.util.function package is at:
>
> http://cr.openjdk.java.net/~mduigou/JDK-8004561/1/specdiff/
>
> Thanks!
>
> Mike
>
>

From paul.sandoz at oracle.com  Tue Feb 19 01:24:00 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 19 Feb 2013 10:24:00 +0100
Subject: hg: lambda/lambda/jdk: Modify the conc-Node spliterator forEach
	and tryAdvance from using the call
In-Reply-To: <CALNbAKyf3uOAmiUeUUzHyJ1TajH=Q8zk49DT+WD4T9HmEQNfuQ@mail.gmail.com>
References: <20130218141113.13E1347B5D@hg.openjdk.java.net>
	<CALNbAKyf3uOAmiUeUUzHyJ1TajH=Q8zk49DT+WD4T9HmEQNfuQ@mail.gmail.com>
Message-ID: <161EDA9A-7224-41EC-9625-7FAD18693753@oracle.com>

On Feb 18, 2013, at 7:44 PM, Edward Harned <edharned at gmail.com> wrote:
> Is the stack problem for serial, parallel or both?
> 

It can be both. A conc-Node is an intermediate result produced from a parallel computation which can be input to a another parallel or serial computation. It all depends at which Node in in the conc-Node tree traversal occurs at and the distance from that Node to the leaf Nodes.


> Do you have an example for where the problem lies? (a little stack trace maybe)
> 

The code to traverse the Spliterator of a conc-Node was recursive for both tryAdvance and forEach. For trees of large depth this can result in a stack overflow, especially on smaller memory configurations.

Consider a right-balanced tree such as that of a spliterator from an iterator. 

For large input, say 10^6 elements, this can result in a tree depth of at least 1024 (it's gonna be marginally higher soon when we change the way that spliterator works) and the stack depth will be proportional to that, for tryAdvance it was 4x e.g.:

"java.lang.StackOverflowError
	at java.util.stream.Nodes$InternalNodeSpliterator.internalTryAdvance(Nodes.java:559)
	at java.util.stream.Nodes$InternalNodeSpliterator$OfDouble.tryAdvance(Nodes.java:732)
	at java.util.stream.Nodes$InternalNodeSpliterator$OfDouble.tryAdvance(Nodes.java:737)
	at java.util.stream.Nodes$InternalNodeSpliterator$OfDouble.tryAdvance(Nodes.java:723)
	at java.util.stream.Nodes$InternalNodeSpliterator.internalTryAdvance(Nodes.java:566)
	at java.util.stream.Nodes$InternalNodeSpliterator$OfDouble.tryAdvance(Nodes.java:732)
	at java.util.stream.Nodes$InternalNodeSpliterator$OfDouble.tryAdvance(Nodes.java:737)
	at java.util.stream.Nodes$InternalNodeSpliterator$OfDouble.tryAdvance(Nodes.java:723)
	at java.util.stream.Nodes$InternalNodeSpliterator.internalTryAdvance(Nodes.java:562)

It is possible to reduce that 4x factor but that is not solving the underlying problem. Also tryAdvance was rather inefficient creating n wrapping Spliterators. So overall i think it a reasonable tradeoff.

The general aim is that a conc-Node represents the shape of the computation producing output elements i.e. it is already split for you for the next computation. The expectation is that splitting should occur all the way down to, or very close to, the leaf nodes. Note that operations like filter or flatMap (replace an element with zero or more elements) can distort the shape of the tree so it will not always be the case and it may be possible to create edge cases especially with right-balanced trees where things could blowup [*].

So this is really fixing for edge cases where those expectations do not hold, while still being efficient for the expected fast path of using forEach traversal close to or at the leaf nodes.

Hth,
Paul.

[*] Infact i should also update the count implementation to pre-compute the size when creating conc-Nodes, it any needs to be used so pre-calculating is more efficient.

> 
> On Mon, Feb 18, 2013 at 9:10 AM, <paul.sandoz at oracle.com> wrote:
> Changeset: 66c0dd07e288
> Author:    psandoz
> Date:      2013-02-18 15:09 +0100
> URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/66c0dd07e288
> 
> Modify the conc-Node spliterator forEach and tryAdvance from using the call
> stack to using an explicit (Deque) stack and a depth first search to
> find leaf nodes. This avoids stack overflow expceptions with tryAdvance
> and forEach for right-balanced or degenerate treess. This also avoids
> the internal creation of n spliterators when using tryAdvance, where n is the
> depth of the tree.
> 
> ! src/share/classes/java/util/stream/Nodes.java
> 
> 
> 


From maurizio.cimadamore at oracle.com  Tue Feb 19 03:34:09 2013
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Tue, 19 Feb 2013 11:34:09 +0000
Subject: hg: lambda/lambda/langtools: Fix: Avoid circularity between
	LambdaToMethod.visitClassDef and LambdaTranslationContext.complete()
Message-ID: <20130219113416.DA83A47B92@hg.openjdk.java.net>

Changeset: 9e101aaa2c5c
Author:    mcimadamore
Date:      2013-02-19 11:33 +0000
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/9e101aaa2c5c

Fix: Avoid circularity between LambdaToMethod.visitClassDef and LambdaTranslationContext.complete()

Simplify logic for handling classes nested within a lambda; Lower always capture 'this' when an inner class is defined in a non-static context - this update to LambdaToMethod reflects the behavior in Lower: any lambda (defined in a non-static context) defining an inner class will indirectly capture 'this'. Lambdas that do not define any inner classes will continue to capture 'this' on-demand.

! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java
! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java
! test/tools/javac/lambda/LambdaExpr15.java


From chris.hegarty at oracle.com  Tue Feb 19 05:12:31 2013
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 19 Feb 2013 13:12:31 +0000
Subject: Regular sync-ups from the upstream?
In-Reply-To: <603C947A-5459-420D-9550-E8DD3D21BA8F@oracle.com>
References: <5121EAF8.80608@oracle.com>
	<CABKW8RgFZN9QXL1Jew2t6LePdPUaMBEW1obGdQZ8NF1XQSxSfA@mail.gmail.com>
	<F7EE3950-FA46-4D08-A42D-C14160FCAD7A@oracle.com>
	<CABKW8Ri2BydLB76KhH+427mN8scmoZBS9u9YQiaQNS-x8Vk+=Q@mail.gmail.com>
	<CABKW8Rjsi52BqfGB3abS_t=02B5EtehnTDMinayBL_5+vn0uTw@mail.gmail.com>
	<603C947A-5459-420D-9550-E8DD3D21BA8F@oracle.com>
Message-ID: <BB7BF90D-66D9-45BB-8C52-191EFB8722E9@oracle.com>


On 18 Feb 2013, at 21:45, Mike Duigou <mike.duigou at oracle.com> wrote:

> Good to hear that you got it working.
> 
> The forest extension has turned out to be unsuitable because it's not longer maintained. The current alternative is the get_sources.sh script in the root repo. (Which is actually faster than forest). I believe Kelly's latest OpenJDK README-build has eliminated mention of forest extension.
> 
> There has been work exploring alternatives to forest but to my knowledge not have yet progressed to an actual alternative.
> 
> The inability to generate webrevs for multi repo patches is the only real problem arising from lack of the forest extension.

webrev accepts a file.list that can be used to pass the names of files from multiple repos

-Chris

> Mike
> 
> On Feb 18 2013, at 12:38 , Ben Evans wrote:
> 
>> Fixed.
>> 
>> My install was not pulling correctly from hg - due to reasons which
>> seem to be related to this issue:
>> 
>> http://mail.openjdk.java.net/pipermail/build-dev/2012-August/006588.html
>> 
>> Which is still not fixed :(
>> 
>> Ben
>> 
>> On Mon, Feb 18, 2013 at 2:07 PM, Ben Evans
>> <benjamin.john.evans at gmail.com> wrote:
>>> On Mon, Feb 18, 2013 at 1:47 PM, Mike Duigou <mike.duigou at oracle.com> wrote:
>>>> On Feb 18 2013, at 10:29 , Ben Evans wrote:
>>>> 
>>>>> I'd like to echo this.
>>>>> 
>>>>> I'm trying to write a patch to java.util.regex.Pattern, which
>>>>> implements methods for use with lambda expressions, to make using
>>>>> regexps easy in Java 8.
>>>>> 
>>>>> Unfortunately, I have a couple of problems:
>>>>> 
>>>>> 1) The lambdas repo doesn't currently support Mac.
>>>> 
>>>> What problems are you running into on Mac? (and where were the problems reported)
>>>> 
>>>> We haven't seen any recent problems with the new build on Mac. There are a few known problems with image rebuilds but those aren't mac specific.
>>> 
>>> I've seen a chain of problems, most of which I was able to work around
>>> - issues with lint flags, other make issues which I needed to hand
>>> coax, etc, etc.
>>> 
>>> The current failure is:
>>> 
>>> ## Starting images
>>> make[2]: *** No rule to make target `)', needed by
>>> `/Users/boxcat/projects/lambda-old/build/macosx-x86_64-normal-server-release/images/lib/JObjC.jar'.
>>> Stop.
>>> make[2]: *** Waiting for unfinished jobs....
>>> make[1]: *** [images] Error 2
>>> make: *** [images-only] Error 2
>>> 
>>> A re-pull a few days ago didn't help matters, but I can try another
>>> re-pull & rebuild, given that everyone is pretty sure that this should
>>> work.
>>> 
>>> Will let you know how I get on,
>>> 
>>> Ben
> 
> 

From aleksey.shipilev at oracle.com  Tue Feb 19 06:06:35 2013
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Tue, 19 Feb 2013 18:06:35 +0400
Subject: Regular sync-ups from the upstream?
In-Reply-To: <5121EAF8.80608@oracle.com>
References: <5121EAF8.80608@oracle.com>
Message-ID: <512386EB.8040900@oracle.com>

On 02/18/2013 12:48 PM, Aleksey Shipilev wrote:
> With the headlines like that, I'm going to ask regular sync-ups with the
> upstream to bring more goodness from regular channels, including
> non-lambda-specific j.u.c.*/HotSpot changes. Many of j.u.c. changes are
> pushed directly into jdk8.
> 
> Example: @Contended already accessible in jdk8-b75 (promoted Jan 31),
> but not accessible in jdk8-lambda-b76 (promoted Feb 05?),
> jdk8-lambda-b77 (promoted Feb 11?).

Feels like I'm at the Apple Store! :) Ben had sidetracked this thread to
Mac build problems. Can I please have my @Contended along with other
stuff jsr166 in lambda/lambda?

-Aleksey.

From chris.hegarty at oracle.com  Tue Feb 19 06:39:29 2013
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 19 Feb 2013 14:39:29 +0000
Subject: RFR (M) : JDK-8004561 : Addition Functional Interfaces for Lambda
	Libraries
In-Reply-To: <51230DAF.7030402@oracle.com>
References: <2CB90323-8862-4735-BC75-7A1EB3C8276B@oracle.com>
	<51230DAF.7030402@oracle.com>
Message-ID: <51238EA1.8030207@oracle.com>


On 02/19/2013 05:29 AM, David Holmes wrote:
> ...
> Aside: it would be much easier to maintain consistent style if we used a
> "template" to define the main outline of each family of interfaces and
> generated the specializations from that (similar to how we generate the
> various bytebuffer classes).

Oh, please god no! I find the way the buffer classes are generated a 
real pain. Yes, it is good for maintaining consistency across similar 
versions, but I don't see that as a good justification to introduce this 
complexity. I was secretly hoping that nio Buffer generation would go 
away in jdk8.

-Chris.

From Alan.Bateman at oracle.com  Tue Feb 19 07:08:16 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 19 Feb 2013 15:08:16 +0000
Subject: RFR (M) : JDK-8004561 : Addition Functional Interfaces for Lambda
	Libraries
In-Reply-To: <51238EA1.8030207@oracle.com>
References: <2CB90323-8862-4735-BC75-7A1EB3C8276B@oracle.com>
	<51230DAF.7030402@oracle.com> <51238EA1.8030207@oracle.com>
Message-ID: <51239560.1060505@oracle.com>

On 19/02/2013 14:39, Chris Hegarty wrote:
> :
>
> Oh, please god no! I find the way the buffer classes are generated a 
> real pain. Yes, it is good for maintaining consistency across similar 
> versions, but I don't see that as a good justification to introduce 
> this complexity. I was secretly hoping that nio Buffer generation 
> would go away in jdk8.
I assume the "pain" with the generated buffer classes is in the IDE so 
you need to remember to include the gensrc tree in the project.

-Alan.

From chris.hegarty at oracle.com  Tue Feb 19 07:14:41 2013
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 19 Feb 2013 15:14:41 +0000
Subject: RFR (M) : JDK-8004561 : Addition Functional Interfaces for Lambda
	Libraries
In-Reply-To: <51239560.1060505@oracle.com>
References: <2CB90323-8862-4735-BC75-7A1EB3C8276B@oracle.com>
	<51230DAF.7030402@oracle.com> <51238EA1.8030207@oracle.com>
	<51239560.1060505@oracle.com>
Message-ID: <512396E1.4010506@oracle.com>

On 02/19/2013 03:08 PM, Alan Bateman wrote:
> On 19/02/2013 14:39, Chris Hegarty wrote:
>> :
>>
>> Oh, please god no! I find the way the buffer classes are generated a
>> real pain. Yes, it is good for maintaining consistency across similar
>> versions, but I don't see that as a good justification to introduce
>> this complexity. I was secretly hoping that nio Buffer generation
>> would go away in jdk8.
> I assume the "pain" with the generated buffer classes is in the IDE so
> you need to remember to include the gensrc tree in the project.

Right, but this assumes you to have a build. They also don't play well 
with tools that index the source, like opengrok.

-Chris.

>
> -Alan.

From chris.hegarty at oracle.com  Tue Feb 19 07:44:21 2013
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 19 Feb 2013 15:44:21 +0000
Subject: RFR (M) : JDK-8004561 : Addition Functional Interfaces for Lambda
	Libraries
In-Reply-To: <51230DAF.7030402@oracle.com>
References: <2CB90323-8862-4735-BC75-7A1EB3C8276B@oracle.com>
	<51230DAF.7030402@oracle.com>
Message-ID: <51239DD5.2060106@oracle.com>

Mike,

Thanks for updating the j.u.c classes. David seems to have covered most 
of the issues, otherwise looks fine to me.

On 02/19/2013 05:29 AM, David Holmes wrote:
> ...
> package-info.java
>
> I've flagged this elsewhere but you may not have seen it:
>
> + *     Predicate&lt;String>
>
> If we use &lt; then we should also use &gt;.

Additionally, typo

58  *     and {@link java.util.function.Supplier} (@{code () -> T}).

-Chris.


From martinrb at google.com  Tue Feb 19 09:02:07 2013
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 19 Feb 2013 09:02:07 -0800
Subject: Regular sync-ups from the upstream?
In-Reply-To: <512386EB.8040900@oracle.com>
References: <5121EAF8.80608@oracle.com>
	<512386EB.8040900@oracle.com>
Message-ID: <CA+kOe08h=NMvG4kNAq8O4wV0OAczgUtW2BPqC5gDiTHPWLmS4A@mail.gmail.com>

On Tue, Feb 19, 2013 at 6:06 AM, Aleksey Shipilev <
aleksey.shipilev at oracle.com> wrote:

> On 02/18/2013 12:48 PM, Aleksey Shipilev wrote:
> > With the headlines like that, I'm going to ask regular sync-ups with the
> > upstream to bring more goodness from regular channels, including
> > non-lambda-specific j.u.c.*/HotSpot changes. Many of j.u.c. changes are
> > pushed directly into jdk8.
> >
> > Example: @Contended already accessible in jdk8-b75 (promoted Jan 31),
> > but not accessible in jdk8-lambda-b76 (promoted Feb 05?),
> > jdk8-lambda-b77 (promoted Feb 11?).
>
> Feels like I'm at the Apple Store! :) Ben had sidetracked this thread to
> Mac build problems. Can I please have my @Contended along with other
> stuff jsr166 in lambda/lambda?
>

Yes, please do whatever it takes so that jsr166 CVS can build and pass
tests (using lambda release for jdk8) using "ant compile test-tck
test-jtreg"

From mike.duigou at oracle.com  Tue Feb 19 10:03:25 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Tue, 19 Feb 2013 10:03:25 -0800
Subject: Regular sync-ups from the upstream?
In-Reply-To: <5121EAF8.80608@oracle.com>
References: <5121EAF8.80608@oracle.com>
Message-ID: <066FB295-7917-482E-A2B0-3B8A8C38068D@oracle.com>

I plan to sync lambda with JDK8 mainline Wednesday following the next lambda promotion. I can also try do a sync with JSR 166 though am a bit nervous about potentially destabilizing patches in hotspot. Would you happen to have a changeset? It would save time.

We are very much trying to reduce the scope and number of differences between JDK8 mainline and the lambda repo at this point. If there was a way to get the changes in to JDK mainline quicker then I would prefer to use that route. Regardless, I am still willing to do this sync.

Mike


On Feb 18 2013, at 00:48 , Aleksey Shipilev wrote:

> Hi guys,
> 
> It seems the lambda/lambda is the frontier of concurrency development
> these days. Both Doug had locked jsr166 to be compilable with the latest
> lambda/lambda, and me as well locked java-concurrency-torture to be
> compilable with the latest promoted build of jdk8-ea-lambda. (These
> address compilation of all these fancy lambda-enabled APIs).
> 
> With the headlines like that, I'm going to ask regular sync-ups with the
> upstream to bring more goodness from regular channels, including
> non-lambda-specific j.u.c.*/HotSpot changes. Many of j.u.c. changes are
> pushed directly into jdk8.
> 
> Example: @Contended already accessible in jdk8-b75 (promoted Jan 31),
> but not accessible in jdk8-lambda-b76 (promoted Feb 05?),
> jdk8-lambda-b77 (promoted Feb 11?).
> 
> Maybe I'm missing some part of the plan to integrate lambda/lambda to
> upstream jdk8 completely, which will move the development back to
> mainline, and the whole issue would be nilled out.
> 
> Thanks!
> -Aleksey.
> 
> 


From joe.darcy at oracle.com  Tue Feb 19 10:40:42 2013
From: joe.darcy at oracle.com (Joe Darcy)
Date: Tue, 19 Feb 2013 10:40:42 -0800
Subject: RFR (M) : JDK-8004561 : Addition Functional Interfaces for Lambda
	Libraries
In-Reply-To: <512396E1.4010506@oracle.com>
References: <2CB90323-8862-4735-BC75-7A1EB3C8276B@oracle.com>
	<51230DAF.7030402@oracle.com> <51238EA1.8030207@oracle.com>
	<51239560.1060505@oracle.com> <512396E1.4010506@oracle.com>
Message-ID: <5123C72A.30103@oracle.com>

On 02/19/2013 07:14 AM, Chris Hegarty wrote:
> On 02/19/2013 03:08 PM, Alan Bateman wrote:
>> On 19/02/2013 14:39, Chris Hegarty wrote:
>>> :
>>>
>>> Oh, please god no! I find the way the buffer classes are generated a
>>> real pain. Yes, it is good for maintaining consistency across similar
>>> versions, but I don't see that as a good justification to introduce
>>> this complexity. I was secretly hoping that nio Buffer generation
>>> would go away in jdk8.
>> I assume the "pain" with the generated buffer classes is in the IDE so
>> you need to remember to include the gensrc tree in the project.
> Right, but this assumes you to have a build. They also don't play well
> with tools that index the source, like opengrok.
>
>

As an aside, a code generation technique that should play better with 
tooling would to be use an annotation processor to generate the code 
from within the context of the compiler/IDE. As a general-purpose 
meta-programming system, annotation processing doesn't have to be tied 
to annotations.

-Joe

From maurizio.cimadamore at oracle.com  Tue Feb 19 10:45:54 2013
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Tue, 19 Feb 2013 18:45:54 +0000
Subject: hg: lambda/lambda/langtools: 8004962: Code generation crash with
	lambda and local classes
Message-ID: <20130219184600.8086F47BA8@hg.openjdk.java.net>

Changeset: 60ceb785855f
Author:    mcimadamore
Date:      2013-02-19 18:45 +0000
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/60ceb785855f

8004962: Code generation crash with lambda and local classes

! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java
! src/share/classes/com/sun/tools/javac/comp/Lower.java
! test/tools/javac/lambda/LambdaCapture06.java
+ test/tools/javac/lambda/LambdaCapture07.java


From mike.duigou at oracle.com  Tue Feb 19 11:14:00 2013
From: mike.duigou at oracle.com (mike.duigou at oracle.com)
Date: Tue, 19 Feb 2013 19:14:00 +0000
Subject: hg: lambda/lambda/jdk: Many more javadoc nits
Message-ID: <20130219191451.3362B47BAA@hg.openjdk.java.net>

Changeset: a29fc0151ed2
Author:    mduigou
Date:      2013-02-19 11:13 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/a29fc0151ed2

Many more javadoc nits

! src/share/classes/java/util/function/BiConsumer.java
! src/share/classes/java/util/function/BiFunction.java
! src/share/classes/java/util/function/BinaryOperator.java
! src/share/classes/java/util/function/DoubleFunction.java
! src/share/classes/java/util/function/DoublePredicate.java
! src/share/classes/java/util/function/DoubleUnaryOperator.java
! src/share/classes/java/util/function/Function.java
! src/share/classes/java/util/function/IntFunction.java
! src/share/classes/java/util/function/IntPredicate.java
! src/share/classes/java/util/function/LongFunction.java
! src/share/classes/java/util/function/LongPredicate.java
! src/share/classes/java/util/function/LongSupplier.java
! src/share/classes/java/util/function/ObjDoubleConsumer.java
! src/share/classes/java/util/function/ObjIntConsumer.java
! src/share/classes/java/util/function/ObjLongConsumer.java
! src/share/classes/java/util/function/Predicate.java
! src/share/classes/java/util/function/ToDoubleBiFunction.java
! src/share/classes/java/util/function/ToIntBiFunction.java
! src/share/classes/java/util/function/ToLongBiFunction.java
! src/share/classes/java/util/function/UnaryOperator.java
! src/share/classes/java/util/function/package-info.java


From edharned at gmail.com  Tue Feb 19 11:20:16 2013
From: edharned at gmail.com (Edward Harned)
Date: Tue, 19 Feb 2013 14:20:16 -0500
Subject: hg: lambda/lambda/jdk: Modify the conc-Node spliterator forEach
	and tryAdvance from using the call
In-Reply-To: <161EDA9A-7224-41EC-9625-7FAD18693753@oracle.com>
References: <20130218141113.13E1347B5D@hg.openjdk.java.net>
	<CALNbAKyf3uOAmiUeUUzHyJ1TajH=Q8zk49DT+WD4T9HmEQNfuQ@mail.gmail.com>
	<161EDA9A-7224-41EC-9625-7FAD18693753@oracle.com>
Message-ID: <CALNbAKxdv9Fm5n+p1xOz1K+AtpadX2OEkZFqMFARi+qbaFJCDg@mail.gmail.com>

Paul, thank you for the reply.

I?m looking for the root cause of this problem. When you talk about ?A
conc-Node is an intermediate result produced from a parallel computation ??
It makes me think of the join() in the F/J framework. Is this where it all
starts?

The intermediate join() is a known problem in F/J in both Java7 and Java8.
Bypassing join() with CountedCompleter doesn?t solve the excessive use of
resources problem caused by recursive decomposition.

For conc-Node: recursive decomposition only works well on small balanced
trees. When the level of recursion becomes lengthy, there could be a
resource failure (such as Stack Overflow.) It makes perfect sense ? do
more, do more, do more? At some point, it fails. The same problem as F/J
join().

The use of an ArrayDeque works for now by bypassing the calls, but as you
say filter or flatMap can still cause problems and it doesn?t address the
base problem as I see it: One thread is doing too much work. Recursive
decomposition doesn?t spread the work out to as many threads as possible;
it walks down the leaves of a balanced tree.

Am I on the right path here? streams/function packages are quite difficult
to follow sometimes.

If so, as I see it there needs to be more individual units-of-work spread
out to other threads and perhaps recursive decomposition isn?t the best
solution.

ed


On Tue, Feb 19, 2013 at 4:24 AM, Paul Sandoz <paul.sandoz at oracle.com> wrote:

> On Feb 18, 2013, at 7:44 PM, Edward Harned <edharned at gmail.com> wrote:
> > Is the stack problem for serial, parallel or both?
> >
>
> It can be both. A conc-Node is an intermediate result produced from a
> parallel computation which can be input to a another parallel or serial
> computation. It all depends at which Node in in the conc-Node tree
> traversal occurs at and the distance from that Node to the leaf Nodes.
>
>
> > Do you have an example for where the problem lies? (a little stack trace
> maybe)
> >
>
> The code to traverse the Spliterator of a conc-Node was recursive for both
> tryAdvance and forEach. For trees of large depth this can result in a stack
> overflow, especially on smaller memory configurations.
>
> Consider a right-balanced tree such as that of a spliterator from an
> iterator.
>
> For large input, say 10^6 elements, this can result in a tree depth of at
> least 1024 (it's gonna be marginally higher soon when we change the way
> that spliterator works) and the stack depth will be proportional to that,
> for tryAdvance it was 4x e.g.:
>
> "java.lang.StackOverflowError
>         at
> java.util.stream.Nodes$InternalNodeSpliterator.internalTryAdvance(Nodes.java:559)
>         at
> java.util.stream.Nodes$InternalNodeSpliterator$OfDouble.tryAdvance(Nodes.java:732)
>         at
> java.util.stream.Nodes$InternalNodeSpliterator$OfDouble.tryAdvance(Nodes.java:737)
>         at
> java.util.stream.Nodes$InternalNodeSpliterator$OfDouble.tryAdvance(Nodes.java:723)
>         at
> java.util.stream.Nodes$InternalNodeSpliterator.internalTryAdvance(Nodes.java:566)
>         at
> java.util.stream.Nodes$InternalNodeSpliterator$OfDouble.tryAdvance(Nodes.java:732)
>         at
> java.util.stream.Nodes$InternalNodeSpliterator$OfDouble.tryAdvance(Nodes.java:737)
>         at
> java.util.stream.Nodes$InternalNodeSpliterator$OfDouble.tryAdvance(Nodes.java:723)
>         at
> java.util.stream.Nodes$InternalNodeSpliterator.internalTryAdvance(Nodes.java:562)
>
> It is possible to reduce that 4x factor but that is not solving the
> underlying problem. Also tryAdvance was rather inefficient creating n
> wrapping Spliterators. So overall i think it a reasonable tradeoff.
>
> The general aim is that a conc-Node represents the shape of the
> computation producing output elements i.e. it is already split for you for
> the next computation. The expectation is that splitting should occur all
> the way down to, or very close to, the leaf nodes. Note that operations
> like filter or flatMap (replace an element with zero or more elements) can
> distort the shape of the tree so it will not always be the case and it may
> be possible to create edge cases especially with right-balanced trees where
> things could blowup [*].
>
> So this is really fixing for edge cases where those expectations do not
> hold, while still being efficient for the expected fast path of using
> forEach traversal close to or at the leaf nodes.
>
> Hth,
> Paul.
>
> [*] Infact i should also update the count implementation to pre-compute
> the size when creating conc-Nodes, it any needs to be used so
> pre-calculating is more efficient.
>
> >
> > On Mon, Feb 18, 2013 at 9:10 AM, <paul.sandoz at oracle.com> wrote:
> > Changeset: 66c0dd07e288
> > Author:    psandoz
> > Date:      2013-02-18 15:09 +0100
> > URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/66c0dd07e288
> >
> > Modify the conc-Node spliterator forEach and tryAdvance from using the
> call
> > stack to using an explicit (Deque) stack and a depth first search to
> > find leaf nodes. This avoids stack overflow expceptions with tryAdvance
> > and forEach for right-balanced or degenerate treess. This also avoids
> > the internal creation of n spliterators when using tryAdvance, where n
> is the
> > depth of the tree.
> >
> > ! src/share/classes/java/util/stream/Nodes.java
> >
> >
> >
>
>
>

From mike.duigou at oracle.com  Tue Feb 19 11:23:45 2013
From: mike.duigou at oracle.com (mike.duigou at oracle.com)
Date: Tue, 19 Feb 2013 19:23:45 +0000
Subject: hg: lambda/lambda/jdk: even more nits
Message-ID: <20130219192357.2DCD747BAB@hg.openjdk.java.net>

Changeset: 7bb08c5f4449
Author:    mduigou
Date:      2013-02-19 11:23 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/7bb08c5f4449

even more nits

! src/share/classes/java/util/function/BiFunction.java
! src/share/classes/java/util/function/DoubleBinaryOperator.java


From brian.goetz at oracle.com  Tue Feb 19 11:40:55 2013
From: brian.goetz at oracle.com (brian.goetz at oracle.com)
Date: Tue, 19 Feb 2013 19:40:55 +0000
Subject: hg: lambda/lambda/jdk: More spec for STreamOpFlags
Message-ID: <20130219194107.AB10C47BAC@hg.openjdk.java.net>

Changeset: 2ecfff76f078
Author:    briangoetz
Date:      2013-02-19 14:40 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/2ecfff76f078

More spec for STreamOpFlags

! src/share/classes/java/util/stream/StreamOpFlag.java


From mike.duigou at oracle.com  Tue Feb 19 12:03:12 2013
From: mike.duigou at oracle.com (mike.duigou at oracle.com)
Date: Tue, 19 Feb 2013 20:03:12 +0000
Subject: hg: lambda/lambda/jdk: test updates for JDK-8004561 renames
Message-ID: <20130219200324.8175547BAE@hg.openjdk.java.net>

Changeset: 698e5c0c020a
Author:    mduigou
Date:      2013-02-19 12:02 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/698e5c0c020a

test updates for JDK-8004561 renames

! test/java/lang/PrimitiveSumMinMaxTest.java


From mike.duigou at oracle.com  Tue Feb 19 12:22:07 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Tue, 19 Feb 2013 12:22:07 -0800
Subject: RFR (M) : JDK-8004561 : Addition Functional Interfaces for Lambda
	Libraries
In-Reply-To: <51230DAF.7030402@oracle.com>
References: <2CB90323-8862-4735-BC75-7A1EB3C8276B@oracle.com>
	<51230DAF.7030402@oracle.com>
Message-ID: <E59FE7FD-F885-43A3-95E8-F7F99D934F7F@oracle.com>

Thank you for the feedback David. 

On Feb 18 2013, at 21:29 , David Holmes wrote:

> package-info.java
> 
> I've flagged this elsewhere but you may not have seen it:
> 
> + *     Predicate&lt;String>
> 
> If we use &lt; then we should also use &gt;.

It's not required to use &gt; in HTML 4.01 transitional or HTML 5.0. Doclint was complaining about this but it has (or soon will be) amended. It could still be a style requirement to use &gt;

I will push this changeset with ">" but assume that if the decision is to require "&gt;" then doclint will remind us thoroughly and repeatedly to correct this before Java 8 is released. 

> Aside: it would be much easier to maintain consistent style if we used a "template" to define the main outline of each family of interfaces and generated the specializations from that (similar to how we generate the various bytebuffer classes).

Like Chris I have mixed feelings about templating for similar reasons. Our current generated sources work very poorly with IDEs. If we can improve the user experience with generated sources I would be very much willing to consider it.

Thanks again!

Mike


From brian.goetz at oracle.com  Tue Feb 19 12:30:13 2013
From: brian.goetz at oracle.com (brian.goetz at oracle.com)
Date: Tue, 19 Feb 2013 20:30:13 +0000
Subject: hg: lambda/lambda/jdk: Spec fixes in Optional
Message-ID: <20130219203026.C349E47BB1@hg.openjdk.java.net>

Changeset: 493df51924c8
Author:    briangoetz
Date:      2013-02-19 15:30 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/493df51924c8

Spec fixes in Optional

! src/share/classes/java/util/Optional.java


From benjamin.john.evans at gmail.com  Tue Feb 19 12:45:04 2013
From: benjamin.john.evans at gmail.com (Ben Evans)
Date: Tue, 19 Feb 2013 15:45:04 -0500
Subject: API question for point lambdafication
Message-ID: <CABKW8RhYyM3BDLPP80ZoNO6kzs_++TBktJN4hJX4okYhPR7KZw@mail.gmail.com>

Hi,

I've got my regex point lambdafication patch going against the current
state of lambda, but now I have an API question I'd like some feedback
on.

(Btw, if this is more appropriate for core-libs just let me know, and
I'll take my carcass over there & bug those guys instead.)

I currently have this new method on java.util.regex.Pattern:

public Stream<CharSequence> splitAsStream(final CharSequence input);

This provides a stream of values from the input CharSequence, split
around occurrences of this pattern.

However, as the return type of splitAsStream() is
Stream<CharSequence>, then we need to map stream values back to String
to be most useful, like this:

	List<String> out = p.splitAsStream(s)
                            .map(cs -> cs.toString())
                            .collect(Collectors.toList());

So, my question is this - should I continue to use the above
signature, or should it be:

public Stream<String> splitAsStream(final CharSequence input);

This avoids the need for the intermediate map(), which seems like a
bit of a wart to me.

Pattern has a vanilla split() method, which returns String[] - so for
those 2 reasons I'm minded towards the second form.

Anyone else have any thoughts about this?

Ben

From brian.goetz at oracle.com  Tue Feb 19 12:50:45 2013
From: brian.goetz at oracle.com (Brian Goetz)
Date: Tue, 19 Feb 2013 15:50:45 -0500
Subject: API question for point lambdafication
In-Reply-To: <CABKW8RhYyM3BDLPP80ZoNO6kzs_++TBktJN4hJX4okYhPR7KZw@mail.gmail.com>
References: <CABKW8RhYyM3BDLPP80ZoNO6kzs_++TBktJN4hJX4okYhPR7KZw@mail.gmail.com>
Message-ID: <5123E5A5.5010705@oracle.com>

The general advice is "be lenient in what you accept, and specific in 
what you return."  Which would argue for returning Stream<String>. 
Unless creating that String is very expensive and avoidable (neither of 
which are necessarily the case.)  So I think you're probably better off 
with Stream<String> since that's what people want.

BTW, the map parameter could be Object::toString instead of c -> 
c.toString().

On 2/19/2013 3:45 PM, Ben Evans wrote:
> Hi,
>
> I've got my regex point lambdafication patch going against the current
> state of lambda, but now I have an API question I'd like some feedback
> on.
>
> (Btw, if this is more appropriate for core-libs just let me know, and
> I'll take my carcass over there & bug those guys instead.)
>
> I currently have this new method on java.util.regex.Pattern:
>
> public Stream<CharSequence> splitAsStream(final CharSequence input);
>
> This provides a stream of values from the input CharSequence, split
> around occurrences of this pattern.
>
> However, as the return type of splitAsStream() is
> Stream<CharSequence>, then we need to map stream values back to String
> to be most useful, like this:
>
> 	List<String> out = p.splitAsStream(s)
>                              .map(cs -> cs.toString())
>                              .collect(Collectors.toList());
>
> So, my question is this - should I continue to use the above
> signature, or should it be:
>
> public Stream<String> splitAsStream(final CharSequence input);
>
> This avoids the need for the intermediate map(), which seems like a
> bit of a wart to me.
>
> Pattern has a vanilla split() method, which returns String[] - so for
> those 2 reasons I'm minded towards the second form.
>
> Anyone else have any thoughts about this?
>
> Ben
>

From zhong.j.yu at gmail.com  Tue Feb 19 13:49:14 2013
From: zhong.j.yu at gmail.com (Zhong Yu)
Date: Tue, 19 Feb 2013 15:49:14 -0600
Subject: API question for point lambdafication
In-Reply-To: <CABKW8RhYyM3BDLPP80ZoNO6kzs_++TBktJN4hJX4okYhPR7KZw@mail.gmail.com>
References: <CABKW8RhYyM3BDLPP80ZoNO6kzs_++TBktJN4hJX4okYhPR7KZw@mail.gmail.com>
Message-ID: <CACuKZqGHQCLQVVQdOUGiONiDFF+O2mGCy29eZUfuFncYEuYgWA@mail.gmail.com>

On Tue, Feb 19, 2013 at 2:45 PM, Ben Evans
<benjamin.john.evans at gmail.com> wrote:
> Hi,
>
> I've got my regex point lambdafication patch going against the current
> state of lambda, but now I have an API question I'd like some feedback
> on.
>
> (Btw, if this is more appropriate for core-libs just let me know, and
> I'll take my carcass over there & bug those guys instead.)
>
> I currently have this new method on java.util.regex.Pattern:
>
> public Stream<CharSequence> splitAsStream(final CharSequence input);

`input.subSequence()` can be expensive anyway; in String,
StringBuilder and StringBuffer, the method will copy the chars in
range. Therefore you may as well do the copy yourself to make Strings.

Currently String does not have a constructor like

    public String(CharSequence source, int offset, int count)

maybe it should be added?

Zhong Yu

> This provides a stream of values from the input CharSequence, split
> around occurrences of this pattern.
>
> However, as the return type of splitAsStream() is
> Stream<CharSequence>, then we need to map stream values back to String
> to be most useful, like this:
>
>         List<String> out = p.splitAsStream(s)
>                             .map(cs -> cs.toString())
>                             .collect(Collectors.toList());
>
> So, my question is this - should I continue to use the above
> signature, or should it be:
>
> public Stream<String> splitAsStream(final CharSequence input);
>
> This avoids the need for the intermediate map(), which seems like a
> bit of a wart to me.
>
> Pattern has a vanilla split() method, which returns String[] - so for
> those 2 reasons I'm minded towards the second form.
>
> Anyone else have any thoughts about this?
>
> Ben
>

From brian.goetz at oracle.com  Tue Feb 19 14:22:56 2013
From: brian.goetz at oracle.com (brian.goetz at oracle.com)
Date: Tue, 19 Feb 2013 22:22:56 +0000
Subject: hg: lambda/lambda/jdk: Javadoc for Stream
Message-ID: <20130219222308.EDA4C47BB3@hg.openjdk.java.net>

Changeset: 36482d2671d6
Author:    briangoetz
Date:      2013-02-19 17:22 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/36482d2671d6

Javadoc for Stream

! src/share/classes/java/util/stream/DelegatingStream.java
! src/share/classes/java/util/stream/ReferencePipeline.java
! src/share/classes/java/util/stream/Stream.java


From brian.goetz at oracle.com  Tue Feb 19 14:31:30 2013
From: brian.goetz at oracle.com (brian.goetz at oracle.com)
Date: Tue, 19 Feb 2013 22:31:30 +0000
Subject: hg: lambda/lambda/jdk: Add @since tags
Message-ID: <20130219223143.A964A47BB4@hg.openjdk.java.net>

Changeset: c68ca847f63a
Author:    briangoetz
Date:      2013-02-19 17:31 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/c68ca847f63a

Add @since tags

! src/share/classes/java/util/stream/AbstractPipeline.java
! src/share/classes/java/util/stream/AbstractShortCircuitTask.java
! src/share/classes/java/util/stream/AbstractSpinedBuffer.java
! src/share/classes/java/util/stream/AbstractTask.java
! src/share/classes/java/util/stream/BaseStream.java
! src/share/classes/java/util/stream/Collector.java
! src/share/classes/java/util/stream/Collectors.java
! src/share/classes/java/util/stream/ConcurrentCollectors.java
! src/share/classes/java/util/stream/DistinctOp.java
! src/share/classes/java/util/stream/DoublePipeline.java
! src/share/classes/java/util/stream/DoubleStream.java
! src/share/classes/java/util/stream/FindOp.java
! src/share/classes/java/util/stream/FlatMapper.java
! src/share/classes/java/util/stream/FoldOp.java
! src/share/classes/java/util/stream/ForEachOp.java
! src/share/classes/java/util/stream/ForEachUntilOp.java
! src/share/classes/java/util/stream/IntPipeline.java
! src/share/classes/java/util/stream/IntStream.java
! src/share/classes/java/util/stream/IntermediateOp.java
! src/share/classes/java/util/stream/LongPipeline.java
! src/share/classes/java/util/stream/LongStream.java
! src/share/classes/java/util/stream/MatchOp.java
! src/share/classes/java/util/stream/Node.java
! src/share/classes/java/util/stream/NodeUtils.java
! src/share/classes/java/util/stream/Nodes.java
! src/share/classes/java/util/stream/OpUtils.java
! src/share/classes/java/util/stream/PipelineHelper.java
! src/share/classes/java/util/stream/ReferencePipeline.java
! src/share/classes/java/util/stream/Sink.java
! src/share/classes/java/util/stream/SliceOp.java
! src/share/classes/java/util/stream/SortedOp.java
! src/share/classes/java/util/stream/SpinedBuffer.java
! src/share/classes/java/util/stream/Spliterators.java
! src/share/classes/java/util/stream/StatefulOp.java
! src/share/classes/java/util/stream/Stream.java
! src/share/classes/java/util/stream/StreamOpFlag.java
! src/share/classes/java/util/stream/StreamShape.java
! src/share/classes/java/util/stream/Streams.java
! src/share/classes/java/util/stream/TerminalOp.java
! src/share/classes/java/util/stream/TerminalSink.java
! src/share/classes/java/util/stream/Tripwire.java


From brian.goetz at oracle.com  Tue Feb 19 15:41:49 2013
From: brian.goetz at oracle.com (brian.goetz at oracle.com)
Date: Tue, 19 Feb 2013 23:41:49 +0000
Subject: hg: lambda/lambda/jdk: Rename forEachUntil to forEachUntilCancelled
Message-ID: <20130219234202.6F3AA47BB9@hg.openjdk.java.net>

Changeset: bb3af89c6549
Author:    briangoetz
Date:      2013-02-19 18:41 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/bb3af89c6549

Rename forEachUntil to forEachUntilCancelled

! src/share/classes/java/util/stream/DelegatingStream.java
! src/share/classes/java/util/stream/DoublePipeline.java
! src/share/classes/java/util/stream/DoubleStream.java
! src/share/classes/java/util/stream/IntPipeline.java
! src/share/classes/java/util/stream/IntStream.java
! src/share/classes/java/util/stream/LongPipeline.java
! src/share/classes/java/util/stream/LongStream.java
! src/share/classes/java/util/stream/ReferencePipeline.java
! src/share/classes/java/util/stream/Stream.java
! test-ng/tests/org/openjdk/tests/java/util/stream/ForEachOpTest.java
! test-ng/tests/org/openjdk/tests/java/util/stream/SortedOpTest.java
! test/java/util/stream/Stream/IntegerStreamTest.java


From david.holmes at oracle.com  Tue Feb 19 19:26:39 2013
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 20 Feb 2013 13:26:39 +1000
Subject: RFR (M) : JDK-8004561 : Addition Functional Interfaces for Lambda
	Libraries
In-Reply-To: <51238EA1.8030207@oracle.com>
References: <2CB90323-8862-4735-BC75-7A1EB3C8276B@oracle.com>
	<51230DAF.7030402@oracle.com> <51238EA1.8030207@oracle.com>
Message-ID: <5124426F.4020404@oracle.com>

On 20/02/2013 12:39 AM, Chris Hegarty wrote:
>
> On 02/19/2013 05:29 AM, David Holmes wrote:
>> ...
>> Aside: it would be much easier to maintain consistent style if we used a
>> "template" to define the main outline of each family of interfaces and
>> generated the specializations from that (similar to how we generate the
>> various bytebuffer classes).
>
> Oh, please god no! I find the way the buffer classes are generated a
> real pain. Yes, it is good for maintaining consistency across similar
> versions, but I don't see that as a good justification to introduce this
> complexity. I was secretly hoping that nio Buffer generation would go
> away in jdk8.

:) I only meant as a tool during development of the classes, not to 
actually generate them as part of the build.

Sorry for alarming you like that. :)

David

> -Chris.

From david.holmes at oracle.com  Tue Feb 19 19:37:21 2013
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 20 Feb 2013 13:37:21 +1000
Subject: RFR (M) : JDK-8004561 : Addition Functional Interfaces for Lambda
	Libraries
In-Reply-To: <E59FE7FD-F885-43A3-95E8-F7F99D934F7F@oracle.com>
References: <2CB90323-8862-4735-BC75-7A1EB3C8276B@oracle.com>
	<51230DAF.7030402@oracle.com>
	<E59FE7FD-F885-43A3-95E8-F7F99D934F7F@oracle.com>
Message-ID: <512444F1.2010600@oracle.com>

On 20/02/2013 6:22 AM, Mike Duigou wrote:
> Thank you for the feedback David.

So what got updated, if anything, before the push?

The biggest gripe I have with reviewing all this stuff is being able to 
keep track of what comments have been made, what comments have been 
acted upon and what is still outstanding. I'd love to see a nightly doc 
build with change bars; or a doc build with "annotations" highlighting 
known issues. Don't know if we have any tools capable of that though.

> On Feb 18 2013, at 21:29 , David Holmes wrote:
>
>> package-info.java
>>
>> I've flagged this elsewhere but you may not have seen it:
>>
>> + *     Predicate&lt;String>
>>
>> If we use &lt; then we should also use &gt;.
>
> It's not required to use &gt; in HTML 4.01 transitional or HTML 5.0. Doclint was complaining about this but it has (or soon will be) amended. It could still be a style requirement to use &gt;

Nothing like being inconsistent :( (that's directed at HTML standard)


> I will push this changeset with ">" but assume that if the decision is to require "&gt;" then doclint will remind us thoroughly and repeatedly to correct this before Java 8 is released.
>
>> Aside: it would be much easier to maintain consistent style if we used a "template" to define the main outline of each family of interfaces and generated the specializations from that (similar to how we generate the various bytebuffer classes).
>
> Like Chris I have mixed feelings about templating for similar reasons. Our current generated sources work very poorly with IDEs. If we can improve the user experience with generated sources I would be very much willing to consider it.

As I replied to Chris I didn't mean that as a permanent feature or even 
something committed at this stage - simply a tool to help with these 
repetitive definitions of class/method docs to ensure that they are 
consistent in the way they name and express things. Maybe there isn't 
enough commonality to make this worthwhile (you may still have multiple 
templates to keep consistent), but I know from past experience that this 
level of consistency is one of the hardest things to get right - it is 
tedious and error prone.

Cheers,
David

> Thanks again!
>
> Mike
>

From mike.duigou at oracle.com  Tue Feb 19 19:52:33 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Tue, 19 Feb 2013 19:52:33 -0800
Subject: RFR (M) : JDK-8004561 : Addition Functional Interfaces for Lambda
	Libraries
In-Reply-To: <512444F1.2010600@oracle.com>
References: <2CB90323-8862-4735-BC75-7A1EB3C8276B@oracle.com>
	<51230DAF.7030402@oracle.com>
	<E59FE7FD-F885-43A3-95E8-F7F99D934F7F@oracle.com>
	<512444F1.2010600@oracle.com>
Message-ID: <F93944FA-A126-45C4-B1A8-DAD065DE1C27@oracle.com>


On Feb 19 2013, at 19:37 , David Holmes wrote:

> On 20/02/2013 6:22 AM, Mike Duigou wrote:
>> Thank you for the feedback David.
> 
> So what got updated, if anything, before the push?

Everything. With the exception of the &gt; which I mentioned in my response I accepted all of your feedback suggestions as well as Chris's. It was good feedback!

> The biggest gripe I have with reviewing all this stuff is being able to keep track of what comments have been made, what comments have been acted upon and what is still outstanding.

Yes, from experience it's been too easy for review feedback and comments to get lost. I do try to either address as many of the comments as possible and proceed to produce an updated webrev or if nothing seems blocking, push the changeset.

> I'd love to see a nightly doc build with change bars; or a doc build with "annotations" highlighting known issues. Don't know if we have any tools capable of that though.

We don't unfortunately. And ultimately you'd want to be able to diff any two arbitrary versions from the repository. Tools like specdiff do exist for this but aren't hooked up in such a way to make generating the necessary reports simple. It's an infrastructure and tooling shortcoming. :-(

>> On Feb 18 2013, at 21:29 , David Holmes wrote:
>> 
>>> package-info.java
>>> 
>>> I've flagged this elsewhere but you may not have seen it:
>>> 
>>> + *     Predicate&lt;String>
>>> 
>>> If we use &lt; then we should also use &gt;.
>> 
>> It's not required to use &gt; in HTML 4.01 transitional or HTML 5.0. Doclint was complaining about this but it has (or soon will be) amended. It could still be a style requirement to use &gt;
> 
> Nothing like being inconsistent :( (that's directed at HTML standard)
> 
> 
>> I will push this changeset with ">" but assume that if the decision is to require "&gt;" then doclint will remind us thoroughly and repeatedly to correct this before Java 8 is released.
>> 
>>> Aside: it would be much easier to maintain consistent style if we used a "template" to define the main outline of each family of interfaces and generated the specializations from that (similar to how we generate the various bytebuffer classes).
>> 
>> Like Chris I have mixed feelings about templating for similar reasons. Our current generated sources work very poorly with IDEs. If we can improve the user experience with generated sources I would be very much willing to consider it.
> 
> As I replied to Chris I didn't mean that as a permanent feature or even something committed at this stage - simply a tool to help with these repetitive definitions of class/method docs to ensure that they are consistent in the way they name and express things. Maybe there isn't enough commonality to make this worthwhile (you may still have multiple templates to keep consistent), but I know from past experience that this level of consistency is one of the hardest things to get right - it is tedious and error prone.

I have been using a merge tool, meld, to try to make fewer transcription errors between the primitive specializations. I agree that some form of template would be the best solution in the long run.

We could add an explicit gensrc target to our make process which caused all of the generated/templated sources to be build for consumption by IDEs (and later build phases). This is the workflow used by maven projects and it seems to be OK. When you clone or update a maven project you re-run the equivalent of configure+gensrc to get the project ready for use by IDE tools.

> 
> Cheers,
> David
> 
>> Thanks again!
>> 
>> Mike
>> 


From mike.duigou at oracle.com  Tue Feb 19 21:59:42 2013
From: mike.duigou at oracle.com (mike.duigou at oracle.com)
Date: Wed, 20 Feb 2013 05:59:42 +0000
Subject: hg: lambda/lambda/jdk: cleanup nits before TL request for review
Message-ID: <20130220060006.B8A7947BD4@hg.openjdk.java.net>

Changeset: 8ecb70e1f9ab
Author:    mduigou
Date:      2013-02-19 18:30 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/8ecb70e1f9ab

cleanup nits before TL request for review

! src/share/classes/java/util/Optional.java
! src/share/classes/java/util/OptionalDouble.java
! src/share/classes/java/util/OptionalInt.java
! src/share/classes/java/util/OptionalLong.java


From paul.sandoz at oracle.com  Wed Feb 20 01:17:35 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 20 Feb 2013 10:17:35 +0100
Subject: API question for point lambdafication
In-Reply-To: <5123E5A5.5010705@oracle.com>
References: <CABKW8RhYyM3BDLPP80ZoNO6kzs_++TBktJN4hJX4okYhPR7KZw@mail.gmail.com>
	<5123E5A5.5010705@oracle.com>
Message-ID: <FB24A8AD-821D-4CCF-B917-620ACAD1CDC8@oracle.com>


On Feb 19, 2013, at 9:50 PM, Brian Goetz <brian.goetz at Oracle.COM> wrote:

> The general advice is "be lenient in what you accept, and specific in 
> what you return."  Which would argue for returning Stream<String>. 
> Unless creating that String is very expensive and avoidable (neither of 
> which are necessarily the case.)  So I think you're probably better off 
> with Stream<String> since that's what people want.
> 

i.e. like the existing Pattern.split methods that accept a CharSequence and return String[].

Paul.

From paul.sandoz at oracle.com  Wed Feb 20 01:31:30 2013
From: paul.sandoz at oracle.com (paul.sandoz at oracle.com)
Date: Wed, 20 Feb 2013 09:31:30 +0000
Subject: hg: lambda/lambda/jdk: Clean and fix int/long ranges for descending
	values.
Message-ID: <20130220093153.0B01047BE5@hg.openjdk.java.net>

Changeset: 812c8e032423
Author:    psandoz
Date:      2013-02-20 10:31 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/812c8e032423

Clean and fix int/long ranges for descending values.

! src/share/classes/java/util/stream/Streams.java
! test-ng/bootlib/java/util/stream/IntStreamTestDataProvider.java
! test-ng/bootlib/java/util/stream/LongStreamTestDataProvider.java
! test-ng/bootlib/java/util/stream/SpliteratorTestHelper.java
- test-ng/tests/org/openjdk/tests/java/util/stream/ParallelRangeTest.java
+ test-ng/tests/org/openjdk/tests/java/util/stream/RangeTest.java


From scolebourne at joda.org  Wed Feb 20 02:15:21 2013
From: scolebourne at joda.org (Stephen Colebourne)
Date: Wed, 20 Feb 2013 10:15:21 +0000
Subject: Return types array/list/stream [was: API question for point
	lambdafication]
Message-ID: <CACzrW9BiJdixr8uaO-8dDfka9MTOkyZ-9Deyq7kEC+O_db6vDg@mail.gmail.com>

I think there is a broader issue underlying Ben's proposed change to
String/regex that warrants proper discussion.

Currently in the JDK APIs we have variuos kinds of return type for
multiples of stuff. Now we are adding another

- arrays
- List
- Set
- Collection
- Iterable
- Iterator
- Enumeration
- Stream - new in JDK 1.8

I know I've personally found the array return types a right royal pain
on many occasions, and I think the decision to make Enum.values()
return an array was a big mistake.

In general, the Collection, Iterable, Iterator and Enumeration options
are relatively little used AFAICT. List is generally more common than
Set (because its much more useful to the client).

My point is that we need to decide on *why* an API should return
Stream rather than any of the other options.

My preference would be as folows:
- only use array as a return type to match other methods in the same type
- prefer List to Set or Collection
- prefer Stream to Iterator and Enumeration (and probably Iterable)
- prefer List to Stream for small/bounded data sets

Thus, on the last point, I would argue that String.splitAsStream() is
wrong, and should be String.splitToList().  (As a side note, with my
general "arrays are bad" hat on, returning an array here was another
bad choice)

Users wanting a stream can easily get it from the list. The reverse is
not so true, and almost certainly more wasteful.

Stephen


On 19 February 2013 20:45, Ben Evans <benjamin.john.evans at gmail.com> wrote:
> Hi,
>
> I've got my regex point lambdafication patch going against the current
> state of lambda, but now I have an API question I'd like some feedback
> on.
>
> (Btw, if this is more appropriate for core-libs just let me know, and
> I'll take my carcass over there & bug those guys instead.)
>
> I currently have this new method on java.util.regex.Pattern:
>
> public Stream<CharSequence> splitAsStream(final CharSequence input);
>
> This provides a stream of values from the input CharSequence, split
> around occurrences of this pattern.
>
> However, as the return type of splitAsStream() is
> Stream<CharSequence>, then we need to map stream values back to String
> to be most useful, like this:
>
>         List<String> out = p.splitAsStream(s)
>                             .map(cs -> cs.toString())
>                             .collect(Collectors.toList());
>
> So, my question is this - should I continue to use the above
> signature, or should it be:
>
> public Stream<String> splitAsStream(final CharSequence input);
>
> This avoids the need for the intermediate map(), which seems like a
> bit of a wart to me.
>
> Pattern has a vanilla split() method, which returns String[] - so for
> those 2 reasons I'm minded towards the second form.
>
> Anyone else have any thoughts about this?
>
> Ben
>

From paul.sandoz at oracle.com  Wed Feb 20 03:04:26 2013
From: paul.sandoz at oracle.com (paul.sandoz at oracle.com)
Date: Wed, 20 Feb 2013 11:04:26 +0000
Subject: hg: lambda/lambda/jdk: - Spliterator updates for collections and maps.
Message-ID: <20130220110505.E7C2A47BEC@hg.openjdk.java.net>

Changeset: ad8307f9f9a2
Author:    psandoz
Date:      2013-02-20 12:03 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/ad8307f9f9a2

- Spliterator updates for collections and maps.
- Introduce new spliterator from iterator algorithm
where left-hand split sizes follow an arithetic progression
up to a max size after which no more splits occur.
- TODO consolidate new spliterator from iterator algorithm and
array snapshot spliterator and consolidate spliterator impls and
static methods in a class java.util.Spliterators.
Contributed-by: Doug Lea <dl at cs.oswego.edu>

! src/share/classes/java/util/ArrayDeque.java
! src/share/classes/java/util/ArrayList.java
! src/share/classes/java/util/Collections.java
! src/share/classes/java/util/HashMap.java
! src/share/classes/java/util/HashSet.java
! src/share/classes/java/util/IdentityHashMap.java
! src/share/classes/java/util/LinkedList.java
! src/share/classes/java/util/PriorityQueue.java
! src/share/classes/java/util/TreeMap.java
! src/share/classes/java/util/TreeSet.java
! src/share/classes/java/util/Vector.java
! src/share/classes/java/util/WeakHashMap.java
! src/share/classes/java/util/concurrent/ArrayBlockingQueue.java
! src/share/classes/java/util/concurrent/ConcurrentHashMap.java
! src/share/classes/java/util/concurrent/ConcurrentLinkedDeque.java
! src/share/classes/java/util/concurrent/ConcurrentLinkedQueue.java
! src/share/classes/java/util/concurrent/ConcurrentSkipListMap.java
! src/share/classes/java/util/concurrent/ConcurrentSkipListSet.java
! src/share/classes/java/util/concurrent/CopyOnWriteArrayList.java
! src/share/classes/java/util/concurrent/CopyOnWriteArraySet.java
! src/share/classes/java/util/concurrent/LinkedBlockingDeque.java
! src/share/classes/java/util/concurrent/LinkedBlockingQueue.java
! src/share/classes/java/util/concurrent/LinkedTransferQueue.java
! src/share/classes/java/util/concurrent/PriorityBlockingQueue.java


From forax at univ-mlv.fr  Wed Feb 20 03:17:47 2013
From: forax at univ-mlv.fr (Remi Forax)
Date: Wed, 20 Feb 2013 12:17:47 +0100
Subject: Return types array/list/stream [was: API question for point
	lambdafication]
In-Reply-To: <CACzrW9BiJdixr8uaO-8dDfka9MTOkyZ-9Deyq7kEC+O_db6vDg@mail.gmail.com>
References: <CACzrW9BiJdixr8uaO-8dDfka9MTOkyZ-9Deyq7kEC+O_db6vDg@mail.gmail.com>
Message-ID: <5124B0DB.2020809@univ-mlv.fr>

On 02/20/2013 11:15 AM, Stephen Colebourne wrote:
> I think there is a broader issue underlying Ben's proposed change to
> String/regex that warrants proper discussion.
>
> Currently in the JDK APIs we have variuos kinds of return type for
> multiples of stuff. Now we are adding another
>
> - arrays
> - List
> - Set
> - Collection
> - Iterable
> - Iterator
> - Enumeration
> - Stream - new in JDK 1.8
>
> I know I've personally found the array return types a right royal pain
> on many occasions, and I think the decision to make Enum.values()
> return an array was a big mistake.
>
> In general, the Collection, Iterable, Iterator and Enumeration options
> are relatively little used AFAICT. List is generally more common than
> Set (because its much more useful to the client).
>
> My point is that we need to decide on *why* an API should return
> Stream rather than any of the other options.
>
> My preference would be as folows:
> - only use array as a return type to match other methods in the same type
> - prefer List to Set or Collection
> - prefer Stream to Iterator and Enumeration (and probably Iterable)
> - prefer List to Stream for small/bounded data sets
>
> Thus, on the last point, I would argue that String.splitAsStream() is
> wrong, and should be String.splitToList().  (As a side note, with my
> general "arrays are bad" hat on, returning an array here was another
> bad choice)
>
> Users wanting a stream can easily get it from the list. The reverse is
> not so true, and almost certainly more wasteful.
>
> Stephen

Most of java.lang uses arrays instead of List to avoid too many 
dependencies between
java.lang and java.util which cause nightmare during the booting 
sequence of the JDK.

and to answer to the question, when one should use a Stream or not,
a Stream is something which is conceptually lighter than an Iterator,
so I don't expect to (and hope to not) see a lot of methods that returns 
a Stream
apart the one from collections and the ones related to things that are 
inherently
a stream of data like a result of regular expression parsing.

R?mi

>
>
> On 19 February 2013 20:45, Ben Evans <benjamin.john.evans at gmail.com> wrote:
>> Hi,
>>
>> I've got my regex point lambdafication patch going against the current
>> state of lambda, but now I have an API question I'd like some feedback
>> on.
>>
>> (Btw, if this is more appropriate for core-libs just let me know, and
>> I'll take my carcass over there & bug those guys instead.)
>>
>> I currently have this new method on java.util.regex.Pattern:
>>
>> public Stream<CharSequence> splitAsStream(final CharSequence input);
>>
>> This provides a stream of values from the input CharSequence, split
>> around occurrences of this pattern.
>>
>> However, as the return type of splitAsStream() is
>> Stream<CharSequence>, then we need to map stream values back to String
>> to be most useful, like this:
>>
>>          List<String> out = p.splitAsStream(s)
>>                              .map(cs -> cs.toString())
>>                              .collect(Collectors.toList());
>>
>> So, my question is this - should I continue to use the above
>> signature, or should it be:
>>
>> public Stream<String> splitAsStream(final CharSequence input);
>>
>> This avoids the need for the intermediate map(), which seems like a
>> bit of a wart to me.
>>
>> Pattern has a vanilla split() method, which returns String[] - so for
>> those 2 reasons I'm minded towards the second form.
>>
>> Anyone else have any thoughts about this?
>>
>> Ben
>>


From paul.sandoz at oracle.com  Wed Feb 20 04:36:39 2013
From: paul.sandoz at oracle.com (paul.sandoz at oracle.com)
Date: Wed, 20 Feb 2013 12:36:39 +0000
Subject: hg: lambda/lambda/jdk: Add more collections and maps for laziness
	tests.
Message-ID: <20130220123701.9581A47BF4@hg.openjdk.java.net>

Changeset: 32b02cd378c7
Author:    psandoz
Date:      2013-02-20 13:36 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/32b02cd378c7

Add more collections and maps for laziness tests.

+ test-ng/tests/org/openjdk/tests/java/util/stream/CollectionAndMapModifyStreamTest.java
- test-ng/tests/org/openjdk/tests/java/util/stream/CollectionModifyStreamTest.java


From maurizio.cimadamore at oracle.com  Wed Feb 20 04:48:17 2013
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Wed, 20 Feb 2013 12:48:17 +0000
Subject: hg: lambda/lambda/langtools: Fixes:; ...
Message-ID: <20130220124822.6A4F047BF6@hg.openjdk.java.net>

Changeset: 75e630bb6743
Author:    mcimadamore
Date:      2013-02-20 12:47 +0000
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/75e630bb6743

Fixes:
8008540: Constructor reference to non-reifiable array should be rejected
8008539: Spurious error when constructor reference mention an interface type
8008538: Constructor reference accepts wildcard parameterized types

! src/share/classes/com/sun/tools/javac/comp/Check.java
! test/tools/javac/lambda/MethodReference38.out


From paul.sandoz at oracle.com  Wed Feb 20 05:25:44 2013
From: paul.sandoz at oracle.com (paul.sandoz at oracle.com)
Date: Wed, 20 Feb 2013 13:25:44 +0000
Subject: hg: lambda/lambda/jdk: Clean up data providers.
Message-ID: <20130220132606.736FC47BFD@hg.openjdk.java.net>

Changeset: 4d1928438109
Author:    psandoz
Date:      2013-02-20 14:25 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/4d1928438109

Clean up data providers.

! test-ng/bootlib/java/util/stream/DoubleStreamTestDataProvider.java
! test-ng/bootlib/java/util/stream/IntStreamTestDataProvider.java
! test-ng/bootlib/java/util/stream/LongStreamTestDataProvider.java
! test-ng/bootlib/java/util/stream/StreamTestDataProvider.java


From paul.sandoz at oracle.com  Wed Feb 20 05:58:01 2013
From: paul.sandoz at oracle.com (paul.sandoz at oracle.com)
Date: Wed, 20 Feb 2013 13:58:01 +0000
Subject: hg: lambda/lambda/jdk: - PipelineHelper.collect should flatten only
	if a parallel pipeline.
Message-ID: <20130220135823.2116447BFF@hg.openjdk.java.net>

Changeset: acfcba023020
Author:    psandoz
Date:      2013-02-20 14:57 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/acfcba023020

- PipelineHelper.collect should flatten only if a parallel pipeline.
- Add some more JavaDoc.

! src/share/classes/java/util/stream/AbstractPipeline.java
! src/share/classes/java/util/stream/PipelineHelper.java


From georgiy.rakov at oracle.com  Wed Feb 20 06:02:27 2013
From: georgiy.rakov at oracle.com (Georgiy Rakov)
Date: Wed, 20 Feb 2013 18:02:27 +0400
Subject: peek().iterator().hasNext() pre-consumes elements?
In-Reply-To: <511A916D.3080005@univ-mlv.fr>
References: <511A8193.2080402@oracle.com> <511A86F9.6010609@oracle.com>
	<511A916D.3080005@univ-mlv.fr>
Message-ID: <5124D773.10000@oracle.com>


On 12.02.2013 23:01, Remi Forax wrote:
> On 02/12/2013 07:16 PM, Brian Goetz wrote:
>> The answer here is complicated, but in general, calling hasNext may well
>> require consuming an element -- there's often no way to know whether a
>> source would produce an element without asking it to do so.  So it is a
>> common practice in implementing iterators to do this (one of many
>> reasons why we did not build Streams on Iterator.)
>>
>> Because the elements are coming from an array, it might be possible to
>> know simply based on how many elements have gone by that the stream is
>> not yet exhausted.  But in the general case (such as when the stream
>> source is an IO channel), it is not possible to know without actually
>> consuming and buffering some input.  So I would put this in the category
>> of "acceptable" behavior.  We might someday do some work to take
>> advantage of the fact that the source has the SIZED characteristic and
>> the pipeline stages are size-preserving to make this case behave
>> "better", but that would be an implementation quality issue, not a spec
>> issue.  The behavior you observe is allowable by the spec.
> while I a stream may have to do some buffering, peek should always be
> transparent and an iterator on an array doesn't need any buffering but I
> agree that this is an implementation issue.
>
> R?mi
I agree with R?mi that stream could do some buffering.

But regarding if it's an implementation issue or not I see it as follows.
This issue doesn't affect the *main purpose* of peek() that is to 
produce the same stream while iterating through its elements. But such 
behavior could be quite frustrating for experienced user because 
intuitively there is a way could be seen for implementation to avoid 
consuming the element (buffering). Such way doesn't always exist by the 
way, for instance for the following case: 
stream().filter(p).iterator().hasNext() - what is quite obvious for 
experienced user. So from the point of view that this issue doesn't 
affect the *main purpose* of peek() it could be seen as an 
implementation issue. But from the other hand it could be seen as /minor 
/(_not implementation_) issue because its result is visible through 
public API and this result could be quite frustrating.

Georgiy.

>> On 2/12/2013 12:53 PM, Dmitry Bessonov wrote:
>>> Hello,
>>>
>>> The following line prints out the first element, "1"
>>>
>>>       Arrays.asList(1, 2,
>>> 3).stream().peek(System.err::println).iterator().hasNext()
>>>
>>> Is it really an expected behavior?
>>>
>>> -Dmitry
>>>
>>>
>>>
>


From paul.sandoz at oracle.com  Wed Feb 20 06:29:35 2013
From: paul.sandoz at oracle.com (paul.sandoz at oracle.com)
Date: Wed, 20 Feb 2013 14:29:35 +0000
Subject: hg: lambda/lambda/jdk: The Node count will be required when the Node
	spliterator is obtained and it is cheaper
Message-ID: <20130220142956.1EE0247C01@hg.openjdk.java.net>

Changeset: 9d8305f2a26d
Author:    psandoz
Date:      2013-02-20 15:29 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/9d8305f2a26d

The Node count will be required when the Node spliterator is obtained and it is cheaper
to aggressively calculate bottom up as the tree is built rather than later on from the top down
traversing the tree.

! src/share/classes/java/util/stream/Nodes.java


From georgiy.rakov at oracle.com  Wed Feb 20 07:02:35 2013
From: georgiy.rakov at oracle.com (Georgiy Rakov)
Date: Wed, 20 Feb 2013 19:02:35 +0400
Subject: peek().iterator().hasNext() pre-consumes elements?
In-Reply-To: <511A916D.3080005@univ-mlv.fr>
References: <511A8193.2080402@oracle.com> <511A86F9.6010609@oracle.com>
	<511A916D.3080005@univ-mlv.fr>
Message-ID: <5124E58B.9040202@oracle.com>

Hello again,

it has just come into my mind that it could be quite more major issue 
than I wrote in my previous letter.

So the case a bit rewritten:

    Stream s1 = Arrays.asList(1, 2, 3).stream();
    Stream s2 = s1.peek(System.err::println);
    s2.iterator().hasNext();


The spec says:

    Produce a Stream containing the elements of this stream, and also
    provide elements to the specified Consumer as elements are *passed
    through*.

So the core question is what does "passed through" mean?From the first 
glance I would say it means *consuming elements from **stream returned 
****by peek()* (not from stream which peek() is applied to). If this 
interpretation is right then I could suppose it's a bug because the 
element from s2 has not been consumed yet (next() is not called just 
hasNext() has been called).

Could you please confirm if such reasoning is right and it's really a bug.

Thanks, Georgiy.

On 12.02.2013 23:01, Remi Forax wrote:
> On 02/12/2013 07:16 PM, Brian Goetz wrote:
>> The answer here is complicated, but in general, calling hasNext may well
>> require consuming an element -- there's often no way to know whether a
>> source would produce an element without asking it to do so.  So it is a
>> common practice in implementing iterators to do this (one of many
>> reasons why we did not build Streams on Iterator.)
>>
>> Because the elements are coming from an array, it might be possible to
>> know simply based on how many elements have gone by that the stream is
>> not yet exhausted.  But in the general case (such as when the stream
>> source is an IO channel), it is not possible to know without actually
>> consuming and buffering some input.  So I would put this in the category
>> of "acceptable" behavior.  We might someday do some work to take
>> advantage of the fact that the source has the SIZED characteristic and
>> the pipeline stages are size-preserving to make this case behave
>> "better", but that would be an implementation quality issue, not a spec
>> issue.  The behavior you observe is allowable by the spec.
> while I a stream may have to do some buffering, peek should always be
> transparent and an iterator on an array doesn't need any buffering but I
> agree that this is an implementation issue.
>
> R?mi
>
>> On 2/12/2013 12:53 PM, Dmitry Bessonov wrote:
>>> Hello,
>>>
>>> The following line prints out the first element, "1"
>>>
>>>       Arrays.asList(1, 2,
>>> 3).stream().peek(System.err::println).iterator().hasNext()
>>>
>>> Is it really an expected behavior?
>>>
>>> -Dmitry
>>>
>>>
>>>
>


From paul.sandoz at oracle.com  Wed Feb 20 07:40:12 2013
From: paul.sandoz at oracle.com (paul.sandoz at oracle.com)
Date: Wed, 20 Feb 2013 15:40:12 +0000
Subject: hg: lambda/lambda/jdk: Fix parition map iterator issue that was
	iterating twice over
Message-ID: <20130220154033.C573347C04@hg.openjdk.java.net>

Changeset: 49f8ac4374ad
Author:    psandoz
Date:      2013-02-20 16:39 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/49f8ac4374ad

Fix parition map iterator issue that was iterating twice over
the true partition.

! src/share/classes/java/util/stream/Collectors.java


From tom.hawtin at oracle.com  Wed Feb 20 08:10:46 2013
From: tom.hawtin at oracle.com (Tom Hawtin)
Date: Wed, 20 Feb 2013 16:10:46 +0000
Subject: Return types array/list/stream [was: API question for point
	lambdafication]
In-Reply-To: <5124B0DB.2020809@univ-mlv.fr>
References: <CACzrW9BiJdixr8uaO-8dDfka9MTOkyZ-9Deyq7kEC+O_db6vDg@mail.gmail.com>
	<5124B0DB.2020809@univ-mlv.fr>
Message-ID: <5124F586.9000307@oracle.com>

On 20/02/2013 11:17, Remi Forax wrote:

> Most of java.lang uses arrays instead of List to avoid too many
> dependencies between
> java.lang and java.util which cause nightmare during the booting
> sequence of the JDK.

Like many other packages, java.lang predates the Java2 collection 
framework, so has to use arrays. As practically everything already 
existing is using arrays, it's tricky to mix in collections just for new 
methods. It's a pity as "some things" is a pretty fundamental concept. 
Whereas a mutable, ordered collection of fixed size is an implementation 
detail that should be hidden away.

Dependency between packages does not fundamentally cause problems with 
start up. It's dependency between individual classes, irrespective of 
arbitrary package, which is important.

(It may be worth mentioning that implementation of fundamental types may 
be surprisingly complicated. For instance, HashMap currently does a lot 
of work to find a random number for some strange purpose.)

Tom

From brian.goetz at oracle.com  Wed Feb 20 08:35:09 2013
From: brian.goetz at oracle.com (Brian Goetz)
Date: Wed, 20 Feb 2013 11:35:09 -0500
Subject: Return types array/list/stream [was: API question for point
	lambdafication]
In-Reply-To: <CACzrW9BiJdixr8uaO-8dDfka9MTOkyZ-9Deyq7kEC+O_db6vDg@mail.gmail.com>
References: <CACzrW9BiJdixr8uaO-8dDfka9MTOkyZ-9Deyq7kEC+O_db6vDg@mail.gmail.com>
Message-ID: <5124FB3D.4060101@oracle.com>

> My preference would be as folows:
> - only use array as a return type to match other methods in the same type
> - prefer List to Set or Collection
> - prefer Stream to Iterator and Enumeration (and probably Iterable)
> - prefer List to Stream for small/bounded data sets
>
> Thus, on the last point, I would argue that String.splitAsStream() is
> wrong, and should be String.splitToList().  (As a side note, with my
> general "arrays are bad" hat on, returning an array here was another
> bad choice)
>
> Users wanting a stream can easily get it from the list. The reverse is
> not so true, and almost certainly more wasteful.

This ignores a significant consideration -- List requires buffering all 
the matches before any work can be done, whereas Stream is lazy.  What 
if the List is potentially huge (or infinite)?  What if you're only 
going to look at the first few?  What if producing elements is 
expensive?  What if you have an expensive operation to perform on the 
results, and want to do so in parallel?  In all of these cases, 
preferring List over Stream gives up significant performance 
opportunities.  And, constructing lists is likely to be more expensive 
than constructing streams.

The argument that we should "prefer List to Stream because you can 
always get a stream from a list" is too simplistic.

Regex parsing is a good example of where you might want a stream rather 
than a list, as you might well not consume all the matches.


From brian.goetz at oracle.com  Wed Feb 20 08:38:13 2013
From: brian.goetz at oracle.com (Brian Goetz)
Date: Wed, 20 Feb 2013 11:38:13 -0500
Subject: peek().iterator().hasNext() pre-consumes elements?
In-Reply-To: <5124E58B.9040202@oracle.com>
References: <511A8193.2080402@oracle.com> <511A86F9.6010609@oracle.com>
	<511A916D.3080005@univ-mlv.fr> <5124E58B.9040202@oracle.com>
Message-ID: <5124FBF5.60802@oracle.com>

Here's the current spec for this method -- does this help?

     /**
      * Produce a {@code Stream} containing the elements of this stream, 
and also provide elements
      * to the specified {@link Consumer} as elements are consumed from 
the resulting stream.  This is
      * an <a href="package-summary.html#StreamOps">intermediate 
operation</a>.
      * {@apiNote}
      * This method exists mainly to support debugging, where you want 
to see the elements as they flow past a certain
      * point in a pipeline:
      * <pre>
      *     list.stream()
      *         .filter(filteringFunction)
      *         .peek(e -> {System.out.println("Filtered value: " + e); });
      *         .map(mappingFunction)
      *         .peek(e -> {System.out.println("Mapped value: " + e); });
      *         .collect(Collectors.intoList());
      * </pre>
      *
      * <p>For parallel stream pipelines, the {@code Consumer} may be 
called at whatever time and in whatever thread
      * the element is made available by the upstream operation.  If the 
{@code Consumer} modifies shared state,
      * it is responsible for providing the required synchronization.
      *
      * @param consumer The {@code Consumer} to receive the elements
      */



On 2/20/2013 10:02 AM, Georgiy Rakov wrote:
> Hello again,
>
> it has just come into my mind that it could be quite more major issue
> than I wrote in my previous letter.
>
> So the case a bit rewritten:
>
>     Stream s1 = Arrays.asList(1, 2, 3).stream();
>     Stream s2 = s1.peek(System.err::println);
>     s2.iterator().hasNext();
>
>
> The spec says:
>
>     Produce a Stream containing the elements of this stream, and also
>     provide elements to the specified Consumer as elements are *passed
>     through*.
>
> So the core question is what does "passed through" mean?From the first
> glance I would say it means *consuming elements from **stream returned
> ****by peek()* (not from stream which peek() is applied to). If this
> interpretation is right then I could suppose it's a bug because the
> element from s2 has not been consumed yet (next() is not called just
> hasNext() has been called).
>
> Could you please confirm if such reasoning is right and it's really a bug.
>
> Thanks, Georgiy.
>
> On 12.02.2013 23:01, Remi Forax wrote:
>> On 02/12/2013 07:16 PM, Brian Goetz wrote:
>>> The answer here is complicated, but in general, calling hasNext may well
>>> require consuming an element -- there's often no way to know whether a
>>> source would produce an element without asking it to do so.  So it is a
>>> common practice in implementing iterators to do this (one of many
>>> reasons why we did not build Streams on Iterator.)
>>>
>>> Because the elements are coming from an array, it might be possible to
>>> know simply based on how many elements have gone by that the stream is
>>> not yet exhausted.  But in the general case (such as when the stream
>>> source is an IO channel), it is not possible to know without actually
>>> consuming and buffering some input.  So I would put this in the category
>>> of "acceptable" behavior.  We might someday do some work to take
>>> advantage of the fact that the source has the SIZED characteristic and
>>> the pipeline stages are size-preserving to make this case behave
>>> "better", but that would be an implementation quality issue, not a spec
>>> issue.  The behavior you observe is allowable by the spec.
>> while I a stream may have to do some buffering, peek should always be
>> transparent and an iterator on an array doesn't need any buffering but I
>> agree that this is an implementation issue.
>>
>> R?mi
>>
>>> On 2/12/2013 12:53 PM, Dmitry Bessonov wrote:
>>>> Hello,
>>>>
>>>> The following line prints out the first element, "1"
>>>>
>>>>       Arrays.asList(1, 2,
>>>> 3).stream().peek(System.err::println).iterator().hasNext()
>>>>
>>>> Is it really an expected behavior?
>>>>
>>>> -Dmitry
>>>>
>>>>
>>>>
>>
>

From misterm at gmail.com  Wed Feb 20 08:46:50 2013
From: misterm at gmail.com (Michael Nascimento)
Date: Wed, 20 Feb 2013 13:46:50 -0300
Subject: Return types array/list/stream [was: API question for point
	lambdafication]
In-Reply-To: <5124FB3D.4060101@oracle.com>
References: <CACzrW9BiJdixr8uaO-8dDfka9MTOkyZ-9Deyq7kEC+O_db6vDg@mail.gmail.com>
	<5124FB3D.4060101@oracle.com>
Message-ID: <CAAWA2oUYZ1g9W1S+J4MNGNs780j0ScF=H0vMvmb82psvFaX3jA@mail.gmail.com>

Given your reasoning, shouldn't the default be Stream from now on?

Regards,
Michael

On Wed, Feb 20, 2013 at 1:35 PM, Brian Goetz <brian.goetz at oracle.com> wrote:
>> My preference would be as folows:
>> - only use array as a return type to match other methods in the same type
>> - prefer List to Set or Collection
>> - prefer Stream to Iterator and Enumeration (and probably Iterable)
>> - prefer List to Stream for small/bounded data sets
>>
>> Thus, on the last point, I would argue that String.splitAsStream() is
>> wrong, and should be String.splitToList().  (As a side note, with my
>> general "arrays are bad" hat on, returning an array here was another
>> bad choice)
>>
>> Users wanting a stream can easily get it from the list. The reverse is
>> not so true, and almost certainly more wasteful.
>
> This ignores a significant consideration -- List requires buffering all
> the matches before any work can be done, whereas Stream is lazy.  What
> if the List is potentially huge (or infinite)?  What if you're only
> going to look at the first few?  What if producing elements is
> expensive?  What if you have an expensive operation to perform on the
> results, and want to do so in parallel?  In all of these cases,
> preferring List over Stream gives up significant performance
> opportunities.  And, constructing lists is likely to be more expensive
> than constructing streams.
>
> The argument that we should "prefer List to Stream because you can
> always get a stream from a list" is too simplistic.
>
> Regex parsing is a good example of where you might want a stream rather
> than a list, as you might well not consume all the matches.
>
>

From scolebourne at joda.org  Wed Feb 20 08:47:41 2013
From: scolebourne at joda.org (Stephen Colebourne)
Date: Wed, 20 Feb 2013 16:47:41 +0000
Subject: Return types array/list/stream [was: API question for point
	lambdafication]
In-Reply-To: <5124FB3D.4060101@oracle.com>
References: <CACzrW9BiJdixr8uaO-8dDfka9MTOkyZ-9Deyq7kEC+O_db6vDg@mail.gmail.com>
	<5124FB3D.4060101@oracle.com>
Message-ID: <CACzrW9ApNUE8w3mL2-EOM0TFRCrKRJY7b_v0xLueXHawyg9OGQ@mail.gmail.com>

On 20 February 2013 16:35, Brian Goetz <brian.goetz at oracle.com> wrote:
>> My preference would be as folows:
>> - only use array as a return type to match other methods in the same type
>> - prefer List to Set or Collection
>> - prefer Stream to Iterator and Enumeration (and probably Iterable)
>> - prefer List to Stream for small/bounded data sets
>>
>> Thus, on the last point, I would argue that String.splitAsStream() is
>> wrong, and should be String.splitToList().  (As a side note, with my
>> general "arrays are bad" hat on, returning an array here was another
>> bad choice)
>>
>> Users wanting a stream can easily get it from the list. The reverse is
>> not so true, and almost certainly more wasteful.
>
> This ignores a significant consideration -- List requires buffering all the
> matches before any work can be done, whereas Stream is lazy.  What if the
> List is potentially huge (or infinite)?  What if you're only going to look
> at the first few?  What if producing elements is expensive?  What if you
> have an expensive operation to perform on the results, and want to do so in
> parallel?  In all of these cases, preferring List over Stream gives up
> significant performance opportunities.  And, constructing lists is likely to
> be more expensive than constructing streams.
>
> The argument that we should "prefer List to Stream because you can always
> get a stream from a list" is too simplistic.

And I didn't say that... I said "prefer List to Stream for
small/bounded data sets"

> Regex parsing is a good example of where you might want a stream rather than
> a list, as you might well not consume all the matches.

My regex usage tends to be on small (<128 character, or a typical
"line") strings where I want to extract out groups of text. I can
always cope with the entire list of results, and I often want to
access them in random order. For my use case, returning a list would
often have been more useful than an array.

I still say that the original question stands. And I ask it because I
think, like all new features, there is a danger of over-use. Laying
down some guidelines on usage is a Good Thing IMO. Stream really
shouldn't be the default return type - List is frequently much more
useful to clients.

Stephen

From brian.goetz at oracle.com  Wed Feb 20 08:52:28 2013
From: brian.goetz at oracle.com (Brian Goetz)
Date: Wed, 20 Feb 2013 11:52:28 -0500
Subject: Return types array/list/stream [was: API question for point
	lambdafication]
In-Reply-To: <CAAWA2oUYZ1g9W1S+J4MNGNs780j0ScF=H0vMvmb82psvFaX3jA@mail.gmail.com>
References: <CACzrW9BiJdixr8uaO-8dDfka9MTOkyZ-9Deyq7kEC+O_db6vDg@mail.gmail.com>
	<5124FB3D.4060101@oracle.com>
	<CAAWA2oUYZ1g9W1S+J4MNGNs780j0ScF=H0vMvmb82psvFaX3jA@mail.gmail.com>
Message-ID: <5124FF4C.2020405@oracle.com>

I don't want to risk taking it too in the other direction, but I do 
think the points in favor of Stream are applicable in a lot of 
situations.  But as always, it requires some analysis about what you 
expect people to DO with the result.


On 2/20/2013 11:46 AM, Michael Nascimento wrote:
> Given your reasoning, shouldn't the default be Stream from now on?
>
> Regards,
> Michael
>
> On Wed, Feb 20, 2013 at 1:35 PM, Brian Goetz <brian.goetz at oracle.com> wrote:
>>> My preference would be as folows:
>>> - only use array as a return type to match other methods in the same type
>>> - prefer List to Set or Collection
>>> - prefer Stream to Iterator and Enumeration (and probably Iterable)
>>> - prefer List to Stream for small/bounded data sets
>>>
>>> Thus, on the last point, I would argue that String.splitAsStream() is
>>> wrong, and should be String.splitToList().  (As a side note, with my
>>> general "arrays are bad" hat on, returning an array here was another
>>> bad choice)
>>>
>>> Users wanting a stream can easily get it from the list. The reverse is
>>> not so true, and almost certainly more wasteful.
>>
>> This ignores a significant consideration -- List requires buffering all
>> the matches before any work can be done, whereas Stream is lazy.  What
>> if the List is potentially huge (or infinite)?  What if you're only
>> going to look at the first few?  What if producing elements is
>> expensive?  What if you have an expensive operation to perform on the
>> results, and want to do so in parallel?  In all of these cases,
>> preferring List over Stream gives up significant performance
>> opportunities.  And, constructing lists is likely to be more expensive
>> than constructing streams.
>>
>> The argument that we should "prefer List to Stream because you can
>> always get a stream from a list" is too simplistic.
>>
>> Regex parsing is a good example of where you might want a stream rather
>> than a list, as you might well not consume all the matches.
>>
>>

From pdoubleya at gmail.com  Wed Feb 20 08:54:24 2013
From: pdoubleya at gmail.com (Patrick Wright)
Date: Wed, 20 Feb 2013 17:54:24 +0100
Subject: Return types array/list/stream [was: API question for point
	lambdafication]
In-Reply-To: <CACzrW9ApNUE8w3mL2-EOM0TFRCrKRJY7b_v0xLueXHawyg9OGQ@mail.gmail.com>
References: <CACzrW9BiJdixr8uaO-8dDfka9MTOkyZ-9Deyq7kEC+O_db6vDg@mail.gmail.com>
	<5124FB3D.4060101@oracle.com>
	<CACzrW9ApNUE8w3mL2-EOM0TFRCrKRJY7b_v0xLueXHawyg9OGQ@mail.gmail.com>
Message-ID: <CAFn-HvvJ-Vk5gmG1TYtxtN8Y9HdPKKCV6S6WRooYZamz1__WvQ@mail.gmail.com>

Stephen,


think, like all new features, there is a danger of over-use. Laying
> down some guidelines on usage is a Good Thing IMO. Stream really
> shouldn't be the default return type - List is frequently much more
> useful to clients.
>
> For the record, can you tell us exactly why (perhaps with code examples)
you feel that "list is...more useful to clients?"

Thanks,
Patrick

From scolebourne at joda.org  Wed Feb 20 09:22:26 2013
From: scolebourne at joda.org (Stephen Colebourne)
Date: Wed, 20 Feb 2013 17:22:26 +0000
Subject: Return types array/list/stream [was: API question for point
	lambdafication]
In-Reply-To: <CAFn-HvvJ-Vk5gmG1TYtxtN8Y9HdPKKCV6S6WRooYZamz1__WvQ@mail.gmail.com>
References: <CACzrW9BiJdixr8uaO-8dDfka9MTOkyZ-9Deyq7kEC+O_db6vDg@mail.gmail.com>
	<5124FB3D.4060101@oracle.com>
	<CACzrW9ApNUE8w3mL2-EOM0TFRCrKRJY7b_v0xLueXHawyg9OGQ@mail.gmail.com>
	<CAFn-HvvJ-Vk5gmG1TYtxtN8Y9HdPKKCV6S6WRooYZamz1__WvQ@mail.gmail.com>
Message-ID: <CACzrW9CZe2PqPzx-mjTJx-u=-H2vLqE1s7ZMmABRRxAAKjryNA@mail.gmail.com>

On 20 February 2013 16:54, Patrick Wright <pdoubleya at gmail.com> wrote:
>> think, like all new features, there is a danger of over-use. Laying
>> down some guidelines on usage is a Good Thing IMO. Stream really
>> shouldn't be the default return type - List is frequently much more
>> useful to clients.
>>
> For the record, can you tell us exactly why (perhaps with code examples) you
> feel that "list is...more useful to clients?"

Asides from having a working toString, hashCode, equals, it has many
other methods that allow practical manipulation by developers, such as
indexOf, lastIndexOf, contains or subList. It can also be passed on to
other methods (which you may not have written) that expect a list.
While all of these things can be achieved using an array, they are
frequently a pain to read.

I don't recall writing code returning an array publicly in a long
time. If I reviewed any code from someone doing it I'd want a very
good justification for using an array.

Stephen

From sam at sampullara.com  Wed Feb 20 09:36:38 2013
From: sam at sampullara.com (Sam Pullara)
Date: Wed, 20 Feb 2013 09:36:38 -0800
Subject: Return types array/list/stream [was: API question for point
	lambdafication]
In-Reply-To: <CACzrW9CZe2PqPzx-mjTJx-u=-H2vLqE1s7ZMmABRRxAAKjryNA@mail.gmail.com>
References: <CACzrW9BiJdixr8uaO-8dDfka9MTOkyZ-9Deyq7kEC+O_db6vDg@mail.gmail.com>
	<5124FB3D.4060101@oracle.com>
	<CACzrW9ApNUE8w3mL2-EOM0TFRCrKRJY7b_v0xLueXHawyg9OGQ@mail.gmail.com>
	<CAFn-HvvJ-Vk5gmG1TYtxtN8Y9HdPKKCV6S6WRooYZamz1__WvQ@mail.gmail.com>
	<CACzrW9CZe2PqPzx-mjTJx-u=-H2vLqE1s7ZMmABRRxAAKjryNA@mail.gmail.com>
Message-ID: <CAMUF1S=HNuTgkmJ+1cV1nETnzbXyj1DhqxZDmTcdqmVt6XhEhw@mail.gmail.com>

I'd much rather not have the API allocating a List for me, so put me
firmly in the return a Stream camp.

Sam

On Wed, Feb 20, 2013 at 9:22 AM, Stephen Colebourne
<scolebourne at joda.org> wrote:
> On 20 February 2013 16:54, Patrick Wright <pdoubleya at gmail.com> wrote:
>>> think, like all new features, there is a danger of over-use. Laying
>>> down some guidelines on usage is a Good Thing IMO. Stream really
>>> shouldn't be the default return type - List is frequently much more
>>> useful to clients.
>>>
>> For the record, can you tell us exactly why (perhaps with code examples) you
>> feel that "list is...more useful to clients?"
>
> Asides from having a working toString, hashCode, equals, it has many
> other methods that allow practical manipulation by developers, such as
> indexOf, lastIndexOf, contains or subList. It can also be passed on to
> other methods (which you may not have written) that expect a list.
> While all of these things can be achieved using an array, they are
> frequently a pain to read.
>
> I don't recall writing code returning an array publicly in a long
> time. If I reviewed any code from someone doing it I'd want a very
> good justification for using an array.
>
> Stephen
>

From zhong.j.yu at gmail.com  Wed Feb 20 09:58:56 2013
From: zhong.j.yu at gmail.com (Zhong Yu)
Date: Wed, 20 Feb 2013 11:58:56 -0600
Subject: Return types array/list/stream [was: API question for point
	lambdafication]
In-Reply-To: <CACzrW9CZe2PqPzx-mjTJx-u=-H2vLqE1s7ZMmABRRxAAKjryNA@mail.gmail.com>
References: <CACzrW9BiJdixr8uaO-8dDfka9MTOkyZ-9Deyq7kEC+O_db6vDg@mail.gmail.com>
	<5124FB3D.4060101@oracle.com>
	<CACzrW9ApNUE8w3mL2-EOM0TFRCrKRJY7b_v0xLueXHawyg9OGQ@mail.gmail.com>
	<CAFn-HvvJ-Vk5gmG1TYtxtN8Y9HdPKKCV6S6WRooYZamz1__WvQ@mail.gmail.com>
	<CACzrW9CZe2PqPzx-mjTJx-u=-H2vLqE1s7ZMmABRRxAAKjryNA@mail.gmail.com>
Message-ID: <CACuKZqF+JLBhrSNFP9qVHmfvtCiFn0GcHFGQyLOFhZvC-bymUQ@mail.gmail.com>

On Wed, Feb 20, 2013 at 11:22 AM, Stephen Colebourne
<scolebourne at joda.org> wrote:
> On 20 February 2013 16:54, Patrick Wright <pdoubleya at gmail.com> wrote:
>>> think, like all new features, there is a danger of over-use. Laying
>>> down some guidelines on usage is a Good Thing IMO. Stream really
>>> shouldn't be the default return type - List is frequently much more
>>> useful to clients.
>>>
>> For the record, can you tell us exactly why (perhaps with code examples) you
>> feel that "list is...more useful to clients?"
>
> Asides from having a working toString, hashCode, equals, it has many
> other methods that allow practical manipulation by developers, such as
> indexOf, lastIndexOf, contains or subList. It can also be passed on to
> other methods (which you may not have written) that expect a list.
> While all of these things can be achieved using an array, they are
> frequently a pain to read.
>
> I don't recall writing code returning an array publicly in a long
> time. If I reviewed any code from someone doing it I'd want a very
> good justification for using an array.

Array was a poor man's generics, since Java had String[] but not
List<String>. That's why array was a better return type than List.
After generics, non-primitive arrays should be avoided, in all places,
unless there's a solid performance concern.

Zhong Yu

From forax at univ-mlv.fr  Wed Feb 20 10:30:33 2013
From: forax at univ-mlv.fr (Remi Forax)
Date: Wed, 20 Feb 2013 19:30:33 +0100
Subject: Return types array/list/stream [was: API question for point
	lambdafication]
In-Reply-To: <5124F586.9000307@oracle.com>
References: <CACzrW9BiJdixr8uaO-8dDfka9MTOkyZ-9Deyq7kEC+O_db6vDg@mail.gmail.com>
	<5124B0DB.2020809@univ-mlv.fr> <5124F586.9000307@oracle.com>
Message-ID: <51251649.5020808@univ-mlv.fr>

On 02/20/2013 05:10 PM, Tom Hawtin wrote:
> On 20/02/2013 11:17, Remi Forax wrote:
>
>> Most of java.lang uses arrays instead of List to avoid too many
>> dependencies between
>> java.lang and java.util which cause nightmare during the booting
>> sequence of the JDK.
> Like many other packages, java.lang predates the Java2 collection
> framework, so has to use arrays. As practically everything already
> existing is using arrays, it's tricky to mix in collections just for new
> methods. It's a pity as "some things" is a pretty fundamental concept.
> Whereas a mutable, ordered collection of fixed size is an implementation
> detail that should be hidden away.
>
> Dependency between packages does not fundamentally cause problems with
> start up. It's dependency between individual classes, irrespective of
> arbitrary package, which is important.

yes, but classes of a same package tends to depend on classes of the 
same package.
As an example, when you call Collections.emptyList() you ask to run the 
static init block that initializes EMPTY_LIST, EMPTY_SET and EMPTY_MAP 
that loads AbstractCollection, AbtractList, AbstractSet, AbstractMap etc.

>
> (It may be worth mentioning that implementation of fundamental types may
> be surprisingly complicated. For instance, HashMap currently does a lot
> of work to find a random number for some strange purpose.)

or java.util.Local that loads a dozen classes of java.util.concurrent :(

>
> Tom
>

R?mi


From maurizio.cimadamore at oracle.com  Wed Feb 20 11:19:59 2013
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Wed, 20 Feb 2013 19:19:59 +0000
Subject: hg: lambda/lambda/langtools: 8008537: Missing method reference lookup
	error when unbound search finds a static method
Message-ID: <20130220192005.A58E947C10@hg.openjdk.java.net>

Changeset: 66476d1c5e64
Author:    mcimadamore
Date:      2013-02-20 19:19 +0000
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/66476d1c5e64

8008537: Missing method reference lookup error when unbound search finds a static method

! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/Resolve.java
! src/share/classes/com/sun/tools/javac/resources/compiler.properties
! test/tools/javac/diags/examples.not-yet.txt
! test/tools/javac/diags/examples/NonStaticCantBeRefFragment.java
! test/tools/javac/lambda/MethodReference22.java
! test/tools/javac/lambda/MethodReference22.out
! test/tools/javac/lambda/MethodReference28.out
! test/tools/javac/lambda/MethodReference51.out
! test/tools/javac/lambda/TargetType60.java
! test/tools/javac/lambda/TargetType60.out


From pbenedict at apache.org  Wed Feb 20 12:27:30 2013
From: pbenedict at apache.org (Paul Benedict)
Date: Wed, 20 Feb 2013 14:27:30 -0600
Subject: Spliterator javadoc example
Message-ID: <CABLGb9y6SORokF2WVyGgnbz+DGdEasmXamLHSqMWoWfL0=MrbA@mail.gmail.com>

The javadoc class example uses virtually no whitespacing. Methods are
one after another without any blank line separation. Can this be fixed
so it's easier to read?

http://download.java.net/lambda/b78/docs/api/java/util/Spliterator.html

Thanks,
Paul

From benjamin.john.evans at gmail.com  Wed Feb 20 12:40:56 2013
From: benjamin.john.evans at gmail.com (Ben Evans)
Date: Wed, 20 Feb 2013 15:40:56 -0500
Subject: TestNG tests appear to hang with latest lambda
Message-ID: <CABKW8Rg5+3ZuYXbKMcACB7fUY=6Q7GeXoO5L-gvaZqF3L207_g@mail.gmail.com>

Hi,

I'm writing some docs for AdoptOpenJDK about getting started writing
TestNG tests, in advance of the hackdays at Devoxx UK.

However, with latest lambda, the TestNG tests appear to hang (output
below). The process grows in size to over 1Gb, and then appears to
freeze. It's still responsive (so I can connect jvisualvm to it, but
when I sample the code, nothing appears to be running).

This is on Mac 10.7 with OpenJDK 8 from current lambda.

Any ideas?

Thanks,

Ben

ariel:test-ng boxcat$ ant test
Buildfile: /Users/boxcat/projects/lambda/jdk/test-ng/build.xml

prepare:

test-compile:
    [javac] /Users/boxcat/projects/lambda/jdk/test-ng/build.xml:78:
warning: 'includeantruntime' was not set, defaulting to
build.sysclasspath=last; set to false for repeatable builds
    [javac] /Users/boxcat/projects/lambda/jdk/test-ng/build.xml:82:
warning: 'includeantruntime' was not set, defaulting to
build.sysclasspath=last; set to false for repeatable builds
    [javac] /Users/boxcat/projects/lambda/jdk/test-ng/build.xml:86:
warning: 'includeantruntime' was not set, defaulting to
build.sysclasspath=last; set to false for repeatable builds

test:
     [echo] Results at: file:../../build/test-ng/test-reports/index.html
   [testng] [TestNG] Running:
   [testng]   Ant suite
   [testng]
   [testng]
   [testng] Generating exhaustive interface....
   [testng]       8 No default
   [testng]       8 Error
   [testng]      48 OK
   [testng]      64 Total
   [testng]
   [testng] Generating exhaustive class....
   [testng]     729 No default
   [testng]      49 Error
   [testng]     950 OK
   [testng]    1728 Total
   [testng]
   [testng] Generating shapes interface....
   [testng]     109 No default
   [testng]     280 Error
   [testng]     507 OK
   [testng]     896 Total
   [testng]
   [testng] Generating shapes class/interface....
   [testng]     190 No default
   [testng]     568 Error
   [testng]     536 OK
   [testng]    1294 Total
   [testng]
   [testng] Expect OK:    2041 -- unique 1813
   [testng] Expect Error: 905 -- unique 773
   [testng]
   [testng] Generating exhaustive interface....
   [testng]       8 No default
   [testng]       8 Error
   [testng]      48 OK
   [testng]      64 Total
   [testng]
   [testng] Generating exhaustive class....
   [testng]     729 No default
   [testng]      49 Error
   [testng]     950 OK
   [testng]    1728 Total
   [testng]
   [testng] Generating shapes interface....
   [testng]     109 No default
   [testng]     280 Error
   [testng]     507 OK
   [testng]     896 Total
   [testng]
   [testng] Generating shapes class/interface....
   [testng]     190 No default
   [testng]     568 Error
   [testng]     536 OK
   [testng]    1294 Total
   [testng]
   [testng] Expect OK:    2041 -- unique 1813
   [testng] Expect Error: 905 -- unique 773

From mike.duigou at oracle.com  Wed Feb 20 13:15:22 2013
From: mike.duigou at oracle.com (mike.duigou at oracle.com)
Date: Wed, 20 Feb 2013 21:15:22 +0000
Subject: hg: lambda/lambda/jaxp: 8 new changesets
Message-ID: <20130220211545.0380347C16@hg.openjdk.java.net>

Changeset: 8d65b381880b
Author:    katleman
Date:      2013-01-31 17:04 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxp/rev/8d65b381880b

Added tag jdk8-b75 for changeset ff0b73a6b3f6

! .hgtags

Changeset: 8f6ca8755f46
Author:    ohrstrom
Date:      2013-01-31 14:02 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxp/rev/8f6ca8755f46

8006872: Stop creating four jars with identical content in the new build system.
Reviewed-by: erikj

! makefiles/BuildJaxp.gmk

Changeset: 0c08593944d0
Author:    katleman
Date:      2013-02-05 18:54 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxp/rev/0c08593944d0

Merge


Changeset: 02195d0e96b9
Author:    katleman
Date:      2013-02-07 12:32 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxp/rev/02195d0e96b9

Added tag jdk8-b76 for changeset 0c08593944d0

! .hgtags

Changeset: f0ad3747b40e
Author:    emc
Date:      2013-02-05 14:56 +0000
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxp/rev/f0ad3747b40e

8007389: Remove uses of _ as identifier in jaxp
Reviewed-by: lancea, joehw

! src/javax/xml/validation/SchemaFactoryFinder.java
! src/javax/xml/xpath/XPathFactoryFinder.java

Changeset: 573e789c187a
Author:    lana
Date:      2013-02-11 16:12 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxp/rev/573e789c187a

Merge


Changeset: 00958c5a7070
Author:    katleman
Date:      2013-02-14 11:43 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxp/rev/00958c5a7070

Added tag jdk8-b77 for changeset 573e789c187a

! .hgtags

Changeset: ac69bd4c3f65
Author:    mduigou
Date:      2013-02-20 09:46 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxp/rev/ac69bd4c3f65

Merge

! .hgtags


From mike.duigou at oracle.com  Wed Feb 20 13:15:31 2013
From: mike.duigou at oracle.com (mike.duigou at oracle.com)
Date: Wed, 20 Feb 2013 21:15:31 +0000
Subject: hg: lambda/lambda/hotspot: 176 new changesets
Message-ID: <20130220212128.B40ED47C18@hg.openjdk.java.net>

Changeset: d58b7b43031b
Author:    amurillo
Date:      2013-01-11 02:02 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/d58b7b43031b

8006034: new hotspot build - hs25-b16
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: adc176e95bf2
Author:    acorn
Date:      2013-01-09 11:39 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/adc176e95bf2

8005689: InterfaceAccessFlagsTest failures in Lambda-JDK tests
Summary: Fix verifier for new interface access flags
Reviewed-by: acorn, kvn
Contributed-by: bharadwaj.yadavalli at oracle.com

! src/share/vm/classfile/classFileParser.cpp

Changeset: dd7248d3e151
Author:    zgu
Date:      2013-01-09 14:46 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/dd7248d3e151

7152671: RFE: Windows decoder should add some std dirs to the symbol search path
Summary: Added JRE/JDK bin directories to decoder's symbol search path
Reviewed-by: dcubed, sla

! src/os/windows/vm/decoder_windows.cpp
! src/os/windows/vm/decoder_windows.hpp

Changeset: 97ee8abd6ab2
Author:    zgu
Date:      2013-01-09 12:10 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/97ee8abd6ab2

Merge


Changeset: aefb345d3f5e
Author:    acorn
Date:      2013-01-10 17:38 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/aefb345d3f5e

7199207: NPG: Crash in PlaceholderTable::verify after StackOverflow
Summary: Reduce scope of placeholder table entries to improve cleanup
Reviewed-by: dholmes, coleenp

! src/share/vm/classfile/placeholders.cpp
! src/share/vm/classfile/placeholders.hpp
! src/share/vm/classfile/systemDictionary.cpp
! src/share/vm/utilities/exceptions.hpp

Changeset: 91bf7da5c609
Author:    mikael
Date:      2013-01-10 17:06 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/91bf7da5c609

8004747: Remove last_entry from VM_STRUCT macros
Summary: Instead of passing in last_entry to all the VM_ macros just expand it in the main vmStructs.cpp file.
Reviewed-by: dholmes, sspitsyn, minqi

! src/cpu/sparc/vm/vmStructs_sparc.hpp
! src/cpu/x86/vm/vmStructs_x86.hpp
! src/cpu/zero/vm/vmStructs_zero.hpp
! src/os_cpu/bsd_x86/vm/vmStructs_bsd_x86.hpp
! src/os_cpu/bsd_zero/vm/vmStructs_bsd_zero.hpp
! src/os_cpu/linux_sparc/vm/vmStructs_linux_sparc.hpp
! src/os_cpu/linux_x86/vm/vmStructs_linux_x86.hpp
! src/os_cpu/linux_zero/vm/vmStructs_linux_zero.hpp
! src/os_cpu/solaris_sparc/vm/vmStructs_solaris_sparc.hpp
! src/os_cpu/solaris_x86/vm/vmStructs_solaris_x86.hpp
! src/os_cpu/windows_x86/vm/vmStructs_windows_x86.hpp
! src/share/vm/runtime/vmStructs.cpp

Changeset: c1c8479222cd
Author:    dholmes
Date:      2013-01-10 21:00 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/c1c8479222cd

8005921: Memory leaks in vmStructs.cpp
Reviewed-by: dholmes, mikael, rasbold
Contributed-by: Jeremy Manson <jeremymanson at google.com>

! src/share/vm/runtime/vmStructs.cpp

Changeset: e0cf9af8978e
Author:    zgu
Date:      2013-01-11 12:30 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/e0cf9af8978e

8005936: PrintNMTStatistics doesn't work for normal JVM exit
Summary: Moved NMT shutdown code to JVM exit handler to ensure NMT statistics is printed when PrintNMTStatistics is enabled
Reviewed-by: acorn, dholmes, coleenp

! src/share/vm/runtime/java.cpp
! src/share/vm/runtime/thread.cpp

Changeset: 90a92d5bca17
Author:    zgu
Date:      2013-01-11 09:53 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/90a92d5bca17

Merge


Changeset: 4a916f2ce331
Author:    jwilhelm
Date:      2013-01-14 15:17 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/4a916f2ce331

8003985: Support @Contended Annotation - JEP 142
Summary: HotSpot changes to support @Contended annotation.
Reviewed-by: coleenp, kvn, jrose
Contributed-by: Aleksey Shipilev <aleksey.shipilev at oracle.com>

! agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java
! src/cpu/sparc/vm/vm_version_sparc.cpp
! src/cpu/x86/vm/vm_version_x86.cpp
! src/share/vm/classfile/classFileParser.cpp
! src/share/vm/classfile/classFileParser.hpp
! src/share/vm/classfile/vmSymbols.hpp
! src/share/vm/oops/fieldInfo.hpp
! src/share/vm/oops/fieldStreams.hpp
! src/share/vm/oops/instanceKlass.hpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/vmStructs.cpp

Changeset: f9eb431c3efe
Author:    coleenp
Date:      2013-01-14 11:01 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/f9eb431c3efe

8006005: Fix constant pool index validation and alignment trap for method parameter reflection
Summary: This patch addresses an alignment trap due to the storage format of method parameters data in constMethod.  It also adds code to validate constant pool indexes for method parameters data.
Reviewed-by: jrose, dholmes
Contributed-by: eric.mccorkle at oracle.com

! src/share/vm/classfile/classFileParser.cpp
! src/share/vm/oops/constMethod.hpp
! src/share/vm/prims/jvm.cpp
! src/share/vm/runtime/reflection.cpp

Changeset: 5b6a231e5a86
Author:    coleenp
Date:      2013-01-14 08:37 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/5b6a231e5a86

Merge

! src/share/vm/classfile/classFileParser.cpp

Changeset: fe1472c87a27
Author:    mikael
Date:      2013-01-14 11:00 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/fe1472c87a27

8005592: ClassLoaderDataGraph::_unloading incorrectly defined as nonstatic in vmStructs
Summary: Added assertion to catch problem earlier and removed the unused field
Reviewed-by: dholmes, acorn

! src/share/vm/runtime/vmStructs.cpp

Changeset: c793367610c1
Author:    coleenp
Date:      2013-01-15 17:05 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/c793367610c1

8005467: CDS size information is incorrect and unfriendly
Summary: Changed words to bytes, and added usage percentage information
Reviewed-by: coleenp, twisti
Contributed-by: ioi.lam at oracle.com

! src/share/vm/memory/metaspaceShared.cpp

Changeset: 92d4b5d8dde4
Author:    acorn
Date:      2013-01-16 18:23 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/92d4b5d8dde4

Merge

! src/cpu/x86/vm/vm_version_x86.cpp
! src/share/vm/runtime/globals.hpp

Changeset: 337e1dd9d902
Author:    jiangli
Date:      2013-01-11 16:55 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/337e1dd9d902

8005895: Inefficient InstanceKlass field packing wasts memory.
Summary: Pack _misc_has_default_methods into the _misc_flags, move _idnum_allocated_count.
Reviewed-by: coleenp, shade

! src/share/vm/oops/instanceKlass.hpp

Changeset: 94fa3c4e7643
Author:    vladidan
Date:      2013-01-14 13:44 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/94fa3c4e7643

8005639: Move InlineSynchronizedMethods flag from develop to product
Summary: Move InlineSynchronizedMethods flag from develop to product
Reviewed-by: kvn, vladidan
Contributed-by: Alexander Harlap <alexander.harlap at oracle.com>

! src/share/vm/c1/c1_globals.hpp

Changeset: 9deda4d8e126
Author:    vladidan
Date:      2013-01-14 13:52 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/9deda4d8e126

8005204: Code Cache Reduction: command line options implementation
Summary: Adding more detailed output on CodeCache usage
Reviewed-by: kvn, vladidan
Contributed-by: Alexander Harlap <alexander.harlap at oracle.com>

! src/share/vm/code/codeCache.cpp
! src/share/vm/code/codeCache.hpp
! src/share/vm/compiler/compileBroker.cpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/java.cpp
! src/share/vm/utilities/vmError.cpp

Changeset: 212c5b9c38e7
Author:    dlong
Date:      2013-01-17 01:27 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/212c5b9c38e7

Merge

! src/share/vm/oops/instanceKlass.hpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/java.cpp

Changeset: a3f92e6c0274
Author:    twisti
Date:      2013-01-11 14:07 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/a3f92e6c0274

8006031: LibraryCallKit::inline_array_copyOf disabled unintentionally with 7172640
Reviewed-by: kvn

! src/share/vm/opto/library_call.cpp

Changeset: f9bda35f4226
Author:    twisti
Date:      2013-01-11 16:47 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/f9bda35f4226

8005816: Shark: fix volatile float field access
Reviewed-by: twisti
Contributed-by: Roman Kennke <rkennke at redhat.com>

! src/share/vm/shark/sharkBlock.cpp

Changeset: c566b81b3323
Author:    twisti
Date:      2013-01-11 16:47 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/c566b81b3323

8005817: Shark: implement deoptimization support
Reviewed-by: twisti
Contributed-by: Roman Kennke <rkennke at redhat.com>

! src/cpu/zero/vm/frame_zero.cpp
! src/cpu/zero/vm/frame_zero.inline.hpp
! src/cpu/zero/vm/sharkFrame_zero.hpp
! src/share/vm/shark/sharkInvariants.hpp
! src/share/vm/shark/sharkTopLevelBlock.cpp

Changeset: c095a7f289aa
Author:    twisti
Date:      2013-01-11 16:47 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/c095a7f289aa

8005818: Shark: fix OSR for non-empty incoming stack
Reviewed-by: twisti
Contributed-by: Roman Kennke <rkennke at redhat.com>

! src/share/vm/shark/sharkCompiler.cpp
! src/share/vm/shark/sharkFunction.cpp
! src/share/vm/shark/sharkInvariants.hpp

Changeset: 606eada1bf86
Author:    twisti
Date:      2013-01-11 16:47 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/606eada1bf86

8005820: Shark: enable JSR292 support
Reviewed-by: twisti
Contributed-by: Roman Kennke <rkennke at redhat.com>

! src/share/vm/compiler/abstractCompiler.hpp
! src/share/vm/compiler/compileBroker.cpp
! src/share/vm/shark/sharkBlock.cpp
! src/share/vm/shark/sharkCompiler.hpp
! src/share/vm/shark/sharkConstant.cpp
! src/share/vm/shark/sharkInliner.cpp
! src/share/vm/shark/sharkTopLevelBlock.cpp

Changeset: 6d1f5516534e
Author:    twisti
Date:      2013-01-11 20:01 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/6d1f5516534e

8006127: remove printing code added with 8006031
Reviewed-by: kvn

! src/share/vm/opto/library_call.cpp

Changeset: d92fa52a5d03
Author:    vlivanov
Date:      2013-01-14 08:22 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/d92fa52a5d03

8006095: C1: SIGSEGV w/ -XX:+LogCompilation
Summary: avoid printing inlining decision when compilation fails
Reviewed-by: kvn, roland

! src/share/vm/c1/c1_GraphBuilder.cpp

Changeset: f1de9dbc914e
Author:    twisti
Date:      2013-01-15 12:06 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/f1de9dbc914e

8006109: test/java/util/AbstractSequentialList/AddAll.java fails: assert(rtype == ctype) failed: mismatched return types
Reviewed-by: kvn

! src/share/vm/ci/ciType.cpp
! src/share/vm/ci/ciType.hpp
! src/share/vm/opto/doCall.cpp

Changeset: 5b8548391bf3
Author:    kvn
Date:      2013-01-15 14:45 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/5b8548391bf3

8005821: C2: -XX:+PrintIntrinsics is broken
Summary: Check all print inlining flags when processing inlining list.
Reviewed-by: kvn, twisti
Contributed-by: david.r.chase at oracle.com

! src/share/vm/opto/compile.cpp

Changeset: bf623b2d5508
Author:    kvn
Date:      2013-01-16 14:55 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/bf623b2d5508

8006204: please JTREGify test/compiler/7190310/Test7190310.java
Summary: Add proper jtreg annotations in the preceding comment, including an explicit timeout.
Reviewed-by: kvn, twisti
Contributed-by: david.r.chase at oracle.com

! test/compiler/7190310/Test7190310.java

Changeset: eab4f9ed602c
Author:    kvn
Date:      2013-01-17 18:47 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/eab4f9ed602c

Merge

! src/share/vm/compiler/compileBroker.cpp

Changeset: 689e1218d7fe
Author:    brutisso
Date:      2013-01-14 09:58 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/689e1218d7fe

8004018: Remove old initialization flags
Reviewed-by: dholmes, stefank
Contributed-by: erik.helin at oracle.com

! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/thread.cpp

Changeset: a30e7b564541
Author:    brutisso
Date:      2013-01-14 21:30 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/a30e7b564541

8005972: ParNew should not update the tenuring threshold when promotion failed has occurred
Reviewed-by: ysr, johnc, jwilhelm

! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp
! src/share/vm/gc_implementation/parNew/parNewGeneration.hpp
! src/share/vm/memory/defNewGeneration.cpp
! src/share/vm/memory/defNewGeneration.hpp

Changeset: ed6154d7d259
Author:    stefank
Date:      2013-01-15 13:32 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/ed6154d7d259

8005590: java_lang_Class injected field resolved_constructor appears unused
Reviewed-by: coleenp, dholmes

! src/share/vm/classfile/javaClasses.cpp
! src/share/vm/classfile/javaClasses.hpp
! src/share/vm/classfile/vmSymbols.hpp
! src/share/vm/oops/instanceKlass.cpp
! src/share/vm/runtime/vmStructs.cpp

Changeset: ff0a7943fd29
Author:    stefank
Date:      2013-01-15 10:09 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/ff0a7943fd29

8005994: Method annotations are allocated unnecessarily during class file parsing
Summary: Also reviewed by: vitalyd at gmail.com
Reviewed-by: coleenp, acorn

! src/share/vm/classfile/classFileParser.cpp
! src/share/vm/prims/jvm.cpp

Changeset: 4967eb4f67a9
Author:    johnc
Date:      2013-01-15 12:32 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/4967eb4f67a9

8001425: G1: Change the default values for certain G1 specific flags
Summary: Changes to default and ergonomic flag values recommended by performance team. Changes were also reviewed by Monica Beckwith <monica.beckwith at oracle.com>.
Reviewed-by: brutisso, huntch

! src/share/vm/gc_implementation/g1/g1_globals.hpp

Changeset: 2dce7c34c564
Author:    stefank
Date:      2013-01-17 11:39 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/2dce7c34c564

8006513: Null pointer in DefaultMethods::generate_default_methods when merging annotations
Reviewed-by: brutisso, jfranck

! src/share/vm/classfile/defaultMethods.cpp

Changeset: 59a58e20dc60
Author:    jmasa
Date:      2013-01-17 19:04 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/59a58e20dc60

8006537: Assert when dumping archive with default methods
Reviewed-by: coleenp

! src/share/vm/classfile/classLoaderData.cpp
! src/share/vm/memory/metadataFactory.hpp

Changeset: f422634e5828
Author:    brutisso
Date:      2013-01-18 11:03 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/f422634e5828

Merge

! src/share/vm/classfile/classFileParser.cpp
! src/share/vm/classfile/vmSymbols.hpp
! src/share/vm/prims/jvm.cpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/thread.cpp
! src/share/vm/runtime/vmStructs.cpp

Changeset: 70c89bd6b895
Author:    amurillo
Date:      2013-01-18 05:19 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/70c89bd6b895

Merge


Changeset: 2b878edabfc0
Author:    amurillo
Date:      2013-01-18 05:19 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/2b878edabfc0

Added tag hs25-b16 for changeset 70c89bd6b895

! .hgtags

Changeset: 46e60405583b
Author:    amurillo
Date:      2013-01-18 05:33 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/46e60405583b

8006511: new hotspot build - hs25-b17
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: e94ed1591b42
Author:    sla
Date:      2013-01-16 16:30 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/e94ed1591b42

8006403: Regression: jstack failed due to the FieldInfo regression in SA
Reviewed-by: sla, dholmes
Contributed-by: Aleksey Shipilev <aleksey.shipilev at oracle.com>

! agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java
! src/share/vm/runtime/vmStructs.cpp

Changeset: 557bda927cc2
Author:    sla
Date:      2013-01-18 14:15 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/557bda927cc2

Merge

! src/share/vm/runtime/vmStructs.cpp

Changeset: 617b18aadb33
Author:    sla
Date:      2013-01-18 19:13 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/617b18aadb33

Merge


Changeset: 203f64878aab
Author:    hseigel
Date:      2013-01-17 10:25 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/203f64878aab

7102489: RFE: cleanup jlong typedef on __APPLE__and _LLP64 systems.
Summary: Define jlong as long on all LP64 platforms and add JLONG_FORMAT macro.
Reviewed-by: dholmes, coleenp, mikael, kvn

! src/cpu/x86/vm/jni_x86.h
! src/os/bsd/vm/os_bsd.inline.hpp
! src/os/linux/vm/os_linux.inline.hpp
! src/os/posix/launcher/java_md.c
! src/os/posix/launcher/java_md.h
! src/os/solaris/vm/os_solaris.inline.hpp
! src/os/windows/launcher/java_md.c
! src/os/windows/launcher/java_md.h
! src/os/windows/vm/os_windows.cpp
! src/os/windows/vm/os_windows.inline.hpp
! src/share/tools/launcher/java.c
! src/share/tools/launcher/java.h
! src/share/vm/c1/c1_InstructionPrinter.cpp
! src/share/vm/c1/c1_LIR.cpp
! src/share/vm/ci/ciReplay.cpp
! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp
! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp
! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp
! src/share/vm/gc_implementation/shared/ageTable.cpp
! src/share/vm/memory/universe.cpp
! src/share/vm/opto/idealGraphPrinter.cpp
! src/share/vm/opto/type.cpp
! src/share/vm/runtime/aprofiler.cpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/os.hpp
! src/share/vm/runtime/perfData.cpp
! src/share/vm/runtime/virtualspace.cpp
! src/share/vm/services/diagnosticArgument.cpp
! src/share/vm/services/heapDumper.cpp
! src/share/vm/services/lowMemoryDetector.cpp
! src/share/vm/utilities/globalDefinitions.hpp
! src/share/vm/utilities/globalDefinitions_gcc.hpp
! src/share/vm/utilities/ostream.cpp
! src/share/vm/utilities/taskqueue.cpp

Changeset: b14da2e6f2dc
Author:    coleenp
Date:      2013-01-17 13:40 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/b14da2e6f2dc

7174978: NPG: Fix bactrace builder for class redefinition
Summary: Remove Method* from backtrace but save version so redefine classes doesn't give inaccurate line numbers.  Removed old Merlin API with duplicate code.
Reviewed-by: dholmes, sspitsyn

! make/bsd/makefiles/mapfile-vers-debug
! make/bsd/makefiles/mapfile-vers-product
! make/linux/makefiles/mapfile-vers-debug
! make/linux/makefiles/mapfile-vers-product
! make/solaris/makefiles/mapfile-vers
! src/share/vm/classfile/javaClasses.cpp
! src/share/vm/classfile/javaClasses.hpp
! src/share/vm/oops/constantPool.cpp
! src/share/vm/oops/constantPool.hpp
! src/share/vm/prims/jvm.cpp
! src/share/vm/prims/jvm.h
! src/share/vm/prims/jvmtiRedefineClasses.cpp

Changeset: b5f6465019f6
Author:    coleenp
Date:      2013-01-17 22:11 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/b5f6465019f6

8006548: version wrong in new constantPool code
Summary: fix increment problem with saved_version
Reviewed-by: dholmes

! src/share/vm/oops/constantPool.hpp

Changeset: c07c102cbad7
Author:    brutisso
Date:      2013-01-21 09:00 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/c07c102cbad7

8006431: os::Bsd::initialize_system_info() sets _physical_memory too large
Summary: Use HW_MEMSIZE instead of HW_USERMEM to get a 64 bit value of the physical memory on the machine. Also reviewed by vitalyd at gmail.com.
Reviewed-by: sla, dholmes, dlong, mikael

! src/os/bsd/vm/os_bsd.cpp

Changeset: c73c3f2c5b3b
Author:    acorn
Date:      2013-01-21 16:11 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/c73c3f2c5b3b

Merge

! src/share/vm/classfile/javaClasses.cpp
! src/share/vm/classfile/javaClasses.hpp
! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp
! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp
! src/share/vm/prims/jvm.cpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/services/diagnosticArgument.cpp

Changeset: f3184f32ce0b
Author:    dcubed
Date:      2013-01-22 05:55 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/f3184f32ce0b

6444286: Possible naked oop related to biased locking revocation safepoint in jni_exit()
Summary: Add missing Handle.
Reviewed-by: acorn, dholmes, dice, sspitsyn
Contributed-by: karen.kinnear at oracle.com

! src/share/vm/runtime/synchronizer.cpp

Changeset: 22ba8c8ce6a6
Author:    dcubed
Date:      2013-01-22 05:56 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/22ba8c8ce6a6

8004902: correctness fixes motivated by contended locking work (6607129)
Summary: misc correctness fixes
Reviewed-by: acorn, dholmes, dice, sspitsyn
Contributed-by: dave.dice at oracle.com

! src/os/bsd/vm/os_bsd.cpp
! src/os/linux/vm/os_linux.cpp
! src/os/solaris/vm/os_solaris.cpp
! src/os/windows/vm/os_windows.cpp
! src/share/vm/classfile/javaClasses.cpp
! src/share/vm/runtime/objectMonitor.cpp
! src/share/vm/runtime/objectMonitor.inline.hpp

Changeset: 5ce621176715
Author:    dcubed
Date:      2013-01-22 05:57 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/5ce621176715

8004903: VMThread::execute() calls Thread::check_for_valid_safepoint_state() on concurrent VM ops
Summary: check_for_valid_safepoint_state() only applies to blocking VM ops
Reviewed-by: acorn, dholmes, dice, sspitsyn
Contributed-by: karen.kinnear at oracle.com

! src/share/vm/runtime/vmThread.cpp

Changeset: edd23b35b1a5
Author:    zgu
Date:      2013-01-22 14:27 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/edd23b35b1a5

6871190: Don't terminate JVM if it is running in a non-interactive session
Summary: Don't handle CTRL_LOGOFF_EVENT event when the process is running in a non-interactive session
Reviewed-by: ctornqvi, acorn

! src/os/windows/vm/os_windows.cpp

Changeset: 2ef7061f13b4
Author:    zgu
Date:      2013-01-22 11:54 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/2ef7061f13b4

Merge

! src/os/windows/vm/os_windows.cpp

Changeset: 7df93f7c14a5
Author:    brutisso
Date:      2013-01-16 12:46 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/7df93f7c14a5

8006242: G1: WorkerDataArray<T>::verify() too strict for double calculations
Summary: Also reviewed by vitalyd at gmail.com.
Reviewed-by: johnc, mgerdin

! src/share/vm/gc_implementation/g1/g1GCPhaseTimes.cpp
! src/share/vm/gc_implementation/g1/g1GCPhaseTimes.hpp

Changeset: bf8c2b2c8cfa
Author:    mgerdin
Date:      2013-01-22 13:42 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/bf8c2b2c8cfa

8004147: test/Makefile jtreg_tests target does not work with cygwin
Reviewed-by: ctornqvi, brutisso

! test/Makefile

Changeset: d754ef7b9352
Author:    jmasa
Date:      2013-01-24 06:04 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/d754ef7b9352

Merge


Changeset: a7114d3d712e
Author:    kvn
Date:      2013-01-22 11:31 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/a7114d3d712e

8005055: pass outputStream to more opto debug routines
Summary: pass the output stream to node->dump() and everything reachable from there
Reviewed-by: kvn
Contributed-by: goetz.lindenmaier at sap.com

! src/share/vm/compiler/oopMap.cpp
! src/share/vm/opto/callnode.cpp
! src/share/vm/opto/callnode.hpp
! src/share/vm/opto/machnode.cpp
! src/share/vm/opto/node.cpp
! src/share/vm/opto/node.hpp
! src/share/vm/opto/optoreg.hpp
! src/share/vm/opto/regalloc.cpp
! src/share/vm/opto/regmask.cpp
! src/share/vm/opto/regmask.hpp

Changeset: b30b3c2a0cf2
Author:    kvn
Date:      2013-01-22 15:34 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/b30b3c2a0cf2

6896617: Optimize sun.nio.cs.ISO_8859_1$Encode.encodeArrayLoop() on x86
Summary: Use SSE4.2 and AVX2 instructions for encodeArray intrinsic.
Reviewed-by: roland

! src/cpu/x86/vm/assembler_x86.cpp
! src/cpu/x86/vm/assembler_x86.hpp
! src/cpu/x86/vm/macroAssembler_x86.cpp
! src/cpu/x86/vm/macroAssembler_x86.hpp
! src/cpu/x86/vm/x86_32.ad
! src/cpu/x86/vm/x86_64.ad
! src/share/vm/adlc/formssel.cpp
! src/share/vm/classfile/vmSymbols.hpp
! src/share/vm/opto/c2_globals.hpp
! src/share/vm/opto/classes.hpp
! src/share/vm/opto/escape.cpp
! src/share/vm/opto/lcm.cpp
! src/share/vm/opto/library_call.cpp
! src/share/vm/opto/loopTransform.cpp
! src/share/vm/opto/macro.cpp
! src/share/vm/opto/matcher.cpp
! src/share/vm/opto/memnode.cpp
! src/share/vm/opto/memnode.hpp
+ test/compiler/6896617/Test6896617.java

Changeset: 522c328b8b77
Author:    kvn
Date:      2013-01-23 15:11 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/522c328b8b77

8003878: compiler/7196199 test failed on OS X since 8b54, jdk7u12b01
Summary: Limit vectors size to 16 bytes on BSD until the problem is fixed
Reviewed-by: twisti

! src/cpu/x86/vm/vm_version_x86.cpp

Changeset: 22ead76da3f4
Author:    kmo
Date:      2013-01-24 02:03 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/22ead76da3f4

8006758: LinkResolver assertion (caused by @Contended changes)
Summary: treat anonymous classes as privileged code to restore the special handling for @Compiled during class file parsing
Reviewed-by: jrose, coleenp, kvn, dholmes

! src/share/vm/classfile/classFileParser.cpp

Changeset: 274a29bf5682
Author:    kmo
Date:      2013-01-24 09:06 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/274a29bf5682

Merge


Changeset: b4391649e91e
Author:    amurillo
Date:      2013-01-25 02:36 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/b4391649e91e

Merge

! .hgtags

Changeset: 6778d0b16593
Author:    amurillo
Date:      2013-01-25 02:36 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/6778d0b16593

Added tag hs25-b17 for changeset b4391649e91e

! .hgtags

Changeset: 20b605466ccb
Author:    katleman
Date:      2013-01-31 17:04 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/20b605466ccb

Added tag jdk8-b75 for changeset 6778d0b16593

! .hgtags

Changeset: da53cb17186a
Author:    katleman
Date:      2013-02-07 12:32 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/da53cb17186a

Added tag jdk8-b76 for changeset 20b605466ccb

! .hgtags

Changeset: 6fbe8a57549d
Author:    amurillo
Date:      2013-01-25 03:03 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/6fbe8a57549d

8006827: new hotspot build - hs25-b18
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: 3c327c2b6782
Author:    jmasa
Date:      2013-01-03 15:03 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/3c327c2b6782

8004895: NPG: JMapPermCore test failure caused by warnings about missing field
Reviewed-by: johnc

! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp
! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.hpp
! src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp
! src/share/vm/memory/binaryTreeDictionary.cpp
! src/share/vm/memory/binaryTreeDictionary.hpp
! src/share/vm/runtime/vmStructs.cpp

Changeset: ef1e11845e18
Author:    jmasa
Date:      2013-02-04 12:01 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/ef1e11845e18

Merge

! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp
! src/share/vm/runtime/vmStructs.cpp

Changeset: 5daaddd917a1
Author:    coleenp
Date:      2013-01-23 10:34 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/5daaddd917a1

8006040: NPG: on_stack processing wastes space in ConstantPool
Summary: Added on_stack bit to flags.  Also MetadataMarkOnStack is used for more than JVMTI so had to be moved.
Reviewed-by: dholmes, stefank

! src/share/vm/classfile/classLoaderData.cpp
+ src/share/vm/classfile/metadataOnStackMark.cpp
+ src/share/vm/classfile/metadataOnStackMark.hpp
! src/share/vm/interpreter/linkResolver.cpp
! src/share/vm/oops/constantPool.cpp
! src/share/vm/oops/constantPool.hpp
! src/share/vm/oops/method.cpp
! src/share/vm/prims/jvmtiRedefineClasses.cpp
! src/share/vm/prims/jvmtiRedefineClasses.hpp

Changeset: 6cf2530f7fd3
Author:    minqi
Date:      2013-01-24 23:30 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/6cf2530f7fd3

8005278: Serviceability Agent: jmap -heap and jstack -m fail
Summary: BinaryTreeDictionary is typedef'ed as AFLBinaryTreeDictionary in vmStructs and in SA we still use old name for that. FreeList now is a template based class which is not reflect in SA type library. When SA does calculation of heap for CMS, the former will cause failure to retrieve BinaryTreeDictionary  sine the rename. The later will fail wherever it is used in SA.
Reviewed-by: dholmes, sla, coleenp
Contributed-by: yunda.mly at taobao.com

+ agent/src/share/classes/sun/jvm/hotspot/memory/AFLBinaryTreeDictionary.java
- agent/src/share/classes/sun/jvm/hotspot/memory/BinaryTreeDictionary.java
! agent/src/share/classes/sun/jvm/hotspot/memory/CompactibleFreeListSpace.java
! agent/src/share/classes/sun/jvm/hotspot/memory/FreeList.java
! src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp

Changeset: 8b46b0196eb0
Author:    zgu
Date:      2013-01-25 10:04 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/8b46b0196eb0

8000692: Remove old KERNEL code
Summary: Removed depreciated kernel VM source code from hotspot VM
Reviewed-by: dholmes, acorn

! make/Makefile
! make/bsd/makefiles/dtrace.make
! make/solaris/Makefile
! make/solaris/makefiles/dtrace.make
- make/solaris/makefiles/kernel.make
! make/windows/build.bat
! make/windows/create_obj_files.sh
! make/windows/makefiles/defs.make
! make/windows/makefiles/projectcreator.make
! make/windows/makefiles/vm.make
! src/cpu/x86/vm/assembler_x86.hpp
! src/share/vm/classfile/systemDictionary.cpp
! src/share/vm/classfile/systemDictionary.hpp
! src/share/vm/classfile/vmSymbols.hpp
! src/share/vm/prims/jniCheck.hpp
! src/share/vm/prims/jvm.cpp
! src/share/vm/prims/jvmtiCodeBlobEvents.hpp
! src/share/vm/prims/jvmtiEnv.cpp
! src/share/vm/prims/jvmtiEnvBase.cpp
! src/share/vm/prims/jvmtiExport.cpp
! src/share/vm/prims/jvmtiExtensions.hpp
! src/share/vm/prims/jvmtiImpl.cpp
! src/share/vm/prims/jvmtiImpl.hpp
! src/share/vm/prims/jvmtiRawMonitor.hpp
! src/share/vm/prims/jvmtiRedefineClasses.cpp
! src/share/vm/prims/jvmtiTagMap.hpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/arguments.hpp
! src/share/vm/runtime/thread.cpp
! src/share/vm/runtime/vmStructs.hpp
! src/share/vm/runtime/vm_version.cpp
! src/share/vm/services/attachListener.cpp
! src/share/vm/services/attachListener.hpp

Changeset: edd76a5856f7
Author:    sspitsyn
Date:      2013-01-24 22:13 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/edd76a5856f7

8005128: JSR 292: the mlvm redefineClassInBootstrap test crashes in ConstantPool::compare_entry_to
Summary: When constant pool is copied in merge_constant_pools the invokedynamic operands must be copied before.
Reviewed-by: coleenp, twisti
Contributed-by: serguei.spitsyn at oracle.com

! src/share/vm/oops/constantPool.cpp
! src/share/vm/oops/constantPool.hpp
! src/share/vm/prims/jvmtiRedefineClasses.cpp

Changeset: 4a0dd3799a44
Author:    minqi
Date:      2013-01-25 04:23 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/4a0dd3799a44

Merge


Changeset: 8d1fb417a42d
Author:    minqi
Date:      2013-01-25 13:47 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/8d1fb417a42d

Merge

! src/share/vm/prims/jvmtiRedefineClasses.cpp

Changeset: cf8470eaf7e5
Author:    acorn
Date:      2013-01-27 21:58 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/cf8470eaf7e5

Merge

- agent/src/share/classes/sun/jvm/hotspot/memory/BinaryTreeDictionary.java
- make/solaris/makefiles/kernel.make
! src/cpu/x86/vm/assembler_x86.hpp
! src/share/vm/classfile/vmSymbols.hpp

Changeset: 16fb9f942703
Author:    acorn
Date:      2013-01-25 15:06 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/16fb9f942703

6479360: PrintClassHistogram improvements
Summary: jcmd <pid> GC.class_stats (UnlockDiagnosticVMOptions)
Reviewed-by: coleenp, hseigel, sla, acorn
Contributed-by: ioi.lam at oracle.com

! src/share/vm/classfile/classLoaderData.cpp
! src/share/vm/classfile/classLoaderData.hpp
! src/share/vm/gc_implementation/shared/vmGCOperations.cpp
! src/share/vm/gc_implementation/shared/vmGCOperations.hpp
! src/share/vm/memory/heapInspection.cpp
! src/share/vm/memory/heapInspection.hpp
! src/share/vm/oops/annotations.cpp
! src/share/vm/oops/annotations.hpp
! src/share/vm/oops/arrayKlass.hpp
! src/share/vm/oops/constMethod.cpp
! src/share/vm/oops/constMethod.hpp
! src/share/vm/oops/constantPool.cpp
! src/share/vm/oops/constantPool.hpp
! src/share/vm/oops/instanceKlass.cpp
! src/share/vm/oops/instanceKlass.hpp
! src/share/vm/oops/klass.cpp
! src/share/vm/oops/klass.hpp
! src/share/vm/oops/method.cpp
! src/share/vm/oops/method.hpp
! src/share/vm/oops/methodData.cpp
! src/share/vm/oops/methodData.hpp
! src/share/vm/services/diagnosticCommand.cpp
! src/share/vm/services/diagnosticCommand.hpp

Changeset: 0d26ce8e9251
Author:    acorn
Date:      2013-01-28 10:34 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/0d26ce8e9251

Merge

- make/solaris/makefiles/kernel.make
! src/share/vm/oops/constantPool.cpp
! src/share/vm/oops/constantPool.hpp

Changeset: 815957d0203e
Author:    acorn
Date:      2013-01-28 10:55 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/815957d0203e

8004967: Default method cause VerifyError: Illegal use of nonvirtual
Summary: Recognize VM generated method in old verifier
Reviewed-by: acorn, coleenp
Contributed-by: bharadwaj.yadavelli at oracle.com

! make/bsd/makefiles/mapfile-vers-debug
! make/bsd/makefiles/mapfile-vers-product
! make/linux/makefiles/mapfile-vers-debug
! make/linux/makefiles/mapfile-vers-product
! make/solaris/makefiles/mapfile-vers
! src/share/vm/prims/jvm.cpp
! src/share/vm/prims/jvm.h

Changeset: 7885e162c30f
Author:    acorn
Date:      2013-01-28 09:33 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/7885e162c30f

Merge


Changeset: 9be6cde7919d
Author:    ctornqvi
Date:      2013-01-25 10:14 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/9be6cde7919d

8006413: Add utility classes for writing better multiprocess tests in jtreg
Summary: Add a few utility classes to test/testlibrary to support multi process testing in jtreg tests. Added a test case for one of the utility classes. Also reviewed by Vitaly Davidovich
Reviewed-by: brutisso, dholmes, vlivanov, nloodin, mgerdin

+ test/testlibrary/OutputAnalyzerTest.java
+ test/testlibrary/com/oracle/java/testlibrary/JDKToolFinder.java
+ test/testlibrary/com/oracle/java/testlibrary/OutputAnalyzer.java
+ test/testlibrary/com/oracle/java/testlibrary/OutputBuffer.java
+ test/testlibrary/com/oracle/java/testlibrary/ProcessTools.java
+ test/testlibrary/com/oracle/java/testlibrary/StreamPumper.java

Changeset: baf7fac3167e
Author:    hseigel
Date:      2013-02-01 14:14 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/baf7fac3167e

8006298: Specifying malformed JFR options (-XX:+FlightRecorderOptions) outputs non-sensical error
Summary: Change error messages for malformed options so the messages are more useful.
Reviewed-by: mikael, kvn, nloodin

! src/share/vm/runtime/arguments.cpp

Changeset: 4c75576d18d0
Author:    hseigel
Date:      2013-02-01 13:30 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/4c75576d18d0

Merge


Changeset: 9bf5f643d1cf
Author:    sspitsyn
Date:      2013-01-31 20:07 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/9bf5f643d1cf

8006542: JSR 292: the VM_RedefineClasses::append_entry() must support invokedynamic entry kinds
Summary: Need a support for invokedynamic entry kinds when new and old constant pools are merged.
Reviewed-by: coleenp, twisti
Contributed-by: serguei.spitsyn at oracle.com

! src/share/vm/prims/jvmtiRedefineClasses.cpp
! src/share/vm/prims/jvmtiRedefineClasses.hpp

Changeset: dc31f560d6e7
Author:    sspitsyn
Date:      2013-01-31 20:09 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/dc31f560d6e7

8006546: JSR 292: typos in the ConstantPool::copy_cp_impl()
Summary: Simple typos that need to be fixed
Reviewed-by: coleenp, twisti
Contributed-by: serguei.spitsyn at oracle.com

! src/share/vm/oops/constantPool.cpp

Changeset: 79c1bb8fce5d
Author:    sspitsyn
Date:      2013-01-31 20:11 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/79c1bb8fce5d

8006731: JSR 292: the VM_RedefineClasses::rewrite_cp_refs_in_method() must support invokedynamic
Summary: The invokedynamic bytecode ref to a CP entry needs to be checked and fixed as well.
Reviewed-by: coleenp, twisti
Contributed-by: serguei.spitsyn at oracle.com

! src/share/vm/prims/jvmtiRedefineClasses.cpp

Changeset: 9a9f870325cf
Author:    minqi
Date:      2013-02-01 10:57 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/9a9f870325cf

Merge


Changeset: b935589d2807
Author:    minqi
Date:      2013-02-01 14:42 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/b935589d2807

Merge


Changeset: 44c5fcd9cb25
Author:    iklam
Date:      2013-01-24 10:57 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/44c5fcd9cb25

8006280: Need to reorder metadata structures to reduce size (64-bit)
Summary: Reordered Klass, InstanceKlass and Method to save 8 bytes each
Reviewed-by: coleenp, jiangli
Contributed-by: ioi.lam at oracle.com

! src/share/vm/oops/instanceKlass.hpp
! src/share/vm/oops/klass.hpp
! src/share/vm/oops/method.hpp

Changeset: 1eae78177059
Author:    jiangli
Date:      2013-02-01 15:25 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/1eae78177059

Merge

- make/solaris/makefiles/kernel.make
! src/share/vm/oops/instanceKlass.hpp
! src/share/vm/oops/klass.hpp
! src/share/vm/oops/method.hpp

Changeset: dc8ad3fd7050
Author:    jiangli
Date:      2013-02-01 19:36 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/dc8ad3fd7050

Merge


Changeset: 4102b59539ce
Author:    ctornqvi
Date:      2013-02-01 23:48 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/4102b59539ce

8005012: Add WB APIs to better support NMT testing
Summary: Add WB API functions to enable better NMT testing
Reviewed-by: dholmes, zgu

! src/share/tools/whitebox/sun/hotspot/WhiteBox.java
! src/share/vm/memory/allocation.hpp
! src/share/vm/prims/whitebox.cpp
! src/share/vm/services/memBaseline.cpp
! src/share/vm/services/memPtr.cpp
! src/share/vm/services/memPtr.hpp
! src/share/vm/services/memRecorder.cpp
! src/share/vm/services/memRecorder.hpp
! src/share/vm/services/memTrackWorker.cpp
! src/share/vm/services/memTrackWorker.hpp
! src/share/vm/services/memTracker.cpp
! src/share/vm/services/memTracker.hpp

Changeset: 4460acf8687b
Author:    ctornqvi
Date:      2013-02-02 07:24 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/4460acf8687b

Merge


Changeset: 9fe95b01ad32
Author:    ctornqvi
Date:      2013-02-02 08:46 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/9fe95b01ad32

Merge


Changeset: 43badbe2717a
Author:    minqi
Date:      2013-01-31 17:43 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/43badbe2717a

8000973: SA on windows thread inspection is broken
Summary: After bug 7161732, On Windows SA could not find correct address of thread_id of OSThread since _thread_id moved to end of the class . The presupposition of the address is following thread handle no longer stands. Fix by adding thread_id field to OSThread and getting the  address directly from OSThread.
Reviewed-by: nloodin, sspitsyn
Contributed-by: yumin.qi at oracle.com

! agent/src/share/classes/sun/jvm/hotspot/debugger/windbg/amd64/WindbgAMD64Thread.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/windbg/x86/WindbgX86Thread.java
! agent/src/share/classes/sun/jvm/hotspot/runtime/OSThread.java
! agent/src/share/classes/sun/jvm/hotspot/runtime/win32_amd64/Win32AMD64JavaThreadPDAccess.java
! agent/src/share/classes/sun/jvm/hotspot/runtime/win32_x86/Win32X86JavaThreadPDAccess.java

Changeset: 65b632b77a97
Author:    minqi
Date:      2013-02-01 22:41 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/65b632b77a97

Merge


Changeset: ff5401ad5635
Author:    minqi
Date:      2013-02-02 03:51 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/ff5401ad5635

Merge


Changeset: 879c6de913d6
Author:    ctornqvi
Date:      2013-02-02 16:34 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/879c6de913d6

8005013: Add NMT tests
Summary: Add tests for the Native Memory Tracking feature, includes regression tests for 8005936 and 8004802
Reviewed-by: zgu, coleenp

! test/TEST.ROOT
+ test/runtime/NMT/AllocTestType.java
+ test/runtime/NMT/BaselineWithParameter.java
+ test/runtime/NMT/CommandLineDetail.java
+ test/runtime/NMT/CommandLineEmptyArgument.java
+ test/runtime/NMT/CommandLineInvalidArgument.java
+ test/runtime/NMT/CommandLineSummary.java
+ test/runtime/NMT/CommandLineTurnOffNMT.java
+ test/runtime/NMT/JcmdScale.java
+ test/runtime/NMT/JcmdWithNMTDisabled.java
+ test/runtime/NMT/PrintNMTStatistics.java
+ test/runtime/NMT/PrintNMTStatisticsWithNMTDisabled.java
+ test/runtime/NMT/ShutdownTwice.java
+ test/runtime/NMT/SummaryAfterShutdown.java
+ test/runtime/NMT/SummarySanityCheck.java

Changeset: a7f9a1195d86
Author:    ctornqvi
Date:      2013-02-02 20:13 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/a7f9a1195d86

8000363: runtime/7158988/FieldMonitor.java fails with exception
Summary: Removed unnecessary shell script in the test.
Reviewed-by: coleenp, sla

! test/runtime/7158988/FieldMonitor.java
- test/runtime/7158988/TestFieldMonitor.sh

Changeset: 8f696cf1a0fb
Author:    dsamersoff
Date:      2013-02-03 22:28 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/8f696cf1a0fb

8002048: Protocol to discovery of manageable Java processes on a network
Summary: Introduce a protocol to discover manageble Java instances across a network subnet, JDP
Reviewed-by: sla, dfuchs

! src/share/vm/services/diagnosticCommand.cpp
! src/share/vm/services/diagnosticCommand.hpp

Changeset: c4ef3380a70b
Author:    hseigel
Date:      2013-02-03 16:49 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/c4ef3380a70b

7197672: There are issues with shared data on windows
Summary: On Windows, set rw protection on the CDS file just before removing it.
Reviewed-by: dcubed, iklam

! src/share/vm/memory/filemap.cpp

Changeset: ce5467120c84
Author:    hseigel
Date:      2013-02-03 17:12 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/ce5467120c84

Merge


Changeset: 10d5f25a7c67
Author:    hseigel
Date:      2013-02-04 08:26 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/10d5f25a7c67

8000968: NPG: UseCompressedKlassPointers asserts with ObjectAlignmentInBytes for > 32G CompressedOops
Summary: Pick a base that works for both CompressedOpps alignment and CompressedKlassPtrs alignment.
Reviewed-by: kvn, roland

! src/share/vm/memory/universe.cpp
! src/share/vm/memory/universe.hpp
! src/share/vm/oops/oop.inline.hpp
! src/share/vm/runtime/arguments.cpp
+ test/runtime/8000968/Test8000968.sh

Changeset: 24a91505f9d5
Author:    emc
Date:      2013-02-04 13:05 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/24a91505f9d5

8006949: Update hotspot for MethodParameters format change
8006907: Hotspot should reject classfiles with multiple MethodParameters attributes
Summary: Update to Hotspot's processing of MethodParameters attributes in classfiles
Reviewed-by: coleenp, jrose

! src/share/vm/classfile/classFileParser.cpp
! src/share/vm/oops/constMethod.hpp
! src/share/vm/prims/jvm.cpp

Changeset: 42ea5e1fad75
Author:    coleenp
Date:      2013-02-04 13:51 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/42ea5e1fad75

Merge


Changeset: ab826603e572
Author:    simonis
Date:      2013-02-04 13:14 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/ab826603e572

8007475: Memory stomp with UseMallocOnly
Summary: Fix off-by-one error
Reviewed-by: coleenp, hseigel

! src/share/vm/classfile/stackMapFrame.hpp
+ test/runtime/8007475/StackMapFrameTest.java

Changeset: a401757763f9
Author:    coleenp
Date:      2013-02-04 22:59 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/a401757763f9

Merge


Changeset: 12285410684f
Author:    dholmes
Date:      2013-02-04 23:53 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/12285410684f

8006508: Wrong frame constructor is called in os_linux_x86.cpp
Reviewed-by: dholmes, coleenp
Contributed-by: Jeremy Manson <jeremymanson at google.com>

! src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp
! src/os_cpu/linux_x86/vm/os_linux_x86.cpp
! src/os_cpu/windows_x86/vm/os_windows_x86.cpp

Changeset: f3ea1af9207a
Author:    dholmes
Date:      2013-02-05 00:59 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/f3ea1af9207a

Merge


Changeset: 454d7cc622ab
Author:    dcubed
Date:      2013-02-06 15:22 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/454d7cc622ab

Merge

- agent/src/share/classes/sun/jvm/hotspot/memory/BinaryTreeDictionary.java
- make/solaris/makefiles/kernel.make
! src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp
- test/runtime/7158988/TestFieldMonitor.sh

Changeset: fcc9e7681d63
Author:    vlivanov
Date:      2013-02-01 02:50 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/fcc9e7681d63

8006410: allocating without ResourceMark when CompileCommand was specified
Reviewed-by: kvn, vlivanov
Contributed-by: Igor Ignatyev <igor.ignatyev at oracle.com>

! src/share/vm/ci/ciEnv.cpp
! src/share/vm/ci/ciInstanceKlass.cpp
! src/share/vm/ci/ciMethod.cpp
! src/share/vm/ci/ciMethodData.cpp
! src/share/vm/oops/symbol.cpp

Changeset: 60bba1398c51
Author:    vlivanov
Date:      2013-02-01 03:02 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/60bba1398c51

8005439: no message about inline method if it specifed by CompileCommand
Reviewed-by: kvn, vlivanov
Contributed-by: Igor Ignatyev <igor.ignatyev at oracle.com>

! src/share/vm/c1/c1_GraphBuilder.cpp
! src/share/vm/opto/bytecodeInfo.cpp
! src/share/vm/opto/parse.hpp

Changeset: e4bb0bda20a4
Author:    morris
Date:      2013-01-25 16:31 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/e4bb0bda20a4

8005811: Turn off TierdCompilation in JDK8 trunk for all platforms
Summary: Disable tiered compilation in jdk8 because of CodeCache and performance anomalies
Reviewed-by: kvn, twisti

! src/cpu/sparc/vm/c2_globals_sparc.hpp
! src/cpu/x86/vm/c2_globals_x86.hpp

Changeset: 76341426b645
Author:    drchase
Date:      2013-01-25 16:09 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/76341426b645

8006500: compiler/8004741/Test8004741.java fails intermediately
Summary: rewrote the test to be more reliable, add test for invalid size exception
Reviewed-by: kvn

! test/compiler/8004741/Test8004741.java

Changeset: 9fae07c31641
Author:    morris
Date:      2013-01-25 16:50 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/9fae07c31641

6518907: cleanup IA64 specific code in Hotspot
Summary: removed unused IA64 specific code
Reviewed-by: twisti, kvn, dholmes

! agent/src/os/linux/LinuxDebuggerLocal.c
! agent/src/os/linux/libproc.h
! agent/src/os/win32/windbg/sawindbg.cpp
! src/os/linux/vm/os_linux.cpp
! src/os/windows/vm/os_windows.cpp
! src/share/vm/interpreter/bytecodeInterpreter.cpp
! src/share/vm/opto/generateOptoStub.cpp
! src/share/vm/runtime/os.cpp
! src/share/vm/runtime/sharedRuntime.cpp
! src/share/vm/runtime/synchronizer.cpp
! src/share/vm/runtime/vframeArray.cpp

Changeset: 37c18711a0df
Author:    roland
Date:      2013-02-04 09:11 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/37c18711a0df

8005114: VM is crashing in ciKlass*ciObjArrayKlass::element_klass() if metaspaces are full
Summary: missing test for loaded klass in c1
Reviewed-by: kvn

! src/share/vm/c1/c1_Instruction.cpp

Changeset: 39901f2f1abe
Author:    mikael
Date:      2013-02-04 10:28 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/39901f2f1abe

8007403: Incorrect format arguments in adlparse.cpp
Reviewed-by: kvn, twisti

! src/share/vm/adlc/adlparse.cpp

Changeset: 8bd61471a109
Author:    roland
Date:      2013-02-04 11:30 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/8bd61471a109

8007144: Incremental inlining mistakes some call sites for dead ones and doesn't inline them
Summary: wrong detection for dead call sites.
Reviewed-by: kvn

! src/share/vm/opto/callGenerator.cpp

Changeset: 6a51fc70a15e
Author:    vlivanov
Date:      2013-02-05 08:25 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/6a51fc70a15e

8006613: adding reason to made_not_compilable
Reviewed-by: kvn, vlivanov
Contributed-by: Igor Ignatyev <igor.ignatyev at oracle.com>

! src/share/vm/ci/ciMethod.cpp
! src/share/vm/ci/ciMethod.hpp
! src/share/vm/compiler/compileBroker.cpp
! src/share/vm/oops/method.cpp
! src/share/vm/oops/method.hpp
! src/share/vm/oops/methodData.hpp
! src/share/vm/runtime/deoptimization.cpp

Changeset: 4fcf990aa34a
Author:    drchase
Date:      2013-02-06 11:33 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/4fcf990aa34a

8006807: C2 crash due to out of bounds array access in Parse::do_multianewarray
Summary: check ndimensions before accessing length[i] element
Reviewed-by: kvn
Contributed-by: volker.simonis at gmail.com

! src/share/vm/opto/parse3.cpp

Changeset: d05ff4bf41b3
Author:    vlivanov
Date:      2013-02-07 12:23 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/d05ff4bf41b3

Merge

! src/share/vm/oops/method.cpp
! src/share/vm/oops/method.hpp
! src/share/vm/oops/methodData.hpp

Changeset: db9981fd3124
Author:    jprovino
Date:      2013-01-23 13:02 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/db9981fd3124

8005915: Unify SERIALGC and INCLUDE_ALTERNATE_GCS
Summary: Rename INCLUDE_ALTERNATE_GCS to INCLUDE_ALL_GCS and replace SERIALGC with INCLUDE_ALL_GCS.
Reviewed-by: coleenp, stefank

! make/bsd/makefiles/minimal1.make
! make/excludeSrc.make
! make/linux/makefiles/minimal1.make
! src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp
! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp
! src/cpu/sparc/vm/cppInterpreter_sparc.cpp
! src/cpu/sparc/vm/macroAssembler_sparc.cpp
! src/cpu/sparc/vm/macroAssembler_sparc.hpp
! src/cpu/sparc/vm/templateInterpreter_sparc.cpp
! src/cpu/sparc/vm/templateTable_sparc.cpp
! src/cpu/x86/vm/assembler_x86.cpp
! src/cpu/x86/vm/c1_CodeStubs_x86.cpp
! src/cpu/x86/vm/c1_Runtime1_x86.cpp
! src/cpu/x86/vm/cppInterpreter_x86.cpp
! src/cpu/x86/vm/macroAssembler_x86.cpp
! src/cpu/x86/vm/macroAssembler_x86.hpp
! src/cpu/x86/vm/templateInterpreter_x86_32.cpp
! src/cpu/x86/vm/templateInterpreter_x86_64.cpp
! src/cpu/x86/vm/templateTable_x86_32.cpp
! src/cpu/x86/vm/templateTable_x86_64.cpp
! src/cpu/zero/vm/assembler_zero.cpp
! src/cpu/zero/vm/cppInterpreter_zero.cpp
! src/share/vm/c1/c1_CodeStubs.hpp
! src/share/vm/c1/c1_LIRGenerator.cpp
! src/share/vm/ci/ciEnv.cpp
! src/share/vm/ci/ciReplay.cpp
! src/share/vm/gc_implementation/g1/g1SATBCardTableModRefBS.hpp
! src/share/vm/gc_implementation/g1/heapRegion.hpp
! src/share/vm/gc_implementation/shared/allocationStats.cpp
! src/share/vm/gc_implementation/shared/allocationStats.hpp
! src/share/vm/gc_implementation/shared/concurrentGCThread.hpp
! src/share/vm/gc_implementation/shared/gSpaceCounters.cpp
! src/share/vm/gc_implementation/shared/gSpaceCounters.hpp
! src/share/vm/gc_implementation/shared/gcAdaptivePolicyCounters.hpp
! src/share/vm/gc_implementation/shared/hSpaceCounters.hpp
! src/share/vm/gc_implementation/shared/immutableSpace.cpp
! src/share/vm/gc_implementation/shared/isGCActiveMark.hpp
! src/share/vm/gc_implementation/shared/markSweep.inline.hpp
! src/share/vm/gc_implementation/shared/mutableNUMASpace.hpp
! src/share/vm/gc_implementation/shared/mutableSpace.cpp
! src/share/vm/gc_implementation/shared/spaceCounters.cpp
! src/share/vm/gc_implementation/shared/spaceCounters.hpp
! src/share/vm/gc_implementation/shared/vmGCOperations.cpp
! src/share/vm/memory/binaryTreeDictionary.cpp
! src/share/vm/memory/cardTableModRefBS.cpp
! src/share/vm/memory/cardTableRS.cpp
! src/share/vm/memory/collectorPolicy.cpp
! src/share/vm/memory/collectorPolicy.hpp
! src/share/vm/memory/freeBlockDictionary.cpp
! src/share/vm/memory/freeList.cpp
! src/share/vm/memory/genCollectedHeap.cpp
! src/share/vm/memory/generationSpec.cpp
! src/share/vm/memory/heapInspection.cpp
! src/share/vm/memory/heapInspection.hpp
! src/share/vm/memory/space.cpp
! src/share/vm/memory/space.hpp
! src/share/vm/memory/specialized_oop_closures.hpp
! src/share/vm/memory/tenuredGeneration.cpp
! src/share/vm/memory/tenuredGeneration.hpp
! src/share/vm/memory/universe.cpp
! src/share/vm/oops/cpCache.cpp
! src/share/vm/oops/instanceClassLoaderKlass.cpp
! src/share/vm/oops/instanceClassLoaderKlass.hpp
! src/share/vm/oops/instanceKlass.cpp
! src/share/vm/oops/instanceKlass.hpp
! src/share/vm/oops/instanceMirrorKlass.cpp
! src/share/vm/oops/instanceMirrorKlass.hpp
! src/share/vm/oops/instanceRefKlass.cpp
! src/share/vm/oops/instanceRefKlass.hpp
! src/share/vm/oops/klass.cpp
! src/share/vm/oops/klass.hpp
! src/share/vm/oops/klassPS.hpp
! src/share/vm/oops/objArrayKlass.cpp
! src/share/vm/oops/objArrayKlass.hpp
! src/share/vm/oops/objArrayKlass.inline.hpp
! src/share/vm/oops/oop.hpp
! src/share/vm/oops/oop.inline.hpp
! src/share/vm/oops/oop.pcgc.inline.hpp
! src/share/vm/oops/oop.psgc.inline.hpp
! src/share/vm/oops/typeArrayKlass.cpp
! src/share/vm/precompiled/precompiled.hpp
! src/share/vm/prims/jni.cpp
! src/share/vm/prims/jvmtiEnvBase.hpp
! src/share/vm/prims/jvmtiExport.cpp
! src/share/vm/prims/jvmtiExport.hpp
! src/share/vm/prims/jvmtiTagMap.cpp
! src/share/vm/prims/nativeLookup.cpp
! src/share/vm/prims/unsafe.cpp
! src/share/vm/prims/whitebox.cpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/fprofiler.hpp
! src/share/vm/runtime/globals.cpp
! src/share/vm/runtime/globals_extension.hpp
! src/share/vm/runtime/init.cpp
! src/share/vm/runtime/java.cpp
! src/share/vm/runtime/safepoint.cpp
! src/share/vm/runtime/sharedRuntime.cpp
! src/share/vm/runtime/sharedRuntime.hpp
! src/share/vm/runtime/thread.cpp
! src/share/vm/runtime/thread.hpp
! src/share/vm/runtime/vmStructs.cpp
! src/share/vm/services/attachListener.hpp
! src/share/vm/services/classLoadingService.cpp
! src/share/vm/services/classLoadingService.hpp
! src/share/vm/services/diagnosticCommand.cpp
! src/share/vm/services/diagnosticCommand.hpp
! src/share/vm/services/g1MemoryPool.hpp
! src/share/vm/services/heapDumper.cpp
! src/share/vm/services/management.cpp
! src/share/vm/services/memReporter.hpp
! src/share/vm/services/memoryPool.cpp
! src/share/vm/services/memoryPool.hpp
! src/share/vm/services/memoryService.cpp
! src/share/vm/services/psMemoryPool.hpp
! src/share/vm/services/runtimeService.cpp
! src/share/vm/utilities/macros.hpp
! src/share/vm/utilities/top.hpp
! src/share/vm/utilities/yieldingWorkgroup.cpp
! src/share/vm/utilities/yieldingWorkgroup.hpp

Changeset: 8391fdd36e1f
Author:    dlong
Date:      2013-01-27 01:07 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/8391fdd36e1f

Merge

! src/cpu/x86/vm/assembler_x86.cpp
! src/cpu/x86/vm/macroAssembler_x86.cpp
! src/cpu/x86/vm/macroAssembler_x86.hpp
! src/share/vm/ci/ciReplay.cpp
! src/share/vm/memory/universe.cpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/vmStructs.cpp
! src/share/vm/services/heapDumper.cpp

Changeset: 3c9bc17b9403
Author:    bpittore
Date:      2013-02-07 16:05 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/3c9bc17b9403

Merge

! src/share/vm/gc_implementation/shared/vmGCOperations.cpp
! src/share/vm/memory/binaryTreeDictionary.cpp
! src/share/vm/memory/heapInspection.cpp
! src/share/vm/memory/heapInspection.hpp
! src/share/vm/memory/universe.cpp
! src/share/vm/oops/instanceKlass.cpp
! src/share/vm/oops/instanceKlass.hpp
! src/share/vm/oops/klass.cpp
! src/share/vm/oops/klass.hpp
! src/share/vm/oops/oop.inline.hpp
! src/share/vm/prims/jvmtiExport.cpp
! src/share/vm/prims/whitebox.cpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/thread.cpp
! src/share/vm/runtime/vmStructs.cpp
! src/share/vm/services/attachListener.hpp
! src/share/vm/services/diagnosticCommand.cpp
! src/share/vm/services/diagnosticCommand.hpp

Changeset: df8462fbe585
Author:    vladidan
Date:      2013-02-07 20:40 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/df8462fbe585

Merge

! src/share/vm/ci/ciEnv.cpp
! src/share/vm/runtime/sharedRuntime.cpp

Changeset: ec0c4951286c
Author:    stefank
Date:      2013-01-29 10:51 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/ec0c4951286c

8004710: NPG: jmap could throw sun.jvm.hotspot.types.WrongTypeException after PermGen removal
Summary: When calculating live object regions, make sure that the alignment reserve, at the end of a TLAB, is excluded.
Reviewed-by: jmasa, brutisso

! agent/src/share/classes/sun/jvm/hotspot/oops/ObjectHeap.java
! agent/src/share/classes/sun/jvm/hotspot/runtime/ThreadLocalAllocBuffer.java
! agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java
! src/share/vm/runtime/vmStructs.cpp

Changeset: 4700e77d44c1
Author:    johnc
Date:      2013-02-01 13:17 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/4700e77d44c1

8006894: G1: Number of marking threads missing from PrintFlagsFinal output
Summary: Set ConcGCThreads to the calculated number of marking threads.
Reviewed-by: jmasa, ysr

! src/share/vm/gc_implementation/g1/concurrentMark.cpp

Changeset: d9058e388631
Author:    mikael
Date:      2013-02-01 17:21 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/d9058e388631

8007257: NPG: metaspace.cpp: Incorrect arguments in calls to err_msg
Summary: Fix size checks in assert and corrected some print formats. Also reviewed by vitalyd at gmail.com.
Reviewed-by: coleenp, sspitsyn

! src/share/vm/memory/metaspace.cpp

Changeset: 256d3f43c177
Author:    johnc
Date:      2013-01-31 10:45 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/256d3f43c177

8005875: G1: Kitchensink fails with ParallelGCThreads=0
Summary: Check that the concurrent marking worker gang exists in ConcurrentMark::print_worker_threads_on(). Changes were also reviewed by Vitaly Davidovich <vitalyd at gmail.com>.
Reviewed-by: brutisso

! src/share/vm/gc_implementation/g1/concurrentMark.cpp
! src/share/vm/gc_implementation/g1/concurrentMark.hpp

Changeset: 80518f4ecf32
Author:    jmasa
Date:      2013-02-04 12:51 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/80518f4ecf32

Merge

! src/share/vm/runtime/vmStructs.cpp

Changeset: f2f0cf0f5444
Author:    jmasa
Date:      2013-02-04 13:26 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/f2f0cf0f5444

Merge


Changeset: 06fd03af6ce4
Author:    johnc
Date:      2013-02-04 13:24 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/06fd03af6ce4

8001384: G1: assert(!is_null(v)) failed: narrow oop value can never be zero
Summary: Flush any deferred card mark before a Java thread exits.
Reviewed-by: brutisso, jmasa

! src/share/vm/runtime/thread.cpp

Changeset: 84304a77c4e3
Author:    johnc
Date:      2013-02-04 19:40 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/84304a77c4e3

Merge


Changeset: 95ccff9eee8e
Author:    jwilhelm
Date:      2013-01-28 15:41 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/95ccff9eee8e

6348447: Specifying -XX:OldSize crashes 64-bit VMs
Summary: Heap size will be set to allow for OldSize to fit. Also reviewed by vitalyd at gmail.com
Reviewed-by: ehelin, jmasa

! src/share/vm/memory/collectorPolicy.cpp
! src/share/vm/memory/collectorPolicy.hpp

Changeset: f90b9bceb8e5
Author:    johnc
Date:      2013-02-05 09:13 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/f90b9bceb8e5

8005032: G1: Cleanup serial reference processing closures in concurrent marking
Summary: Reuse the parallel reference processing oop closures during serial reference processing.
Reviewed-by: brutisso

! src/share/vm/gc_implementation/g1/concurrentMark.cpp
! src/share/vm/gc_implementation/g1/concurrentMark.hpp

Changeset: 50d3b37d5bcd
Author:    johnc
Date:      2013-02-05 22:24 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/50d3b37d5bcd

Merge


Changeset: 1135141fb97e
Author:    brutisso
Date:      2013-02-08 10:08 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/1135141fb97e

Merge

! src/share/vm/memory/collectorPolicy.cpp
! src/share/vm/memory/collectorPolicy.hpp
! src/share/vm/runtime/thread.cpp
! src/share/vm/runtime/vmStructs.cpp

Changeset: 412d722168bc
Author:    amurillo
Date:      2013-02-08 08:07 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/412d722168bc

Merge

- agent/src/share/classes/sun/jvm/hotspot/memory/BinaryTreeDictionary.java
- make/solaris/makefiles/kernel.make
- test/runtime/7158988/TestFieldMonitor.sh

Changeset: cdb46031e718
Author:    amurillo
Date:      2013-02-08 08:07 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/cdb46031e718

Added tag hs25-b18 for changeset 412d722168bc

! .hgtags

Changeset: 1f84c84f8e1a
Author:    katleman
Date:      2013-02-14 11:43 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/1f84c84f8e1a

Added tag jdk8-b77 for changeset cdb46031e718

! .hgtags

Changeset: 1a0174612b49
Author:    amurillo
Date:      2013-02-08 08:16 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/1a0174612b49

8007801: new hotspot build - hs25-b19
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: 8d9fc28831cc
Author:    dcubed
Date:      2013-02-06 14:31 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/8d9fc28831cc

7182152: Instrumentation hot swap test incorrect monitor count
Summary: Add/refine new tracing support using -XX:TraceRedefineClasses=16384.
Reviewed-by: coleenp, acorn, sspitsyn

! src/share/vm/oops/cpCache.cpp
! src/share/vm/oops/cpCache.hpp
! src/share/vm/oops/klassVtable.cpp
! src/share/vm/oops/klassVtable.hpp
! src/share/vm/oops/method.cpp
! src/share/vm/oops/method.hpp
! src/share/vm/prims/jvmtiRedefineClasses.cpp
! src/share/vm/prims/jvmtiRedefineClasses.hpp
! src/share/vm/prims/jvmtiRedefineClassesTrace.hpp
! src/share/vm/utilities/accessFlags.cpp
! src/share/vm/utilities/accessFlags.hpp

Changeset: 3a88007634b0
Author:    ctornqvi
Date:      2013-02-08 10:42 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/3a88007634b0

8007434: Write tests for 8006298
Summary: Four tests written for 8006298
Reviewed-by: mgerdin, coleenp

+ test/runtime/CommandLine/BooleanFlagWithInvalidValue.java
+ test/runtime/CommandLine/FlagWithInvalidValue.java
+ test/runtime/CommandLine/NonBooleanFlagWithInvalidBooleanPrefix.java
+ test/runtime/CommandLine/UnrecognizedVMOption.java

Changeset: 758935f7c23f
Author:    sla
Date:      2013-02-08 12:48 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/758935f7c23f

8006423: SA: NullPointerException in sun.jvm.hotspot.debugger.bsd.BsdThread.getContext(BsdThread.java:67)
Summary: Do not rely on mach thread port names to identify threads from SA
Reviewed-by: dholmes, minqi, rbackman

! agent/src/os/bsd/MacosxDebuggerLocal.m
! agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdDebugger.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdDebuggerLocal.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdThread.java
! agent/src/share/classes/sun/jvm/hotspot/runtime/bsd_amd64/BsdAMD64JavaThreadPDAccess.java
! src/os/bsd/vm/osThread_bsd.hpp
! src/os/bsd/vm/os_bsd.cpp
! src/os_cpu/bsd_x86/vm/vmStructs_bsd_x86.hpp

Changeset: 7194f764221c
Author:    sla
Date:      2013-02-08 14:05 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/7194f764221c

Merge


Changeset: 461a3adac4d1
Author:    sspitsyn
Date:      2013-02-08 09:14 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/461a3adac4d1

Merge

! src/share/vm/oops/cpCache.cpp
! src/share/vm/oops/method.cpp
! src/share/vm/oops/method.hpp

Changeset: 8bf62bd86a4e
Author:    zgu
Date:      2013-02-08 14:49 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/8bf62bd86a4e

8007791: More Restricted hs_err file permission
Summary: Enforce more restricted hs_file permission
Reviewed-by: acorn, dcubed, dsamersoff

! src/share/vm/utilities/vmError.cpp

Changeset: 1ba5b18088a8
Author:    zgu
Date:      2013-02-08 14:32 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/1ba5b18088a8

Merge


Changeset: 41d73c9b30a8
Author:    zgu
Date:      2013-02-08 16:31 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/41d73c9b30a8

8006691: Remove jvm_version_info.is_kernel_jvm field
Summary: Removed is_kernel_jvm from jvm_version_info as Kernel VM has been deprecated
Reviewed-by: mchung, coleenp

! src/share/vm/prims/jvm.cpp
! src/share/vm/prims/jvm.h

Changeset: 3f11b37f047c
Author:    zgu
Date:      2013-02-08 13:55 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/3f11b37f047c

Merge


Changeset: f989aff6946f
Author:    zgu
Date:      2013-02-08 16:56 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/f989aff6946f

Merge


Changeset: 927a311d00f9
Author:    coleenp
Date:      2013-02-11 14:06 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/927a311d00f9

8007320: NPG: move method annotations
Summary: allocate method annotations and attach to ConstMethod if present
Reviewed-by: dcubed, jiangli, sspitsyn, iklam

! agent/src/share/classes/sun/jvm/hotspot/oops/ConstMethod.java
! src/share/vm/classfile/classFileParser.cpp
! src/share/vm/classfile/classFileParser.hpp
! src/share/vm/classfile/defaultMethods.cpp
! src/share/vm/memory/heapInspection.hpp
! src/share/vm/oops/annotations.cpp
! src/share/vm/oops/annotations.hpp
! src/share/vm/oops/constMethod.cpp
! src/share/vm/oops/constMethod.hpp
! src/share/vm/oops/instanceKlass.cpp
! src/share/vm/oops/instanceKlass.hpp
! src/share/vm/oops/method.cpp
! src/share/vm/oops/method.hpp
! src/share/vm/prims/jvm.cpp
! src/share/vm/prims/jvmtiRedefineClasses.cpp
! src/share/vm/prims/jvmtiRedefineClasses.hpp
! src/share/vm/runtime/fieldDescriptor.cpp
! src/share/vm/runtime/vmStructs.cpp
+ test/runtime/8007320/ConstMethodTest.java

Changeset: 5ee2b330eacd
Author:    zgu
Date:      2013-02-12 12:19 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/5ee2b330eacd

8007950: Undo hs_file permission change
Summary: Reverse hs_err file permission back to 0666, as early push was premature
Reviewed-by: dsamersoff, dcubed, acorn

! src/share/vm/utilities/vmError.cpp

Changeset: deb43b8a436e
Author:    sspitsyn
Date:      2013-02-13 08:42 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/deb43b8a436e

Merge


Changeset: bce1ac447f6b
Author:    johnc
Date:      2013-02-06 14:50 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/bce1ac447f6b

7052429: G1: Avoid unnecessary scanning of humongous regions during concurrent marking
Summary: Skip unnecessary scanning of bitmap for unmarked humongous objects/regions.
Reviewed-by: jwilhelm, johnc
Contributed-by: Tao Mao <tao.mao at oracle.com>

! src/share/vm/gc_implementation/g1/concurrentMark.cpp
! src/share/vm/runtime/globals.hpp

Changeset: f64ffbf81af5
Author:    jwilhelm
Date:      2013-02-07 15:51 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/f64ffbf81af5

8006432: Ratio flags should be unsigned
Summary: Flags changed to be of uintx type
Reviewed-by: johnc, tamao

! src/cpu/zero/vm/shark_globals_zero.hpp
! src/os_cpu/bsd_x86/vm/globals_bsd_x86.hpp
! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp
! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp
! src/share/vm/gc_implementation/g1/g1_globals.hpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/globals.hpp

Changeset: 5d8325eb8240
Author:    brutisso
Date:      2013-02-07 22:04 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/5d8325eb8240

Merge

! src/share/vm/runtime/thread.cpp

Changeset: 9425ba04792d
Author:    brutisso
Date:      2013-02-07 18:40 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/9425ba04792d

Merge

- agent/src/share/classes/sun/jvm/hotspot/memory/BinaryTreeDictionary.java
- make/solaris/makefiles/kernel.make
! src/share/vm/runtime/arguments.cpp
- test/runtime/7158988/TestFieldMonitor.sh

Changeset: ad747ee9d0b1
Author:    brutisso
Date:      2013-02-10 21:15 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/ad747ee9d0b1

8002144: G1: large number of evacuation failures may lead to large c heap memory usage
Summary: Use Stack<> instead of GrowableArray to keep track of preserved marks. Also reviewed by vitalyd at gmail.com.
Reviewed-by: johnc, jcoomes

! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp

Changeset: 5e401ef52ec0
Author:    johnc
Date:      2013-02-11 15:24 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/5e401ef52ec0

8007772: G1: assert(!hr->isHumongous() || mr.start() == hr->bottom()) failed: the start of HeapRegion and MemRegion should be consistent for humongous regions
Summary: In do_marking_step(), we should always give up current region after scanning the object, if the region is humongous.
Reviewed-by: brutisso, jwilhelm, tamao

! src/share/vm/gc_implementation/g1/concurrentMark.cpp

Changeset: a83cd101fd62
Author:    jmasa
Date:      2013-01-23 19:08 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/a83cd101fd62

8005452: NPG: Create new flags for Metaspace resizing policy
Reviewed-by: johnc, jwilhelm, coleenp, stefank

! src/share/vm/memory/metaspace.cpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/globals.hpp

Changeset: b8d5d7a6c94c
Author:    brutisso
Date:      2013-02-14 11:01 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/b8d5d7a6c94c

Merge

! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/thread.cpp

Changeset: 91a23b11d8dc
Author:    kvn
Date:      2013-02-08 15:07 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/91a23b11d8dc

8007708: compiler/6855215 assert(VM_Version::supports_sse4_2())
Summary: Added missing UseSSE42 check. Also added missing avx2 assert for vpermq instruction.
Reviewed-by: roland, twisti

! src/cpu/x86/vm/assembler_x86.cpp
! src/cpu/x86/vm/macroAssembler_x86.cpp

Changeset: 309460dcedf7
Author:    morris
Date:      2013-02-08 15:39 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/309460dcedf7

8006851: When TieredCompilation is set, max code cache should be bumped to 256mb
Summary: Set ReservedCodeCacheSize to (default value)*5 when TieredCompilation is on.
Reviewed-by: kvn, twisti

! src/share/vm/runtime/arguments.cpp

Changeset: 2c673161698a
Author:    drchase
Date:      2013-02-09 12:55 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/2c673161698a

8007402: Code cleanup to remove Parfait false positive
Summary: add array access range check
Reviewed-by: kvn

! src/share/vm/opto/regmask.cpp
! src/share/vm/opto/regmask.hpp

Changeset: 64d2a0a39954
Author:    kmo
Date:      2013-02-10 22:35 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/64d2a0a39954

8006430: TraceTypeProfile is a product flag while it should be a diagnostic flag
Summary: make sure all diagnostic and experimental flag kinds are checked in Flag::is_unlocked()
Reviewed-by: kvn

! src/share/vm/runtime/globals.cpp

Changeset: a9c29dfc7d73
Author:    morris
Date:      2013-02-11 10:38 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/a9c29dfc7d73

8003251: ARM: move MacroAssembler into separate file
Summary: moved MacroAssembler into separate file
Reviewed-by: twisti, kvn, dlong

! src/share/vm/asm/macroAssembler.hpp
! src/share/vm/asm/macroAssembler.inline.hpp

Changeset: 1e5e28bac299
Author:    morris
Date:      2013-02-11 14:47 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/1e5e28bac299

8003252: PPC: move MacroAssembler into separate file
Summary: moved MacroAssembler into separate file
Reviewed-by: twisti, kvn, dlong

! src/share/vm/asm/macroAssembler.hpp
! src/share/vm/asm/macroAssembler.inline.hpp

Changeset: 8b3da8d14c93
Author:    roland
Date:      2013-02-12 12:56 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/8b3da8d14c93

7197327: 40% regression on 8 b41 comp 8 b40 on specjvm2008.mpegaudio on oob
Summary: Add support for expensive nodes.
Reviewed-by: kvn

! src/share/vm/opto/c2_globals.hpp
! src/share/vm/opto/compile.cpp
! src/share/vm/opto/compile.hpp
! src/share/vm/opto/library_call.cpp
! src/share/vm/opto/loopnode.cpp
! src/share/vm/opto/loopnode.hpp
! src/share/vm/opto/node.cpp
! src/share/vm/opto/node.hpp
! src/share/vm/opto/phaseX.cpp
! src/share/vm/opto/subnode.hpp

Changeset: c703f9c4b025
Author:    kmo
Date:      2013-02-12 07:39 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/c703f9c4b025

8002169: TEST_BUG: compiler/7009359/Test7009359.java sometimes times out
Summary: make the test less prone to timeout by reducing the amount of iteration and allowing main to be compiled
Reviewed-by: jrose

! test/compiler/7009359/Test7009359.java

Changeset: aaad39923cdb
Author:    kmo
Date:      2013-02-12 14:33 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/aaad39923cdb

Merge


Changeset: 12e01444ca2d
Author:    iignatyev
Date:      2013-02-13 08:29 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/12e01444ca2d

8006683: Add WhiteBox API to testing of compiler
Reviewed-by: kvn, vlivanov

! src/share/tools/whitebox/sun/hotspot/WhiteBox.java
! src/share/vm/prims/wbtestmethods/parserTests.hpp
! src/share/vm/prims/whitebox.cpp
! src/share/vm/prims/whitebox.hpp
+ test/compiler/whitebox/CompilerWhiteBoxTest.java
+ test/compiler/whitebox/DeoptimizeAllTest.java
+ test/compiler/whitebox/DeoptimizeMethodTest.java
+ test/compiler/whitebox/IsMethodCompilableTest.java
+ test/compiler/whitebox/MakeMethodNotCompilableTest.java
+ test/compiler/whitebox/SetDontInlineMethodTest.java

Changeset: 1cdf241a4b26
Author:    vlivanov
Date:      2013-02-14 05:36 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/1cdf241a4b26

Merge

! src/share/vm/runtime/arguments.cpp

Changeset: 9f19f4a7d48a
Author:    amurillo
Date:      2013-02-15 13:27 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/9f19f4a7d48a

Merge


Changeset: d5e12e7d2f71
Author:    amurillo
Date:      2013-02-15 13:27 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/d5e12e7d2f71

Added tag hs25-b19 for changeset 9f19f4a7d48a

! .hgtags

Changeset: b2c8e33dcd1c
Author:    mduigou
Date:      2013-02-20 13:10 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/b2c8e33dcd1c

Merge

! .hgtags
- agent/src/share/classes/sun/jvm/hotspot/memory/BinaryTreeDictionary.java
- make/solaris/makefiles/kernel.make
! src/share/vm/classfile/classFileParser.cpp
! src/share/vm/classfile/classFileParser.hpp
! src/share/vm/classfile/defaultMethods.cpp
! src/share/vm/classfile/systemDictionary.cpp
! src/share/vm/classfile/systemDictionary.hpp
! src/share/vm/classfile/vmSymbols.hpp
! src/share/vm/interpreter/linkResolver.cpp
! src/share/vm/oops/constMethod.cpp
! src/share/vm/oops/constMethod.hpp
! src/share/vm/oops/constantPool.cpp
! src/share/vm/oops/instanceKlass.cpp
! src/share/vm/oops/instanceKlass.hpp
! src/share/vm/oops/klassVtable.cpp
! src/share/vm/oops/klassVtable.hpp
! src/share/vm/oops/method.cpp
! src/share/vm/oops/method.hpp
! src/share/vm/prims/jvm.h
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/reflection.cpp
! src/share/vm/utilities/accessFlags.hpp
! src/share/vm/utilities/ostream.cpp
- test/runtime/7158988/TestFieldMonitor.sh


From mike.duigou at oracle.com  Wed Feb 20 13:15:22 2013
From: mike.duigou at oracle.com (mike.duigou at oracle.com)
Date: Wed, 20 Feb 2013 21:15:22 +0000
Subject: hg: lambda/lambda/corba: 6 new changesets
Message-ID: <20130220211527.C345047C15@hg.openjdk.java.net>

Changeset: 4a6be02e66a3
Author:    katleman
Date:      2013-01-31 17:04 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/corba/rev/4a6be02e66a3

Added tag jdk8-b75 for changeset d4e68ce17795

! .hgtags

Changeset: ce106b6b7394
Author:    ohrstrom
Date:      2013-01-31 14:02 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/corba/rev/ce106b6b7394

8006872: Stop creating four jars with identical content in the new build system.
Reviewed-by: erikj

! makefiles/BuildCorba.gmk

Changeset: 58be6ca3c060
Author:    katleman
Date:      2013-02-05 18:54 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/corba/rev/58be6ca3c060

Merge


Changeset: 35684a40c584
Author:    katleman
Date:      2013-02-07 12:32 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/corba/rev/35684a40c584

Added tag jdk8-b76 for changeset 58be6ca3c060

! .hgtags

Changeset: 27d6368ae8ba
Author:    katleman
Date:      2013-02-14 11:43 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/corba/rev/27d6368ae8ba

Added tag jdk8-b77 for changeset 35684a40c584

! .hgtags

Changeset: d6c69903eb13
Author:    mduigou
Date:      2013-02-20 09:45 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/corba/rev/d6c69903eb13

Merge

! .hgtags


From mike.duigou at oracle.com  Wed Feb 20 13:15:22 2013
From: mike.duigou at oracle.com (mike.duigou at oracle.com)
Date: Wed, 20 Feb 2013 21:15:22 +0000
Subject: hg: lambda/lambda: 25 new changesets
Message-ID: <20130220211524.EAB2C47C14@hg.openjdk.java.net>

Changeset: e28985c549aa
Author:    raginip
Date:      2013-01-18 11:31 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/rev/e28985c549aa

8000839: Integrate the Java Access Bridge with Java Runtime
Reviewed-by: ptbrunet, erikj

! common/bin/compare_exceptions.sh.incl

Changeset: db46b1c27a93
Author:    erikj
Date:      2013-01-28 14:23 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/rev/db46b1c27a93

Merge

- common/autoconf/closed.version.numbers
! common/autoconf/generated-configure.sh
- common/autoconf/version.numbers
! common/bin/compare_exceptions.sh.incl

Changeset: 8baaaba2ee6b
Author:    lana
Date:      2013-01-29 20:16 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/rev/8baaaba2ee6b

Merge


Changeset: 0d4b0a13adb2
Author:    erikj
Date:      2013-01-23 11:37 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/rev/0d4b0a13adb2

8005855: build-infra: Remove -R flag when cross compiling
Reviewed-by: dholmes, tbell

! common/autoconf/generated-configure.sh
! common/autoconf/libraries.m4

Changeset: ea6379d4624f
Author:    erikj
Date:      2013-01-23 11:41 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/rev/ea6379d4624f

8006663: build-infra: Compare two arbitrary zip/jar files with compare.sh
Reviewed-by: tbell

! common/bin/compare.sh

Changeset: 0d46733cfffb
Author:    erikj
Date:      2013-01-23 11:42 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/rev/0d46733cfffb

8006658: build-infra: Make MILESTONE behave the same as JDK_BUILD_NUMBER
Reviewed-by: ohrstrom, dholmes, tbell

! common/autoconf/generated-configure.sh
! common/autoconf/jdk-options.m4

Changeset: 9e5847257731
Author:    erikj
Date:      2013-01-24 09:17 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/rev/9e5847257731

Merge


Changeset: 2a713921952c
Author:    katleman
Date:      2013-01-30 13:39 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/rev/2a713921952c

Merge

! common/autoconf/generated-configure.sh

Changeset: 5b19cef637a6
Author:    katleman
Date:      2013-01-31 17:04 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/rev/5b19cef637a6

Added tag jdk8-b75 for changeset 2a713921952c

! .hgtags

Changeset: 6e296219633d
Author:    tbell
Date:      2013-01-31 13:31 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/rev/6e296219633d

8006933: Need to use nawk on Solaris to avoid awk limitations
Reviewed-by: erikj, dholmes, dsamersoff

! common/makefiles/IdlCompilation.gmk

Changeset: 12782ec1da5f
Author:    ohrstrom
Date:      2013-01-31 14:00 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/rev/12782ec1da5f

8006872: Stop creating four jars with identical content in the new build system.
Reviewed-by: erikj

! common/autoconf/spec.gmk.in
! common/makefiles/JavaCompilation.gmk
! common/makefiles/javadoc/Javadoc.gmk

Changeset: 7e584be2ee58
Author:    ohrstrom
Date:      2013-02-01 11:22 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/rev/7e584be2ee58

Merge


Changeset: 339e4df096a2
Author:    erikj
Date:      2013-02-04 10:53 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/rev/339e4df096a2

8007093: build-infra: Make should fail if spec is older than configure files
Reviewed-by: tbell

! common/makefiles/Main.gmk

Changeset: dea045cc48ca
Author:    erikj
Date:      2013-02-04 11:02 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/rev/dea045cc48ca

8007275: build-infra: Create final-images target
Reviewed-by: tbell

! common/autoconf/generated-configure.sh
! common/makefiles/Jprt.gmk

Changeset: d3d9ab8ee7b0
Author:    erikj
Date:      2013-02-05 16:50 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/rev/d3d9ab8ee7b0

8007524: build-infra: Incremental build of tools.jar broken
Reviewed-by: tbell

! common/makefiles/JavaCompilation.gmk

Changeset: 278af9fc67e7
Author:    katleman
Date:      2013-02-05 18:54 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/rev/278af9fc67e7

Merge


Changeset: 3933eebc659d
Author:    katleman
Date:      2013-02-07 12:32 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/rev/3933eebc659d

Added tag jdk8-b76 for changeset 278af9fc67e7

! .hgtags

Changeset: 45dcccc6d221
Author:    katleman
Date:      2013-02-14 11:43 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/rev/45dcccc6d221

Added tag jdk8-b77 for changeset 3933eebc659d

! .hgtags

Changeset: 8dd61906da5f
Author:    chegar
Date:      2013-02-06 11:36 +0000
URL:       http://hg.openjdk.java.net/lambda/lambda/rev/8dd61906da5f

8007625: race with nested repos in /common/bin/hgforest.sh
Reviewed-by: dholmes, ohair, ohrstrom

! common/bin/hgforest.sh
! get_source.sh

Changeset: 168dd033604a
Author:    mduigou
Date:      2013-02-06 11:09 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/rev/168dd033604a

8004726: Link bug ids to jbs rather than monaco.
Reviewed-by: ohair, chegar, katleman

! make/scripts/webrev.ksh

Changeset: 7817368287cd
Author:    mduigou
Date:      2013-02-06 11:12 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/rev/7817368287cd

8006595: Use jdk/test/Makefile targets in preference to local definitions
Reviewed-by: alanb

! common/makefiles/Main.gmk
! test/Makefile

Changeset: fdb1e09519ed
Author:    sherman
Date:      2013-02-12 09:27 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/rev/fdb1e09519ed

8007392: JSR 310: DateTime API Updates
Summary: Integration of JSR310 Date/Time API for M7
Reviewed-by: darcy, alanb, naoto
Contributed-by: scolebourne at joda.org, roger.riggs at oracle.com, masayoshi.okutsu at oracle.com, patrick.zhang at oracle.com

! common/makefiles/javadoc/CORE_PKGS.gmk

Changeset: 76808fb4194a
Author:    lana
Date:      2013-02-13 11:21 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/rev/76808fb4194a

Merge

! common/makefiles/Main.gmk

Changeset: bbb7548d45c7
Author:    lana
Date:      2013-02-14 22:11 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/rev/bbb7548d45c7

Merge


Changeset: 60ab41568f02
Author:    mduigou
Date:      2013-02-20 09:44 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/rev/60ab41568f02

Merge

! .hgtags
! common/autoconf/generated-configure.sh
! common/makefiles/JavaCompilation.gmk
! common/makefiles/javadoc/CORE_PKGS.gmk
! common/makefiles/javadoc/Javadoc.gmk


From benjamin.john.evans at gmail.com  Wed Feb 20 13:27:30 2013
From: benjamin.john.evans at gmail.com (Ben Evans)
Date: Wed, 20 Feb 2013 16:27:30 -0500
Subject: TestNG tests appear to hang with latest lambda
In-Reply-To: <CABKW8Rg5+3ZuYXbKMcACB7fUY=6Q7GeXoO5L-gvaZqF3L207_g@mail.gmail.com>
References: <CABKW8Rg5+3ZuYXbKMcACB7fUY=6Q7GeXoO5L-gvaZqF3L207_g@mail.gmail.com>
Message-ID: <CABKW8Rj2eF2+kn_Membu6PWOGUbkg=3Sm7FupNTCEzjM-RVjXA@mail.gmail.com>

OK, following up to my own mail.

The tests will actually complete if left for long enough, but the
process gets *huge* - at least 2.8G in size, and if other processes
are running, it will take a very long time to complete.

Does anyone have any insight as to why the tests consume so much memory?

Ben

On Wed, Feb 20, 2013 at 3:40 PM, Ben Evans
<benjamin.john.evans at gmail.com> wrote:
> Hi,
>
> I'm writing some docs for AdoptOpenJDK about getting started writing
> TestNG tests, in advance of the hackdays at Devoxx UK.
>
> However, with latest lambda, the TestNG tests appear to hang (output
> below). The process grows in size to over 1Gb, and then appears to
> freeze. It's still responsive (so I can connect jvisualvm to it, but
> when I sample the code, nothing appears to be running).
>
> This is on Mac 10.7 with OpenJDK 8 from current lambda.
>
> Any ideas?
>
> Thanks,
>
> Ben
>
> ariel:test-ng boxcat$ ant test
> Buildfile: /Users/boxcat/projects/lambda/jdk/test-ng/build.xml
>
> prepare:
>
> test-compile:
>     [javac] /Users/boxcat/projects/lambda/jdk/test-ng/build.xml:78:
> warning: 'includeantruntime' was not set, defaulting to
> build.sysclasspath=last; set to false for repeatable builds
>     [javac] /Users/boxcat/projects/lambda/jdk/test-ng/build.xml:82:
> warning: 'includeantruntime' was not set, defaulting to
> build.sysclasspath=last; set to false for repeatable builds
>     [javac] /Users/boxcat/projects/lambda/jdk/test-ng/build.xml:86:
> warning: 'includeantruntime' was not set, defaulting to
> build.sysclasspath=last; set to false for repeatable builds
>
> test:
>      [echo] Results at: file:../../build/test-ng/test-reports/index.html
>    [testng] [TestNG] Running:
>    [testng]   Ant suite
>    [testng]
>    [testng]
>    [testng] Generating exhaustive interface....
>    [testng]       8 No default
>    [testng]       8 Error
>    [testng]      48 OK
>    [testng]      64 Total
>    [testng]
>    [testng] Generating exhaustive class....
>    [testng]     729 No default
>    [testng]      49 Error
>    [testng]     950 OK
>    [testng]    1728 Total
>    [testng]
>    [testng] Generating shapes interface....
>    [testng]     109 No default
>    [testng]     280 Error
>    [testng]     507 OK
>    [testng]     896 Total
>    [testng]
>    [testng] Generating shapes class/interface....
>    [testng]     190 No default
>    [testng]     568 Error
>    [testng]     536 OK
>    [testng]    1294 Total
>    [testng]
>    [testng] Expect OK:    2041 -- unique 1813
>    [testng] Expect Error: 905 -- unique 773
>    [testng]
>    [testng] Generating exhaustive interface....
>    [testng]       8 No default
>    [testng]       8 Error
>    [testng]      48 OK
>    [testng]      64 Total
>    [testng]
>    [testng] Generating exhaustive class....
>    [testng]     729 No default
>    [testng]      49 Error
>    [testng]     950 OK
>    [testng]    1728 Total
>    [testng]
>    [testng] Generating shapes interface....
>    [testng]     109 No default
>    [testng]     280 Error
>    [testng]     507 OK
>    [testng]     896 Total
>    [testng]
>    [testng] Generating shapes class/interface....
>    [testng]     190 No default
>    [testng]     568 Error
>    [testng]     536 OK
>    [testng]    1294 Total
>    [testng]
>    [testng] Expect OK:    2041 -- unique 1813
>    [testng] Expect Error: 905 -- unique 773

From jonathan.gibbons at oracle.com  Wed Feb 20 13:32:08 2013
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Wed, 20 Feb 2013 13:32:08 -0800
Subject: TestNG tests appear to hang with latest lambda
In-Reply-To: <CABKW8Rj2eF2+kn_Membu6PWOGUbkg=3Sm7FupNTCEzjM-RVjXA@mail.gmail.com>
References: <CABKW8Rg5+3ZuYXbKMcACB7fUY=6Q7GeXoO5L-gvaZqF3L207_g@mail.gmail.com>
	<CABKW8Rj2eF2+kn_Membu6PWOGUbkg=3Sm7FupNTCEzjM-RVjXA@mail.gmail.com>
Message-ID: <512540D8.6060702@oracle.com>

My understanding is that TestNG does not scale well with too many test 
cases,
and folk are just testing stuff "too much" these days :-)

-- Jon

On 02/20/2013 01:27 PM, Ben Evans wrote:
> OK, following up to my own mail.
>
> The tests will actually complete if left for long enough, but the
> process gets *huge* - at least 2.8G in size, and if other processes
> are running, it will take a very long time to complete.
>
> Does anyone have any insight as to why the tests consume so much memory?
>
> Ben
>
> On Wed, Feb 20, 2013 at 3:40 PM, Ben Evans
> <benjamin.john.evans at gmail.com> wrote:
>> Hi,
>>
>> I'm writing some docs for AdoptOpenJDK about getting started writing
>> TestNG tests, in advance of the hackdays at Devoxx UK.
>>
>> However, with latest lambda, the TestNG tests appear to hang (output
>> below). The process grows in size to over 1Gb, and then appears to
>> freeze. It's still responsive (so I can connect jvisualvm to it, but
>> when I sample the code, nothing appears to be running).
>>
>> This is on Mac 10.7 with OpenJDK 8 from current lambda.
>>
>> Any ideas?
>>
>> Thanks,
>>
>> Ben
>>
>> ariel:test-ng boxcat$ ant test
>> Buildfile: /Users/boxcat/projects/lambda/jdk/test-ng/build.xml
>>
>> prepare:
>>
>> test-compile:
>>      [javac] /Users/boxcat/projects/lambda/jdk/test-ng/build.xml:78:
>> warning: 'includeantruntime' was not set, defaulting to
>> build.sysclasspath=last; set to false for repeatable builds
>>      [javac] /Users/boxcat/projects/lambda/jdk/test-ng/build.xml:82:
>> warning: 'includeantruntime' was not set, defaulting to
>> build.sysclasspath=last; set to false for repeatable builds
>>      [javac] /Users/boxcat/projects/lambda/jdk/test-ng/build.xml:86:
>> warning: 'includeantruntime' was not set, defaulting to
>> build.sysclasspath=last; set to false for repeatable builds
>>
>> test:
>>       [echo] Results at: file:../../build/test-ng/test-reports/index.html
>>     [testng] [TestNG] Running:
>>     [testng]   Ant suite
>>     [testng]
>>     [testng]
>>     [testng] Generating exhaustive interface....
>>     [testng]       8 No default
>>     [testng]       8 Error
>>     [testng]      48 OK
>>     [testng]      64 Total
>>     [testng]
>>     [testng] Generating exhaustive class....
>>     [testng]     729 No default
>>     [testng]      49 Error
>>     [testng]     950 OK
>>     [testng]    1728 Total
>>     [testng]
>>     [testng] Generating shapes interface....
>>     [testng]     109 No default
>>     [testng]     280 Error
>>     [testng]     507 OK
>>     [testng]     896 Total
>>     [testng]
>>     [testng] Generating shapes class/interface....
>>     [testng]     190 No default
>>     [testng]     568 Error
>>     [testng]     536 OK
>>     [testng]    1294 Total
>>     [testng]
>>     [testng] Expect OK:    2041 -- unique 1813
>>     [testng] Expect Error: 905 -- unique 773
>>     [testng]
>>     [testng] Generating exhaustive interface....
>>     [testng]       8 No default
>>     [testng]       8 Error
>>     [testng]      48 OK
>>     [testng]      64 Total
>>     [testng]
>>     [testng] Generating exhaustive class....
>>     [testng]     729 No default
>>     [testng]      49 Error
>>     [testng]     950 OK
>>     [testng]    1728 Total
>>     [testng]
>>     [testng] Generating shapes interface....
>>     [testng]     109 No default
>>     [testng]     280 Error
>>     [testng]     507 OK
>>     [testng]     896 Total
>>     [testng]
>>     [testng] Generating shapes class/interface....
>>     [testng]     190 No default
>>     [testng]     568 Error
>>     [testng]     536 OK
>>     [testng]    1294 Total
>>     [testng]
>>     [testng] Expect OK:    2041 -- unique 1813
>>     [testng] Expect Error: 905 -- unique 773


From mike.duigou at oracle.com  Wed Feb 20 13:18:29 2013
From: mike.duigou at oracle.com (mike.duigou at oracle.com)
Date: Wed, 20 Feb 2013 21:18:29 +0000
Subject: hg: lambda/lambda/jaxws: 6 new changesets
Message-ID: <20130220211842.EBCC647C17@hg.openjdk.java.net>

Changeset: a63ef2391c20
Author:    katleman
Date:      2013-01-31 17:04 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxws/rev/a63ef2391c20

Added tag jdk8-b75 for changeset 966bf9f3c41a

! .hgtags

Changeset: 54beebb17494
Author:    ohrstrom
Date:      2013-01-31 14:02 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxws/rev/54beebb17494

8006872: Stop creating four jars with identical content in the new build system.
Reviewed-by: erikj

! makefiles/BuildJaxws.gmk

Changeset: c4853f3f0e89
Author:    katleman
Date:      2013-02-05 18:54 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxws/rev/c4853f3f0e89

Merge


Changeset: 64dfba1bad16
Author:    katleman
Date:      2013-02-07 12:33 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxws/rev/64dfba1bad16

Added tag jdk8-b76 for changeset c4853f3f0e89

! .hgtags

Changeset: 391de4c992d1
Author:    katleman
Date:      2013-02-14 11:43 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxws/rev/391de4c992d1

Added tag jdk8-b77 for changeset 64dfba1bad16

! .hgtags

Changeset: 242e9b02a7b2
Author:    mduigou
Date:      2013-02-20 13:18 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxws/rev/242e9b02a7b2

Merge

! .hgtags


From mike.duigou at oracle.com  Wed Feb 20 13:15:44 2013
From: mike.duigou at oracle.com (mike.duigou at oracle.com)
Date: Wed, 20 Feb 2013 21:15:44 +0000
Subject: hg: lambda/lambda/jdk: 121 new changesets
Message-ID: <20130220214017.85CD747C1A@hg.openjdk.java.net>

Changeset: 4faaaf5027a5
Author:    alexsch
Date:      2013-01-14 08:32 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/4faaaf5027a5

7166409: bug4331515.java fail with NullPointerException on ubuntu10.04-x86 for JDK8
Reviewed-by: serb

! src/share/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java

Changeset: 9c6ca265b4a1
Author:    alexsch
Date:      2013-01-15 12:49 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/9c6ca265b4a1

8003978: closed/javax/swing/JRootPane/bug4670486.java fails since jdk7u12b01 on macosx
Reviewed-by: serb, leonidr

! src/share/classes/com/sun/java/swing/plaf/gtk/GTKLookAndFeel.java
! src/share/classes/com/sun/java/swing/plaf/motif/MotifLookAndFeel.java
! src/share/classes/javax/swing/plaf/basic/BasicLookAndFeel.java
! src/share/classes/sun/swing/SwingUtilities2.java
! test/java/awt/KeyboardFocusmanager/TypeAhead/SubMenuShowTest/SubMenuShowTest.java

Changeset: 1b886bd5e5bf
Author:    serb
Date:      2013-01-15 21:57 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/1b886bd5e5bf

7124525: [macosx] No animation on certain Swing components in Aqua LaF
Reviewed-by: alexsch, swingler

! src/macosx/classes/com/apple/laf/AquaPainter.java
! src/macosx/classes/com/apple/laf/ImageCache.java

Changeset: 7ea1372be2fe
Author:    mcherkas
Date:      2013-01-16 17:26 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/7ea1372be2fe

8005492: Reduce number of warnings in sun/awt/* classes
Reviewed-by: art, anthony

! src/share/classes/java/awt/Button.java
! src/share/classes/java/awt/Checkbox.java
! src/share/classes/java/awt/Choice.java
! src/share/classes/java/awt/Component.java
! src/share/classes/java/awt/Container.java
! src/share/classes/java/awt/Dialog.java
! src/share/classes/java/awt/Frame.java
! src/share/classes/java/awt/KeyboardFocusManager.java
! src/share/classes/java/awt/Scrollbar.java
! src/share/classes/java/awt/TextArea.java
! src/share/classes/java/awt/TextComponent.java
! src/share/classes/java/awt/TextField.java
! src/share/classes/java/awt/Toolkit.java
! src/share/classes/java/awt/Window.java
! src/share/classes/sun/awt/image/SurfaceManager.java

Changeset: 23f9955ae34a
Author:    lana
Date:      2013-01-16 15:57 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/23f9955ae34a

Merge


Changeset: 47243a4efb8b
Author:    kshefov
Date:      2013-01-17 15:08 +0000
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/47243a4efb8b

7124209: [macosx] SpringLayout issue. BASELINE is not in the range: [NORTH, SOUTH]
Reviewed-by: serb, alexsch

+ test/javax/swing/SpringLayout/4726194/bug4726194.java

Changeset: 035f87fc9f74
Author:    anthony
Date:      2013-01-18 14:17 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/035f87fc9f74

8005465: [macosx] Evaluate if checking for the -XstartOnFirstThread is still needed in awt.m
Summary: Allow one to start AWT on the main thread w/o exceptions
Reviewed-by: art, serb

! src/macosx/native/sun/awt/awt.m

Changeset: 5309fed435b5
Author:    serb
Date:      2013-01-18 18:17 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/5309fed435b5

7179050: [macosx] Make LWAWT be able to run on AppKit thread
Summary: Removed irrelevant assertions from the LWAWT native methods
Reviewed-by: serb, anthony
Contributed-by: petr.pchelko at oracle.com

! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java
! src/macosx/native/sun/awt/AWTSurfaceLayers.m
! src/macosx/native/sun/awt/AWTView.m
! src/macosx/native/sun/awt/AWTWindow.m
! src/macosx/native/sun/awt/ApplicationDelegate.m
! src/macosx/native/sun/awt/CClipboard.m
! src/macosx/native/sun/awt/CCursorManager.m
! src/macosx/native/sun/awt/CDesktopPeer.m
! src/macosx/native/sun/awt/CDragSourceContextPeer.m
! src/macosx/native/sun/awt/CImage.m
! src/macosx/native/sun/awt/CInputMethod.m
! src/macosx/native/sun/awt/CMenu.m
! src/macosx/native/sun/awt/CMenuComponent.m
! src/macosx/native/sun/awt/CMenuItem.m
! src/macosx/native/sun/awt/CPopupMenu.m
! src/macosx/native/sun/awt/CTrayIcon.m
! src/macosx/native/sun/awt/CWrapper.m
! src/macosx/native/sun/awt/JavaComponentAccessibility.m
! src/macosx/native/sun/awt/LWCToolkit.m
! src/macosx/native/sun/awt/awt.m
! src/macosx/native/sun/osxapp/ThreadUtilities.h
! src/macosx/native/sun/osxapp/ThreadUtilities.m

Changeset: 112c08b41ca2
Author:    alitvinov
Date:      2013-01-18 18:34 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/112c08b41ca2

8006417: JComboBox.showPopup(), hidePopup() fails in JRE 1.7 on OS X
Reviewed-by: art, serb

! src/macosx/classes/sun/lwawt/LWToolkit.java
! src/macosx/classes/sun/lwawt/LWWindowPeer.java
+ test/javax/swing/JComboBox/ShowPopupAfterHidePopupTest/ShowPopupAfterHidePopupTest.java

Changeset: b4131358120a
Author:    raginip
Date:      2013-01-18 11:33 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/b4131358120a

8000839: Integrate the Java Access Bridge with Java Runtime
Reviewed-by: ptbrunet, erikj

! make/Makefile
+ make/bridge/AccessBridgeJava/Makefile
+ make/bridge/JAWTAccessBridge/Files_cpp.gmk
+ make/bridge/JAWTAccessBridge/Makefile
+ make/bridge/Jabswitch/Makefile
+ make/bridge/Jaccess/Makefile
+ make/bridge/JavaAccessBridge/Files_cpp.gmk
+ make/bridge/JavaAccessBridge/Makefile
+ make/bridge/Makefile
+ make/bridge/WindowsAccessBridge/Files_cpp.gmk
+ make/bridge/WindowsAccessBridge/Makefile
! makefiles/CompileJavaClasses.gmk
! makefiles/CompileLaunchers.gmk
! makefiles/CompileNativeLibraries.gmk
! makefiles/CopyFiles.gmk
! makefiles/CreateJars.gmk
! makefiles/GensrcMisc.gmk

Changeset: f55d869052dd
Author:    alexsch
Date:      2013-01-21 17:55 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/f55d869052dd

8004298: NPE in WindowsTreeUI.ensureRowsAreVisible
Reviewed-by: serb

! src/share/classes/com/sun/java/swing/plaf/windows/WindowsTreeUI.java
+ test/javax/swing/JTree/8004298/bug8004298.java

Changeset: dd7e1cc4253c
Author:    alexp
Date:      2013-01-24 15:26 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/dd7e1cc4253c

7147078: [macosx] Echo char set in TextField doesn't prevent word jumping
Reviewed-by: art

! src/macosx/classes/com/apple/laf/AquaKeyBindings.java
! src/macosx/classes/com/apple/laf/AquaLookAndFeel.java
! src/macosx/classes/sun/lwawt/LWTextFieldPeer.java

Changeset: 04d2005fa178
Author:    alexp
Date:      2013-01-24 15:52 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/04d2005fa178

7132793: [macosx] setWheelScrollEnabled action reversed
Reviewed-by: serb, art

! src/macosx/classes/sun/lwawt/LWComponentPeer.java
! src/macosx/classes/sun/lwawt/LWScrollPanePeer.java

Changeset: 40a45a72a120
Author:    serb
Date:      2013-01-24 15:55 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/40a45a72a120

8005997: [macosx] Printer Dialog opens an additional title bar
Reviewed-by: anthony, art
Contributed-by: petr.pchelko at oracle.com

! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java

Changeset: fab11b21ee6e
Author:    kizune
Date:      2013-01-24 16:09 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/fab11b21ee6e

7143768: [macosx] Unexpected NullPointerException and java.io.IOException during DnD
Reviewed-by: alexp

! src/macosx/classes/sun/lwawt/macosx/CDataTransferer.java

Changeset: 7dd1896b37c8
Author:    malenkov
Date:      2013-01-24 17:26 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/7dd1896b37c8

6817933: Setting the background of an HTML Widget changes the native Windows JFileChooser
Reviewed-by: alexsch

! src/share/classes/sun/swing/WindowsPlacesBar.java
+ test/javax/swing/JFileChooser/6817933/Test6817933.java

Changeset: f8526b99b825
Author:    serb
Date:      2013-01-24 17:50 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/f8526b99b825

8003173: [macosx] Fullscreen on Mac leaves an empty rectangle
Reviewed-by: anthony, alexsch

! src/macosx/classes/sun/awt/CGraphicsDevice.java
! src/macosx/classes/sun/lwawt/LWWindowPeer.java
! src/macosx/classes/sun/lwawt/macosx/CPlatformView.java
! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java
+ test/java/awt/FullScreen/FullScreenInsets/FullScreenInsets.java

Changeset: 32721a1a8da8
Author:    malenkov
Date:      2013-01-24 17:57 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/32721a1a8da8

8005138: test/java/beans/Introspector/TestTypeResolver.java fails
Reviewed-by: alexsch

! test/java/beans/Introspector/TestTypeResolver.java

Changeset: 7cda96a78260
Author:    malenkov
Date:      2013-01-24 18:06 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/7cda96a78260

8003400: JTree scrolling problem when using large model in WindowsLookAndFeel
Reviewed-by: alexsch

! src/share/classes/javax/swing/plaf/basic/BasicTreeUI.java
+ test/javax/swing/JTree/8003400/Test8003400.java

Changeset: e616c28c5120
Author:    erikj
Date:      2013-01-28 14:23 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/e616c28c5120

Merge

- make/tools/swing-beans/beaninfo/BeanInfoUtils.java
- make/tools/swing-beans/beaninfo/SwingBeanInfoBase.java
! makefiles/CompileJavaClasses.gmk
! makefiles/CompileLaunchers.gmk
! makefiles/CompileNativeLibraries.gmk
! makefiles/CopyFiles.gmk
! makefiles/CreateJars.gmk
- src/share/demo/jfc/CodePointIM/CodePointInputMethod.java
- src/share/demo/jfc/CodePointIM/CodePointInputMethodDescriptor.java

Changeset: a1a55db02f34
Author:    lana
Date:      2013-01-29 20:19 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/a1a55db02f34

Merge

! makefiles/CreateJars.gmk

Changeset: 9d5c43050210
Author:    dl
Date:      2013-01-11 16:50 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/9d5c43050210

8006123: Support @Contended Annotation - JEP 142 (jdk part)
Summary: jdk changes for 8003895.
Reviewed-by: darcy, jrose, coleenp, dholmes, kvn
Contributed-by: Aleksey Shipilev <aleksey.shipilev at oracle.com>

+ src/share/classes/sun/misc/Contended.java

Changeset: 739351a0a7a1
Author:    kvn
Date:      2013-01-23 11:47 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/739351a0a7a1

8006799: Optimize sun.nio.cs.ISO_8859_1$Encode.encodeArrayLoop() (jdk part of 6896617)
Summary: Move hot loop in ISO_8859_1$Encode.encodeArrayLoop() into separate method encodeISOArray() to be replaced by JVM JIT compiler with optimized intrinsic code.
Reviewed-by: alanb, sherman

! src/share/classes/sun/nio/cs/ISO_8859_1.java

Changeset: e9d00d30fcca
Author:    amurillo
Date:      2013-01-25 03:02 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/e9d00d30fcca

Merge


Changeset: ac286bf65242
Author:    amurillo
Date:      2013-01-30 10:18 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/ac286bf65242

Merge

- test/java/rmi/activation/ActivationSystem/unregisterGroup/CallbackInterface.java
- test/java/rmi/activation/ActivationSystem/unregisterGroup/Callback_Stub.java
- test/java/rmi/activation/ActivationSystem/unregisterGroup/UnregisterGroup_Stub.java

Changeset: 3c499051a5df
Author:    erikj
Date:      2013-01-29 16:35 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/3c499051a5df

8006873: SWAT-b74 msvcr100.dll does not have the permission for all
Reviewed-by: alanb, tbell

! makefiles/CopyFiles.gmk

Changeset: 4a67fdb752b7
Author:    katleman
Date:      2013-01-30 13:04 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/4a67fdb752b7

Merge

! makefiles/CopyFiles.gmk

Changeset: 6ba6353ab42c
Author:    katleman
Date:      2013-01-31 17:04 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/6ba6353ab42c

Added tag jdk8-b75 for changeset 4a67fdb752b7

! .hgtags

Changeset: c5a7ac2a721f
Author:    ohrstrom
Date:      2013-01-31 14:03 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/c5a7ac2a721f

8006872: Stop creating four jars with identical content in the new build system.
Reviewed-by: erikj

! makefiles/CreateJars.gmk
! makefiles/GensrcSwing.gmk
! makefiles/Setup.gmk

Changeset: 35cf77f633c9
Author:    tbell
Date:      2013-02-01 09:16 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/35cf77f633c9

8006808: mapfile use check in jdk/make/common/shared/Defs-solaris.gmk is throwing 'egrep: syntax error'
Summary: Use a valid egrep expression in the non-SPARC case
Reviewed-by: dholmes

! make/common/shared/Defs-solaris.gmk

Changeset: 5692ebe15321
Author:    erikj
Date:      2013-02-04 10:58 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/5692ebe15321

8007268: build-infra: configure reports Solaris needs gcc for deploy, but logs don't indicate it's used.
Reviewed-by: tbell, katleman

! make/common/shared/Sanity.gmk

Changeset: 3a2630528661
Author:    katleman
Date:      2013-02-05 18:54 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/3a2630528661

Merge


Changeset: 933742f4bb4c
Author:    katleman
Date:      2013-02-07 12:33 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/933742f4bb4c

Added tag jdk8-b76 for changeset 3a2630528661

! .hgtags

Changeset: e63e7ee18412
Author:    bae
Date:      2013-02-01 20:06 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/e63e7ee18412

8004801: The image of BufferedImage.TYPE_INT_ARGB is blank.
Reviewed-by: prr

! src/share/native/sun/awt/image/awt_parseImage.c
! src/solaris/native/sun/awt/awt_Mlib.c
! src/solaris/native/sun/awt/awt_Mlib.h
! src/windows/native/sun/windows/awt_Mlib.cpp
! src/windows/native/sun/windows/awt_Mlib.h
+ test/java/awt/image/LookupOp/IntImageReverseTest.java

Changeset: 1df2944db538
Author:    serb
Date:      2013-02-04 19:50 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/1df2944db538

8004821: Graphics2D.drawPolygon() fails with IllegalPathStateException
Reviewed-by: prr, flar

! src/share/classes/sun/java2d/pipe/PixelToShapeConverter.java
+ test/sun/java2d/pipe/Test8004821.java

Changeset: 8fc3e4015b09
Author:    jgodinez
Date:      2013-02-04 12:04 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/8fc3e4015b09

8005052: [parfait] #416 X11SurfaceData.c UNINITIALISED OR MISSING RETURN VALUE
8005054: [parfait] #417 X11SurfaceData.c UNINITIALISED OR MISSING RETURN VALUE
Reviewed-by: prr, vadim
Contributed-by: jia-hong.chen at oracle.com

! src/solaris/native/sun/java2d/x11/X11SurfaceData.c

Changeset: fd61fcc1a5a9
Author:    leonidr
Date:      2013-01-31 18:25 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/fd61fcc1a5a9

8007006: [macosx] Closing subwindow loses main window menus
Reviewed-by: anthony

! src/macosx/native/sun/awt/AWTWindow.m

Changeset: 452deb976c92
Author:    ptbrunet
Date:      2013-01-31 18:51 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/452deb976c92

7179482: Component.accessibleContext and JComponent.accessibleContext refactoring
Reviewed-by: art, anthony, alexsch

! src/share/classes/java/awt/Component.java
! src/share/classes/java/awt/Container.java
! src/share/classes/javax/swing/JComponent.java

Changeset: 0b56a169295f
Author:    pchelko
Date:      2013-02-04 13:54 +0000
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/0b56a169295f

8005405: [macosx] Drag and Drop: wrong animation when dropped outside any drop target.
Summary: Changed the calculation of the drag image offset
Reviewed-by: serb, kizune

! src/macosx/classes/sun/lwawt/macosx/CDragSourceContextPeer.java
! src/macosx/native/sun/awt/CDragSource.m

Changeset: 171443b1eb3b
Author:    kshefov
Date:      2013-02-04 16:01 +0000
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/171443b1eb3b

7077259: [TEST_BUG] [macosx] Test work correctly only when default L&F is Metal
Reviewed-by: serb, alexsch

! test/javax/swing/JSlider/4252173/bug4252173.java
! test/javax/swing/JSpinner/6532833/bug6532833.java
! test/javax/swing/plaf/metal/MetalSliderUI/Test6657026.java

Changeset: 0e929be3a9da
Author:    lana
Date:      2013-02-05 11:10 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/0e929be3a9da

Merge


Changeset: a343d280bd8c
Author:    jfranck
Date:      2013-01-29 10:32 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/a343d280bd8c

8004698: Implement Core Reflection for Type Annotations
Reviewed-by: darcy

! src/share/classes/java/lang/Class.java
! src/share/classes/java/lang/System.java
+ src/share/classes/java/lang/reflect/AnnotatedArrayType.java
+ src/share/classes/java/lang/reflect/AnnotatedParameterizedType.java
+ src/share/classes/java/lang/reflect/AnnotatedType.java
+ src/share/classes/java/lang/reflect/AnnotatedTypeVariable.java
+ src/share/classes/java/lang/reflect/AnnotatedWildcardType.java
! src/share/classes/java/lang/reflect/Constructor.java
! src/share/classes/java/lang/reflect/Executable.java
! src/share/classes/java/lang/reflect/Field.java
! src/share/classes/java/lang/reflect/Method.java
! src/share/classes/java/lang/reflect/ReflectAccess.java
! src/share/classes/java/lang/reflect/TypeVariable.java
! src/share/classes/sun/misc/JavaLangAccess.java
! src/share/classes/sun/reflect/LangReflectAccess.java
! src/share/classes/sun/reflect/ReflectionFactory.java
+ src/share/classes/sun/reflect/annotation/AnnotatedTypeFactory.java
! src/share/classes/sun/reflect/annotation/AnnotationParser.java
+ src/share/classes/sun/reflect/annotation/TypeAnnotation.java
+ src/share/classes/sun/reflect/annotation/TypeAnnotationParser.java
! src/share/classes/sun/reflect/generics/reflectiveObjects/TypeVariableImpl.java
! src/share/javavm/export/jvm.h
! src/share/native/java/lang/Class.c
+ test/java/lang/annotation/TypeAnnotationReflection.java
+ test/java/lang/annotation/TypeParamAnnotation.java

Changeset: 5097fe015763
Author:    jfranck
Date:      2013-01-31 10:10 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/5097fe015763

8005712: Simplify support for repeating annotations in j.l.r.AnnotatedElement
8004919: AnnotationSupport uses possibly half-constructed AnnotationType instances
Summary: Implements the simplified semantics for repeating annotations and removes the incorrect obtaining of an AnnotationType
Reviewed-by: darcy, abuckley

! src/share/classes/java/lang/Class.java
! src/share/classes/java/lang/System.java
! src/share/classes/java/lang/reflect/AnnotatedElement.java
! src/share/classes/java/lang/reflect/Executable.java
! src/share/classes/java/lang/reflect/Field.java
! src/share/classes/java/lang/reflect/Parameter.java
! src/share/classes/sun/misc/JavaLangAccess.java
! src/share/classes/sun/reflect/annotation/AnnotationSupport.java
! test/java/lang/annotation/repeatingAnnotations/RepeatedUnitTest.java
! test/java/lang/annotation/repeatingAnnotations/subpackage/Containee.java
! test/java/lang/annotation/repeatingAnnotations/subpackage/Container.java
! test/java/lang/annotation/repeatingAnnotations/subpackage/InheritedContainee.java
! test/java/lang/annotation/repeatingAnnotations/subpackage/InheritedContainer.java

Changeset: 3f766f58c48a
Author:    dbuck
Date:      2013-01-31 10:55 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/3f766f58c48a

7042126: (alt-rt) HashMap.clone implementation should be re-examined
Summary: Test case for cr7042126. Issue only found in OracleJDK, but test case is valid for OpenJDK as well
Reviewed-by: mduigou

+ test/java/util/HashMap/HashMapCloneLeak.java

Changeset: 857d99bef21d
Author:    sherman
Date:      2013-01-31 11:09 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/857d99bef21d

8005394: Base64.Decoder/Encoder.wrap(XStream) don't throw NPE for null args passed
Summary: to check null for dec/enc.wrap methods
Reviewed-by: alanb

! src/share/classes/java/util/Base64.java
! test/java/util/Base64/TestBase64.java

Changeset: 278397f752da
Author:    darcy
Date:      2013-01-31 12:13 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/278397f752da

8005832: Remove java.lang.annotation.{ContainedBy, ContainerFor} annotation types
Reviewed-by: mduigou

- src/share/classes/java/lang/annotation/ContainedBy.java
- src/share/classes/java/lang/annotation/ContainerFor.java
! src/share/classes/java/lang/annotation/InvalidContainerAnnotationError.java

Changeset: a5f38e811ab0
Author:    darcy
Date:      2013-01-31 12:23 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/a5f38e811ab0

8007115: Refactor regression tests for java.lang.reflect.Parameter
Reviewed-by: emc

! test/java/lang/reflect/Parameter/WithoutParameters.java

Changeset: e5ce312a5b10
Author:    sherman
Date:      2013-01-31 13:13 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/e5ce312a5b10

8007298: Base64.getMimeDecoder().decode() throws IAE for a single non-base64 character
8006526: Base64.Decoder.decode(String) spec contains a copy-paste mistake
Summary: to ignore single non-base64 char in mime decoding
Reviewed-by: alanb

! src/share/classes/java/util/Base64.java
! test/java/util/Base64/TestBase64.java

Changeset: cff8d7768d72
Author:    mduigou
Date:      2013-01-31 13:27 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/cff8d7768d72

8006709: Add minimal support of MacOSX platform for NetBeans Projects
Summary: Adds support for MacOSX platform and architecture detection. Other minor updates (-source/target 1.8)
Reviewed-by: ohair

+ make/netbeans/common/architectures/arch-x86_64.properties
+ make/netbeans/common/architectures/name-Macosx.properties
! make/netbeans/common/java-data-native.ent
! make/netbeans/common/java-data-no-native.ent
! make/netbeans/common/make.xml
! make/netbeans/common/shared.xml

Changeset: 771551bc9e02
Author:    lana
Date:      2013-01-31 10:22 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/771551bc9e02

Merge


Changeset: e822b4d50a5b
Author:    lana
Date:      2013-01-31 14:10 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/e822b4d50a5b

Merge

- src/share/classes/java/lang/annotation/ContainedBy.java
- src/share/classes/java/lang/annotation/ContainerFor.java

Changeset: a09a37cff333
Author:    mchung
Date:      2013-01-31 14:29 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/a09a37cff333

6355704: (fmt) %f formatting of BigDecimals is incorrect
Reviewed-by: darcy
Contributed-by: brian.burkhalter at oracle.com

! test/java/util/Formatter/Basic-X.java.template
! test/java/util/Formatter/BasicBigDecimal.java

Changeset: d2495b9984fa
Author:    weijun
Date:      2013-02-01 07:39 +0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/d2495b9984fa

8006564: Test sun/security/util/Oid/S11N.sh fails with timeout on Linux 32-bit
Reviewed-by: alanb

+ test/sun/security/util/Oid/S11N.java
- test/sun/security/util/Oid/S11N.sh
- test/sun/security/util/Oid/SerialTest.java

Changeset: 17b643956999
Author:    chegar
Date:      2013-02-01 06:51 +0000
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/17b643956999

8006395: Race in async socket close on Linux
Reviewed-by: alanb, dsamersoff

! src/solaris/native/java/net/linux_close.c
+ test/java/net/Socket/asyncClose/Race.java

Changeset: ea8f3ca83501
Author:    ksrini
Date:      2013-02-01 07:25 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/ea8f3ca83501

8006536: [launcher]  removes trailing slashes on arguments
Reviewed-by: ksrini, akhil
Contributed-by: jviswana at linux.vnet.ibm.com

! src/windows/bin/cmdtoargs.c
! test/tools/launcher/Arrrghs.java

Changeset: 5e47ee4d7196
Author:    alanb
Date:      2013-02-01 21:01 +0000
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/5e47ee4d7196

5035569: Formatter should document that %a conversion unsupported for BigDecimal args
Reviewed-by: darcy
Contributed-by: brian.burkhalter at oracle.com

! src/share/classes/java/util/Formatter.java

Changeset: cba578db5f39
Author:    darcy
Date:      2013-02-01 19:30 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/cba578db5f39

6964528: Double.toHexString(double d) String manipulation with + in an append of StringBuilder
Reviewed-by: shade

! src/share/classes/java/lang/Double.java

Changeset: c1aaa8451547
Author:    ksrini
Date:      2013-02-01 22:12 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/c1aaa8451547

8003549: (pack200) assertion errors when processing lambda class files with IMethods
Summary: add more check for opcode, sketch provided by jrose
Reviewed-by: jrose

! src/share/classes/com/sun/java/util/jar/pack/Attribute.java
! src/share/classes/com/sun/java/util/jar/pack/ClassReader.java
! src/share/classes/com/sun/java/util/jar/pack/ConstantPool.java
! src/share/classes/com/sun/java/util/jar/pack/Instruction.java
! src/share/classes/com/sun/java/util/jar/pack/PackageWriter.java
! src/share/classes/com/sun/java/util/jar/pack/PackerImpl.java
! src/share/classes/com/sun/java/util/jar/pack/PropMap.java
! src/share/classes/com/sun/java/util/jar/pack/Utils.java
! test/ProblemList.txt
+ test/tools/pack200/InstructionTests.java
! test/tools/pack200/pack200-verifier/src/xmlkit/ClassReader.java

Changeset: 6c88a12ea834
Author:    ksrini
Date:      2013-02-01 22:18 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/6c88a12ea834

8007428: [launcher] add tools/launcher/FXLauncherTest.java to ProblemList.txt
Reviewed-by: mchung

! test/ProblemList.txt

Changeset: ee83319029a5
Author:    chegar
Date:      2013-02-02 17:15 +0000
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/ee83319029a5

8007322: untangle ftp protocol from general networking URL tests
Reviewed-by: alanb

! test/java/net/URL/Constructor.java
! test/java/net/URL/HandlerLoop.java
! test/java/net/URL/Test.java
! test/java/net/URL/URIToURLTest.java
- test/java/net/URL/abnormal_http_urls
- test/java/net/URL/ftp_urls
- test/java/net/URL/jar_urls
- test/java/net/URL/normal_http_urls
- test/java/net/URL/runconstructor.sh
- test/java/net/URL/share_file_urls
- test/java/net/URL/win32_file_urls
! test/java/net/URLConnection/RequestProperties.java
! test/java/net/URLConnection/RequestPropertyValues.java
+ test/sun/net/ftp/EncDec.doc
+ test/sun/net/ftp/MarkResetTest.java
+ test/sun/net/ftp/MarkResetTest.sh
- test/sun/net/www/EncDec.doc
- test/sun/net/www/MarkResetTest.java
- test/sun/net/www/MarkResetTest.sh
! test/sun/net/www/http/HttpClient/ProxyTest.java

Changeset: 25831e7009c4
Author:    ksrini
Date:      2013-02-02 12:08 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/25831e7009c4

8007135: tools/launcher/VersionCheck.java failing with new tool jabswitch
Reviewed-by: ksrini, mduigou
Contributed-by: ragini.prasad at oracle.com

! test/tools/launcher/VersionCheck.java

Changeset: 308d1362b60a
Author:    dmeetry
Date:      2013-02-03 18:20 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/308d1362b60a

6471906: java.lang.NegativeArraySizeException in tenToThe
Reviewed-by: darcy
Contributed-by: brian.burkhalter at oracle.com

! src/share/classes/java/math/BigDecimal.java

Changeset: 962d6612cace
Author:    dsamersoff
Date:      2013-02-03 21:39 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/962d6612cace

8002048: Protocol to discovery of manageable Java processes on a network
Summary: Introduce a protocol to discover manageble Java instances across a network subnet, JDP
Reviewed-by: sla, dfuchs

! src/share/classes/sun/management/Agent.java
+ src/share/classes/sun/management/jdp/JdpBroadcaster.java
+ src/share/classes/sun/management/jdp/JdpController.java
+ src/share/classes/sun/management/jdp/JdpException.java
+ src/share/classes/sun/management/jdp/JdpGenericPacket.java
+ src/share/classes/sun/management/jdp/JdpJmxPacket.java
+ src/share/classes/sun/management/jdp/JdpPacket.java
+ src/share/classes/sun/management/jdp/JdpPacketReader.java
+ src/share/classes/sun/management/jdp/JdpPacketWriter.java
+ src/share/classes/sun/management/jdp/package-info.java
+ test/sun/management/jdp/JdpClient.java
+ test/sun/management/jdp/JdpDoSomething.java
+ test/sun/management/jdp/JdpTest.sh
+ test/sun/management/jdp/JdpUnitTest.java

Changeset: 5bf1c9e6be60
Author:    vinnie
Date:      2013-02-04 17:20 +0000
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/5bf1c9e6be60

8006994: Cleanup PKCS12 tests to ensure streams get closed
Reviewed-by: mullan

! test/java/security/KeyStore/PBETest.java
! test/sun/security/pkcs12/StorePasswordTest.java
! test/sun/security/pkcs12/StoreSecretKeyTest.java
! test/sun/security/pkcs12/StoreTrustedCertTest.java

Changeset: e202f43a8b8a
Author:    sherman
Date:      2013-02-04 11:58 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/e202f43a8b8a

8006295: Base64.Decoder.wrap(java.io.InputStream) returns InputStream which throws unspecified IOException on attempt to decode invalid Base64 byte stream
8006315: Base64.Decoder decoding methods are not consistent in treating non-padded data
8006530: Base64.getMimeDecoder().decode() throws exception for non-base64 character after adding =
Summary: updated the spec to describe the expected behave explicitly and the implementation to follow
Reviewed-by: alanb, chegar, lancea

! src/share/classes/java/util/Base64.java
! test/java/util/Base64/TestBase64.java

Changeset: e04467fa13af
Author:    darcy
Date:      2013-02-04 17:56 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/e04467fa13af

8007113: Upgrade AnnotatedElement.isAnnotionPresent to be a default method
Reviewed-by: chegar, jfranck

! src/share/classes/java/lang/Class.java
! src/share/classes/java/lang/Package.java
! src/share/classes/java/lang/reflect/AccessibleObject.java
! src/share/classes/java/lang/reflect/AnnotatedElement.java
! src/share/classes/java/lang/reflect/Parameter.java
! src/share/classes/sun/reflect/annotation/AnnotatedTypeFactory.java
! src/share/classes/sun/reflect/generics/reflectiveObjects/TypeVariableImpl.java

Changeset: fd37f0846653
Author:    lana
Date:      2013-02-04 22:37 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/fd37f0846653

Merge


Changeset: 9ffcd758e2be
Author:    jbachorik
Date:      2013-02-05 12:28 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/9ffcd758e2be

7170447: Intermittent DeadListenerTest.java failure
Summary: Due to asynchronous nature of processing server notifications it may happen that an "unregister" notification ha$
Reviewed-by: sjiang

! test/javax/management/remote/mandatory/notif/DeadListenerTest.java

Changeset: 3119f0ebb58d
Author:    jbachorik
Date:      2013-02-05 12:36 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/3119f0ebb58d

8005791: Remove java.beans.* imports from com.sun.jmx.mbeanserver.Introspector
Reviewed-by: rbackman

! src/share/classes/com/sun/jmx/mbeanserver/Introspector.java

Changeset: e526277b51be
Author:    vinnie
Date:      2013-02-05 14:25 +0000
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/e526277b51be

8007483: attributes are ignored when loading keys from a PKCS12 keystore
Reviewed-by: mullan

! src/share/classes/sun/security/pkcs12/PKCS12KeyStore.java
! test/sun/security/pkcs12/StorePasswordTest.java

Changeset: f26b539bf1d5
Author:    lana
Date:      2013-02-05 11:11 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/f26b539bf1d5

Merge

- src/share/classes/java/lang/annotation/ContainedBy.java
- src/share/classes/java/lang/annotation/ContainerFor.java
- test/java/net/URL/abnormal_http_urls
- test/java/net/URL/ftp_urls
- test/java/net/URL/jar_urls
- test/java/net/URL/normal_http_urls
- test/java/net/URL/runconstructor.sh
- test/java/net/URL/share_file_urls
- test/java/net/URL/win32_file_urls
- test/sun/net/www/EncDec.doc
- test/sun/net/www/MarkResetTest.java
- test/sun/net/www/MarkResetTest.sh
- test/sun/security/util/Oid/S11N.sh
- test/sun/security/util/Oid/SerialTest.java

Changeset: b2fc8e31cecc
Author:    lana
Date:      2013-02-11 16:14 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/b2fc8e31cecc

Merge

- src/share/classes/java/lang/annotation/ContainedBy.java
- src/share/classes/java/lang/annotation/ContainerFor.java
- test/java/net/URL/abnormal_http_urls
- test/java/net/URL/ftp_urls
- test/java/net/URL/jar_urls
- test/java/net/URL/normal_http_urls
- test/java/net/URL/runconstructor.sh
- test/java/net/URL/share_file_urls
- test/java/net/URL/win32_file_urls
- test/sun/net/www/EncDec.doc
- test/sun/net/www/MarkResetTest.java
- test/sun/net/www/MarkResetTest.sh
- test/sun/security/util/Oid/S11N.sh
- test/sun/security/util/Oid/SerialTest.java

Changeset: c1304eb051f6
Author:    katleman
Date:      2013-02-14 11:44 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/c1304eb051f6

Added tag jdk8-b77 for changeset b2fc8e31cecc

! .hgtags

Changeset: 37719b174e87
Author:    jgodinez
Date:      2013-02-06 14:45 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/37719b174e87

8005194: [parfait] #353 sun/awt/image/jpeg/imageioJPEG.c Memory leak of pointer 'scale' allocated with calloc()
Reviewed-by: prr, vadim
Contributed-by: jia-hong.chen at oracle.com

! src/share/native/sun/awt/image/jpeg/imageioJPEG.c

Changeset: ad49012d10a1
Author:    jgodinez
Date:      2013-02-08 11:25 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/ad49012d10a1

8005129: [parfait] #1122 - #1130 native/sun/awt/medialib/mlib_Image*.c Memory leak of pointer 'k' allocated with mlib_malloc
Reviewed-by: prr, vadim
Contributed-by: jia-hong.chen at oracle.com

! src/share/native/sun/awt/medialib/mlib_ImageConv.h
! src/share/native/sun/awt/medialib/mlib_ImageConvMxN_ext.c
! src/share/native/sun/awt/medialib/mlib_ImageConv_16ext.c
! src/share/native/sun/awt/medialib/mlib_ImageConv_16nw.c
! src/share/native/sun/awt/medialib/mlib_ImageConv_32nw.c
! src/share/native/sun/awt/medialib/mlib_ImageConv_8ext.c
! src/share/native/sun/awt/medialib/mlib_ImageConv_8nw.c
! src/share/native/sun/awt/medialib/mlib_ImageConv_u16ext.c
! src/share/native/sun/awt/medialib/mlib_ImageConv_u16nw.c
! src/share/native/sun/awt/medialib/mlib_ImageCreate.c
! src/share/native/sun/awt/medialib/mlib_c_ImageConv.h

Changeset: 1ea9feb6d8c5
Author:    jgodinez
Date:      2013-02-08 11:36 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/1ea9feb6d8c5

8005261: [parfait] #415 sun/java2d/opengl/GLXSurfaceData.c Memory leak of pointer 'glxsdo' allocated with malloc
Reviewed-by: prr, vadim
Contributed-by: jia-hong.chen at oracle.com

! src/solaris/native/sun/java2d/opengl/GLXSurfaceData.c

Changeset: 5f0217537435
Author:    prr
Date:      2013-02-12 09:58 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/5f0217537435

8007748: MacOSX build error : cast of type 'SEL' to 'uintptr_t' (aka 'unsigned long') is deprecated; use sel_getName instead
Reviewed-by: anthony

! src/macosx/native/jobjc/src/core/native/SEL.m

Changeset: 1b47e2dfa89a
Author:    lana
Date:      2013-02-13 13:01 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/1b47e2dfa89a

Merge

- src/share/classes/java/lang/annotation/ContainedBy.java
- src/share/classes/java/lang/annotation/ContainerFor.java
- test/java/net/URL/abnormal_http_urls
- test/java/net/URL/ftp_urls
- test/java/net/URL/jar_urls
- test/java/net/URL/normal_http_urls
- test/java/net/URL/runconstructor.sh
- test/java/net/URL/share_file_urls
- test/java/net/URL/win32_file_urls
- test/sun/net/www/EncDec.doc
- test/sun/net/www/MarkResetTest.java
- test/sun/net/www/MarkResetTest.sh
- test/sun/security/util/Oid/S11N.sh
- test/sun/security/util/Oid/SerialTest.java

Changeset: 6df3acd02449
Author:    prr
Date:      2013-02-13 15:06 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/6df3acd02449

8008017: The fix for 8005129 does not build on Windows
Reviewed-by: prr, jgodinez
Contributed-by: jia-hong.chen at oracle.com

! src/share/native/sun/awt/medialib/mlib_ImageConv_16ext.c
! src/share/native/sun/awt/medialib/mlib_ImageConv_16nw.c
! src/share/native/sun/awt/medialib/mlib_ImageConv_8ext.c
! src/share/native/sun/awt/medialib/mlib_ImageConv_8nw.c
! src/share/native/sun/awt/medialib/mlib_ImageConv_u16ext.c
! src/share/native/sun/awt/medialib/mlib_ImageConv_u16nw.c

Changeset: ac89a5d71466
Author:    alexsch
Date:      2013-02-06 18:25 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/ac89a5d71466

8000326: Focus unable to traverse in the menubar
Reviewed-by: alexsch, malenkov

! src/share/classes/javax/swing/JMenuBar.java

Changeset: 6e17465f4a1a
Author:    mcherkas
Date:      2013-02-08 22:08 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/6e17465f4a1a

8005932: Java 7 on mac os x only provides text clipboard formats
Reviewed-by: alexp, denis

! src/macosx/lib/flavormap.properties
+ test/java/awt/DataFlavor/MissedHtmlAndRtfBug/AbsoluteComponentCenterCalculator.java
+ test/java/awt/DataFlavor/MissedHtmlAndRtfBug/DataFlavorSearcher.java
+ test/java/awt/DataFlavor/MissedHtmlAndRtfBug/InterprocessMessages.java
+ test/java/awt/DataFlavor/MissedHtmlAndRtfBug/MissedHtmlAndRtfBug.html
+ test/java/awt/DataFlavor/MissedHtmlAndRtfBug/MissedHtmlAndRtfBug.java
+ test/java/awt/DataFlavor/MissedHtmlAndRtfBug/MyTransferable.java
+ test/java/awt/DataFlavor/MissedHtmlAndRtfBug/NextFramePositionCalculator.java
+ test/java/awt/DataFlavor/MissedHtmlAndRtfBug/SourcePanel.java
+ test/java/awt/DataFlavor/MissedHtmlAndRtfBug/TargetPanel.java

Changeset: 5406c4e381e2
Author:    kshefov
Date:      2013-02-13 18:01 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/5406c4e381e2

7161759: TEST_BUG: java/awt/Frame/WindowDragTest/WindowDragTest.java fails to compile, should be modified
Summary: Added @build Util jtreg tag
Reviewed-by: serb, alexsch
Contributed-by: Vera Akulova <vera.akulova at oracle.com>

! test/java/awt/Frame/WindowDragTest/WindowDragTest.java

Changeset: dd6cf41a6953
Author:    kshefov
Date:      2013-02-13 19:06 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/dd6cf41a6953

7132383: [macosx] bug6596966.java should be adapted for Mac
Reviewed-by: serb, alexsch
Contributed-by: Vera Akulova <vera.akulova at oracle.com>

! test/javax/swing/JLabel/6596966/bug6596966.java
! test/javax/swing/regtesthelpers/Util.java

Changeset: caec64340f42
Author:    vkarnauk
Date:      2013-02-13 19:23 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/caec64340f42

4199622: RFE: JComboBox shouldn't sending ActionEvents for keyboard navigation
Reviewed-by: alexp, alexsch

! src/share/classes/javax/swing/plaf/basic/BasicComboBoxUI.java
! src/share/classes/javax/swing/plaf/basic/BasicLookAndFeel.java
+ test/javax/swing/JComboBox/4199622/bug4199622.java

Changeset: 4d9691e95e05
Author:    pchelko
Date:      2013-02-13 15:27 +0000
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/4d9691e95e05

7079260: InputContext leaks memory
Summary: Replaced strong refs with weak refs
Reviewed-by: art, serb

! src/share/classes/sun/awt/im/CompositionAreaHandler.java
! src/solaris/classes/sun/awt/X11InputMethod.java
+ test/java/awt/im/memoryleak/InputContextMemoryLeakTest.java
! test/java/awt/regtesthelpers/Util.java

Changeset: c552cde0e3f9
Author:    pchelko
Date:      2013-02-13 15:32 +0000
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/c552cde0e3f9

8005629: javac warnings compiling java.awt.EventDispatchThread and sun.awt.X11.XIconWindow
Summary: Removed macosx specific workaround from shared code and made macosx use public API
Reviewed-by: art, serb

! src/macosx/classes/sun/lwawt/macosx/CPrinterJob.java
- src/macosx/classes/sun/lwawt/macosx/EventDispatchAccess.java
! src/macosx/native/sun/awt/CPrinterJob.m
! src/share/classes/java/awt/EventDispatchThread.java
! src/solaris/classes/sun/awt/X11/XIconWindow.java

Changeset: c95dc15ac183
Author:    lana
Date:      2013-02-13 12:38 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/c95dc15ac183

Merge

- src/share/classes/java/lang/annotation/ContainedBy.java
- src/share/classes/java/lang/annotation/ContainerFor.java
- test/java/net/URL/abnormal_http_urls
- test/java/net/URL/ftp_urls
- test/java/net/URL/jar_urls
- test/java/net/URL/normal_http_urls
- test/java/net/URL/runconstructor.sh
- test/java/net/URL/share_file_urls
- test/java/net/URL/win32_file_urls
- test/sun/net/www/EncDec.doc
- test/sun/net/www/MarkResetTest.java
- test/sun/net/www/MarkResetTest.sh
- test/sun/security/util/Oid/S11N.sh
- test/sun/security/util/Oid/SerialTest.java

Changeset: c9efb349b391
Author:    lana
Date:      2013-02-13 17:55 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/c9efb349b391

Merge

- src/macosx/classes/sun/lwawt/macosx/EventDispatchAccess.java

Changeset: 0e7d5dd84fdf
Author:    dsamersoff
Date:      2013-02-06 16:53 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/0e7d5dd84fdf

8007277: JDK-8002048 testcase fails to compile
Summary: sun.* classes is not included to ct.sym file and symbol file have to be ignored
Reviewed-by: alanb

! test/sun/management/jdp/JdpTest.sh

Changeset: 1574fa3df1c0
Author:    lancea
Date:      2013-02-06 14:15 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/1574fa3df1c0

8006505: additional changes for JSR 310 support
Reviewed-by: naoto, ulfzibis

! src/share/classes/java/sql/JDBCType.java
! src/share/classes/java/sql/SQLInput.java
! src/share/classes/java/sql/SQLOutput.java
! src/share/classes/java/sql/Types.java

Changeset: 2f1505c49e79
Author:    martin
Date:      2013-02-06 17:59 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/2f1505c49e79

8006995: java launcher fails to open executable JAR > 2GB
Summary: Use O_LARGEFILE consistently when opening jar files
Reviewed-by: alanb, sherman

! src/share/bin/parse_manifest.c

Changeset: 2de8c6c2d652
Author:    ykantser
Date:      2013-02-07 11:22 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/2de8c6c2d652

8007142: Add utility classes for writing better multiprocess tests in jtreg
Reviewed-by: alanb, rbackman

+ test/lib/testlibrary/OutputAnalyzerTest.java
+ test/lib/testlibrary/jdk/testlibrary/JcmdBase.java
+ test/lib/testlibrary/jdk/testlibrary/JdkFinder.java
+ test/lib/testlibrary/jdk/testlibrary/OutputAnalyzer.java
+ test/lib/testlibrary/jdk/testlibrary/OutputBuffer.java
+ test/lib/testlibrary/jdk/testlibrary/ProcessTools.java
+ test/lib/testlibrary/jdk/testlibrary/StreamPumper.java

Changeset: 79d7595abe95
Author:    naoto
Date:      2013-02-08 09:35 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/79d7595abe95

8007038: ArrayIndexOutOfBoundsException on calling localizedDateTime().print() with JapaneseChrono
Reviewed-by: okutsu

! src/share/classes/sun/util/locale/provider/CalendarNameProviderImpl.java
+ test/java/util/Calendar/Bug8007038.java

Changeset: 522fb3867a3a
Author:    darcy
Date:      2013-02-08 16:00 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/522fb3867a3a

8005623: Retrofit FunctionalInterface annotations to core platform interfaces
Reviewed-by: mduigou, chegar, alanb

! src/share/classes/java/io/Closeable.java
! src/share/classes/java/io/FileFilter.java
! src/share/classes/java/io/FilenameFilter.java
! src/share/classes/java/io/Flushable.java
! src/share/classes/java/lang/AutoCloseable.java
! src/share/classes/java/lang/Comparable.java
! src/share/classes/java/lang/Iterable.java
! src/share/classes/java/lang/Readable.java
! src/share/classes/java/lang/Runnable.java
! src/share/classes/java/lang/Thread.java
! src/share/classes/java/nio/file/DirectoryStream.java
! src/share/classes/java/nio/file/PathMatcher.java
! src/share/classes/java/util/Comparator.java
! src/share/classes/java/util/function/BinaryOperator.java
! src/share/classes/java/util/function/Block.java
! src/share/classes/java/util/function/DoubleBinaryOperator.java
! src/share/classes/java/util/function/DoubleBlock.java
! src/share/classes/java/util/function/DoubleFunction.java
! src/share/classes/java/util/function/DoubleSupplier.java
! src/share/classes/java/util/function/DoubleUnaryOperator.java
! src/share/classes/java/util/function/Function.java
! src/share/classes/java/util/function/IntBinaryOperator.java
! src/share/classes/java/util/function/IntBlock.java
! src/share/classes/java/util/function/IntFunction.java
! src/share/classes/java/util/function/IntSupplier.java
! src/share/classes/java/util/function/IntUnaryOperator.java
! src/share/classes/java/util/function/LongBinaryOperator.java
! src/share/classes/java/util/function/LongBlock.java
! src/share/classes/java/util/function/LongFunction.java
! src/share/classes/java/util/function/LongSupplier.java
! src/share/classes/java/util/function/LongUnaryOperator.java
! src/share/classes/java/util/function/Predicate.java
! src/share/classes/java/util/function/Supplier.java
! src/share/classes/java/util/function/UnaryOperator.java
! src/share/classes/java/util/logging/Filter.java
! src/share/classes/java/util/prefs/PreferenceChangeListener.java

Changeset: 36d25dc2b8f0
Author:    dl
Date:      2013-02-09 08:35 +0000
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/36d25dc2b8f0

8005697: Add StampedLock
Reviewed-by: chegar, alanb, dice, martin

! make/java/java/FILES_java.gmk
! src/share/classes/java/util/concurrent/locks/LockSupport.java
+ src/share/classes/java/util/concurrent/locks/StampedLock.java
+ test/java/util/concurrent/locks/StampedLock/Basic.java

Changeset: d14cd2272b2d
Author:    weijun
Date:      2013-02-09 16:43 +0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/d14cd2272b2d

8001104: Unbound SASL service: the GSSAPI/krb5 mech
Reviewed-by: valeriep

! src/share/classes/com/sun/security/auth/module/Krb5LoginModule.java
! src/share/classes/javax/security/auth/kerberos/JavaxSecurityAuthKerberosAccessImpl.java
! src/share/classes/javax/security/auth/kerberos/KeyTab.java
! src/share/classes/sun/security/jgss/LoginConfigImpl.java
! src/share/classes/sun/security/jgss/krb5/Krb5Util.java
! src/share/classes/sun/security/jgss/krb5/ServiceCreds.java
! src/share/classes/sun/security/jgss/krb5/SubjectComber.java
! src/share/classes/sun/security/krb5/JavaxSecurityAuthKerberosAccess.java
! src/share/classes/sun/security/krb5/internal/ktab/KeyTab.java
! src/share/classes/sun/security/provider/ConfigSpiFile.java
! test/sun/security/krb5/ServiceCredsCombination.java
! test/sun/security/krb5/auto/AcceptPermissions.java
+ test/sun/security/krb5/auto/GSSUnbound.java
! test/sun/security/krb5/auto/OneKDC.java
+ test/sun/security/krb5/auto/SaslUnbound.java
+ test/sun/security/krb5/auto/UnboundService.java

Changeset: 57cb988c811e
Author:    weijun
Date:      2013-02-09 16:43 +0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/57cb988c811e

8007761: NTLM coding errors
Reviewed-by: chegar

! src/share/classes/com/sun/security/ntlm/Client.java
! src/share/classes/com/sun/security/ntlm/NTLM.java

Changeset: 58c95d0b6b1a
Author:    ksrini
Date:      2013-02-10 08:07 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/58c95d0b6b1a

8007519: [unpack200] produces bad class files when producing BootstrapMethods attribute
Reviewed-by: alanb

! test/ProblemList.txt

Changeset: 520a3433883d
Author:    ksrini
Date:      2013-02-10 08:49 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/520a3433883d

8007902: [unpack200] incorrect BootstrapMethods attribute
Reviewed-by: jjh

! src/share/native/com/sun/java/util/jar/pack/unpack.cpp
! test/tools/pack200/Pack200Test.java
! test/tools/pack200/pack200-verifier/data/golden.jar

Changeset: 1df991184045
Author:    dsamersoff
Date:      2013-02-11 18:44 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/1df991184045

8007536: Incorrect copyright header in JDP files
Summary: Copyright header in JDP files missed the "classpath exception" rule.
Reviewed-by: mikael

! src/share/classes/sun/management/jdp/JdpBroadcaster.java
! src/share/classes/sun/management/jdp/JdpController.java
! src/share/classes/sun/management/jdp/JdpException.java
! src/share/classes/sun/management/jdp/JdpGenericPacket.java
! src/share/classes/sun/management/jdp/JdpJmxPacket.java
! src/share/classes/sun/management/jdp/JdpPacket.java
! src/share/classes/sun/management/jdp/JdpPacketReader.java
! src/share/classes/sun/management/jdp/JdpPacketWriter.java
! src/share/classes/sun/management/jdp/package-info.java

Changeset: abd530253f01
Author:    dcubed
Date:      2013-02-11 10:07 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/abd530253f01

8007420: add test for 6805864 to com/sun/jdi, add test for 7182152 to java/lang/instrument
Reviewed-by: coleenp, sspitsyn

+ test/com/sun/jdi/RedefineAbstractClass.sh
+ test/java/lang/instrument/RedefineSubclassWithTwoInterfaces.sh
+ test/java/lang/instrument/RedefineSubclassWithTwoInterfacesAgent.java
+ test/java/lang/instrument/RedefineSubclassWithTwoInterfacesApp.java
+ test/java/lang/instrument/RedefineSubclassWithTwoInterfacesImpl.java
+ test/java/lang/instrument/RedefineSubclassWithTwoInterfacesImpl_1.java
+ test/java/lang/instrument/RedefineSubclassWithTwoInterfacesIntf1.java
+ test/java/lang/instrument/RedefineSubclassWithTwoInterfacesIntf2.java
+ test/java/lang/instrument/RedefineSubclassWithTwoInterfacesRemote.java
+ test/java/lang/instrument/RedefineSubclassWithTwoInterfacesTarget.java
+ test/java/lang/instrument/RedefineSubclassWithTwoInterfacesTarget_1.java

Changeset: f21a4b761424
Author:    alanb
Date:      2013-02-11 20:16 +0000
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/f21a4b761424

8007405: Update java.lang.reflect API to replace SYNTHESIZED with MANDATED
Reviewed-by: darcy

! src/share/classes/java/lang/reflect/Executable.java
! src/share/classes/java/lang/reflect/Modifier.java
! src/share/classes/java/lang/reflect/Parameter.java

Changeset: 465cce29a9ed
Author:    mduigou
Date:      2013-02-06 11:28 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/465cce29a9ed

8006594: Add jdk_core target to jdk/test/Makefile
Reviewed-by: alanb

! make/jprt.properties
! test/Makefile
! test/ProblemList.txt

Changeset: f7fb173ac833
Author:    dsamersoff
Date:      2013-02-12 16:02 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/f7fb173ac833

8007786: JDK-8002048 testcase doesn't work on Solaris
Summary: test built in into Solaris shell doesn't have -e operator
Reviewed-by: sla, sspitsyn

! test/sun/management/jdp/JdpTest.sh

Changeset: 7dcb74c3ffba
Author:    sherman
Date:      2013-02-12 09:25 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/7dcb74c3ffba

8007392: JSR 310: DateTime API Updates
8007520: Update date/time classes in j.util and j.sql packages
8007572: Replace existing jdk timezone data at <java.home>/lib/zi with JSR310's tzdb
Summary: Integration of JSR310 Date/Time API for M7
Reviewed-by: darcy, alanb, naoto
Contributed-by: scolebourne at joda.org, roger.riggs at oracle.com, masayoshi.okutsu at oracle.com, patrick.zhang at oracle.com

! make/docs/CORE_PKGS.gmk
! make/java/java/FILES_java.gmk
! make/sun/Makefile
! make/sun/javazic/Makefile
+ make/sun/javazic/tzdata/gmt
+ make/sun/javazic/tzdata/jdk11_backward
! make/sun/tzdb/Makefile
! make/tools/Makefile
! make/tools/src/build/tools/javazic/Zoneinfo.java
! make/tools/src/build/tools/tzdb/TzdbZoneRulesCompiler.java
! makefiles/GendataTZDB.gmk
! makefiles/GendataTimeZone.gmk
! makefiles/GenerateData.gmk
! makefiles/Tools.gmk
! src/share/classes/java/sql/Date.java
! src/share/classes/java/sql/Time.java
! src/share/classes/java/sql/Timestamp.java
! src/share/classes/java/time/Clock.java
! src/share/classes/java/time/DayOfWeek.java
! src/share/classes/java/time/Duration.java
! src/share/classes/java/time/Instant.java
! src/share/classes/java/time/LocalDate.java
! src/share/classes/java/time/LocalDateTime.java
! src/share/classes/java/time/LocalTime.java
! src/share/classes/java/time/Month.java
+ src/share/classes/java/time/MonthDay.java
+ src/share/classes/java/time/OffsetDateTime.java
+ src/share/classes/java/time/OffsetTime.java
! src/share/classes/java/time/Period.java
- src/share/classes/java/time/PeriodParser.java
! src/share/classes/java/time/Ser.java
+ src/share/classes/java/time/Year.java
+ src/share/classes/java/time/YearMonth.java
! src/share/classes/java/time/ZoneId.java
! src/share/classes/java/time/ZoneOffset.java
! src/share/classes/java/time/ZoneRegion.java
! src/share/classes/java/time/ZonedDateTime.java
- src/share/classes/java/time/calendar/ChronoDateImpl.java
- src/share/classes/java/time/calendar/HijrahChrono.java
- src/share/classes/java/time/calendar/HijrahDate.java
- src/share/classes/java/time/calendar/HijrahDeviationReader.java
- src/share/classes/java/time/calendar/HijrahEra.java
- src/share/classes/java/time/calendar/JapaneseChrono.java
- src/share/classes/java/time/calendar/JapaneseDate.java
- src/share/classes/java/time/calendar/JapaneseEra.java
- src/share/classes/java/time/calendar/MinguoChrono.java
- src/share/classes/java/time/calendar/MinguoDate.java
- src/share/classes/java/time/calendar/MinguoEra.java
- src/share/classes/java/time/calendar/Ser.java
- src/share/classes/java/time/calendar/ThaiBuddhistChrono.java
- src/share/classes/java/time/calendar/ThaiBuddhistDate.java
- src/share/classes/java/time/calendar/ThaiBuddhistEra.java
- src/share/classes/java/time/calendar/package-info.java
+ src/share/classes/java/time/chrono/ChronoDateImpl.java
+ src/share/classes/java/time/chrono/ChronoLocalDate.java
+ src/share/classes/java/time/chrono/ChronoLocalDateTime.java
+ src/share/classes/java/time/chrono/ChronoLocalDateTimeImpl.java
+ src/share/classes/java/time/chrono/ChronoZonedDateTime.java
+ src/share/classes/java/time/chrono/ChronoZonedDateTimeImpl.java
+ src/share/classes/java/time/chrono/Chronology.java
+ src/share/classes/java/time/chrono/Era.java
+ src/share/classes/java/time/chrono/HijrahChronology.java
+ src/share/classes/java/time/chrono/HijrahDate.java
+ src/share/classes/java/time/chrono/HijrahDeviationReader.java
+ src/share/classes/java/time/chrono/HijrahEra.java
+ src/share/classes/java/time/chrono/IsoChronology.java
+ src/share/classes/java/time/chrono/IsoEra.java
+ src/share/classes/java/time/chrono/JapaneseChronology.java
+ src/share/classes/java/time/chrono/JapaneseDate.java
+ src/share/classes/java/time/chrono/JapaneseEra.java
+ src/share/classes/java/time/chrono/MinguoChronology.java
+ src/share/classes/java/time/chrono/MinguoDate.java
+ src/share/classes/java/time/chrono/MinguoEra.java
+ src/share/classes/java/time/chrono/Ser.java
+ src/share/classes/java/time/chrono/ThaiBuddhistChronology.java
+ src/share/classes/java/time/chrono/ThaiBuddhistDate.java
+ src/share/classes/java/time/chrono/ThaiBuddhistEra.java
+ src/share/classes/java/time/chrono/package-info.java
! src/share/classes/java/time/format/DateTimeBuilder.java
! src/share/classes/java/time/format/DateTimeFormatStyleProvider.java
! src/share/classes/java/time/format/DateTimeFormatter.java
! src/share/classes/java/time/format/DateTimeFormatterBuilder.java
- src/share/classes/java/time/format/DateTimeFormatters.java
! src/share/classes/java/time/format/DateTimeParseContext.java
! src/share/classes/java/time/format/DateTimePrintContext.java
- src/share/classes/java/time/format/DateTimePrintException.java
! src/share/classes/java/time/format/DateTimeTextProvider.java
! src/share/classes/java/time/format/FormatStyle.java
+ src/share/classes/java/time/format/ZoneName.java
! src/share/classes/java/time/format/package-info.java
! src/share/classes/java/time/overview.html
! src/share/classes/java/time/package-info.java
- src/share/classes/java/time/temporal/Chrono.java
! src/share/classes/java/time/temporal/ChronoField.java
- src/share/classes/java/time/temporal/ChronoLocalDate.java
- src/share/classes/java/time/temporal/ChronoLocalDateTime.java
- src/share/classes/java/time/temporal/ChronoLocalDateTimeImpl.java
! src/share/classes/java/time/temporal/ChronoUnit.java
- src/share/classes/java/time/temporal/ChronoZonedDateTime.java
- src/share/classes/java/time/temporal/ChronoZonedDateTimeImpl.java
- src/share/classes/java/time/temporal/Era.java
- src/share/classes/java/time/temporal/ISOChrono.java
- src/share/classes/java/time/temporal/ISOEra.java
- src/share/classes/java/time/temporal/ISOFields.java
+ src/share/classes/java/time/temporal/IsoFields.java
! src/share/classes/java/time/temporal/JulianFields.java
- src/share/classes/java/time/temporal/MonthDay.java
- src/share/classes/java/time/temporal/OffsetDate.java
- src/share/classes/java/time/temporal/OffsetDateTime.java
- src/share/classes/java/time/temporal/OffsetTime.java
! src/share/classes/java/time/temporal/Queries.java
- src/share/classes/java/time/temporal/Ser.java
- src/share/classes/java/time/temporal/SimplePeriod.java
! src/share/classes/java/time/temporal/Temporal.java
! src/share/classes/java/time/temporal/TemporalAccessor.java
- src/share/classes/java/time/temporal/TemporalAdder.java
! src/share/classes/java/time/temporal/TemporalAdjuster.java
+ src/share/classes/java/time/temporal/TemporalAmount.java
! src/share/classes/java/time/temporal/TemporalField.java
! src/share/classes/java/time/temporal/TemporalQuery.java
- src/share/classes/java/time/temporal/TemporalSubtractor.java
! src/share/classes/java/time/temporal/TemporalUnit.java
! src/share/classes/java/time/temporal/WeekFields.java
- src/share/classes/java/time/temporal/Year.java
- src/share/classes/java/time/temporal/YearMonth.java
! src/share/classes/java/time/temporal/package-info.java
! src/share/classes/java/time/zone/TzdbZoneRulesProvider.java
! src/share/classes/java/time/zone/ZoneOffsetTransitionRule.java
! src/share/classes/java/time/zone/ZoneRules.java
! src/share/classes/java/time/zone/ZoneRulesProvider.java
! src/share/classes/java/util/Calendar.java
! src/share/classes/java/util/Date.java
! src/share/classes/java/util/Formatter.java
! src/share/classes/java/util/GregorianCalendar.java
! src/share/classes/java/util/TimeZone.java
! src/share/classes/sun/text/resources/FormatData.java
! src/share/classes/sun/text/resources/ar/FormatData_ar.java
! src/share/classes/sun/text/resources/el/FormatData_el.java
! src/share/classes/sun/text/resources/hr/FormatData_hr.java
! src/share/classes/sun/text/resources/ja/FormatData_ja.java
! src/share/classes/sun/text/resources/ko/FormatData_ko.java
! src/share/classes/sun/text/resources/sr/FormatData_sr.java
! src/share/classes/sun/text/resources/sv/FormatData_sv.java
! src/share/classes/sun/text/resources/zh/FormatData_zh.java
! src/share/classes/sun/text/resources/zh/FormatData_zh_TW.java
! src/share/classes/sun/util/calendar/CalendarSystem.java
! src/share/classes/sun/util/calendar/LocalGregorianCalendar.java
- src/share/classes/sun/util/calendar/TzIDOldMapping.java
! src/share/classes/sun/util/calendar/ZoneInfo.java
! src/share/classes/sun/util/calendar/ZoneInfoFile.java
! src/share/classes/sun/util/locale/provider/CalendarDataUtility.java
! src/share/classes/sun/util/locale/provider/CalendarNameProviderImpl.java
! src/share/classes/sun/util/locale/provider/LocaleResources.java
+ test/java/sql/JavatimeTest.java
+ test/java/time/META-INF/services/java.time.chrono.Chronology
- test/java/time/META-INF/services/java.time.temporal.Chrono
! test/java/time/tck/java/time/AbstractTCKTest.java
+ test/java/time/tck/java/time/MockSimplePeriod.java
! test/java/time/tck/java/time/TCKClock.java
! test/java/time/tck/java/time/TCKClock_Fixed.java
! test/java/time/tck/java/time/TCKClock_Offset.java
! test/java/time/tck/java/time/TCKClock_System.java
! test/java/time/tck/java/time/TCKClock_Tick.java
! test/java/time/tck/java/time/TCKDayOfWeek.java
! test/java/time/tck/java/time/TCKDuration.java
! test/java/time/tck/java/time/TCKInstant.java
! test/java/time/tck/java/time/TCKLocalDate.java
! test/java/time/tck/java/time/TCKLocalDateTime.java
! test/java/time/tck/java/time/TCKLocalTime.java
! test/java/time/tck/java/time/TCKMonth.java
+ test/java/time/tck/java/time/TCKMonthDay.java
+ test/java/time/tck/java/time/TCKOffsetDateTime.java
+ test/java/time/tck/java/time/TCKOffsetTime.java
+ test/java/time/tck/java/time/TCKPeriod.java
+ test/java/time/tck/java/time/TCKYear.java
+ test/java/time/tck/java/time/TCKYearMonth.java
! test/java/time/tck/java/time/TCKZoneId.java
! test/java/time/tck/java/time/TCKZoneOffset.java
! test/java/time/tck/java/time/TCKZonedDateTime.java
+ test/java/time/tck/java/time/TestChronology.java
+ test/java/time/tck/java/time/TestIsoChronology.java
- test/java/time/tck/java/time/calendar/CopticChrono.java
- test/java/time/tck/java/time/calendar/CopticDate.java
- test/java/time/tck/java/time/calendar/CopticEra.java
- test/java/time/tck/java/time/calendar/TestChronoLocalDate.java
- test/java/time/tck/java/time/calendar/TestChronoLocalDateTime.java
- test/java/time/tck/java/time/calendar/TestHijrahChrono.java
- test/java/time/tck/java/time/calendar/TestJapaneseChrono.java
- test/java/time/tck/java/time/calendar/TestMinguoChrono.java
- test/java/time/tck/java/time/calendar/TestServiceLoader.java
- test/java/time/tck/java/time/calendar/TestThaiBuddhistChrono.java
+ test/java/time/tck/java/time/chrono/CopticChronology.java
+ test/java/time/tck/java/time/chrono/CopticDate.java
+ test/java/time/tck/java/time/chrono/CopticEra.java
+ test/java/time/tck/java/time/chrono/TCKChronology.java
+ test/java/time/tck/java/time/chrono/TCKTestServiceLoader.java
+ test/java/time/tck/java/time/chrono/TestChronoLocalDate.java
+ test/java/time/tck/java/time/chrono/TestChronoLocalDateTime.java
+ test/java/time/tck/java/time/chrono/TestHijrahChronology.java
+ test/java/time/tck/java/time/chrono/TestJapaneseChronology.java
+ test/java/time/tck/java/time/chrono/TestMinguoChronology.java
+ test/java/time/tck/java/time/chrono/TestThaiBuddhistChronology.java
+ test/java/time/tck/java/time/format/TCKChronoPrinterParser.java
! test/java/time/tck/java/time/format/TCKDateTimeFormatter.java
! test/java/time/tck/java/time/format/TCKDateTimeFormatterBuilder.java
! test/java/time/tck/java/time/format/TCKDateTimeFormatters.java
- test/java/time/tck/java/time/format/TCKDateTimePrintException.java
! test/java/time/tck/java/time/format/TCKDateTimeTextPrinting.java
! test/java/time/tck/java/time/format/TCKLocalizedFieldParser.java
! test/java/time/tck/java/time/format/TCKLocalizedFieldPrinter.java
+ test/java/time/tck/java/time/format/TCKLocalizedPrinterParser.java
+ test/java/time/tck/java/time/format/TCKOffsetPrinterParser.java
+ test/java/time/tck/java/time/format/TCKPadPrinterParser.java
+ test/java/time/tck/java/time/format/TCKZoneIdPrinterParser.java
- test/java/time/tck/java/time/temporal/TCKISOFields.java
+ test/java/time/tck/java/time/temporal/TCKIsoFields.java
! test/java/time/tck/java/time/temporal/TCKJulianFields.java
- test/java/time/tck/java/time/temporal/TCKMonthDay.java
- test/java/time/tck/java/time/temporal/TCKOffsetDate.java
- test/java/time/tck/java/time/temporal/TCKOffsetDateTime.java
- test/java/time/tck/java/time/temporal/TCKOffsetTime.java
- test/java/time/tck/java/time/temporal/TCKSimplePeriod.java
! test/java/time/tck/java/time/temporal/TCKWeekFields.java
- test/java/time/tck/java/time/temporal/TCKYear.java
- test/java/time/tck/java/time/temporal/TCKYearMonth.java
- test/java/time/tck/java/time/temporal/TestChrono.java
! test/java/time/tck/java/time/temporal/TestChronoLocalDate.java
! test/java/time/tck/java/time/temporal/TestChronoLocalDateTime.java
! test/java/time/tck/java/time/temporal/TestChronoZonedDateTime.java
- test/java/time/tck/java/time/temporal/TestISOChrono.java
! test/java/time/tck/java/time/zone/TCKFixedZoneRules.java
! test/java/time/tck/java/time/zone/TCKZoneOffsetTransition.java
! test/java/time/tck/java/time/zone/TCKZoneOffsetTransitionRule.java
! test/java/time/tck/java/time/zone/TCKZoneRules.java
! test/java/time/tck/java/time/zone/TCKZoneRulesProvider.java
! test/java/time/test/java/time/MockSimplePeriod.java
! test/java/time/test/java/time/TestDuration.java
! test/java/time/test/java/time/TestLocalDateTime.java
! test/java/time/test/java/time/TestLocalTime.java
+ test/java/time/test/java/time/TestMonthDay.java
+ test/java/time/test/java/time/TestOffsetDateTime.java
+ test/java/time/test/java/time/TestOffsetDateTime_instants.java
+ test/java/time/test/java/time/TestOffsetTime.java
! test/java/time/test/java/time/TestPeriod.java
- test/java/time/test/java/time/TestPeriodParser.java
+ test/java/time/test/java/time/TestYear.java
+ test/java/time/test/java/time/TestYearMonth.java
! test/java/time/test/java/time/TestZoneId.java
+ test/java/time/test/java/time/chrono/TestExampleCode.java
+ test/java/time/test/java/time/chrono/TestIsoChronoImpl.java
+ test/java/time/test/java/time/chrono/TestServiceLoader.java
! test/java/time/test/java/time/format/TestCharLiteralParser.java
! test/java/time/test/java/time/format/TestCharLiteralPrinter.java
+ test/java/time/test/java/time/format/TestDateTimeFormatterBuilder.java
- test/java/time/test/java/time/format/TestDateTimeFormatters.java
- test/java/time/test/java/time/format/TestDateTimePrintException.java
! test/java/time/test/java/time/format/TestDateTimeTextProvider.java
! test/java/time/test/java/time/format/TestFractionPrinterParser.java
+ test/java/time/test/java/time/format/TestNonIsoFormatter.java
! test/java/time/test/java/time/format/TestNumberParser.java
! test/java/time/test/java/time/format/TestNumberPrinter.java
- test/java/time/test/java/time/format/TestPadParserDecorator.java
! test/java/time/test/java/time/format/TestPadPrinterDecorator.java
! test/java/time/test/java/time/format/TestReducedParser.java
! test/java/time/test/java/time/format/TestReducedPrinter.java
! test/java/time/test/java/time/format/TestSettingsParser.java
! test/java/time/test/java/time/format/TestStringLiteralParser.java
! test/java/time/test/java/time/format/TestStringLiteralPrinter.java
! test/java/time/test/java/time/format/TestTextParser.java
! test/java/time/test/java/time/format/TestTextPrinter.java
- test/java/time/test/java/time/format/TestZoneIdParser.java
! test/java/time/test/java/time/format/TestZoneOffsetParser.java
! test/java/time/test/java/time/format/TestZoneOffsetPrinter.java
! test/java/time/test/java/time/format/TestZoneTextPrinterParser.java
+ test/java/time/test/java/time/format/ZoneName.java
! test/java/time/test/java/time/temporal/MockFieldNoValue.java
! test/java/time/test/java/time/temporal/MockFieldValue.java
! test/java/time/test/java/time/temporal/TestChronoUnit.java
! test/java/time/test/java/time/temporal/TestDateTimeBuilderCombinations.java
- test/java/time/test/java/time/temporal/TestISOChronoImpl.java
! test/java/time/test/java/time/temporal/TestJapaneseChronoImpl.java
+ test/java/time/test/java/time/temporal/TestJulianFields.java
- test/java/time/test/java/time/temporal/TestMonthDay.java
- test/java/time/test/java/time/temporal/TestOffsetDate.java
- test/java/time/test/java/time/temporal/TestOffsetDateTime.java
- test/java/time/test/java/time/temporal/TestOffsetDateTime_instants.java
- test/java/time/test/java/time/temporal/TestOffsetTime.java
! test/java/time/test/java/time/temporal/TestThaiBuddhistChronoImpl.java
- test/java/time/test/java/time/temporal/TestYear.java
- test/java/time/test/java/time/temporal/TestYearMonth.java
! test/java/time/test/java/time/zone/TestFixedZoneRules.java
! test/java/time/test/java/util/TestFormatter.java
+ test/java/util/Calendar/JavatimeTest.java
! test/java/util/TimeZone/OldIDMappingTest.java
+ test/java/util/TimeZone/TzIDOldMapping.java
+ test/sun/util/calendar/zi/BackEnd.java
+ test/sun/util/calendar/zi/Checksum.java
+ test/sun/util/calendar/zi/DayOfWeek.java
+ test/sun/util/calendar/zi/Gen.java
+ test/sun/util/calendar/zi/GenDoc.java
+ test/sun/util/calendar/zi/Main.java
+ test/sun/util/calendar/zi/Mappings.java
+ test/sun/util/calendar/zi/Month.java
+ test/sun/util/calendar/zi/Rule.java
+ test/sun/util/calendar/zi/RuleDay.java
+ test/sun/util/calendar/zi/RuleRec.java
+ test/sun/util/calendar/zi/Simple.java
+ test/sun/util/calendar/zi/TestZoneInfo310.java
+ test/sun/util/calendar/zi/Time.java
+ test/sun/util/calendar/zi/Timezone.java
+ test/sun/util/calendar/zi/TzIDOldMapping.java
+ test/sun/util/calendar/zi/Zone.java
+ test/sun/util/calendar/zi/ZoneInfoFile.java
+ test/sun/util/calendar/zi/ZoneInfoOld.java
+ test/sun/util/calendar/zi/ZoneRec.java
+ test/sun/util/calendar/zi/Zoneinfo.java
+ test/sun/util/calendar/zi/tzdata/VERSION
+ test/sun/util/calendar/zi/tzdata/africa
+ test/sun/util/calendar/zi/tzdata/antarctica
+ test/sun/util/calendar/zi/tzdata/asia
+ test/sun/util/calendar/zi/tzdata/australasia
+ test/sun/util/calendar/zi/tzdata/backward
+ test/sun/util/calendar/zi/tzdata/etcetera
+ test/sun/util/calendar/zi/tzdata/europe
+ test/sun/util/calendar/zi/tzdata/factory
+ test/sun/util/calendar/zi/tzdata/gmt
+ test/sun/util/calendar/zi/tzdata/iso3166.tab
+ test/sun/util/calendar/zi/tzdata/jdk11_backward
+ test/sun/util/calendar/zi/tzdata/leapseconds
+ test/sun/util/calendar/zi/tzdata/northamerica
+ test/sun/util/calendar/zi/tzdata/pacificnew
+ test/sun/util/calendar/zi/tzdata/solar87
+ test/sun/util/calendar/zi/tzdata/solar88
+ test/sun/util/calendar/zi/tzdata/solar89
+ test/sun/util/calendar/zi/tzdata/southamerica
+ test/sun/util/calendar/zi/tzdata/systemv
+ test/sun/util/calendar/zi/tzdata/zone.tab
+ test/sun/util/calendar/zi/tzdata_jdk/gmt
+ test/sun/util/calendar/zi/tzdata_jdk/jdk11_backward
+ test/sun/util/calendar/zi/tzdata_jdk/jdk11_full_backward

Changeset: 2cd67a8c7abc
Author:    jfranck
Date:      2013-02-13 10:36 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/2cd67a8c7abc

8007278: Rename j.l.r.AnnotatedElement.getAnnotations(Class) to getAnnotationsByType(Class)
Reviewed-by: darcy, abuckley

! src/share/classes/java/lang/Class.java
! src/share/classes/java/lang/Package.java
! src/share/classes/java/lang/reflect/AccessibleObject.java
! src/share/classes/java/lang/reflect/AnnotatedElement.java
! src/share/classes/java/lang/reflect/Executable.java
! src/share/classes/java/lang/reflect/Field.java
! src/share/classes/java/lang/reflect/Parameter.java
! src/share/classes/sun/reflect/annotation/AnnotatedTypeFactory.java
! src/share/classes/sun/reflect/generics/reflectiveObjects/TypeVariableImpl.java
! test/java/lang/annotation/TypeParamAnnotation.java
! test/java/lang/annotation/repeatingAnnotations/RepeatedUnitTest.java

Changeset: cd111064d4e9
Author:    zgu
Date:      2013-02-12 14:47 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/cd111064d4e9

8006691: Remove jvm_version_info->is_kernel_jvm field
Summary: Remove is_kernel_jvm field in jvm_version_info structure, as kernel VM has been deprecated
Reviewed-by: mchung

! src/share/javavm/export/jvm.h

Changeset: bf64f83aa0cd
Author:    vinnie
Date:      2013-02-13 16:01 +0000
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/bf64f83aa0cd

8007934: algorithm parameters for PBE Scheme 2 not decoded correctly in PKCS12 keystore
Reviewed-by: mullan

! src/share/classes/sun/security/pkcs12/PKCS12KeyStore.java
! test/java/security/KeyStore/PBETest.java

Changeset: ceb7c712c693
Author:    vinnie
Date:      2013-02-13 16:03 +0000
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/ceb7c712c693

Merge


Changeset: 8181be9a3538
Author:    dsamersoff
Date:      2013-02-13 21:06 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/8181be9a3538

8008095: TEST_BUG: JDK-8002048 one more testcase failure on Solaris
Summary: fixed couple of more Solaris shell incompatibilities
Reviewed-by: chegar

! test/sun/management/jdp/JdpTest.sh

Changeset: 11438befdd4c
Author:    vinnie
Date:      2013-02-13 19:40 +0000
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/11438befdd4c

8007755: Support the logical grouping of keystores
Reviewed-by: mullan

! src/share/classes/java/security/KeyStore.java
+ src/share/classes/sun/security/provider/DomainKeyStore.java
! src/share/classes/sun/security/provider/PolicyParser.java
! src/share/classes/sun/security/provider/Sun.java
! src/share/classes/sun/security/provider/SunEntries.java
! src/share/classes/sun/security/util/Resources.java
+ test/sun/security/provider/KeyStore/DKSTest.java
+ test/sun/security/provider/KeyStore/DKSTest.sh
+ test/sun/security/provider/KeyStore/domains.cfg
! test/sun/security/tools/keytool/AltProviderPath.sh
! test/sun/security/tools/keytool/DummyProvider.java

Changeset: efc66fe16f91
Author:    sherman
Date:      2013-02-13 11:49 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/efc66fe16f91

8008161: Regression: j.u.TimeZone.getAvailableIDs(rawOffset) returns non-sorted list
Summary: to return a sorted list
Reviewed-by: lancea, naoto

! src/share/classes/sun/util/calendar/ZoneInfoFile.java
! test/sun/util/calendar/zi/TestZoneInfo310.java

Changeset: ff80a6b2ae9b
Author:    lana
Date:      2013-02-13 11:25 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/ff80a6b2ae9b

Merge


Changeset: a5aad284904e
Author:    lana
Date:      2013-02-13 11:57 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/a5aad284904e

Merge


Changeset: 83c09292f5ad
Author:    ksrini
Date:      2013-02-13 12:56 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/83c09292f5ad

8005750: [parfait] Memory leak at jdk/src/share/bin/parse_manifest.c
Reviewed-by: jjh

! src/share/bin/parse_manifest.c

Changeset: b13247d5408d
Author:    dcubed
Date:      2013-02-13 13:22 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/b13247d5408d

8007935: java/lang/instrument/RedefineSubclassWithTwoInterfaces.sh should use $COMPILEJAVA for javac
Reviewed-by: sspitsyn, alanb

! test/java/lang/instrument/RedefineSubclassWithTwoInterfaces.sh

Changeset: 4f520ce7ba3f
Author:    acorn
Date:      2013-02-13 16:09 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/4f520ce7ba3f

8007888: jdk fix default method: VerifyError: Illegal use of nonvirtual
Summary: Recognize VM generated method in old verifier. With 8004967
Reviewed-by: coleenp, acorn
Contributed-by: bharadwaj.yadavalli at oracle.com

! src/share/javavm/export/jvm.h
! src/share/native/common/check_code.c

Changeset: e6f34051c60c
Author:    acorn
Date:      2013-02-13 16:15 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/e6f34051c60c

Merge


Changeset: dc3019a336c0
Author:    lana
Date:      2013-02-13 17:57 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/dc3019a336c0

Merge

- src/share/classes/java/time/PeriodParser.java
- src/share/classes/java/time/calendar/ChronoDateImpl.java
- src/share/classes/java/time/calendar/HijrahChrono.java
- src/share/classes/java/time/calendar/HijrahDate.java
- src/share/classes/java/time/calendar/HijrahDeviationReader.java
- src/share/classes/java/time/calendar/HijrahEra.java
- src/share/classes/java/time/calendar/JapaneseChrono.java
- src/share/classes/java/time/calendar/JapaneseDate.java
- src/share/classes/java/time/calendar/JapaneseEra.java
- src/share/classes/java/time/calendar/MinguoChrono.java
- src/share/classes/java/time/calendar/MinguoDate.java
- src/share/classes/java/time/calendar/MinguoEra.java
- src/share/classes/java/time/calendar/Ser.java
- src/share/classes/java/time/calendar/ThaiBuddhistChrono.java
- src/share/classes/java/time/calendar/ThaiBuddhistDate.java
- src/share/classes/java/time/calendar/ThaiBuddhistEra.java
- src/share/classes/java/time/calendar/package-info.java
- src/share/classes/java/time/format/DateTimeFormatters.java
- src/share/classes/java/time/format/DateTimePrintException.java
- src/share/classes/java/time/temporal/Chrono.java
- src/share/classes/java/time/temporal/ChronoLocalDate.java
- src/share/classes/java/time/temporal/ChronoLocalDateTime.java
- src/share/classes/java/time/temporal/ChronoLocalDateTimeImpl.java
- src/share/classes/java/time/temporal/ChronoZonedDateTime.java
- src/share/classes/java/time/temporal/ChronoZonedDateTimeImpl.java
- src/share/classes/java/time/temporal/Era.java
- src/share/classes/java/time/temporal/ISOChrono.java
- src/share/classes/java/time/temporal/ISOEra.java
- src/share/classes/java/time/temporal/ISOFields.java
- src/share/classes/java/time/temporal/MonthDay.java
- src/share/classes/java/time/temporal/OffsetDate.java
- src/share/classes/java/time/temporal/OffsetDateTime.java
- src/share/classes/java/time/temporal/OffsetTime.java
- src/share/classes/java/time/temporal/Ser.java
- src/share/classes/java/time/temporal/SimplePeriod.java
- src/share/classes/java/time/temporal/TemporalAdder.java
- src/share/classes/java/time/temporal/TemporalSubtractor.java
- src/share/classes/java/time/temporal/Year.java
- src/share/classes/java/time/temporal/YearMonth.java
- src/share/classes/sun/util/calendar/TzIDOldMapping.java
- test/java/time/META-INF/services/java.time.temporal.Chrono
- test/java/time/tck/java/time/calendar/CopticChrono.java
- test/java/time/tck/java/time/calendar/CopticDate.java
- test/java/time/tck/java/time/calendar/CopticEra.java
- test/java/time/tck/java/time/calendar/TestChronoLocalDate.java
- test/java/time/tck/java/time/calendar/TestChronoLocalDateTime.java
- test/java/time/tck/java/time/calendar/TestHijrahChrono.java
- test/java/time/tck/java/time/calendar/TestJapaneseChrono.java
- test/java/time/tck/java/time/calendar/TestMinguoChrono.java
- test/java/time/tck/java/time/calendar/TestServiceLoader.java
- test/java/time/tck/java/time/calendar/TestThaiBuddhistChrono.java
- test/java/time/tck/java/time/format/TCKDateTimePrintException.java
- test/java/time/tck/java/time/temporal/TCKISOFields.java
- test/java/time/tck/java/time/temporal/TCKMonthDay.java
- test/java/time/tck/java/time/temporal/TCKOffsetDate.java
- test/java/time/tck/java/time/temporal/TCKOffsetDateTime.java
- test/java/time/tck/java/time/temporal/TCKOffsetTime.java
- test/java/time/tck/java/time/temporal/TCKSimplePeriod.java
- test/java/time/tck/java/time/temporal/TCKYear.java
- test/java/time/tck/java/time/temporal/TCKYearMonth.java
- test/java/time/tck/java/time/temporal/TestChrono.java
- test/java/time/tck/java/time/temporal/TestISOChrono.java
- test/java/time/test/java/time/TestPeriodParser.java
- test/java/time/test/java/time/format/TestDateTimeFormatters.java
- test/java/time/test/java/time/format/TestDateTimePrintException.java
- test/java/time/test/java/time/format/TestPadParserDecorator.java
- test/java/time/test/java/time/format/TestZoneIdParser.java
- test/java/time/test/java/time/temporal/TestISOChronoImpl.java
- test/java/time/test/java/time/temporal/TestMonthDay.java
- test/java/time/test/java/time/temporal/TestOffsetDate.java
- test/java/time/test/java/time/temporal/TestOffsetDateTime.java
- test/java/time/test/java/time/temporal/TestOffsetDateTime_instants.java
- test/java/time/test/java/time/temporal/TestOffsetTime.java
- test/java/time/test/java/time/temporal/TestYear.java
- test/java/time/test/java/time/temporal/TestYearMonth.java

Changeset: 5ea0024ba765
Author:    lana
Date:      2013-02-14 22:12 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/5ea0024ba765

Merge


Changeset: f93625257fbd
Author:    mduigou
Date:      2013-02-20 10:16 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/f93625257fbd

Merge

! .hgtags
! make/Makefile
! make/common/shared/Sanity.gmk
! make/docs/CORE_PKGS.gmk
! make/java/java/FILES_java.gmk
! make/netbeans/common/architectures/arch-x86_64.properties
! make/netbeans/common/architectures/name-Macosx.properties
! make/netbeans/common/java-data-native.ent
! make/netbeans/common/java-data-no-native.ent
! make/netbeans/common/shared.xml
! makefiles/Setup.gmk
- src/macosx/classes/sun/lwawt/macosx/EventDispatchAccess.java
! src/share/classes/java/awt/EventDispatchThread.java
! src/share/classes/java/lang/Double.java
! src/share/classes/java/lang/Iterable.java
- src/share/classes/java/lang/annotation/ContainedBy.java
- src/share/classes/java/lang/annotation/ContainerFor.java
! src/share/classes/java/nio/file/DirectoryStream.java
- src/share/classes/java/time/PeriodParser.java
- src/share/classes/java/time/calendar/ChronoDateImpl.java
- src/share/classes/java/time/calendar/HijrahChrono.java
- src/share/classes/java/time/calendar/HijrahDate.java
- src/share/classes/java/time/calendar/HijrahDeviationReader.java
- src/share/classes/java/time/calendar/HijrahEra.java
- src/share/classes/java/time/calendar/JapaneseChrono.java
- src/share/classes/java/time/calendar/JapaneseDate.java
- src/share/classes/java/time/calendar/JapaneseEra.java
- src/share/classes/java/time/calendar/MinguoChrono.java
- src/share/classes/java/time/calendar/MinguoDate.java
- src/share/classes/java/time/calendar/MinguoEra.java
- src/share/classes/java/time/calendar/Ser.java
- src/share/classes/java/time/calendar/ThaiBuddhistChrono.java
- src/share/classes/java/time/calendar/ThaiBuddhistDate.java
- src/share/classes/java/time/calendar/ThaiBuddhistEra.java
- src/share/classes/java/time/calendar/package-info.java
- src/share/classes/java/time/format/DateTimeFormatters.java
- src/share/classes/java/time/format/DateTimePrintException.java
- src/share/classes/java/time/temporal/Chrono.java
- src/share/classes/java/time/temporal/ChronoLocalDate.java
- src/share/classes/java/time/temporal/ChronoLocalDateTime.java
- src/share/classes/java/time/temporal/ChronoLocalDateTimeImpl.java
- src/share/classes/java/time/temporal/ChronoZonedDateTime.java
- src/share/classes/java/time/temporal/ChronoZonedDateTimeImpl.java
- src/share/classes/java/time/temporal/Era.java
- src/share/classes/java/time/temporal/ISOChrono.java
- src/share/classes/java/time/temporal/ISOEra.java
- src/share/classes/java/time/temporal/ISOFields.java
- src/share/classes/java/time/temporal/MonthDay.java
- src/share/classes/java/time/temporal/OffsetDate.java
- src/share/classes/java/time/temporal/OffsetDateTime.java
- src/share/classes/java/time/temporal/OffsetTime.java
- src/share/classes/java/time/temporal/Ser.java
- src/share/classes/java/time/temporal/SimplePeriod.java
- src/share/classes/java/time/temporal/TemporalAdder.java
- src/share/classes/java/time/temporal/TemporalSubtractor.java
- src/share/classes/java/time/temporal/Year.java
- src/share/classes/java/time/temporal/YearMonth.java
! src/share/classes/java/util/Comparator.java
! src/share/classes/java/util/function/BinaryOperator.java
! src/share/classes/java/util/function/Consumer.java
! src/share/classes/java/util/function/DoubleBinaryOperator.java
! src/share/classes/java/util/function/DoubleConsumer.java
! src/share/classes/java/util/function/DoubleFunction.java
! src/share/classes/java/util/function/DoubleSupplier.java
! src/share/classes/java/util/function/DoubleUnaryOperator.java
! src/share/classes/java/util/function/Function.java
! src/share/classes/java/util/function/IntBinaryOperator.java
! src/share/classes/java/util/function/IntConsumer.java
! src/share/classes/java/util/function/IntFunction.java
! src/share/classes/java/util/function/IntSupplier.java
! src/share/classes/java/util/function/IntUnaryOperator.java
! src/share/classes/java/util/function/LongBinaryOperator.java
! src/share/classes/java/util/function/LongConsumer.java
! src/share/classes/java/util/function/LongFunction.java
! src/share/classes/java/util/function/LongSupplier.java
! src/share/classes/java/util/function/LongUnaryOperator.java
! src/share/classes/java/util/function/Predicate.java
! src/share/classes/java/util/function/Supplier.java
! src/share/classes/java/util/function/ToDoubleFunction.java
! src/share/classes/java/util/function/ToIntFunction.java
! src/share/classes/java/util/function/ToLongFunction.java
! src/share/classes/java/util/function/UnaryOperator.java
- src/share/classes/sun/util/calendar/TzIDOldMapping.java
! src/share/javavm/export/jvm.h
! src/share/native/common/check_code.c
- test/java/net/URL/abnormal_http_urls
- test/java/net/URL/ftp_urls
- test/java/net/URL/jar_urls
- test/java/net/URL/normal_http_urls
- test/java/net/URL/runconstructor.sh
- test/java/net/URL/share_file_urls
- test/java/net/URL/win32_file_urls
- test/java/time/META-INF/services/java.time.temporal.Chrono
- test/java/time/tck/java/time/calendar/CopticChrono.java
- test/java/time/tck/java/time/calendar/CopticDate.java
- test/java/time/tck/java/time/calendar/CopticEra.java
- test/java/time/tck/java/time/calendar/TestChronoLocalDate.java
- test/java/time/tck/java/time/calendar/TestChronoLocalDateTime.java
- test/java/time/tck/java/time/calendar/TestHijrahChrono.java
- test/java/time/tck/java/time/calendar/TestJapaneseChrono.java
- test/java/time/tck/java/time/calendar/TestMinguoChrono.java
- test/java/time/tck/java/time/calendar/TestServiceLoader.java
- test/java/time/tck/java/time/calendar/TestThaiBuddhistChrono.java
- test/java/time/tck/java/time/format/TCKDateTimePrintException.java
- test/java/time/tck/java/time/temporal/TCKISOFields.java
- test/java/time/tck/java/time/temporal/TCKMonthDay.java
- test/java/time/tck/java/time/temporal/TCKOffsetDate.java
- test/java/time/tck/java/time/temporal/TCKOffsetDateTime.java
- test/java/time/tck/java/time/temporal/TCKOffsetTime.java
- test/java/time/tck/java/time/temporal/TCKSimplePeriod.java
- test/java/time/tck/java/time/temporal/TCKYear.java
- test/java/time/tck/java/time/temporal/TCKYearMonth.java
- test/java/time/tck/java/time/temporal/TestChrono.java
- test/java/time/tck/java/time/temporal/TestISOChrono.java
- test/java/time/test/java/time/TestPeriodParser.java
- test/java/time/test/java/time/format/TestDateTimeFormatters.java
- test/java/time/test/java/time/format/TestDateTimePrintException.java
- test/java/time/test/java/time/format/TestPadParserDecorator.java
- test/java/time/test/java/time/format/TestZoneIdParser.java
- test/java/time/test/java/time/temporal/TestISOChronoImpl.java
- test/java/time/test/java/time/temporal/TestMonthDay.java
- test/java/time/test/java/time/temporal/TestOffsetDate.java
- test/java/time/test/java/time/temporal/TestOffsetDateTime.java
- test/java/time/test/java/time/temporal/TestOffsetDateTime_instants.java
- test/java/time/test/java/time/temporal/TestOffsetTime.java
- test/java/time/test/java/time/temporal/TestYear.java
- test/java/time/test/java/time/temporal/TestYearMonth.java
- test/sun/net/www/EncDec.doc
- test/sun/net/www/MarkResetTest.java
- test/sun/net/www/MarkResetTest.sh
- test/sun/security/util/Oid/S11N.sh
- test/sun/security/util/Oid/SerialTest.java


From misterm at gmail.com  Wed Feb 20 13:49:22 2013
From: misterm at gmail.com (Michael Nascimento)
Date: Wed, 20 Feb 2013 18:49:22 -0300
Subject: TestNG tests appear to hang with latest lambda
In-Reply-To: <CABKW8Rj2eF2+kn_Membu6PWOGUbkg=3Sm7FupNTCEzjM-RVjXA@mail.gmail.com>
References: <CABKW8Rg5+3ZuYXbKMcACB7fUY=6Q7GeXoO5L-gvaZqF3L207_g@mail.gmail.com>
	<CABKW8Rj2eF2+kn_Membu6PWOGUbkg=3Sm7FupNTCEzjM-RVjXA@mail.gmail.com>
Message-ID: <CAAWA2oVhowZ8v6MW6NRZ92BcrS-J0SFqN7GEur00Y8uh-6tYzQ@mail.gmail.com>

Aren't you experiencing this:

https://github.com/cbeust/testng/issues/219

Regards,
Michael

On Wed, Feb 20, 2013 at 6:27 PM, Ben Evans
<benjamin.john.evans at gmail.com> wrote:
> OK, following up to my own mail.
>
> The tests will actually complete if left for long enough, but the
> process gets *huge* - at least 2.8G in size, and if other processes
> are running, it will take a very long time to complete.
>
> Does anyone have any insight as to why the tests consume so much memory?
>
> Ben
>
> On Wed, Feb 20, 2013 at 3:40 PM, Ben Evans
> <benjamin.john.evans at gmail.com> wrote:
>> Hi,
>>
>> I'm writing some docs for AdoptOpenJDK about getting started writing
>> TestNG tests, in advance of the hackdays at Devoxx UK.
>>
>> However, with latest lambda, the TestNG tests appear to hang (output
>> below). The process grows in size to over 1Gb, and then appears to
>> freeze. It's still responsive (so I can connect jvisualvm to it, but
>> when I sample the code, nothing appears to be running).
>>
>> This is on Mac 10.7 with OpenJDK 8 from current lambda.
>>
>> Any ideas?
>>
>> Thanks,
>>
>> Ben
>>
>> ariel:test-ng boxcat$ ant test
>> Buildfile: /Users/boxcat/projects/lambda/jdk/test-ng/build.xml
>>
>> prepare:
>>
>> test-compile:
>>     [javac] /Users/boxcat/projects/lambda/jdk/test-ng/build.xml:78:
>> warning: 'includeantruntime' was not set, defaulting to
>> build.sysclasspath=last; set to false for repeatable builds
>>     [javac] /Users/boxcat/projects/lambda/jdk/test-ng/build.xml:82:
>> warning: 'includeantruntime' was not set, defaulting to
>> build.sysclasspath=last; set to false for repeatable builds
>>     [javac] /Users/boxcat/projects/lambda/jdk/test-ng/build.xml:86:
>> warning: 'includeantruntime' was not set, defaulting to
>> build.sysclasspath=last; set to false for repeatable builds
>>
>> test:
>>      [echo] Results at: file:../../build/test-ng/test-reports/index.html
>>    [testng] [TestNG] Running:
>>    [testng]   Ant suite
>>    [testng]
>>    [testng]
>>    [testng] Generating exhaustive interface....
>>    [testng]       8 No default
>>    [testng]       8 Error
>>    [testng]      48 OK
>>    [testng]      64 Total
>>    [testng]
>>    [testng] Generating exhaustive class....
>>    [testng]     729 No default
>>    [testng]      49 Error
>>    [testng]     950 OK
>>    [testng]    1728 Total
>>    [testng]
>>    [testng] Generating shapes interface....
>>    [testng]     109 No default
>>    [testng]     280 Error
>>    [testng]     507 OK
>>    [testng]     896 Total
>>    [testng]
>>    [testng] Generating shapes class/interface....
>>    [testng]     190 No default
>>    [testng]     568 Error
>>    [testng]     536 OK
>>    [testng]    1294 Total
>>    [testng]
>>    [testng] Expect OK:    2041 -- unique 1813
>>    [testng] Expect Error: 905 -- unique 773
>>    [testng]
>>    [testng] Generating exhaustive interface....
>>    [testng]       8 No default
>>    [testng]       8 Error
>>    [testng]      48 OK
>>    [testng]      64 Total
>>    [testng]
>>    [testng] Generating exhaustive class....
>>    [testng]     729 No default
>>    [testng]      49 Error
>>    [testng]     950 OK
>>    [testng]    1728 Total
>>    [testng]
>>    [testng] Generating shapes interface....
>>    [testng]     109 No default
>>    [testng]     280 Error
>>    [testng]     507 OK
>>    [testng]     896 Total
>>    [testng]
>>    [testng] Generating shapes class/interface....
>>    [testng]     190 No default
>>    [testng]     568 Error
>>    [testng]     536 OK
>>    [testng]    1294 Total
>>    [testng]
>>    [testng] Expect OK:    2041 -- unique 1813
>>    [testng] Expect Error: 905 -- unique 773
>

From mike.duigou at oracle.com  Wed Feb 20 13:49:14 2013
From: mike.duigou at oracle.com (mike.duigou at oracle.com)
Date: Wed, 20 Feb 2013 21:49:14 +0000
Subject: hg: lambda/lambda/jdk: Add missing specification of null handling
	behaviour.
Message-ID: <20130220214925.A5E7447C1C@hg.openjdk.java.net>

Changeset: 1ca7473e08aa
Author:    mduigou
Date:      2013-02-20 13:49 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/1ca7473e08aa

Add missing specification of null handling behaviour.
Contributed-by: alan.bateman at oracle.com

! src/share/classes/java/time/chrono/HijrahDeviationReader.java
! src/share/classes/java/util/Optional.java
! src/share/classes/java/util/OptionalDouble.java
! src/share/classes/java/util/OptionalInt.java
! src/share/classes/java/util/OptionalLong.java


From brian.goetz at oracle.com  Wed Feb 20 13:53:14 2013
From: brian.goetz at oracle.com (Brian Goetz)
Date: Wed, 20 Feb 2013 16:53:14 -0500
Subject: TestNG tests appear to hang with latest lambda
In-Reply-To: <512540D8.6060702@oracle.com>
References: <CABKW8Rg5+3ZuYXbKMcACB7fUY=6Q7GeXoO5L-gvaZqF3L207_g@mail.gmail.com>
	<CABKW8Rj2eF2+kn_Membu6PWOGUbkg=3Sm7FupNTCEzjM-RVjXA@mail.gmail.com>
	<512540D8.6060702@oracle.com>
Message-ID: <512545CA.3010203@oracle.com>

I think that's likely what's going on -- TestNG buffering lots of 
per-test metadata, expanding the heap and causing paging/frequent GCs.

There's a smaller test suite for the libraries only (ant test-libs) that 
we usually run.

On 2/20/2013 4:32 PM, Jonathan Gibbons wrote:
> My understanding is that TestNG does not scale well with too many test
> cases,
> and folk are just testing stuff "too much" these days :-)
>
> -- Jon
>
> On 02/20/2013 01:27 PM, Ben Evans wrote:
>> OK, following up to my own mail.
>>
>> The tests will actually complete if left for long enough, but the
>> process gets *huge* - at least 2.8G in size, and if other processes
>> are running, it will take a very long time to complete.
>>
>> Does anyone have any insight as to why the tests consume so much memory?
>>
>> Ben
>>
>> On Wed, Feb 20, 2013 at 3:40 PM, Ben Evans
>> <benjamin.john.evans at gmail.com> wrote:
>>> Hi,
>>>
>>> I'm writing some docs for AdoptOpenJDK about getting started writing
>>> TestNG tests, in advance of the hackdays at Devoxx UK.
>>>
>>> However, with latest lambda, the TestNG tests appear to hang (output
>>> below). The process grows in size to over 1Gb, and then appears to
>>> freeze. It's still responsive (so I can connect jvisualvm to it, but
>>> when I sample the code, nothing appears to be running).
>>>
>>> This is on Mac 10.7 with OpenJDK 8 from current lambda.
>>>
>>> Any ideas?
>>>
>>> Thanks,
>>>
>>> Ben
>>>
>>> ariel:test-ng boxcat$ ant test
>>> Buildfile: /Users/boxcat/projects/lambda/jdk/test-ng/build.xml
>>>
>>> prepare:
>>>
>>> test-compile:
>>>       [javac] /Users/boxcat/projects/lambda/jdk/test-ng/build.xml:78:
>>> warning: 'includeantruntime' was not set, defaulting to
>>> build.sysclasspath=last; set to false for repeatable builds
>>>       [javac] /Users/boxcat/projects/lambda/jdk/test-ng/build.xml:82:
>>> warning: 'includeantruntime' was not set, defaulting to
>>> build.sysclasspath=last; set to false for repeatable builds
>>>       [javac] /Users/boxcat/projects/lambda/jdk/test-ng/build.xml:86:
>>> warning: 'includeantruntime' was not set, defaulting to
>>> build.sysclasspath=last; set to false for repeatable builds
>>>
>>> test:
>>>        [echo] Results at: file:../../build/test-ng/test-reports/index.html
>>>      [testng] [TestNG] Running:
>>>      [testng]   Ant suite
>>>      [testng]
>>>      [testng]
>>>      [testng] Generating exhaustive interface....
>>>      [testng]       8 No default
>>>      [testng]       8 Error
>>>      [testng]      48 OK
>>>      [testng]      64 Total
>>>      [testng]
>>>      [testng] Generating exhaustive class....
>>>      [testng]     729 No default
>>>      [testng]      49 Error
>>>      [testng]     950 OK
>>>      [testng]    1728 Total
>>>      [testng]
>>>      [testng] Generating shapes interface....
>>>      [testng]     109 No default
>>>      [testng]     280 Error
>>>      [testng]     507 OK
>>>      [testng]     896 Total
>>>      [testng]
>>>      [testng] Generating shapes class/interface....
>>>      [testng]     190 No default
>>>      [testng]     568 Error
>>>      [testng]     536 OK
>>>      [testng]    1294 Total
>>>      [testng]
>>>      [testng] Expect OK:    2041 -- unique 1813
>>>      [testng] Expect Error: 905 -- unique 773
>>>      [testng]
>>>      [testng] Generating exhaustive interface....
>>>      [testng]       8 No default
>>>      [testng]       8 Error
>>>      [testng]      48 OK
>>>      [testng]      64 Total
>>>      [testng]
>>>      [testng] Generating exhaustive class....
>>>      [testng]     729 No default
>>>      [testng]      49 Error
>>>      [testng]     950 OK
>>>      [testng]    1728 Total
>>>      [testng]
>>>      [testng] Generating shapes interface....
>>>      [testng]     109 No default
>>>      [testng]     280 Error
>>>      [testng]     507 OK
>>>      [testng]     896 Total
>>>      [testng]
>>>      [testng] Generating shapes class/interface....
>>>      [testng]     190 No default
>>>      [testng]     568 Error
>>>      [testng]     536 OK
>>>      [testng]    1294 Total
>>>      [testng]
>>>      [testng] Expect OK:    2041 -- unique 1813
>>>      [testng] Expect Error: 905 -- unique 773
>
>

From brian.goetz at oracle.com  Wed Feb 20 14:20:27 2013
From: brian.goetz at oracle.com (brian.goetz at oracle.com)
Date: Wed, 20 Feb 2013 22:20:27 +0000
Subject: hg: lambda/lambda/jdk: Javadoc for AbstractPipeline
Message-ID: <20130220222048.3170047C1D@hg.openjdk.java.net>

Changeset: c499c13fa66a
Author:    briangoetz
Date:      2013-02-20 17:20 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/c499c13fa66a

Javadoc for AbstractPipeline

! src/share/classes/java/util/stream/AbstractPipeline.java
! src/share/classes/java/util/stream/ReferencePipeline.java


From cedric at beust.com  Wed Feb 20 14:29:05 2013
From: cedric at beust.com (=?UTF-8?B?Q8OpZHJpYyBCZXVzdCDimZQ=?=)
Date: Wed, 20 Feb 2013 14:29:05 -0800
Subject: TestNG tests appear to hang with latest lambda
In-Reply-To: <512545CA.3010203@oracle.com>
References: <CABKW8Rg5+3ZuYXbKMcACB7fUY=6Q7GeXoO5L-gvaZqF3L207_g@mail.gmail.com>
	<CABKW8Rj2eF2+kn_Membu6PWOGUbkg=3Sm7FupNTCEzjM-RVjXA@mail.gmail.com>
	<512540D8.6060702@oracle.com> <512545CA.3010203@oracle.com>
Message-ID: <CAOphgJDZYFRf01R=Chq_YXcvvt83Sr+j08NTH=VrC1A=MKJKpw@mail.gmail.com>

I provided a beta version in the issue provided by Michael (reproduced
below) which gets rid of EmailableReporter. Ben, can you try with this beta
version and see if it fixes the problem?

Issue: https://github.com/cbeust/testng/issues/219
Beta: http://testng.org/beta

-- 
C?dric


-- 
C?dric



On Wed, Feb 20, 2013 at 1:53 PM, Brian Goetz <brian.goetz at oracle.com> wrote:

> I think that's likely what's going on -- TestNG buffering lots of
> per-test metadata, expanding the heap and causing paging/frequent GCs.
>
> There's a smaller test suite for the libraries only (ant test-libs) that
> we usually run.
>
> On 2/20/2013 4:32 PM, Jonathan Gibbons wrote:
> > My understanding is that TestNG does not scale well with too many test
> > cases,
> > and folk are just testing stuff "too much" these days :-)
> >
> > -- Jon
> >
> > On 02/20/2013 01:27 PM, Ben Evans wrote:
> >> OK, following up to my own mail.
> >>
> >> The tests will actually complete if left for long enough, but the
> >> process gets *huge* - at least 2.8G in size, and if other processes
> >> are running, it will take a very long time to complete.
> >>
> >> Does anyone have any insight as to why the tests consume so much memory?
> >>
> >> Ben
> >>
> >> On Wed, Feb 20, 2013 at 3:40 PM, Ben Evans
> >> <benjamin.john.evans at gmail.com> wrote:
> >>> Hi,
> >>>
> >>> I'm writing some docs for AdoptOpenJDK about getting started writing
> >>> TestNG tests, in advance of the hackdays at Devoxx UK.
> >>>
> >>> However, with latest lambda, the TestNG tests appear to hang (output
> >>> below). The process grows in size to over 1Gb, and then appears to
> >>> freeze. It's still responsive (so I can connect jvisualvm to it, but
> >>> when I sample the code, nothing appears to be running).
> >>>
> >>> This is on Mac 10.7 with OpenJDK 8 from current lambda.
> >>>
> >>> Any ideas?
> >>>
> >>> Thanks,
> >>>
> >>> Ben
> >>>
> >>> ariel:test-ng boxcat$ ant test
> >>> Buildfile: /Users/boxcat/projects/lambda/jdk/test-ng/build.xml
> >>>
> >>> prepare:
> >>>
> >>> test-compile:
> >>>       [javac] /Users/boxcat/projects/lambda/jdk/test-ng/build.xml:78:
> >>> warning: 'includeantruntime' was not set, defaulting to
> >>> build.sysclasspath=last; set to false for repeatable builds
> >>>       [javac] /Users/boxcat/projects/lambda/jdk/test-ng/build.xml:82:
> >>> warning: 'includeantruntime' was not set, defaulting to
> >>> build.sysclasspath=last; set to false for repeatable builds
> >>>       [javac] /Users/boxcat/projects/lambda/jdk/test-ng/build.xml:86:
> >>> warning: 'includeantruntime' was not set, defaulting to
> >>> build.sysclasspath=last; set to false for repeatable builds
> >>>
> >>> test:
> >>>        [echo] Results at:
> file:../../build/test-ng/test-reports/index.html
> >>>      [testng] [TestNG] Running:
> >>>      [testng]   Ant suite
> >>>      [testng]
> >>>      [testng]
> >>>      [testng] Generating exhaustive interface....
> >>>      [testng]       8 No default
> >>>      [testng]       8 Error
> >>>      [testng]      48 OK
> >>>      [testng]      64 Total
> >>>      [testng]
> >>>      [testng] Generating exhaustive class....
> >>>      [testng]     729 No default
> >>>      [testng]      49 Error
> >>>      [testng]     950 OK
> >>>      [testng]    1728 Total
> >>>      [testng]
> >>>      [testng] Generating shapes interface....
> >>>      [testng]     109 No default
> >>>      [testng]     280 Error
> >>>      [testng]     507 OK
> >>>      [testng]     896 Total
> >>>      [testng]
> >>>      [testng] Generating shapes class/interface....
> >>>      [testng]     190 No default
> >>>      [testng]     568 Error
> >>>      [testng]     536 OK
> >>>      [testng]    1294 Total
> >>>      [testng]
> >>>      [testng] Expect OK:    2041 -- unique 1813
> >>>      [testng] Expect Error: 905 -- unique 773
> >>>      [testng]
> >>>      [testng] Generating exhaustive interface....
> >>>      [testng]       8 No default
> >>>      [testng]       8 Error
> >>>      [testng]      48 OK
> >>>      [testng]      64 Total
> >>>      [testng]
> >>>      [testng] Generating exhaustive class....
> >>>      [testng]     729 No default
> >>>      [testng]      49 Error
> >>>      [testng]     950 OK
> >>>      [testng]    1728 Total
> >>>      [testng]
> >>>      [testng] Generating shapes interface....
> >>>      [testng]     109 No default
> >>>      [testng]     280 Error
> >>>      [testng]     507 OK
> >>>      [testng]     896 Total
> >>>      [testng]
> >>>      [testng] Generating shapes class/interface....
> >>>      [testng]     190 No default
> >>>      [testng]     568 Error
> >>>      [testng]     536 OK
> >>>      [testng]    1294 Total
> >>>      [testng]
> >>>      [testng] Expect OK:    2041 -- unique 1813
> >>>      [testng] Expect Error: 905 -- unique 773
> >
> >
>
>

From mike.duigou at oracle.com  Wed Feb 20 16:41:38 2013
From: mike.duigou at oracle.com (mike.duigou at oracle.com)
Date: Thu, 21 Feb 2013 00:41:38 +0000
Subject: hg: lambda/lambda/jdk: Updates to JSR-166 code from Doug's workspace
Message-ID: <20130221004200.9564647C21@hg.openjdk.java.net>

Changeset: a66e0dfd2973
Author:    mduigou
Date:      2013-02-20 15:42 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/a66e0dfd2973

Updates to JSR-166 code from Doug's workspace
Contributed-by: dl

! src/share/classes/java/util/concurrent/AbstractExecutorService.java
! src/share/classes/java/util/concurrent/ArrayBlockingQueue.java
! src/share/classes/java/util/concurrent/BlockingDeque.java
! src/share/classes/java/util/concurrent/BlockingQueue.java
! src/share/classes/java/util/concurrent/BrokenBarrierException.java
! src/share/classes/java/util/concurrent/Callable.java
! src/share/classes/java/util/concurrent/CancellationException.java
+ src/share/classes/java/util/concurrent/CompletableFuture.java
+ src/share/classes/java/util/concurrent/CompletionException.java
! src/share/classes/java/util/concurrent/CompletionService.java
! src/share/classes/java/util/concurrent/ConcurrentLinkedDeque.java
! src/share/classes/java/util/concurrent/ConcurrentLinkedQueue.java
! src/share/classes/java/util/concurrent/ConcurrentMap.java
! src/share/classes/java/util/concurrent/ConcurrentSkipListSet.java
! src/share/classes/java/util/concurrent/CountedCompleter.java
! src/share/classes/java/util/concurrent/CyclicBarrier.java
! src/share/classes/java/util/concurrent/DelayQueue.java
! src/share/classes/java/util/concurrent/Delayed.java
- src/share/classes/java/util/concurrent/DoubleAdder.java
- src/share/classes/java/util/concurrent/DoubleMaxUpdater.java
! src/share/classes/java/util/concurrent/Exchanger.java
! src/share/classes/java/util/concurrent/ExecutionException.java
! src/share/classes/java/util/concurrent/Executor.java
! src/share/classes/java/util/concurrent/ExecutorService.java
! src/share/classes/java/util/concurrent/Executors.java
! src/share/classes/java/util/concurrent/ForkJoinPool.java
! src/share/classes/java/util/concurrent/ForkJoinTask.java
! src/share/classes/java/util/concurrent/Future.java
! src/share/classes/java/util/concurrent/FutureTask.java
! src/share/classes/java/util/concurrent/LinkedTransferQueue.java
- src/share/classes/java/util/concurrent/LongAdder.java
- src/share/classes/java/util/concurrent/LongMaxUpdater.java
! src/share/classes/java/util/concurrent/Phaser.java
! src/share/classes/java/util/concurrent/PriorityBlockingQueue.java
! src/share/classes/java/util/concurrent/RecursiveAction.java
! src/share/classes/java/util/concurrent/RecursiveTask.java
! src/share/classes/java/util/concurrent/RejectedExecutionException.java
! src/share/classes/java/util/concurrent/RunnableFuture.java
! src/share/classes/java/util/concurrent/RunnableScheduledFuture.java
! src/share/classes/java/util/concurrent/ScheduledExecutorService.java
! src/share/classes/java/util/concurrent/ScheduledThreadPoolExecutor.java
- src/share/classes/java/util/concurrent/SequenceLock.java
- src/share/classes/java/util/concurrent/Striped64.java
! src/share/classes/java/util/concurrent/SynchronousQueue.java
! src/share/classes/java/util/concurrent/ThreadLocalRandom.java
! src/share/classes/java/util/concurrent/ThreadPoolExecutor.java
! src/share/classes/java/util/concurrent/TimeUnit.java
! src/share/classes/java/util/concurrent/TimeoutException.java
! src/share/classes/java/util/concurrent/atomic/AtomicInteger.java
! src/share/classes/java/util/concurrent/atomic/AtomicIntegerArray.java
! src/share/classes/java/util/concurrent/atomic/AtomicLong.java
! src/share/classes/java/util/concurrent/atomic/AtomicLongFieldUpdater.java
! src/share/classes/java/util/concurrent/atomic/AtomicReferenceArray.java
! src/share/classes/java/util/concurrent/atomic/AtomicReferenceFieldUpdater.java
! src/share/classes/java/util/concurrent/atomic/DoubleAccumulator.java
! src/share/classes/java/util/concurrent/atomic/DoubleAdder.java
+ src/share/classes/java/util/concurrent/atomic/Fences.java
! src/share/classes/java/util/concurrent/atomic/LongAccumulator.java
! src/share/classes/java/util/concurrent/atomic/package-info.java
- src/share/classes/java/util/concurrent/extra/AtomicDouble.java
- src/share/classes/java/util/concurrent/extra/AtomicDoubleArray.java
- src/share/classes/java/util/concurrent/extra/ReadMostlyVector.java
! src/share/classes/java/util/concurrent/locks/AbstractOwnableSynchronizer.java
! src/share/classes/java/util/concurrent/locks/AbstractQueuedLongSynchronizer.java
! src/share/classes/java/util/concurrent/locks/AbstractQueuedSynchronizer.java
! src/share/classes/java/util/concurrent/locks/Lock.java
! src/share/classes/java/util/concurrent/locks/LockSupport.java
! src/share/classes/java/util/concurrent/locks/ReadWriteLock.java
! src/share/classes/java/util/concurrent/locks/ReentrantLock.java
! src/share/classes/java/util/concurrent/locks/ReentrantReadWriteLock.java
! src/share/classes/java/util/concurrent/locks/StampedLock.java
! src/share/classes/java/util/concurrent/package-info.java


From benjamin.john.evans at gmail.com  Wed Feb 20 17:19:34 2013
From: benjamin.john.evans at gmail.com (Ben Evans)
Date: Wed, 20 Feb 2013 20:19:34 -0500
Subject: TestNG tests appear to hang with latest lambda
In-Reply-To: <CAOphgJDZYFRf01R=Chq_YXcvvt83Sr+j08NTH=VrC1A=MKJKpw@mail.gmail.com>
References: <CABKW8Rg5+3ZuYXbKMcACB7fUY=6Q7GeXoO5L-gvaZqF3L207_g@mail.gmail.com>
	<CABKW8Rj2eF2+kn_Membu6PWOGUbkg=3Sm7FupNTCEzjM-RVjXA@mail.gmail.com>
	<512540D8.6060702@oracle.com> <512545CA.3010203@oracle.com>
	<CAOphgJDZYFRf01R=Chq_YXcvvt83Sr+j08NTH=VrC1A=MKJKpw@mail.gmail.com>
Message-ID: <CABKW8RjXY7rAFsot357AM-ribYHS9eejP-2nayauDpm2OHW7YA@mail.gmail.com>

Hi C?dric,

I've tried with 6.9-beta. It reduces the amount of memory used
slightly (but the process still grows to over 2Gb) and the time taken
somewhat - now down to 8 mins for the ant test target.

However, the ant test-libs target is now dying with a SIGSEGV (hs_err
files attached) - although this may of course be for unrelated
reasons.

Thanks,

Ben

On Wed, Feb 20, 2013 at 5:29 PM, C?dric Beust ? <cedric at beust.com> wrote:
> I provided a beta version in the issue provided by Michael (reproduced
> below) which gets rid of EmailableReporter. Ben, can you try with this beta
> version and see if it fixes the problem?
>
> Issue: https://github.com/cbeust/testng/issues/219
> Beta: http://testng.org/beta
>
> --
> C?dric
>
>
> --
> C?dric
>
>
>
> On Wed, Feb 20, 2013 at 1:53 PM, Brian Goetz <brian.goetz at oracle.com> wrote:
>
>> I think that's likely what's going on -- TestNG buffering lots of
>> per-test metadata, expanding the heap and causing paging/frequent GCs.
>>
>> There's a smaller test suite for the libraries only (ant test-libs) that
>> we usually run.
>>
>> On 2/20/2013 4:32 PM, Jonathan Gibbons wrote:
>> > My understanding is that TestNG does not scale well with too many test
>> > cases,
>> > and folk are just testing stuff "too much" these days :-)
>> >
>> > -- Jon
>> >
>> > On 02/20/2013 01:27 PM, Ben Evans wrote:
>> >> OK, following up to my own mail.
>> >>
>> >> The tests will actually complete if left for long enough, but the
>> >> process gets *huge* - at least 2.8G in size, and if other processes
>> >> are running, it will take a very long time to complete.
>> >>
>> >> Does anyone have any insight as to why the tests consume so much memory?
>> >>
>> >> Ben
>> >>
>> >> On Wed, Feb 20, 2013 at 3:40 PM, Ben Evans
>> >> <benjamin.john.evans at gmail.com> wrote:
>> >>> Hi,
>> >>>
>> >>> I'm writing some docs for AdoptOpenJDK about getting started writing
>> >>> TestNG tests, in advance of the hackdays at Devoxx UK.
>> >>>
>> >>> However, with latest lambda, the TestNG tests appear to hang (output
>> >>> below). The process grows in size to over 1Gb, and then appears to
>> >>> freeze. It's still responsive (so I can connect jvisualvm to it, but
>> >>> when I sample the code, nothing appears to be running).
>> >>>
>> >>> This is on Mac 10.7 with OpenJDK 8 from current lambda.
>> >>>
>> >>> Any ideas?
>> >>>
>> >>> Thanks,
>> >>>
>> >>> Ben
>> >>>
>> >>> ariel:test-ng boxcat$ ant test
>> >>> Buildfile: /Users/boxcat/projects/lambda/jdk/test-ng/build.xml
>> >>>
>> >>> prepare:
>> >>>
>> >>> test-compile:
>> >>>       [javac] /Users/boxcat/projects/lambda/jdk/test-ng/build.xml:78:
>> >>> warning: 'includeantruntime' was not set, defaulting to
>> >>> build.sysclasspath=last; set to false for repeatable builds
>> >>>       [javac] /Users/boxcat/projects/lambda/jdk/test-ng/build.xml:82:
>> >>> warning: 'includeantruntime' was not set, defaulting to
>> >>> build.sysclasspath=last; set to false for repeatable builds
>> >>>       [javac] /Users/boxcat/projects/lambda/jdk/test-ng/build.xml:86:
>> >>> warning: 'includeantruntime' was not set, defaulting to
>> >>> build.sysclasspath=last; set to false for repeatable builds
>> >>>
>> >>> test:
>> >>>        [echo] Results at:
>> file:../../build/test-ng/test-reports/index.html
>> >>>      [testng] [TestNG] Running:
>> >>>      [testng]   Ant suite
>> >>>      [testng]
>> >>>      [testng]
>> >>>      [testng] Generating exhaustive interface....
>> >>>      [testng]       8 No default
>> >>>      [testng]       8 Error
>> >>>      [testng]      48 OK
>> >>>      [testng]      64 Total
>> >>>      [testng]
>> >>>      [testng] Generating exhaustive class....
>> >>>      [testng]     729 No default
>> >>>      [testng]      49 Error
>> >>>      [testng]     950 OK
>> >>>      [testng]    1728 Total
>> >>>      [testng]
>> >>>      [testng] Generating shapes interface....
>> >>>      [testng]     109 No default
>> >>>      [testng]     280 Error
>> >>>      [testng]     507 OK
>> >>>      [testng]     896 Total
>> >>>      [testng]
>> >>>      [testng] Generating shapes class/interface....
>> >>>      [testng]     190 No default
>> >>>      [testng]     568 Error
>> >>>      [testng]     536 OK
>> >>>      [testng]    1294 Total
>> >>>      [testng]
>> >>>      [testng] Expect OK:    2041 -- unique 1813
>> >>>      [testng] Expect Error: 905 -- unique 773
>> >>>      [testng]
>> >>>      [testng] Generating exhaustive interface....
>> >>>      [testng]       8 No default
>> >>>      [testng]       8 Error
>> >>>      [testng]      48 OK
>> >>>      [testng]      64 Total
>> >>>      [testng]
>> >>>      [testng] Generating exhaustive class....
>> >>>      [testng]     729 No default
>> >>>      [testng]      49 Error
>> >>>      [testng]     950 OK
>> >>>      [testng]    1728 Total
>> >>>      [testng]
>> >>>      [testng] Generating shapes interface....
>> >>>      [testng]     109 No default
>> >>>      [testng]     280 Error
>> >>>      [testng]     507 OK
>> >>>      [testng]     896 Total
>> >>>      [testng]
>> >>>      [testng] Generating shapes class/interface....
>> >>>      [testng]     190 No default
>> >>>      [testng]     568 Error
>> >>>      [testng]     536 OK
>> >>>      [testng]    1294 Total
>> >>>      [testng]
>> >>>      [testng] Expect OK:    2041 -- unique 1813
>> >>>      [testng] Expect Error: 905 -- unique 773
>> >
>> >
>>
>>
>

From brian.goetz at oracle.com  Wed Feb 20 17:31:06 2013
From: brian.goetz at oracle.com (Brian Goetz)
Date: Wed, 20 Feb 2013 20:31:06 -0500
Subject: TestNG tests appear to hang with latest lambda
In-Reply-To: <CABKW8RjXY7rAFsot357AM-ribYHS9eejP-2nayauDpm2OHW7YA@mail.gmail.com>
References: <CABKW8Rg5+3ZuYXbKMcACB7fUY=6Q7GeXoO5L-gvaZqF3L207_g@mail.gmail.com>
	<CABKW8Rj2eF2+kn_Membu6PWOGUbkg=3Sm7FupNTCEzjM-RVjXA@mail.gmail.com>
	<512540D8.6060702@oracle.com> <512545CA.3010203@oracle.com>
	<CAOphgJDZYFRf01R=Chq_YXcvvt83Sr+j08NTH=VrC1A=MKJKpw@mail.gmail.com>
	<CABKW8RjXY7rAFsot357AM-ribYHS9eejP-2nayauDpm2OHW7YA@mail.gmail.com>
Message-ID: <512578DA.3090501@oracle.com>

The error you see is a transient VM error that we're chasing down, 
meanwhile the tests may pass if you try again.

On 2/20/2013 8:19 PM, Ben Evans wrote:
> Hi C?dric,
>
> I've tried with 6.9-beta. It reduces the amount of memory used
> slightly (but the process still grows to over 2Gb) and the time taken
> somewhat - now down to 8 mins for the ant test target.
>
> However, the ant test-libs target is now dying with a SIGSEGV (hs_err
> files attached) - although this may of course be for unrelated
> reasons.
>
> Thanks,
>
> Ben
>
> On Wed, Feb 20, 2013 at 5:29 PM, C?dric Beust ? <cedric at beust.com> wrote:
>> I provided a beta version in the issue provided by Michael (reproduced
>> below) which gets rid of EmailableReporter. Ben, can you try with this beta
>> version and see if it fixes the problem?
>>
>> Issue: https://github.com/cbeust/testng/issues/219
>> Beta: http://testng.org/beta
>>
>> --
>> C?dric
>>
>>
>> --
>> C?dric
>>
>>
>>
>> On Wed, Feb 20, 2013 at 1:53 PM, Brian Goetz <brian.goetz at oracle.com> wrote:
>>
>>> I think that's likely what's going on -- TestNG buffering lots of
>>> per-test metadata, expanding the heap and causing paging/frequent GCs.
>>>
>>> There's a smaller test suite for the libraries only (ant test-libs) that
>>> we usually run.
>>>
>>> On 2/20/2013 4:32 PM, Jonathan Gibbons wrote:
>>>> My understanding is that TestNG does not scale well with too many test
>>>> cases,
>>>> and folk are just testing stuff "too much" these days :-)
>>>>
>>>> -- Jon
>>>>
>>>> On 02/20/2013 01:27 PM, Ben Evans wrote:
>>>>> OK, following up to my own mail.
>>>>>
>>>>> The tests will actually complete if left for long enough, but the
>>>>> process gets *huge* - at least 2.8G in size, and if other processes
>>>>> are running, it will take a very long time to complete.
>>>>>
>>>>> Does anyone have any insight as to why the tests consume so much memory?
>>>>>
>>>>> Ben
>>>>>
>>>>> On Wed, Feb 20, 2013 at 3:40 PM, Ben Evans
>>>>> <benjamin.john.evans at gmail.com> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I'm writing some docs for AdoptOpenJDK about getting started writing
>>>>>> TestNG tests, in advance of the hackdays at Devoxx UK.
>>>>>>
>>>>>> However, with latest lambda, the TestNG tests appear to hang (output
>>>>>> below). The process grows in size to over 1Gb, and then appears to
>>>>>> freeze. It's still responsive (so I can connect jvisualvm to it, but
>>>>>> when I sample the code, nothing appears to be running).
>>>>>>
>>>>>> This is on Mac 10.7 with OpenJDK 8 from current lambda.
>>>>>>
>>>>>> Any ideas?
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Ben
>>>>>>
>>>>>> ariel:test-ng boxcat$ ant test
>>>>>> Buildfile: /Users/boxcat/projects/lambda/jdk/test-ng/build.xml
>>>>>>
>>>>>> prepare:
>>>>>>
>>>>>> test-compile:
>>>>>>        [javac] /Users/boxcat/projects/lambda/jdk/test-ng/build.xml:78:
>>>>>> warning: 'includeantruntime' was not set, defaulting to
>>>>>> build.sysclasspath=last; set to false for repeatable builds
>>>>>>        [javac] /Users/boxcat/projects/lambda/jdk/test-ng/build.xml:82:
>>>>>> warning: 'includeantruntime' was not set, defaulting to
>>>>>> build.sysclasspath=last; set to false for repeatable builds
>>>>>>        [javac] /Users/boxcat/projects/lambda/jdk/test-ng/build.xml:86:
>>>>>> warning: 'includeantruntime' was not set, defaulting to
>>>>>> build.sysclasspath=last; set to false for repeatable builds
>>>>>>
>>>>>> test:
>>>>>>         [echo] Results at:
>>> file:../../build/test-ng/test-reports/index.html
>>>>>>       [testng] [TestNG] Running:
>>>>>>       [testng]   Ant suite
>>>>>>       [testng]
>>>>>>       [testng]
>>>>>>       [testng] Generating exhaustive interface....
>>>>>>       [testng]       8 No default
>>>>>>       [testng]       8 Error
>>>>>>       [testng]      48 OK
>>>>>>       [testng]      64 Total
>>>>>>       [testng]
>>>>>>       [testng] Generating exhaustive class....
>>>>>>       [testng]     729 No default
>>>>>>       [testng]      49 Error
>>>>>>       [testng]     950 OK
>>>>>>       [testng]    1728 Total
>>>>>>       [testng]
>>>>>>       [testng] Generating shapes interface....
>>>>>>       [testng]     109 No default
>>>>>>       [testng]     280 Error
>>>>>>       [testng]     507 OK
>>>>>>       [testng]     896 Total
>>>>>>       [testng]
>>>>>>       [testng] Generating shapes class/interface....
>>>>>>       [testng]     190 No default
>>>>>>       [testng]     568 Error
>>>>>>       [testng]     536 OK
>>>>>>       [testng]    1294 Total
>>>>>>       [testng]
>>>>>>       [testng] Expect OK:    2041 -- unique 1813
>>>>>>       [testng] Expect Error: 905 -- unique 773
>>>>>>       [testng]
>>>>>>       [testng] Generating exhaustive interface....
>>>>>>       [testng]       8 No default
>>>>>>       [testng]       8 Error
>>>>>>       [testng]      48 OK
>>>>>>       [testng]      64 Total
>>>>>>       [testng]
>>>>>>       [testng] Generating exhaustive class....
>>>>>>       [testng]     729 No default
>>>>>>       [testng]      49 Error
>>>>>>       [testng]     950 OK
>>>>>>       [testng]    1728 Total
>>>>>>       [testng]
>>>>>>       [testng] Generating shapes interface....
>>>>>>       [testng]     109 No default
>>>>>>       [testng]     280 Error
>>>>>>       [testng]     507 OK
>>>>>>       [testng]     896 Total
>>>>>>       [testng]
>>>>>>       [testng] Generating shapes class/interface....
>>>>>>       [testng]     190 No default
>>>>>>       [testng]     568 Error
>>>>>>       [testng]     536 OK
>>>>>>       [testng]    1294 Total
>>>>>>       [testng]
>>>>>>       [testng] Expect OK:    2041 -- unique 1813
>>>>>>       [testng] Expect Error: 905 -- unique 773
>>>>
>>>>
>>>
>>>
>>

From brian.goetz at oracle.com  Wed Feb 20 17:37:54 2013
From: brian.goetz at oracle.com (brian.goetz at oracle.com)
Date: Thu, 21 Feb 2013 01:37:54 +0000
Subject: hg: lambda/lambda/jdk: Javadoc for XxxPipeline
Message-ID: <20130221013817.3E68247C25@hg.openjdk.java.net>

Changeset: 70bc1cf8584a
Author:    briangoetz
Date:      2013-02-20 20:37 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/70bc1cf8584a

Javadoc for XxxPipeline

! src/share/classes/java/util/stream/DoublePipeline.java
! src/share/classes/java/util/stream/IntPipeline.java
! src/share/classes/java/util/stream/LongPipeline.java
! src/share/classes/java/util/stream/ReferencePipeline.java


From cedric at beust.com  Wed Feb 20 18:01:18 2013
From: cedric at beust.com (=?UTF-8?B?Q8OpZHJpYyBCZXVzdCDimZQ=?=)
Date: Wed, 20 Feb 2013 18:01:18 -0800
Subject: TestNG tests appear to hang with latest lambda
In-Reply-To: <CABKW8RjXY7rAFsot357AM-ribYHS9eejP-2nayauDpm2OHW7YA@mail.gmail.com>
References: <CABKW8Rg5+3ZuYXbKMcACB7fUY=6Q7GeXoO5L-gvaZqF3L207_g@mail.gmail.com>
	<CABKW8Rj2eF2+kn_Membu6PWOGUbkg=3Sm7FupNTCEzjM-RVjXA@mail.gmail.com>
	<512540D8.6060702@oracle.com> <512545CA.3010203@oracle.com>
	<CAOphgJDZYFRf01R=Chq_YXcvvt83Sr+j08NTH=VrC1A=MKJKpw@mail.gmail.com>
	<CABKW8RjXY7rAFsot357AM-ribYHS9eejP-2nayauDpm2OHW7YA@mail.gmail.com>
Message-ID: <CAOphgJD+h8fNwrO6WCuD9cWJ7cGmKtEc7FuXg9GLf4hoZa5fcA@mail.gmail.com>

This is definitely not normal, it would be great if you could capture a
memory snap shot.

-- 
C?dric


-- 
C?dric



On Wed, Feb 20, 2013 at 5:19 PM, Ben Evans <benjamin.john.evans at gmail.com>wrote:

> Hi C?dric,
>
> I've tried with 6.9-beta. It reduces the amount of memory used
> slightly (but the process still grows to over 2Gb) and the time taken
> somewhat - now down to 8 mins for the ant test target.
>
> However, the ant test-libs target is now dying with a SIGSEGV (hs_err
> files attached) - although this may of course be for unrelated
> reasons.
>
> Thanks,
>
> Ben
>
> On Wed, Feb 20, 2013 at 5:29 PM, C?dric Beust ? <cedric at beust.com> wrote:
> > I provided a beta version in the issue provided by Michael (reproduced
> > below) which gets rid of EmailableReporter. Ben, can you try with this
> beta
> > version and see if it fixes the problem?
> >
> > Issue: https://github.com/cbeust/testng/issues/219
> > Beta: http://testng.org/beta
> >
> > --
> > C?dric
> >
> >
> > --
> > C?dric
> >
> >
> >
> > On Wed, Feb 20, 2013 at 1:53 PM, Brian Goetz <brian.goetz at oracle.com>
> wrote:
> >
> >> I think that's likely what's going on -- TestNG buffering lots of
> >> per-test metadata, expanding the heap and causing paging/frequent GCs.
> >>
> >> There's a smaller test suite for the libraries only (ant test-libs) that
> >> we usually run.
> >>
> >> On 2/20/2013 4:32 PM, Jonathan Gibbons wrote:
> >> > My understanding is that TestNG does not scale well with too many test
> >> > cases,
> >> > and folk are just testing stuff "too much" these days :-)
> >> >
> >> > -- Jon
> >> >
> >> > On 02/20/2013 01:27 PM, Ben Evans wrote:
> >> >> OK, following up to my own mail.
> >> >>
> >> >> The tests will actually complete if left for long enough, but the
> >> >> process gets *huge* - at least 2.8G in size, and if other processes
> >> >> are running, it will take a very long time to complete.
> >> >>
> >> >> Does anyone have any insight as to why the tests consume so much
> memory?
> >> >>
> >> >> Ben
> >> >>
> >> >> On Wed, Feb 20, 2013 at 3:40 PM, Ben Evans
> >> >> <benjamin.john.evans at gmail.com> wrote:
> >> >>> Hi,
> >> >>>
> >> >>> I'm writing some docs for AdoptOpenJDK about getting started writing
> >> >>> TestNG tests, in advance of the hackdays at Devoxx UK.
> >> >>>
> >> >>> However, with latest lambda, the TestNG tests appear to hang (output
> >> >>> below). The process grows in size to over 1Gb, and then appears to
> >> >>> freeze. It's still responsive (so I can connect jvisualvm to it, but
> >> >>> when I sample the code, nothing appears to be running).
> >> >>>
> >> >>> This is on Mac 10.7 with OpenJDK 8 from current lambda.
> >> >>>
> >> >>> Any ideas?
> >> >>>
> >> >>> Thanks,
> >> >>>
> >> >>> Ben
> >> >>>
> >> >>> ariel:test-ng boxcat$ ant test
> >> >>> Buildfile: /Users/boxcat/projects/lambda/jdk/test-ng/build.xml
> >> >>>
> >> >>> prepare:
> >> >>>
> >> >>> test-compile:
> >> >>>       [javac]
> /Users/boxcat/projects/lambda/jdk/test-ng/build.xml:78:
> >> >>> warning: 'includeantruntime' was not set, defaulting to
> >> >>> build.sysclasspath=last; set to false for repeatable builds
> >> >>>       [javac]
> /Users/boxcat/projects/lambda/jdk/test-ng/build.xml:82:
> >> >>> warning: 'includeantruntime' was not set, defaulting to
> >> >>> build.sysclasspath=last; set to false for repeatable builds
> >> >>>       [javac]
> /Users/boxcat/projects/lambda/jdk/test-ng/build.xml:86:
> >> >>> warning: 'includeantruntime' was not set, defaulting to
> >> >>> build.sysclasspath=last; set to false for repeatable builds
> >> >>>
> >> >>> test:
> >> >>>        [echo] Results at:
> >> file:../../build/test-ng/test-reports/index.html
> >> >>>      [testng] [TestNG] Running:
> >> >>>      [testng]   Ant suite
> >> >>>      [testng]
> >> >>>      [testng]
> >> >>>      [testng] Generating exhaustive interface....
> >> >>>      [testng]       8 No default
> >> >>>      [testng]       8 Error
> >> >>>      [testng]      48 OK
> >> >>>      [testng]      64 Total
> >> >>>      [testng]
> >> >>>      [testng] Generating exhaustive class....
> >> >>>      [testng]     729 No default
> >> >>>      [testng]      49 Error
> >> >>>      [testng]     950 OK
> >> >>>      [testng]    1728 Total
> >> >>>      [testng]
> >> >>>      [testng] Generating shapes interface....
> >> >>>      [testng]     109 No default
> >> >>>      [testng]     280 Error
> >> >>>      [testng]     507 OK
> >> >>>      [testng]     896 Total
> >> >>>      [testng]
> >> >>>      [testng] Generating shapes class/interface....
> >> >>>      [testng]     190 No default
> >> >>>      [testng]     568 Error
> >> >>>      [testng]     536 OK
> >> >>>      [testng]    1294 Total
> >> >>>      [testng]
> >> >>>      [testng] Expect OK:    2041 -- unique 1813
> >> >>>      [testng] Expect Error: 905 -- unique 773
> >> >>>      [testng]
> >> >>>      [testng] Generating exhaustive interface....
> >> >>>      [testng]       8 No default
> >> >>>      [testng]       8 Error
> >> >>>      [testng]      48 OK
> >> >>>      [testng]      64 Total
> >> >>>      [testng]
> >> >>>      [testng] Generating exhaustive class....
> >> >>>      [testng]     729 No default
> >> >>>      [testng]      49 Error
> >> >>>      [testng]     950 OK
> >> >>>      [testng]    1728 Total
> >> >>>      [testng]
> >> >>>      [testng] Generating shapes interface....
> >> >>>      [testng]     109 No default
> >> >>>      [testng]     280 Error
> >> >>>      [testng]     507 OK
> >> >>>      [testng]     896 Total
> >> >>>      [testng]
> >> >>>      [testng] Generating shapes class/interface....
> >> >>>      [testng]     190 No default
> >> >>>      [testng]     568 Error
> >> >>>      [testng]     536 OK
> >> >>>      [testng]    1294 Total
> >> >>>      [testng]
> >> >>>      [testng] Expect OK:    2041 -- unique 1813
> >> >>>      [testng] Expect Error: 905 -- unique 773
> >> >
> >> >
> >>
> >>
> >
>

From cedric at beust.com  Wed Feb 20 18:02:21 2013
From: cedric at beust.com (=?UTF-8?B?Q8OpZHJpYyBCZXVzdCDimZQ=?=)
Date: Wed, 20 Feb 2013 18:02:21 -0800
Subject: TestNG tests appear to hang with latest lambda
In-Reply-To: <CAOphgJD+h8fNwrO6WCuD9cWJ7cGmKtEc7FuXg9GLf4hoZa5fcA@mail.gmail.com>
References: <CABKW8Rg5+3ZuYXbKMcACB7fUY=6Q7GeXoO5L-gvaZqF3L207_g@mail.gmail.com>
	<CABKW8Rj2eF2+kn_Membu6PWOGUbkg=3Sm7FupNTCEzjM-RVjXA@mail.gmail.com>
	<512540D8.6060702@oracle.com> <512545CA.3010203@oracle.com>
	<CAOphgJDZYFRf01R=Chq_YXcvvt83Sr+j08NTH=VrC1A=MKJKpw@mail.gmail.com>
	<CABKW8RjXY7rAFsot357AM-ribYHS9eejP-2nayauDpm2OHW7YA@mail.gmail.com>
	<CAOphgJD+h8fNwrO6WCuD9cWJ7cGmKtEc7FuXg9GLf4hoZa5fcA@mail.gmail.com>
Message-ID: <CAOphgJCUdPQ_yksB_Q7Q6i0Srmex9ker78U2Zr7MjXwfpJzEAQ@mail.gmail.com>

Oh wait, I guess that's what you attached to your message :-)


-- 
C?dric



On Wed, Feb 20, 2013 at 6:01 PM, C?dric Beust ? <cedric at beust.com> wrote:

> This is definitely not normal, it would be great if you could capture a
> memory snap shot.
>
> --
> C?dric
>
>
> --
> C?dric
>
>
>
> On Wed, Feb 20, 2013 at 5:19 PM, Ben Evans <benjamin.john.evans at gmail.com>wrote:
>
>> Hi C?dric,
>>
>> I've tried with 6.9-beta. It reduces the amount of memory used
>> slightly (but the process still grows to over 2Gb) and the time taken
>> somewhat - now down to 8 mins for the ant test target.
>>
>> However, the ant test-libs target is now dying with a SIGSEGV (hs_err
>> files attached) - although this may of course be for unrelated
>> reasons.
>>
>> Thanks,
>>
>> Ben
>>
>> On Wed, Feb 20, 2013 at 5:29 PM, C?dric Beust ? <cedric at beust.com> wrote:
>> > I provided a beta version in the issue provided by Michael (reproduced
>> > below) which gets rid of EmailableReporter. Ben, can you try with this
>> beta
>> > version and see if it fixes the problem?
>> >
>> > Issue: https://github.com/cbeust/testng/issues/219
>> > Beta: http://testng.org/beta
>> >
>> > --
>> > C?dric
>> >
>> >
>> > --
>> > C?dric
>> >
>> >
>> >
>> > On Wed, Feb 20, 2013 at 1:53 PM, Brian Goetz <brian.goetz at oracle.com>
>> wrote:
>> >
>> >> I think that's likely what's going on -- TestNG buffering lots of
>> >> per-test metadata, expanding the heap and causing paging/frequent GCs.
>> >>
>> >> There's a smaller test suite for the libraries only (ant test-libs)
>> that
>> >> we usually run.
>> >>
>> >> On 2/20/2013 4:32 PM, Jonathan Gibbons wrote:
>> >> > My understanding is that TestNG does not scale well with too many
>> test
>> >> > cases,
>> >> > and folk are just testing stuff "too much" these days :-)
>> >> >
>> >> > -- Jon
>> >> >
>> >> > On 02/20/2013 01:27 PM, Ben Evans wrote:
>> >> >> OK, following up to my own mail.
>> >> >>
>> >> >> The tests will actually complete if left for long enough, but the
>> >> >> process gets *huge* - at least 2.8G in size, and if other processes
>> >> >> are running, it will take a very long time to complete.
>> >> >>
>> >> >> Does anyone have any insight as to why the tests consume so much
>> memory?
>> >> >>
>> >> >> Ben
>> >> >>
>> >> >> On Wed, Feb 20, 2013 at 3:40 PM, Ben Evans
>> >> >> <benjamin.john.evans at gmail.com> wrote:
>> >> >>> Hi,
>> >> >>>
>> >> >>> I'm writing some docs for AdoptOpenJDK about getting started
>> writing
>> >> >>> TestNG tests, in advance of the hackdays at Devoxx UK.
>> >> >>>
>> >> >>> However, with latest lambda, the TestNG tests appear to hang
>> (output
>> >> >>> below). The process grows in size to over 1Gb, and then appears to
>> >> >>> freeze. It's still responsive (so I can connect jvisualvm to it,
>> but
>> >> >>> when I sample the code, nothing appears to be running).
>> >> >>>
>> >> >>> This is on Mac 10.7 with OpenJDK 8 from current lambda.
>> >> >>>
>> >> >>> Any ideas?
>> >> >>>
>> >> >>> Thanks,
>> >> >>>
>> >> >>> Ben
>> >> >>>
>> >> >>> ariel:test-ng boxcat$ ant test
>> >> >>> Buildfile: /Users/boxcat/projects/lambda/jdk/test-ng/build.xml
>> >> >>>
>> >> >>> prepare:
>> >> >>>
>> >> >>> test-compile:
>> >> >>>       [javac]
>> /Users/boxcat/projects/lambda/jdk/test-ng/build.xml:78:
>> >> >>> warning: 'includeantruntime' was not set, defaulting to
>> >> >>> build.sysclasspath=last; set to false for repeatable builds
>> >> >>>       [javac]
>> /Users/boxcat/projects/lambda/jdk/test-ng/build.xml:82:
>> >> >>> warning: 'includeantruntime' was not set, defaulting to
>> >> >>> build.sysclasspath=last; set to false for repeatable builds
>> >> >>>       [javac]
>> /Users/boxcat/projects/lambda/jdk/test-ng/build.xml:86:
>> >> >>> warning: 'includeantruntime' was not set, defaulting to
>> >> >>> build.sysclasspath=last; set to false for repeatable builds
>> >> >>>
>> >> >>> test:
>> >> >>>        [echo] Results at:
>> >> file:../../build/test-ng/test-reports/index.html
>> >> >>>      [testng] [TestNG] Running:
>> >> >>>      [testng]   Ant suite
>> >> >>>      [testng]
>> >> >>>      [testng]
>> >> >>>      [testng] Generating exhaustive interface....
>> >> >>>      [testng]       8 No default
>> >> >>>      [testng]       8 Error
>> >> >>>      [testng]      48 OK
>> >> >>>      [testng]      64 Total
>> >> >>>      [testng]
>> >> >>>      [testng] Generating exhaustive class....
>> >> >>>      [testng]     729 No default
>> >> >>>      [testng]      49 Error
>> >> >>>      [testng]     950 OK
>> >> >>>      [testng]    1728 Total
>> >> >>>      [testng]
>> >> >>>      [testng] Generating shapes interface....
>> >> >>>      [testng]     109 No default
>> >> >>>      [testng]     280 Error
>> >> >>>      [testng]     507 OK
>> >> >>>      [testng]     896 Total
>> >> >>>      [testng]
>> >> >>>      [testng] Generating shapes class/interface....
>> >> >>>      [testng]     190 No default
>> >> >>>      [testng]     568 Error
>> >> >>>      [testng]     536 OK
>> >> >>>      [testng]    1294 Total
>> >> >>>      [testng]
>> >> >>>      [testng] Expect OK:    2041 -- unique 1813
>> >> >>>      [testng] Expect Error: 905 -- unique 773
>> >> >>>      [testng]
>> >> >>>      [testng] Generating exhaustive interface....
>> >> >>>      [testng]       8 No default
>> >> >>>      [testng]       8 Error
>> >> >>>      [testng]      48 OK
>> >> >>>      [testng]      64 Total
>> >> >>>      [testng]
>> >> >>>      [testng] Generating exhaustive class....
>> >> >>>      [testng]     729 No default
>> >> >>>      [testng]      49 Error
>> >> >>>      [testng]     950 OK
>> >> >>>      [testng]    1728 Total
>> >> >>>      [testng]
>> >> >>>      [testng] Generating shapes interface....
>> >> >>>      [testng]     109 No default
>> >> >>>      [testng]     280 Error
>> >> >>>      [testng]     507 OK
>> >> >>>      [testng]     896 Total
>> >> >>>      [testng]
>> >> >>>      [testng] Generating shapes class/interface....
>> >> >>>      [testng]     190 No default
>> >> >>>      [testng]     568 Error
>> >> >>>      [testng]     536 OK
>> >> >>>      [testng]    1294 Total
>> >> >>>      [testng]
>> >> >>>      [testng] Expect OK:    2041 -- unique 1813
>> >> >>>      [testng] Expect Error: 905 -- unique 773
>> >> >
>> >> >
>> >>
>> >>
>> >
>>
>
>

From brian.goetz at oracle.com  Wed Feb 20 20:13:44 2013
From: brian.goetz at oracle.com (brian.goetz at oracle.com)
Date: Thu, 21 Feb 2013 04:13:44 +0000
Subject: hg: lambda/lambda/jdk: Javadoc for stateful ops
Message-ID: <20130221041422.7E7E847C2D@hg.openjdk.java.net>

Changeset: 8875666d12a8
Author:    briangoetz
Date:      2013-02-20 23:13 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/8875666d12a8

Javadoc for stateful ops

! src/share/classes/java/util/stream/DistinctOp.java
! src/share/classes/java/util/stream/SliceOp.java
! src/share/classes/java/util/stream/SortedOp.java


From howard.lovatt at gmail.com  Thu Feb 21 01:39:21 2013
From: howard.lovatt at gmail.com (Howard Lovatt)
Date: Thu, 21 Feb 2013 20:39:21 +1100
Subject: [concurrency-interest] Numerical Stream code
In-Reply-To: <511EA508.3080202@oracle.com>
References: <CACR_FB41DwO6HBohqAMYdH3DMnUhS=PoqKZjb0tp-8WWw1qQtQ@mail.gmail.com>
	<511CF6C3.8000709@oracle.com> <511CF876.1000003@oracle.com>
	<511D093D.5010608@gmail.com> <511D1E24.7070700@oracle.com>
	<CAEJX8oozMKoTiE_-rwF_d48cc9ySwK4RUqa8itO2OeFTivHkuQ@mail.gmail.com>
	<7F8A8604-06CA-44A3-A190-1F4C814D2164@gmail.com>
	<511EA508.3080202@oracle.com>
Message-ID: <CACR_FB7TfC7J8ca5H50hPwBSH8Sni5sx47gwt24bzAz8e=2-GQ@mail.gmail.com>

Hi,

I have taken a look at the Numerical Stream Code example previously posted
for the serial case, hence no cross  posting to the concurrency interest
group. I tried a number of different programming styles and the timings are
below and the code at the end:

CLike: time = 2329 ms, result = 99.99581170383331
SerialStream: time = 20441 ms, result = 99.99581170383331
SerialStreamMock: time = 5870 ms, result = 99.99581170383331
SerialStreamManualAverage: time = 18296 ms, result = 99.99581170383331
SerialStreamRange: time = 21775 ms, result = 99.99581170383331
SerialStreamInLine: time = 21775 ms, result = 99.99581170383331
SerialStreamCollect: time = 21754 ms, result = 99.99581170383331

1. CLike is not using streams at all and is the base case
2. SerialStream is using the Stream API in a 'natural' way; 9 times slower
than base
3. SerialStreamMock is using a quick and dirty stream implementation; 3
times slower than base but 3 times quicker than Stream API
4. SerialStreamManualAverage is as SerialStream but instead of calling
average() the calculation from CLike is used; little difference
5. SerialStreamRange uses Streams.intRange instead of Arrays.indices;
little difference
6. SerialStreamInLine inlines the function calls (as suggested by Brian
Goetz); little difference
7. SerialStreamCollect replaces average with a collect call (as suggested
by Brian Goetz); little difference

So I am left with the overhead of the stream API being larger than I
expected; I was expecting more like the overhead of SerialStreamMock, not 3
times worse again. It is probably me doing something wrong so any
suggestions greatly appreciated.

Thanks is advance:

 -- Howard.

=======================================================================

package fdm;

import static java.lang.System.*;
import java.util.Arrays;
import java.util.OptionalDouble;
import java.util.function.BinaryOperator;
import java.util.function.DoubleConsumer;
import java.util.function.IntConsumer;
import java.util.function.IntUnaryOperator;
import java.util.function.ObjDoubleConsumer;
import java.util.function.Supplier;
import java.util.stream.Collector;
import java.util.stream.Streams;

/**
 * Numerical solution to: alpha d^2u/dt^2=du/dt for alpha = 1, u(t,0)=100,
u(t,1)=100, u(0,x)=0, see
 * Hornbeck, "Numerical Methods", section 11.1, pp 283. Apples an
explicit-finite-difference-method
 * kernel as a specific example of applying a kernel. Applying a kernel to
a vector/matrix of data
 * is a common numerical operation.
 *
 * @author Howard Lovatt
 */
public final class FDMSerial {
  // Problem constants
  private static final double alpha = 1;
  private static final double uT0 = 100;
  private static final double uT1 = 100;
  private static final double u0X = 0;
  private static final double maxT = 1;
  private static final double deltaX = 0.001; // <= 1
  private static final double deltaT = 0.75 * deltaX * deltaX / 2 / alpha;
// 0.75 is a typical constant used, must be < 1 and > 0
  private static final double k1 = alpha * deltaT / (deltaX * deltaX); //
Constant in front of deltaT / 2
  private static final double k2 = 1 - 2 * k1; // 1 - constant in front of
deltaT
  private static final int numXs = (int) (1 / deltaX) + 1;
  private static final int numTs = (int) (maxT / deltaT) + 1;

  @FunctionalInterface public interface Kernel1D { double u00(double uM1M1,
double uM10, double uM1P1); }

  private static final Kernel1D explicitFDM = (uM1M1, uM10, uM1P1) -> k1 *
(uM1M1 + uM1P1) + k2 * uM10;

  @FunctionalInterface private interface Style { double solve(); }

  private enum Styles implements Style {
    CLike {
      @Override public double solve() {
        uM1[0] = uT0; // t = 0
        for (int xi = 1; xi < numXs - 1; xi++) { uM1[xi] = u0X; }
        uM1[numXs - 1] = uT1;
        for (int ti = 1; ti < numTs; ti++, uTemp = uM1, uM1 = u0, u0 =
uTemp) { // t > 0
          u0[0] = uT0; // x = 0
          for (int xi = 1; xi < numXs - 1; xi++) { u0[xi] =
explicitFDM.u00(uM1[xi - 1], uM1[xi], uM1[xi + 1]); } // 0 < x < 1
          u0[numXs - 1] = uT1; // x = 1
        }
        double sum = 0; // Calculate average of last us
        for (final double u : uM1) { sum += u; }
        return sum / numXs;
      }
    },

    SerialStream {
      @Override public double solve() {
        Arrays.indices(uM1).forEach(this::t0);
        for (int ti = 1; ti < numTs; ti++, uTemp = uM1, uM1 = u0, u0 =
uTemp) { // t > 0
          Arrays.indices(uM1).forEach(this::tg0);
        }
        return Arrays.stream(uM1).average().getAsDouble(); // Really slow!
      }
    },

    SerialStreamMock {
      @Override public double solve() {
        IntStreamMock.indices(uM1).forEach(this::t0);
        for (int ti = 1; ti < numTs; ti++, uTemp = uM1, uM1 = u0, u0 =
uTemp) { // t > 0
          IntStreamMock.indices(uM1).forEach(this::tg0);
        }
        return Arrays.stream(uM1).average().getAsDouble();
      }
    },

    SerialStreamManualAverage {
      @Override public double solve() {
        Arrays.indices(uM1).forEach(this::t0);
        for (int ti = 1; ti < numTs; ti++, uTemp = uM1, uM1 = u0, u0 =
uTemp) { // t > 0
          Arrays.indices(uM1).forEach(this::tg0);
        }
        double sum = 0;
        for (final double u : uM1) { sum += u; }
        return sum / numXs;
      }
    },

    SerialStreamRange {
      @Override public double solve() {
        Streams.intRange(0, numXs).forEach(this::t0);
        for (int ti = 1; ti < numTs; ti++, uTemp = uM1, uM1 = u0, u0 =
uTemp) { // t > 0
          Streams.intRange(0, numXs).forEach(this::tg0);
        }
        return Arrays.stream(uM1).average().getAsDouble(); // Really slow!
      }
    },

    SerialStreamInLine {
      @Override public double solve() {
        Arrays.indices(uM1).forEach( (xi) -> {
          if (xi == 0) { uM1[0] = uT0; }
          else if (xi == numXs - 1) { uM1[numXs - 1] = uT1; }
          else { uM1[xi] = u0X; }
        } );
        for (int ti = 1; ti < numTs; ti++, uTemp = uM1, uM1 = u0, u0 =
uTemp) { // t > 0
          Arrays.indices(uM1).forEach( (xi) -> {
            if (xi == 0) { u0[0] = uT0; }
            else if (xi == numXs - 1) { u0[numXs - 1] = uT1; }
            else { u0[xi] = explicitFDM.u00(uM1[xi - 1], uM1[xi], uM1[xi +
1]); }
          } );
        }
        return Arrays.stream(uM1).average().getAsDouble(); // Really slow!
      }
    },

    SerialStreamCollect {
      @Override public double solve() {
        Arrays.indices(uM1).forEach(this::t0);
        for (int ti = 1; ti < numTs; ti++, uTemp = uM1, uM1 = u0, u0 =
uTemp) { // t > 0
          Arrays.indices(uM1).forEach(this::tg0);
        }
        final double[] sum = Arrays.stream(uM1).collectUnordered( new
Collector.OfDouble<double[]>() {
          public Supplier<double[]> resultSupplier() { return () -> {
return new double[1]; }; }
          public ObjDoubleConsumer<double[]> doubleAccumulator() { return
(sum, value) -> { sum[0] += value; }; }
          public BinaryOperator<double[]> combiner() { return (sum1, sum2)
-> {
            sum1[0] += sum2[0];
            return sum1;
          }; }
        } ); // Also tried sum, reduce, & collect - all really slow
including collectUnordered
        return sum[0] / numXs;
      }
    };

    double[] u0 = new double[numXs];
    double[] uM1 = new double[numXs];
    double[] uTemp;

    void t0(final int xi) {
      if (xi == 0) { uM1[0] = uT0; }
      else if (xi == numXs - 1) { uM1[numXs - 1] = uT1; }
      else { uM1[xi] = u0X; }
    }

    void tg0(final int xi) {
      if (xi == 0) { u0[0] = uT0; }
      else if (xi == numXs - 1) { u0[numXs - 1] = uT1; }
      else { u0[xi] = explicitFDM.u00(uM1[xi - 1], uM1[xi], uM1[xi + 1]); }
    }
  }

  private static void debug(final int ti, final double[] us) {
out.println(ti + ": " + Arrays.toString(us)); }

  private static void time(final Style s) {
      gc(); // Paranoid precaution
      gc();
      final long start = currentTimeMillis();
      final double result = s.solve();
      final long end = currentTimeMillis();
      out.println(s + ": time = " + (end - start) + " ms, result = " +
result);
    }

  /**
   * Time implementations and then print the time and the result for each.
   *
   * @param notUsed the command line arguments are ignored
   */
  public static void main(final String... notUsed) throws Exception {
//    Arrays.stream(Styles.values()).forEach( (s) -> s.solve() ); // Warm
up - doesn't seem to make any difference!
    Arrays.stream(Styles.values()).forEach(FDMSerial::time);
  }

  /* Stuff for stream mocks. Which I have tried to make representative so
that a half decent
   * comparison with Stream can be made, but to keep the size down I have
only priovided a few
   * methods. The mock steams have one abstract method next(), ontop of
which everything else is
   * built. The JVM kicked up when I tried to use interfaces with default
methods, therefore
   * abstract classes used instead and forgo lambdas :(. */
  private static final class Break extends Exception {
    private static final long serialVersionUID = 201302211810L;
    private Break() {}
  }

  private static final Break BREAK = new Break();

  private static final class Continue extends Exception {
    private static final long serialVersionUID = 201302211820L;
    private Continue() {}
  }

  private static final Continue CONTINUE = new Continue();

  private static abstract class IntStreamMock {
    abstract int next() throws Break, Continue;
    void forEach(final IntConsumer consumer) {
      try {
        for (;;) {
          try { consumer.accept(next()); }
          catch (final Continue c) {}
        }
      }
      catch (final Break e) {}
    }
    IntStreamMock map(final IntUnaryOperator unary) {
      return new IntStreamMock() {
        @Override public int next() throws Break, Continue {
          return unary.applyAsInt(IntStreamMock.this.next());
        }
      };
    }
    // ...
    static IntStreamMock indices(final double[] array) { return
indices(array.length); }
    static IntStreamMock indices(final int size) {
      return new IntStreamMock() {
        int index = 0;
        @Override public int next() throws Break {
          if (index == size) { throw BREAK; }
          return index++;
        }
      };
    }
    // ...
  }

  private static abstract class DoubleStreamMock {
    abstract double next() throws Break, Continue;
    void forEach(final DoubleConsumer consumer) {
      try {
        for (;;) {
          try { consumer.accept(next()); }
          catch (final Continue c) {}
        }
      }
      catch (final Break e) {}
    }
    OptionalDouble average() {
      final long size[] = new long[1];
      size[0] = 0;
      final double[] sum = new double[1];
      sum[0] = 0;
      forEach( (v) -> { sum[0] += v; size[0]++; } );
      if (size[0] == 0) { return OptionalDouble.empty(); }
      return OptionalDouble.of(sum[0] / size[0]);
    }
    // ...
    static DoubleStreamMock stream(final double[] array) {
      return new DoubleStreamMock() {
        final int size = array.length;
        int index = 0;
        @Override public double next() throws Break {
          if (index == size) { throw BREAK; }
          return array[index++];
        }
      };
    }
    // ...
  }
}



On 16 February 2013 08:13, Brian Goetz <brian.goetz at oracle.com> wrote:

> Try computing average as:
>
>   int[] collected = stream.collect(() -> new int[2],
>            (arr, i) -> { arr[0] += i; arr[1]++; }
>            (a1, a2) -> { a1[0] += a2[0]; a1[1] += a2[1] });
>   double avg = (collected[1] == 0)
>              ? 0
>              : (double) collected[0]/collected[1];
>
> since the current implementation of average() is doing way more work than
> you need.
>
>
> On 2/15/2013 3:26 PM, Howard Lovatt wrote:
>
>> Hi,
>>
>> Thanks for all the replies. This is largely a holding email. I am
>> travelling with work and don't have my laptop. When get home I will post
>> some more code.
>>
>> @Jin: I did warm up the code, but I do agree that benchmarks are tricky.
>> As I said I was expecting some overhead but was surprised at how much.
>>
>> @Brian: The reason I factored t0 and tg0 out into methods is that they
>> are common between the serial and parallel versions and I thought the
>> code read better. I don't think it makes any difference, but I will check.
>>
>> @Others: To avoid writing over an old array I will have to allocate each
>> time round the t loop. I will give this a try and see if it helps. The
>> discussion about the parallel problems is interesting, but how come the
>> serial version is so slow? Could a problem with the Stream code in
>> general be the underlying problem with the parallel version?
>>
>> Sent from my iPad
>>
>> On 15/02/2013, at 3:48 AM, Stanimir Simeonoff <stanimir at riflexo.com
>> <mailto:stanimir at riflexo.com>> wrote:
>>
>>
>>>     > Do element sizes matter (byte vs. short vs. int  vs. long)?
>>>
>>>     I don't think so.  All of this assumes that the proper instruction
>>>     is used.  For example, if 2 threads are writing to adjacent bytes,
>>>     then the "mov" instruction has to only write the byte.  If the
>>>     compiler, decides to read 32-bits, mask in the 8-bits and write
>>>     32-bits then the data will be corrupted.
>>>
>>> JLS mandates no corruption for neighbor writes.
>>>
>>>     I believe that HotSpot will only generate the write byte mov
>>>     instruction.
>>>
>>> That would be the correct one. The case affects only
>>> boolean[]/byte[]/short[]/char[**]  as simple primitive fields are always
>>> at least 32bits.
>>>
>>> Stanimir
>>>
>>>
>>>     Nathan Reynolds
>>>     <http://psr.us.oracle.com/**wiki/index.php/User:Nathan_**Reynolds<http://psr.us.oracle.com/wiki/index.php/User:Nathan_Reynolds>>
>>> |
>>>     Architect | 602.333.9091 <tel:602.333.9091>
>>>     Oracle PSR Engineering <http://psr.us.oracle.com/> | Server
>>> Technology
>>>
>>>     On 2/14/2013 8:56 AM, Peter Levart wrote:
>>>
>>>>     On 02/14/2013 03:45 PM, Brian Goetz wrote:
>>>>
>>>>>     The parallel version is almost certainly suffering false cache
>>>>>>     line
>>>>>>     sharing when adjacent tasks are writing to the shared arrays
>>>>>>     u0, etc.
>>>>>>     Nothing to do with streams, just a standard parallelism gotcha.
>>>>>>
>>>>>     Cure: don't write to shared arrays from parallel tasks.
>>>>>
>>>>>
>>>>>      Hi,
>>>>
>>>>     I would like to discuss this a little bit (hence the cc:
>>>>     concurrency-interest - the conversation can continue on this list
>>>>     only).
>>>>
>>>>     Is it really important to avoid writing to shared arrays from
>>>>     multiple threads (of course without synchronization, not even
>>>>     volatile writes/reads) when indexes are not shared (each thread
>>>>     writes/reads it's own disjunct subset).
>>>>
>>>>     Do element sizes matter (byte vs. short vs. int  vs. long)?
>>>>
>>>>     I had a (false?) feeling that cache lines are not invalidated
>>>>     when writes are performed without fences.
>>>>
>>>>     Also I don't know how short (byte, char) writes are combined into
>>>>     memory words on the hardware when they come from different cores
>>>>     and whether this is connected to any performance issues.
>>>>
>>>>     Thanks,
>>>>
>>>>     Peter
>>>>
>>>>     ______________________________**_________________
>>>>     Concurrency-interest mailing list
>>>>     Concurrency-interest at cs.**oswego.edu<Concurrency-interest at cs.oswego.edu>
>>>>     <mailto:Concurrency-interest@**cs.oswego.edu<Concurrency-interest at cs.oswego.edu>
>>>> >
>>>>     http://cs.oswego.edu/mailman/**listinfo/concurrency-interest<http://cs.oswego.edu/mailman/listinfo/concurrency-interest>
>>>>
>>>
>>>
>>>     ______________________________**_________________
>>>     Concurrency-interest mailing list
>>>     Concurrency-interest at cs.**oswego.edu<Concurrency-interest at cs.oswego.edu>
>>>     <mailto:Concurrency-interest@**cs.oswego.edu<Concurrency-interest at cs.oswego.edu>
>>> >
>>>
>>>     http://cs.oswego.edu/mailman/**listinfo/concurrency-interest<http://cs.oswego.edu/mailman/listinfo/concurrency-interest>
>>>
>>>
>>> ______________________________**_________________
>>> Concurrency-interest mailing list
>>> Concurrency-interest at cs.**oswego.edu<Concurrency-interest at cs.oswego.edu>
>>> <mailto:Concurrency-interest@**cs.oswego.edu<Concurrency-interest at cs.oswego.edu>
>>> >
>>> http://cs.oswego.edu/mailman/**listinfo/concurrency-interest<http://cs.oswego.edu/mailman/listinfo/concurrency-interest>
>>>
>>


-- 
  -- Howard.

From georgiy.rakov at oracle.com  Thu Feb 21 02:08:37 2013
From: georgiy.rakov at oracle.com (Georgiy Rakov)
Date: Thu, 21 Feb 2013 14:08:37 +0400
Subject: peek().iterator().hasNext() pre-consumes elements?
In-Reply-To: <5124FBF5.60802@oracle.com>
References: <511A8193.2080402@oracle.com> <511A86F9.6010609@oracle.com>
	<511A916D.3080005@univ-mlv.fr> <5124E58B.9040202@oracle.com>
	<5124FBF5.60802@oracle.com>
Message-ID: <5125F225.5020500@oracle.com>

Could you please provide some more information regarding following part 
of this spec:

      * Produce a {@code Stream} containing the elements of this stream, 
and also provide elements
      * to the specified {@link Consumer} as elements are consumed from 
the /_*resulting stream*_/.  This is


What is "*resulting stream*" - stream returned by peek() or the stream 
the peek() is applied to, i.e. considering following code - s1 or s2?

    Stream s1;
    ...
    Stream s2 = s1.peek();

Thanks,
Georgiy.

On 20.02.2013 20:38, Brian Goetz wrote:
> Here's the current spec for this method -- does this help?
>
>     /**
>      * Produce a {@code Stream} containing the elements of this 
> stream, and also provide elements
>      * to the specified {@link Consumer} as elements are consumed from 
> the resulting stream.  This is
>      * an <a href="package-summary.html#StreamOps">intermediate 
> operation</a>.
>      * {@apiNote}
>      * This method exists mainly to support debugging, where you want 
> to see the elements as they flow past a certain
>      * point in a pipeline:
>      * <pre>
>      *     list.stream()
>      *         .filter(filteringFunction)
>      *         .peek(e -> {System.out.println("Filtered value: " + e); 
> });
>      *         .map(mappingFunction)
>      *         .peek(e -> {System.out.println("Mapped value: " + e); });
>      *         .collect(Collectors.intoList());
>      * </pre>
>      *
>      * <p>For parallel stream pipelines, the {@code Consumer} may be 
> called at whatever time and in whatever thread
>      * the element is made available by the upstream operation. If the 
> {@code Consumer} modifies shared state,
>      * it is responsible for providing the required synchronization.
>      *
>      * @param consumer The {@code Consumer} to receive the elements
>      */
>
>
>
> On 2/20/2013 10:02 AM, Georgiy Rakov wrote:
>> Hello again,
>>
>> it has just come into my mind that it could be quite more major issue
>> than I wrote in my previous letter.
>>
>> So the case a bit rewritten:
>>
>>     Stream s1 = Arrays.asList(1, 2, 3).stream();
>>     Stream s2 = s1.peek(System.err::println);
>>     s2.iterator().hasNext();
>>
>>
>> The spec says:
>>
>>     Produce a Stream containing the elements of this stream, and also
>>     provide elements to the specified Consumer as elements are *passed
>>     through*.
>>
>> So the core question is what does "passed through" mean?From the first
>> glance I would say it means *consuming elements from **stream returned
>> ****by peek()* (not from stream which peek() is applied to). If this
>> interpretation is right then I could suppose it's a bug because the
>> element from s2 has not been consumed yet (next() is not called just
>> hasNext() has been called).
>>
>> Could you please confirm if such reasoning is right and it's really a 
>> bug.
>>
>> Thanks, Georgiy.
>>
>> On 12.02.2013 23:01, Remi Forax wrote:
>>> On 02/12/2013 07:16 PM, Brian Goetz wrote:
>>>> The answer here is complicated, but in general, calling hasNext may 
>>>> well
>>>> require consuming an element -- there's often no way to know whether a
>>>> source would produce an element without asking it to do so. So it is a
>>>> common practice in implementing iterators to do this (one of many
>>>> reasons why we did not build Streams on Iterator.)
>>>>
>>>> Because the elements are coming from an array, it might be possible to
>>>> know simply based on how many elements have gone by that the stream is
>>>> not yet exhausted.  But in the general case (such as when the stream
>>>> source is an IO channel), it is not possible to know without actually
>>>> consuming and buffering some input.  So I would put this in the 
>>>> category
>>>> of "acceptable" behavior.  We might someday do some work to take
>>>> advantage of the fact that the source has the SIZED characteristic and
>>>> the pipeline stages are size-preserving to make this case behave
>>>> "better", but that would be an implementation quality issue, not a 
>>>> spec
>>>> issue.  The behavior you observe is allowable by the spec.
>>> while I a stream may have to do some buffering, peek should always be
>>> transparent and an iterator on an array doesn't need any buffering 
>>> but I
>>> agree that this is an implementation issue.
>>>
>>> R?mi
>>>
>>>> On 2/12/2013 12:53 PM, Dmitry Bessonov wrote:
>>>>> Hello,
>>>>>
>>>>> The following line prints out the first element, "1"
>>>>>
>>>>>       Arrays.asList(1, 2,
>>>>> 3).stream().peek(System.err::println).iterator().hasNext()
>>>>>
>>>>> Is it really an expected behavior?
>>>>>
>>>>> -Dmitry
>>>>>
>>>>>
>>>>>
>>>
>>


From benjamin.john.evans at gmail.com  Thu Feb 21 05:09:38 2013
From: benjamin.john.evans at gmail.com (Ben Evans)
Date: Thu, 21 Feb 2013 08:09:38 -0500
Subject: TestNG tests appear to hang with latest lambda
In-Reply-To: <512578DA.3090501@oracle.com>
References: <CABKW8Rg5+3ZuYXbKMcACB7fUY=6Q7GeXoO5L-gvaZqF3L207_g@mail.gmail.com>
	<CABKW8Rj2eF2+kn_Membu6PWOGUbkg=3Sm7FupNTCEzjM-RVjXA@mail.gmail.com>
	<512540D8.6060702@oracle.com> <512545CA.3010203@oracle.com>
	<CAOphgJDZYFRf01R=Chq_YXcvvt83Sr+j08NTH=VrC1A=MKJKpw@mail.gmail.com>
	<CABKW8RjXY7rAFsot357AM-ribYHS9eejP-2nayauDpm2OHW7YA@mail.gmail.com>
	<512578DA.3090501@oracle.com>
Message-ID: <CABKW8RjbpouH=Ph13h-em3xKvsZYUdLSVz4t+vr00QYw3m-+Cw@mail.gmail.com>

Tried again, tests pass about 1/3 (others SIGSEGV) - but without
appreciable speedup for  ant test-libs.

Ben
On 20 Feb 2013 20:31, "Brian Goetz" <brian.goetz at oracle.com> wrote:

> The error you see is a transient VM error that we're chasing down,
> meanwhile the tests may pass if you try again.
>
> On 2/20/2013 8:19 PM, Ben Evans wrote:
>
>> Hi C?dric,
>>
>> I've tried with 6.9-beta. It reduces the amount of memory used
>> slightly (but the process still grows to over 2Gb) and the time taken
>> somewhat - now down to 8 mins for the ant test target.
>>
>> However, the ant test-libs target is now dying with a SIGSEGV (hs_err
>> files attached) - although this may of course be for unrelated
>> reasons.
>>
>> Thanks,
>>
>> Ben
>>
>> On Wed, Feb 20, 2013 at 5:29 PM, C?dric Beust ? <cedric at beust.com> wrote:
>>
>>> I provided a beta version in the issue provided by Michael (reproduced
>>> below) which gets rid of EmailableReporter. Ben, can you try with this
>>> beta
>>> version and see if it fixes the problem?
>>>
>>> Issue: https://github.com/cbeust/**testng/issues/219<https://github.com/cbeust/testng/issues/219>
>>> Beta: http://testng.org/beta
>>>
>>> --
>>> C?dric
>>>
>>>
>>> --
>>> C?dric
>>>
>>>
>>>
>>> On Wed, Feb 20, 2013 at 1:53 PM, Brian Goetz <brian.goetz at oracle.com>
>>> wrote:
>>>
>>>  I think that's likely what's going on -- TestNG buffering lots of
>>>> per-test metadata, expanding the heap and causing paging/frequent GCs.
>>>>
>>>> There's a smaller test suite for the libraries only (ant test-libs) that
>>>> we usually run.
>>>>
>>>> On 2/20/2013 4:32 PM, Jonathan Gibbons wrote:
>>>>
>>>>> My understanding is that TestNG does not scale well with too many test
>>>>> cases,
>>>>> and folk are just testing stuff "too much" these days :-)
>>>>>
>>>>> -- Jon
>>>>>
>>>>> On 02/20/2013 01:27 PM, Ben Evans wrote:
>>>>>
>>>>>> OK, following up to my own mail.
>>>>>>
>>>>>> The tests will actually complete if left for long enough, but the
>>>>>> process gets *huge* - at least 2.8G in size, and if other processes
>>>>>> are running, it will take a very long time to complete.
>>>>>>
>>>>>> Does anyone have any insight as to why the tests consume so much
>>>>>> memory?
>>>>>>
>>>>>> Ben
>>>>>>
>>>>>> On Wed, Feb 20, 2013 at 3:40 PM, Ben Evans
>>>>>> <benjamin.john.evans at gmail.com**> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I'm writing some docs for AdoptOpenJDK about getting started writing
>>>>>>> TestNG tests, in advance of the hackdays at Devoxx UK.
>>>>>>>
>>>>>>> However, with latest lambda, the TestNG tests appear to hang (output
>>>>>>> below). The process grows in size to over 1Gb, and then appears to
>>>>>>> freeze. It's still responsive (so I can connect jvisualvm to it, but
>>>>>>> when I sample the code, nothing appears to be running).
>>>>>>>
>>>>>>> This is on Mac 10.7 with OpenJDK 8 from current lambda.
>>>>>>>
>>>>>>> Any ideas?
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Ben
>>>>>>>
>>>>>>> ariel:test-ng boxcat$ ant test
>>>>>>> Buildfile: /Users/boxcat/projects/lambda/**jdk/test-ng/build.xml
>>>>>>>
>>>>>>> prepare:
>>>>>>>
>>>>>>> test-compile:
>>>>>>>        [javac] /Users/boxcat/projects/lambda/**
>>>>>>> jdk/test-ng/build.xml:78:
>>>>>>> warning: 'includeantruntime' was not set, defaulting to
>>>>>>> build.sysclasspath=last; set to false for repeatable builds
>>>>>>>        [javac] /Users/boxcat/projects/lambda/**
>>>>>>> jdk/test-ng/build.xml:82:
>>>>>>> warning: 'includeantruntime' was not set, defaulting to
>>>>>>> build.sysclasspath=last; set to false for repeatable builds
>>>>>>>        [javac] /Users/boxcat/projects/lambda/**
>>>>>>> jdk/test-ng/build.xml:86:
>>>>>>> warning: 'includeantruntime' was not set, defaulting to
>>>>>>> build.sysclasspath=last; set to false for repeatable builds
>>>>>>>
>>>>>>> test:
>>>>>>>         [echo] Results at:
>>>>>>>
>>>>>> file:../../build/test-ng/test-**reports/index.html
>>>>
>>>>>       [testng] [TestNG] Running:
>>>>>>>       [testng]   Ant suite
>>>>>>>       [testng]
>>>>>>>       [testng]
>>>>>>>       [testng] Generating exhaustive interface....
>>>>>>>       [testng]       8 No default
>>>>>>>       [testng]       8 Error
>>>>>>>       [testng]      48 OK
>>>>>>>       [testng]      64 Total
>>>>>>>       [testng]
>>>>>>>       [testng] Generating exhaustive class....
>>>>>>>       [testng]     729 No default
>>>>>>>       [testng]      49 Error
>>>>>>>       [testng]     950 OK
>>>>>>>       [testng]    1728 Total
>>>>>>>       [testng]
>>>>>>>       [testng] Generating shapes interface....
>>>>>>>       [testng]     109 No default
>>>>>>>       [testng]     280 Error
>>>>>>>       [testng]     507 OK
>>>>>>>       [testng]     896 Total
>>>>>>>       [testng]
>>>>>>>       [testng] Generating shapes class/interface....
>>>>>>>       [testng]     190 No default
>>>>>>>       [testng]     568 Error
>>>>>>>       [testng]     536 OK
>>>>>>>       [testng]    1294 Total
>>>>>>>       [testng]
>>>>>>>       [testng] Expect OK:    2041 -- unique 1813
>>>>>>>       [testng] Expect Error: 905 -- unique 773
>>>>>>>       [testng]
>>>>>>>       [testng] Generating exhaustive interface....
>>>>>>>       [testng]       8 No default
>>>>>>>       [testng]       8 Error
>>>>>>>       [testng]      48 OK
>>>>>>>       [testng]      64 Total
>>>>>>>       [testng]
>>>>>>>       [testng] Generating exhaustive class....
>>>>>>>       [testng]     729 No default
>>>>>>>       [testng]      49 Error
>>>>>>>       [testng]     950 OK
>>>>>>>       [testng]    1728 Total
>>>>>>>       [testng]
>>>>>>>       [testng] Generating shapes interface....
>>>>>>>       [testng]     109 No default
>>>>>>>       [testng]     280 Error
>>>>>>>       [testng]     507 OK
>>>>>>>       [testng]     896 Total
>>>>>>>       [testng]
>>>>>>>       [testng] Generating shapes class/interface....
>>>>>>>       [testng]     190 No default
>>>>>>>       [testng]     568 Error
>>>>>>>       [testng]     536 OK
>>>>>>>       [testng]    1294 Total
>>>>>>>       [testng]
>>>>>>>       [testng] Expect OK:    2041 -- unique 1813
>>>>>>>       [testng] Expect Error: 905 -- unique 773
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>

From scolebourne at joda.org  Thu Feb 21 05:13:55 2013
From: scolebourne at joda.org (Stephen Colebourne)
Date: Thu, 21 Feb 2013 13:13:55 +0000
Subject: TestNG tests appear to hang with latest lambda
In-Reply-To: <CABKW8RjbpouH=Ph13h-em3xKvsZYUdLSVz4t+vr00QYw3m-+Cw@mail.gmail.com>
References: <CABKW8Rg5+3ZuYXbKMcACB7fUY=6Q7GeXoO5L-gvaZqF3L207_g@mail.gmail.com>
	<CABKW8Rj2eF2+kn_Membu6PWOGUbkg=3Sm7FupNTCEzjM-RVjXA@mail.gmail.com>
	<512540D8.6060702@oracle.com> <512545CA.3010203@oracle.com>
	<CAOphgJDZYFRf01R=Chq_YXcvvt83Sr+j08NTH=VrC1A=MKJKpw@mail.gmail.com>
	<CABKW8RjXY7rAFsot357AM-ribYHS9eejP-2nayauDpm2OHW7YA@mail.gmail.com>
	<512578DA.3090501@oracle.com>
	<CABKW8RjbpouH=Ph13h-em3xKvsZYUdLSVz4t+vr00QYw3m-+Cw@mail.gmail.com>
Message-ID: <CACzrW9AWCt7g7=Dr56VnRO0WvhC0eToVxf2CsVw+R-6F70sgeQ@mail.gmail.com>

In order to get the testng tests on JSR-310 to complete in any
reasonable time, I had to make the testng output directory excluded in
the virus checker.
Stephen


On 21 February 2013 13:09, Ben Evans <benjamin.john.evans at gmail.com> wrote:
> Tried again, tests pass about 1/3 (others SIGSEGV) - but without
> appreciable speedup for  ant test-libs.
>
> Ben
> On 20 Feb 2013 20:31, "Brian Goetz" <brian.goetz at oracle.com> wrote:
>
>> The error you see is a transient VM error that we're chasing down,
>> meanwhile the tests may pass if you try again.
>>
>> On 2/20/2013 8:19 PM, Ben Evans wrote:
>>
>>> Hi C?dric,
>>>
>>> I've tried with 6.9-beta. It reduces the amount of memory used
>>> slightly (but the process still grows to over 2Gb) and the time taken
>>> somewhat - now down to 8 mins for the ant test target.
>>>
>>> However, the ant test-libs target is now dying with a SIGSEGV (hs_err
>>> files attached) - although this may of course be for unrelated
>>> reasons.
>>>
>>> Thanks,
>>>
>>> Ben
>>>
>>> On Wed, Feb 20, 2013 at 5:29 PM, C?dric Beust ? <cedric at beust.com> wrote:
>>>
>>>> I provided a beta version in the issue provided by Michael (reproduced
>>>> below) which gets rid of EmailableReporter. Ben, can you try with this
>>>> beta
>>>> version and see if it fixes the problem?
>>>>
>>>> Issue: https://github.com/cbeust/**testng/issues/219<https://github.com/cbeust/testng/issues/219>
>>>> Beta: http://testng.org/beta
>>>>
>>>> --
>>>> C?dric
>>>>
>>>>
>>>> --
>>>> C?dric
>>>>
>>>>
>>>>
>>>> On Wed, Feb 20, 2013 at 1:53 PM, Brian Goetz <brian.goetz at oracle.com>
>>>> wrote:
>>>>
>>>>  I think that's likely what's going on -- TestNG buffering lots of
>>>>> per-test metadata, expanding the heap and causing paging/frequent GCs.
>>>>>
>>>>> There's a smaller test suite for the libraries only (ant test-libs) that
>>>>> we usually run.
>>>>>
>>>>> On 2/20/2013 4:32 PM, Jonathan Gibbons wrote:
>>>>>
>>>>>> My understanding is that TestNG does not scale well with too many test
>>>>>> cases,
>>>>>> and folk are just testing stuff "too much" these days :-)
>>>>>>
>>>>>> -- Jon
>>>>>>
>>>>>> On 02/20/2013 01:27 PM, Ben Evans wrote:
>>>>>>
>>>>>>> OK, following up to my own mail.
>>>>>>>
>>>>>>> The tests will actually complete if left for long enough, but the
>>>>>>> process gets *huge* - at least 2.8G in size, and if other processes
>>>>>>> are running, it will take a very long time to complete.
>>>>>>>
>>>>>>> Does anyone have any insight as to why the tests consume so much
>>>>>>> memory?
>>>>>>>
>>>>>>> Ben
>>>>>>>
>>>>>>> On Wed, Feb 20, 2013 at 3:40 PM, Ben Evans
>>>>>>> <benjamin.john.evans at gmail.com**> wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I'm writing some docs for AdoptOpenJDK about getting started writing
>>>>>>>> TestNG tests, in advance of the hackdays at Devoxx UK.
>>>>>>>>
>>>>>>>> However, with latest lambda, the TestNG tests appear to hang (output
>>>>>>>> below). The process grows in size to over 1Gb, and then appears to
>>>>>>>> freeze. It's still responsive (so I can connect jvisualvm to it, but
>>>>>>>> when I sample the code, nothing appears to be running).
>>>>>>>>
>>>>>>>> This is on Mac 10.7 with OpenJDK 8 from current lambda.
>>>>>>>>
>>>>>>>> Any ideas?
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> Ben
>>>>>>>>
>>>>>>>> ariel:test-ng boxcat$ ant test
>>>>>>>> Buildfile: /Users/boxcat/projects/lambda/**jdk/test-ng/build.xml
>>>>>>>>
>>>>>>>> prepare:
>>>>>>>>
>>>>>>>> test-compile:
>>>>>>>>        [javac] /Users/boxcat/projects/lambda/**
>>>>>>>> jdk/test-ng/build.xml:78:
>>>>>>>> warning: 'includeantruntime' was not set, defaulting to
>>>>>>>> build.sysclasspath=last; set to false for repeatable builds
>>>>>>>>        [javac] /Users/boxcat/projects/lambda/**
>>>>>>>> jdk/test-ng/build.xml:82:
>>>>>>>> warning: 'includeantruntime' was not set, defaulting to
>>>>>>>> build.sysclasspath=last; set to false for repeatable builds
>>>>>>>>        [javac] /Users/boxcat/projects/lambda/**
>>>>>>>> jdk/test-ng/build.xml:86:
>>>>>>>> warning: 'includeantruntime' was not set, defaulting to
>>>>>>>> build.sysclasspath=last; set to false for repeatable builds
>>>>>>>>
>>>>>>>> test:
>>>>>>>>         [echo] Results at:
>>>>>>>>
>>>>>>> file:../../build/test-ng/test-**reports/index.html
>>>>>
>>>>>>       [testng] [TestNG] Running:
>>>>>>>>       [testng]   Ant suite
>>>>>>>>       [testng]
>>>>>>>>       [testng]
>>>>>>>>       [testng] Generating exhaustive interface....
>>>>>>>>       [testng]       8 No default
>>>>>>>>       [testng]       8 Error
>>>>>>>>       [testng]      48 OK
>>>>>>>>       [testng]      64 Total
>>>>>>>>       [testng]
>>>>>>>>       [testng] Generating exhaustive class....
>>>>>>>>       [testng]     729 No default
>>>>>>>>       [testng]      49 Error
>>>>>>>>       [testng]     950 OK
>>>>>>>>       [testng]    1728 Total
>>>>>>>>       [testng]
>>>>>>>>       [testng] Generating shapes interface....
>>>>>>>>       [testng]     109 No default
>>>>>>>>       [testng]     280 Error
>>>>>>>>       [testng]     507 OK
>>>>>>>>       [testng]     896 Total
>>>>>>>>       [testng]
>>>>>>>>       [testng] Generating shapes class/interface....
>>>>>>>>       [testng]     190 No default
>>>>>>>>       [testng]     568 Error
>>>>>>>>       [testng]     536 OK
>>>>>>>>       [testng]    1294 Total
>>>>>>>>       [testng]
>>>>>>>>       [testng] Expect OK:    2041 -- unique 1813
>>>>>>>>       [testng] Expect Error: 905 -- unique 773
>>>>>>>>       [testng]
>>>>>>>>       [testng] Generating exhaustive interface....
>>>>>>>>       [testng]       8 No default
>>>>>>>>       [testng]       8 Error
>>>>>>>>       [testng]      48 OK
>>>>>>>>       [testng]      64 Total
>>>>>>>>       [testng]
>>>>>>>>       [testng] Generating exhaustive class....
>>>>>>>>       [testng]     729 No default
>>>>>>>>       [testng]      49 Error
>>>>>>>>       [testng]     950 OK
>>>>>>>>       [testng]    1728 Total
>>>>>>>>       [testng]
>>>>>>>>       [testng] Generating shapes interface....
>>>>>>>>       [testng]     109 No default
>>>>>>>>       [testng]     280 Error
>>>>>>>>       [testng]     507 OK
>>>>>>>>       [testng]     896 Total
>>>>>>>>       [testng]
>>>>>>>>       [testng] Generating shapes class/interface....
>>>>>>>>       [testng]     190 No default
>>>>>>>>       [testng]     568 Error
>>>>>>>>       [testng]     536 OK
>>>>>>>>       [testng]    1294 Total
>>>>>>>>       [testng]
>>>>>>>>       [testng] Expect OK:    2041 -- unique 1813
>>>>>>>>       [testng] Expect Error: 905 -- unique 773
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>

From brian.goetz at oracle.com  Thu Feb 21 07:57:16 2013
From: brian.goetz at oracle.com (Brian Goetz)
Date: Thu, 21 Feb 2013 10:57:16 -0500
Subject: peek().iterator().hasNext() pre-consumes elements?
In-Reply-To: <5125F225.5020500@oracle.com>
References: <511A8193.2080402@oracle.com> <511A86F9.6010609@oracle.com>
	<511A916D.3080005@univ-mlv.fr> <5124E58B.9040202@oracle.com>
	<5124FBF5.60802@oracle.com> <5125F225.5020500@oracle.com>
Message-ID: <512643DC.2070706@oracle.com>

It is s2.

Once you do s2 = s1.peek(), s1 is "used up" and all access to the stream 
data is through s2.

On 2/21/2013 5:08 AM, Georgiy Rakov wrote:
> Could you please provide some more information regarding following part
> of this spec:
>
>       * Produce a {@code Stream} containing the elements of this stream,
> and also provide elements
>       * to the specified {@link Consumer} as elements are consumed from
> the /_*resulting stream*_/.  This is
>
>
> What is "*resulting stream*" - stream returned by peek() or the stream
> the peek() is applied to, i.e. considering following code - s1 or s2?
>
>     Stream s1;
>     ...
>     Stream s2 = s1.peek();
>
> Thanks,
> Georgiy.
>
> On 20.02.2013 20:38, Brian Goetz wrote:
>> Here's the current spec for this method -- does this help?
>>
>>     /**
>>      * Produce a {@code Stream} containing the elements of this
>> stream, and also provide elements
>>      * to the specified {@link Consumer} as elements are consumed from
>> the resulting stream.  This is
>>      * an <a href="package-summary.html#StreamOps">intermediate
>> operation</a>.
>>      * {@apiNote}
>>      * This method exists mainly to support debugging, where you want
>> to see the elements as they flow past a certain
>>      * point in a pipeline:
>>      * <pre>
>>      *     list.stream()
>>      *         .filter(filteringFunction)
>>      *         .peek(e -> {System.out.println("Filtered value: " + e);
>> });
>>      *         .map(mappingFunction)
>>      *         .peek(e -> {System.out.println("Mapped value: " + e); });
>>      *         .collect(Collectors.intoList());
>>      * </pre>
>>      *
>>      * <p>For parallel stream pipelines, the {@code Consumer} may be
>> called at whatever time and in whatever thread
>>      * the element is made available by the upstream operation. If the
>> {@code Consumer} modifies shared state,
>>      * it is responsible for providing the required synchronization.
>>      *
>>      * @param consumer The {@code Consumer} to receive the elements
>>      */
>>
>>
>>
>> On 2/20/2013 10:02 AM, Georgiy Rakov wrote:
>>> Hello again,
>>>
>>> it has just come into my mind that it could be quite more major issue
>>> than I wrote in my previous letter.
>>>
>>> So the case a bit rewritten:
>>>
>>>     Stream s1 = Arrays.asList(1, 2, 3).stream();
>>>     Stream s2 = s1.peek(System.err::println);
>>>     s2.iterator().hasNext();
>>>
>>>
>>> The spec says:
>>>
>>>     Produce a Stream containing the elements of this stream, and also
>>>     provide elements to the specified Consumer as elements are *passed
>>>     through*.
>>>
>>> So the core question is what does "passed through" mean?From the first
>>> glance I would say it means *consuming elements from **stream returned
>>> ****by peek()* (not from stream which peek() is applied to). If this
>>> interpretation is right then I could suppose it's a bug because the
>>> element from s2 has not been consumed yet (next() is not called just
>>> hasNext() has been called).
>>>
>>> Could you please confirm if such reasoning is right and it's really a
>>> bug.
>>>
>>> Thanks, Georgiy.
>>>
>>> On 12.02.2013 23:01, Remi Forax wrote:
>>>> On 02/12/2013 07:16 PM, Brian Goetz wrote:
>>>>> The answer here is complicated, but in general, calling hasNext may
>>>>> well
>>>>> require consuming an element -- there's often no way to know whether a
>>>>> source would produce an element without asking it to do so. So it is a
>>>>> common practice in implementing iterators to do this (one of many
>>>>> reasons why we did not build Streams on Iterator.)
>>>>>
>>>>> Because the elements are coming from an array, it might be possible to
>>>>> know simply based on how many elements have gone by that the stream is
>>>>> not yet exhausted.  But in the general case (such as when the stream
>>>>> source is an IO channel), it is not possible to know without actually
>>>>> consuming and buffering some input.  So I would put this in the
>>>>> category
>>>>> of "acceptable" behavior.  We might someday do some work to take
>>>>> advantage of the fact that the source has the SIZED characteristic and
>>>>> the pipeline stages are size-preserving to make this case behave
>>>>> "better", but that would be an implementation quality issue, not a
>>>>> spec
>>>>> issue.  The behavior you observe is allowable by the spec.
>>>> while I a stream may have to do some buffering, peek should always be
>>>> transparent and an iterator on an array doesn't need any buffering
>>>> but I
>>>> agree that this is an implementation issue.
>>>>
>>>> R?mi
>>>>
>>>>> On 2/12/2013 12:53 PM, Dmitry Bessonov wrote:
>>>>>> Hello,
>>>>>>
>>>>>> The following line prints out the first element, "1"
>>>>>>
>>>>>>       Arrays.asList(1, 2,
>>>>>> 3).stream().peek(System.err::println).iterator().hasNext()
>>>>>>
>>>>>> Is it really an expected behavior?
>>>>>>
>>>>>> -Dmitry
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>
>

From georgiy.rakov at oracle.com  Thu Feb 21 10:28:34 2013
From: georgiy.rakov at oracle.com (Georgiy Rakov)
Date: Thu, 21 Feb 2013 22:28:34 +0400
Subject: peek().iterator().hasNext() pre-consumes elements?
In-Reply-To: <512643DC.2070706@oracle.com>
References: <511A8193.2080402@oracle.com> <511A86F9.6010609@oracle.com>
	<511A916D.3080005@univ-mlv.fr> <5124E58B.9040202@oracle.com>
	<5124FBF5.60802@oracle.com> <5125F225.5020500@oracle.com>
	<512643DC.2070706@oracle.com>
Message-ID: <51266752.9020703@oracle.com>

If it's s2 then two following questions arise:

1. The behavior originally described by Dmitry, i. e. when following 
code prints 1, could be considered to be faulty because calling 
hasNext() doesn't mean /consuming/ I believe.

       Arrays.asList(1, 2, 
3).stream().peek(System.err::println).iterator().hasNext()

Please confirm if this is right and going to be fixed.

2. Regarding following part of spec (say *part A*):

    * <p>For parallel stream pipelines, the {@code Consumer} may be
    called at whatever time and in whatever thread
    * the element is made available by the /_*upstream operation*_/. If
    the {@code Consumer} modifies shared state,

If I hasn't got mixed up in the terminology /_*upstream operation*_/ 
means s1. So it looks like a contradiction with the first part of spec 
(say *part B*):

    * Produce a {@code Stream} containing the elements of this stream,
    and also provide elements
    * to the specified {@link Consumer} as elements are consumed from
    the /_*resulting stream*_/.  This is

because in accordance with *part A* consumer is called when the *element 
is made available by /_s1_/*/__/while in accordance with *part B* the 
consumer is called when *the element is consumed from /_s2_/*.
If it's really the case then such a big difference between behavior of 
parallel and sequential pipelines should be more explicitly displayed in 
spec I believe. Please provide your comments.

Thank you,
Georgiy.


On 21.02.2013 19:57, Brian Goetz wrote:
> It is s2.
>
> Once you do s2 = s1.peek(), s1 is "used up" and all access to the 
> stream data is through s2.
>
> On 2/21/2013 5:08 AM, Georgiy Rakov wrote:
>> Could you please provide some more information regarding following part
>> of this spec:
>>
>>       * Produce a {@code Stream} containing the elements of this stream,
>> and also provide elements
>>       * to the specified {@link Consumer} as elements are consumed from
>> the /_*resulting stream*_/.  This is
>>
>>
>> What is "*resulting stream*" - stream returned by peek() or the stream
>> the peek() is applied to, i.e. considering following code - s1 or s2?
>>
>>     Stream s1;
>>     ...
>>     Stream s2 = s1.peek();
>>
>> Thanks,
>> Georgiy.
>>
>> On 20.02.2013 20:38, Brian Goetz wrote:
>>> Here's the current spec for this method -- does this help?
>>>
>>>     /**
>>>      * Produce a {@code Stream} containing the elements of this
>>> stream, and also provide elements
>>>      * to the specified {@link Consumer} as elements are consumed from
>>> the resulting stream.  This is
>>>      * an <a href="package-summary.html#StreamOps">intermediate
>>> operation</a>.
>>>      * {@apiNote}
>>>      * This method exists mainly to support debugging, where you want
>>> to see the elements as they flow past a certain
>>>      * point in a pipeline:
>>>      * <pre>
>>>      *     list.stream()
>>>      *         .filter(filteringFunction)
>>>      *         .peek(e -> {System.out.println("Filtered value: " + e);
>>> });
>>>      *         .map(mappingFunction)
>>>      *         .peek(e -> {System.out.println("Mapped value: " + e); 
>>> });
>>>      *         .collect(Collectors.intoList());
>>>      * </pre>
>>>      *
>>>      * <p>For parallel stream pipelines, the {@code Consumer} may be
>>> called at whatever time and in whatever thread
>>>      * the element is made available by the upstream operation. If the
>>> {@code Consumer} modifies shared state,
>>>      * it is responsible for providing the required synchronization.
>>>      *
>>>      * @param consumer The {@code Consumer} to receive the elements
>>>      */
>>>
>>>
>>>
>>> On 2/20/2013 10:02 AM, Georgiy Rakov wrote:
>>>> Hello again,
>>>>
>>>> it has just come into my mind that it could be quite more major issue
>>>> than I wrote in my previous letter.
>>>>
>>>> So the case a bit rewritten:
>>>>
>>>>     Stream s1 = Arrays.asList(1, 2, 3).stream();
>>>>     Stream s2 = s1.peek(System.err::println);
>>>>     s2.iterator().hasNext();
>>>>
>>>>
>>>> The spec says:
>>>>
>>>>     Produce a Stream containing the elements of this stream, and also
>>>>     provide elements to the specified Consumer as elements are *passed
>>>>     through*.
>>>>
>>>> So the core question is what does "passed through" mean?From the first
>>>> glance I would say it means *consuming elements from **stream returned
>>>> ****by peek()* (not from stream which peek() is applied to). If this
>>>> interpretation is right then I could suppose it's a bug because the
>>>> element from s2 has not been consumed yet (next() is not called just
>>>> hasNext() has been called).
>>>>
>>>> Could you please confirm if such reasoning is right and it's really a
>>>> bug.
>>>>
>>>> Thanks, Georgiy.
>>>>
>>>> On 12.02.2013 23:01, Remi Forax wrote:
>>>>> On 02/12/2013 07:16 PM, Brian Goetz wrote:
>>>>>> The answer here is complicated, but in general, calling hasNext may
>>>>>> well
>>>>>> require consuming an element -- there's often no way to know 
>>>>>> whether a
>>>>>> source would produce an element without asking it to do so. So it 
>>>>>> is a
>>>>>> common practice in implementing iterators to do this (one of many
>>>>>> reasons why we did not build Streams on Iterator.)
>>>>>>
>>>>>> Because the elements are coming from an array, it might be 
>>>>>> possible to
>>>>>> know simply based on how many elements have gone by that the 
>>>>>> stream is
>>>>>> not yet exhausted.  But in the general case (such as when the stream
>>>>>> source is an IO channel), it is not possible to know without 
>>>>>> actually
>>>>>> consuming and buffering some input.  So I would put this in the
>>>>>> category
>>>>>> of "acceptable" behavior.  We might someday do some work to take
>>>>>> advantage of the fact that the source has the SIZED 
>>>>>> characteristic and
>>>>>> the pipeline stages are size-preserving to make this case behave
>>>>>> "better", but that would be an implementation quality issue, not a
>>>>>> spec
>>>>>> issue.  The behavior you observe is allowable by the spec.
>>>>> while I a stream may have to do some buffering, peek should always be
>>>>> transparent and an iterator on an array doesn't need any buffering
>>>>> but I
>>>>> agree that this is an implementation issue.
>>>>>
>>>>> R?mi
>>>>>
>>>>>> On 2/12/2013 12:53 PM, Dmitry Bessonov wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> The following line prints out the first element, "1"
>>>>>>>
>>>>>>>       Arrays.asList(1, 2,
>>>>>>> 3).stream().peek(System.err::println).iterator().hasNext()
>>>>>>>
>>>>>>> Is it really an expected behavior?
>>>>>>>
>>>>>>> -Dmitry
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>
>>


From brian.goetz at oracle.com  Thu Feb 21 10:52:11 2013
From: brian.goetz at oracle.com (Brian Goetz)
Date: Thu, 21 Feb 2013 13:52:11 -0500
Subject: peek().iterator().hasNext() pre-consumes elements?
In-Reply-To: <51266752.9020703@oracle.com>
References: <511A8193.2080402@oracle.com> <511A86F9.6010609@oracle.com>
	<511A916D.3080005@univ-mlv.fr> <5124E58B.9040202@oracle.com>
	<5124FBF5.60802@oracle.com> <5125F225.5020500@oracle.com>
	<512643DC.2070706@oracle.com> <51266752.9020703@oracle.com>
Message-ID: <51266CDB.5060803@oracle.com>

Good point.  I'll have to tighten up the spec to allow for this; there's 
no way we can prevent hasNext() from "peeking" ahead, nor can we delay 
the side-effects until the caller actually calls next().

On (2), you are right that the upstream operation is s1.  Again, I think 
the existing spec is simply sloppy (though having spec at all is an 
improvement!) and needs to be tightened.



On 2/21/2013 1:28 PM, Georgiy Rakov wrote:
> If it's s2 then two following questions arise:
>
> 1. The behavior originally described by Dmitry, i. e. when following
> code prints 1, could be considered to be faulty because calling
> hasNext() doesn't mean /consuming/ I believe.
>
>        Arrays.asList(1, 2,
> 3).stream().peek(System.err::println).iterator().hasNext()
>
> Please confirm if this is right and going to be fixed.
>
> 2. Regarding following part of spec (say *part A*):
>
>     * <p>For parallel stream pipelines, the {@code Consumer} may be
>     called at whatever time and in whatever thread
>     * the element is made available by the /_*upstream operation*_/. If
>     the {@code Consumer} modifies shared state,
>
> If I hasn't got mixed up in the terminology /_*upstream operation*_/
> means s1. So it looks like a contradiction with the first part of spec
> (say *part B*):
>
>     * Produce a {@code Stream} containing the elements of this stream,
>     and also provide elements
>     * to the specified {@link Consumer} as elements are consumed from
>     the /_*resulting stream*_/.  This is
>
> because in accordance with *part A* consumer is called when the *element
> is made available by /_s1_/*/__/while in accordance with *part B* the
> consumer is called when *the element is consumed from /_s2_/*.
> If it's really the case then such a big difference between behavior of
> parallel and sequential pipelines should be more explicitly displayed in
> spec I believe. Please provide your comments.
>
> Thank you,
> Georgiy.
>
>
> On 21.02.2013 19:57, Brian Goetz wrote:
>> It is s2.
>>
>> Once you do s2 = s1.peek(), s1 is "used up" and all access to the
>> stream data is through s2.
>>
>> On 2/21/2013 5:08 AM, Georgiy Rakov wrote:
>>> Could you please provide some more information regarding following part
>>> of this spec:
>>>
>>>       * Produce a {@code Stream} containing the elements of this stream,
>>> and also provide elements
>>>       * to the specified {@link Consumer} as elements are consumed from
>>> the /_*resulting stream*_/.  This is
>>>
>>>
>>> What is "*resulting stream*" - stream returned by peek() or the stream
>>> the peek() is applied to, i.e. considering following code - s1 or s2?
>>>
>>>     Stream s1;
>>>     ...
>>>     Stream s2 = s1.peek();
>>>
>>> Thanks,
>>> Georgiy.
>>>
>>> On 20.02.2013 20:38, Brian Goetz wrote:
>>>> Here's the current spec for this method -- does this help?
>>>>
>>>>     /**
>>>>      * Produce a {@code Stream} containing the elements of this
>>>> stream, and also provide elements
>>>>      * to the specified {@link Consumer} as elements are consumed from
>>>> the resulting stream.  This is
>>>>      * an <a href="package-summary.html#StreamOps">intermediate
>>>> operation</a>.
>>>>      * {@apiNote}
>>>>      * This method exists mainly to support debugging, where you want
>>>> to see the elements as they flow past a certain
>>>>      * point in a pipeline:
>>>>      * <pre>
>>>>      *     list.stream()
>>>>      *         .filter(filteringFunction)
>>>>      *         .peek(e -> {System.out.println("Filtered value: " + e);
>>>> });
>>>>      *         .map(mappingFunction)
>>>>      *         .peek(e -> {System.out.println("Mapped value: " + e);
>>>> });
>>>>      *         .collect(Collectors.intoList());
>>>>      * </pre>
>>>>      *
>>>>      * <p>For parallel stream pipelines, the {@code Consumer} may be
>>>> called at whatever time and in whatever thread
>>>>      * the element is made available by the upstream operation. If the
>>>> {@code Consumer} modifies shared state,
>>>>      * it is responsible for providing the required synchronization.
>>>>      *
>>>>      * @param consumer The {@code Consumer} to receive the elements
>>>>      */
>>>>
>>>>
>>>>
>>>> On 2/20/2013 10:02 AM, Georgiy Rakov wrote:
>>>>> Hello again,
>>>>>
>>>>> it has just come into my mind that it could be quite more major issue
>>>>> than I wrote in my previous letter.
>>>>>
>>>>> So the case a bit rewritten:
>>>>>
>>>>>     Stream s1 = Arrays.asList(1, 2, 3).stream();
>>>>>     Stream s2 = s1.peek(System.err::println);
>>>>>     s2.iterator().hasNext();
>>>>>
>>>>>
>>>>> The spec says:
>>>>>
>>>>>     Produce a Stream containing the elements of this stream, and also
>>>>>     provide elements to the specified Consumer as elements are *passed
>>>>>     through*.
>>>>>
>>>>> So the core question is what does "passed through" mean?From the first
>>>>> glance I would say it means *consuming elements from **stream returned
>>>>> ****by peek()* (not from stream which peek() is applied to). If this
>>>>> interpretation is right then I could suppose it's a bug because the
>>>>> element from s2 has not been consumed yet (next() is not called just
>>>>> hasNext() has been called).
>>>>>
>>>>> Could you please confirm if such reasoning is right and it's really a
>>>>> bug.
>>>>>
>>>>> Thanks, Georgiy.
>>>>>
>>>>> On 12.02.2013 23:01, Remi Forax wrote:
>>>>>> On 02/12/2013 07:16 PM, Brian Goetz wrote:
>>>>>>> The answer here is complicated, but in general, calling hasNext may
>>>>>>> well
>>>>>>> require consuming an element -- there's often no way to know
>>>>>>> whether a
>>>>>>> source would produce an element without asking it to do so. So it
>>>>>>> is a
>>>>>>> common practice in implementing iterators to do this (one of many
>>>>>>> reasons why we did not build Streams on Iterator.)
>>>>>>>
>>>>>>> Because the elements are coming from an array, it might be
>>>>>>> possible to
>>>>>>> know simply based on how many elements have gone by that the
>>>>>>> stream is
>>>>>>> not yet exhausted.  But in the general case (such as when the stream
>>>>>>> source is an IO channel), it is not possible to know without
>>>>>>> actually
>>>>>>> consuming and buffering some input.  So I would put this in the
>>>>>>> category
>>>>>>> of "acceptable" behavior.  We might someday do some work to take
>>>>>>> advantage of the fact that the source has the SIZED
>>>>>>> characteristic and
>>>>>>> the pipeline stages are size-preserving to make this case behave
>>>>>>> "better", but that would be an implementation quality issue, not a
>>>>>>> spec
>>>>>>> issue.  The behavior you observe is allowable by the spec.
>>>>>> while I a stream may have to do some buffering, peek should always be
>>>>>> transparent and an iterator on an array doesn't need any buffering
>>>>>> but I
>>>>>> agree that this is an implementation issue.
>>>>>>
>>>>>> R?mi
>>>>>>
>>>>>>> On 2/12/2013 12:53 PM, Dmitry Bessonov wrote:
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> The following line prints out the first element, "1"
>>>>>>>>
>>>>>>>>       Arrays.asList(1, 2,
>>>>>>>> 3).stream().peek(System.err::println).iterator().hasNext()
>>>>>>>>
>>>>>>>> Is it really an expected behavior?
>>>>>>>>
>>>>>>>> -Dmitry
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>
>

From brian.goetz at oracle.com  Thu Feb 21 11:16:35 2013
From: brian.goetz at oracle.com (Brian Goetz)
Date: Thu, 21 Feb 2013 14:16:35 -0500
Subject: Code review request: JDK-8008670 (partial java.util.stream
	implementation)
Message-ID: <51267293.4060203@oracle.com>

At:
   http://cr.openjdk.java.net/~briangoetz/jdk-8008670/webrev/

there is a webrev of a subset of the implementation of java.util.stream, 
for review.  These are all new files.  None of these are public classes; 
they are internal interfaces for the Stream library, as well as some 
implementation classes.  This is about half the classes in the Streams 
package.

(The webrev includes changes to Map, but those are being reviewed 
separately, so just ignore those.)

We're asking people to focus their review on both the quality of API 
specification for these internal APIs, and the quality of implementation 
of the specified classes.  It may not be obvious how some of these work 
until you've seen the rest of it, but do what you can.


From ali.ebrahimi1781 at gmail.com  Thu Feb 21 13:16:11 2013
From: ali.ebrahimi1781 at gmail.com (Ali Ebrahimi)
Date: Fri, 22 Feb 2013 01:46:11 +0430
Subject: hg: lambda/lambda/langtools: 8008537: Missing method reference
	lookup error when unbound search finds a static method
In-Reply-To: <20130220192005.A58E947C10@hg.openjdk.java.net>
References: <20130220192005.A58E947C10@hg.openjdk.java.net>
Message-ID: <CAA0cW5AmsDPKzOmPnxN4Yvq5VzkbNFzuiU_jpeaEOU_kpe=UNQ@mail.gmail.com>

Hi maurizio,

are you sure this is ambiguous? I don't think so. (u(Sam2)  is not only
answer?)

TargetType60 s2 = u(TargetType60::n1); //ambiguous (u(Sam1), u(Sam2) apply)


Best Regards,
Ali Ebrahimi

On Wed, Feb 20, 2013 at 11:49 PM, <maurizio.cimadamore at oracle.com> wrote:

> Changeset: 66476d1c5e64
> Author:    mcimadamore
> Date:      2013-02-20 19:19 +0000
> URL:
> http://hg.openjdk.java.net/lambda/lambda/langtools/rev/66476d1c5e64
>
> 8008537: Missing method reference lookup error when unbound search finds a
> static method
>
> ! src/share/classes/com/sun/tools/javac/comp/Attr.java
> ! src/share/classes/com/sun/tools/javac/comp/Resolve.java
> ! src/share/classes/com/sun/tools/javac/resources/compiler.properties
> ! test/tools/javac/diags/examples.not-yet.txt
> ! test/tools/javac/diags/examples/NonStaticCantBeRefFragment.java
> ! test/tools/javac/lambda/MethodReference22.java
> ! test/tools/javac/lambda/MethodReference22.out
> ! test/tools/javac/lambda/MethodReference28.out
> ! test/tools/javac/lambda/MethodReference51.out
> ! test/tools/javac/lambda/TargetType60.java
> ! test/tools/javac/lambda/TargetType60.out
>
>
>

From maurizio.cimadamore at oracle.com  Thu Feb 21 13:28:06 2013
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Thu, 21 Feb 2013 21:28:06 +0000
Subject: hg: lambda/lambda/langtools: 8008537: Missing method reference
	lookup error when unbound search finds a static method
In-Reply-To: <CAA0cW5AmsDPKzOmPnxN4Yvq5VzkbNFzuiU_jpeaEOU_kpe=UNQ@mail.gmail.com>
References: <20130220192005.A58E947C10@hg.openjdk.java.net>
	<CAA0cW5AmsDPKzOmPnxN4Yvq5VzkbNFzuiU_jpeaEOU_kpe=UNQ@mail.gmail.com>
Message-ID: <51269166.1010802@oracle.com>

On 21/02/13 21:16, Ali Ebrahimi wrote:
> Hi maurizio,
>
> are you sure this is ambiguous? I don't think so. (u(Sam2)  is not 
> only answer?)
>
> TargetType60 s2 = u(TargetType60::n1); //ambiguous (u(Sam1), u(Sam2) 
> apply)
They both apply - turned out I've misread the spec - the fact that the 
method is static/non-static should not affect outcome of method 
reference resolution. So, if target type has parameters P1 ... Pn, we do 
two lookups:

*) one (bound) with P1 ... Pn
*) one (unbound) with P2 ... Pn

The first lookup will cause the match in u(Sam1), while the second 
lookup will match u(Sam2). Hence the ambiguity.

Maurizio
>
>
> Best Regards,
> Ali Ebrahimi
>
> On Wed, Feb 20, 2013 at 11:49 PM, <maurizio.cimadamore at oracle.com 
> <mailto:maurizio.cimadamore at oracle.com>> wrote:
>
>     Changeset: 66476d1c5e64
>     Author:    mcimadamore
>     Date:      2013-02-20 19:19 +0000
>     URL:
>     http://hg.openjdk.java.net/lambda/lambda/langtools/rev/66476d1c5e64
>
>     8008537: Missing method reference lookup error when unbound search
>     finds a static method
>
>     ! src/share/classes/com/sun/tools/javac/comp/Attr.java
>     ! src/share/classes/com/sun/tools/javac/comp/Resolve.java
>     ! src/share/classes/com/sun/tools/javac/resources/compiler.properties
>     ! test/tools/javac/diags/examples.not-yet.txt
>     ! test/tools/javac/diags/examples/NonStaticCantBeRefFragment.java
>     ! test/tools/javac/lambda/MethodReference22.java
>     ! test/tools/javac/lambda/MethodReference22.out
>     ! test/tools/javac/lambda/MethodReference28.out
>     ! test/tools/javac/lambda/MethodReference51.out
>     ! test/tools/javac/lambda/TargetType60.java
>     ! test/tools/javac/lambda/TargetType60.out
>
>
>


From brian.goetz at oracle.com  Thu Feb 21 13:43:10 2013
From: brian.goetz at oracle.com (brian.goetz at oracle.com)
Date: Thu, 21 Feb 2013 21:43:10 +0000
Subject: hg: lambda/lambda/jdk: Clean up generics in XxxPipeline constructors; 
	various other small cleanups
Message-ID: <20130221214331.5B47E47C56@hg.openjdk.java.net>

Changeset: 440c59e7eed0
Author:    briangoetz
Date:      2013-02-21 16:43 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/440c59e7eed0

Clean up generics in XxxPipeline constructors; various other small cleanups

! src/share/classes/java/util/stream/AbstractPipeline.java
! src/share/classes/java/util/stream/DoublePipeline.java
! src/share/classes/java/util/stream/FoldOp.java
! src/share/classes/java/util/stream/IntPipeline.java
! src/share/classes/java/util/stream/LongPipeline.java
! src/share/classes/java/util/stream/ReferencePipeline.java


From ali.ebrahimi1781 at gmail.com  Thu Feb 21 14:27:22 2013
From: ali.ebrahimi1781 at gmail.com (Ali Ebrahimi)
Date: Fri, 22 Feb 2013 02:57:22 +0430
Subject: hg: lambda/lambda/langtools: 8008537: Missing method reference
	lookup error when unbound search finds a static method
In-Reply-To: <51269166.1010802@oracle.com>
References: <20130220192005.A58E947C10@hg.openjdk.java.net>
	<CAA0cW5AmsDPKzOmPnxN4Yvq5VzkbNFzuiU_jpeaEOU_kpe=UNQ@mail.gmail.com>
	<51269166.1010802@oracle.com>
Message-ID: <CAA0cW5AAsgLDKJPR-uR5Ro79dy+=tGsq-nSPWNBvNmrU4cPhHA@mail.gmail.com>

Hi again maurizio,
if i comment u(Sam2) method then we have one answer u(Sam1), correct?

in that case, we woud have u(Sam1<String>) or u(Sam1<TargetType60>)?

I think in any case this is not correct.

u(Sam1<String>)   => TargetType60 s2 = u(TargetType60::n1);
method u returns String and not compatible with TargetType60.

u(Sam1<TargetType60>) => we missed n1 String parameter and fail at runtime.



    interface Sam1<X> {
        void m(X x);
    }

void n1(String s) { }

static <U> U u(Sam1<U> s) {    s.m((U)null)     return null; }

static void testUnbound() {
         TargetType60 s2 = u(TargetType60::n1);
}

main question: what is receiver of this method reff passed to u(Sam1)?

Best Regards,
Ali Ebrahimi

On Fri, Feb 22, 2013 at 1:58 AM, Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

>  On 21/02/13 21:16, Ali Ebrahimi wrote:
>
> Hi maurizio,
>
> are you sure this is ambiguous? I don't think so. (u(Sam2)  is not only
> answer?)
>
> TargetType60 s2 = u(TargetType60::n1); //ambiguous (u(Sam1), u(Sam2) apply)
>
> They both apply - turned out I've misread the spec - the fact that the
> method is static/non-static should not affect outcome of method reference
> resolution. So, if target type has parameters P1 ... Pn, we do two lookups:
>
> *) one (bound) with P1 ... Pn
> *) one (unbound) with P2 ... Pn
>
> The first lookup will cause the match in u(Sam1), while the second lookup
> will match u(Sam2). Hence the ambiguity.
>
> Maurizio
>
>
>
> Best Regards,
> Ali Ebrahimi
>
> On Wed, Feb 20, 2013 at 11:49 PM, <maurizio.cimadamore at oracle.com> wrote:
>
>> Changeset: 66476d1c5e64
>> Author:    mcimadamore
>> Date:      2013-02-20 19:19 +0000
>> URL:
>> http://hg.openjdk.java.net/lambda/lambda/langtools/rev/66476d1c5e64
>>
>> 8008537: Missing method reference lookup error when unbound search finds
>> a static method
>>
>> ! src/share/classes/com/sun/tools/javac/comp/Attr.java
>> ! src/share/classes/com/sun/tools/javac/comp/Resolve.java
>> ! src/share/classes/com/sun/tools/javac/resources/compiler.properties
>> ! test/tools/javac/diags/examples.not-yet.txt
>> ! test/tools/javac/diags/examples/NonStaticCantBeRefFragment.java
>> ! test/tools/javac/lambda/MethodReference22.java
>> ! test/tools/javac/lambda/MethodReference22.out
>> ! test/tools/javac/lambda/MethodReference28.out
>> ! test/tools/javac/lambda/MethodReference51.out
>> ! test/tools/javac/lambda/TargetType60.java
>> ! test/tools/javac/lambda/TargetType60.out
>>
>>
>>
>
>

From brian.goetz at oracle.com  Thu Feb 21 14:50:23 2013
From: brian.goetz at oracle.com (brian.goetz at oracle.com)
Date: Thu, 21 Feb 2013 22:50:23 +0000
Subject: hg: lambda/lambda/jdk: Decouple Stream APIs from implementation;
	fix test bug
Message-ID: <20130221225035.91FF147C58@hg.openjdk.java.net>

Changeset: 2d19796f57c4
Author:    briangoetz
Date:      2013-02-21 17:50 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/2d19796f57c4

Decouple Stream APIs from implementation; fix test bug

! src/share/classes/java/util/stream/DelegatingStream.java
! src/share/classes/java/util/stream/DoublePipeline.java
! src/share/classes/java/util/stream/DoubleStream.java
! src/share/classes/java/util/stream/IntPipeline.java
! src/share/classes/java/util/stream/IntStream.java
! src/share/classes/java/util/stream/LongPipeline.java
! src/share/classes/java/util/stream/LongStream.java
! src/share/classes/java/util/stream/ReferencePipeline.java
! src/share/classes/java/util/stream/Stream.java
! test-ng/tests/org/openjdk/tests/java/util/RandomStreamTest.java


From latsama at gmail.com  Thu Feb 21 20:36:42 2013
From: latsama at gmail.com (Lattie)
Date: Thu, 21 Feb 2013 20:36:42 -0800
Subject: Generalized transformation of a Stream<X> into a Stream<Y>, with lazy
	evaluation and stateful transformation functions
Message-ID: <CAKJVG8Yazqxoo4n+v=Q_Ebph5Rfbde2aRWbX7CkL2P+WcGNeXg@mail.gmail.com>

Following up on a thread from earlier this month:

(See thread "Re: Grouping stream elements by their position - how to handle
tail of stream ?")

There has been some interest expressed (by Boaz Nahum, Zhong Yu, Howard
Lovatt, and myself) in expanding the operations provided by Stream to
support a generalized 'on-the-fly' transformation from a Stream<X> to a
Stream<Y>, where the transformation function consumes 1 or more X's to
produce 1 or more Y's.

Here are a couple examples of this type of transformation:

### EXAMPLES ###

1) Transform a Stream<Character> into a Stream<String> where the resulting
Strings are the words parsed from the stream of Characters.

Stream<Character> chars = makeACharacterStream("This is a test");

Stream<String> words = chars.transform(MyParsingTransformation);

words.stream().forEach(System.out::println);

Would print:

this
is
a
test

Or, as a one liner:

makeACharacterStream("This is a
test").transform(myParsingTransformation).forEach(System.out::println);

Note that this should work for both finite and infinite input streams, and
that lazy evaluation should be preserved (i.e., only enough Characters are
pulled from the input stream to produce 1 parsed word as each word is
pulled out of the output stream.)

Another example:

2) Transform a Stream<Card> (representing a shuffled deck of 52 cards) into
a Stream<List<Card>> where each List<Card> represents a dealt hand of N
cards.

Stream<Card> deck = getShuffledDeck();

Stream<List<Card>> hands = deck.transform(dealTransformation(5)).limit(3);
 // deal 3 hands

This transformation will deal 3 hands of 5 cards each.  Only 15 cards will
be consumed from the deck stream.

The first parsing example is inherently linear, but the 2nd could
potentially be parallelized (assuming one doesn't mind the additional
randomization of the (already shuffled) deck from potential race conditions
in the dealing process.  In other words, the function returned by
dealTransformation() does not care if the Cards it gets from the input
stream are in any particular order.)

### END OF EXAMPLES ###

This general capability would mimic the familiar 'pipe' model offered by
the unix shell.  Each Stream.transformation() operation would consume the
incoming objects, transform them in some way (possibly including
aggregation, or expansion), and produce the new output objects.

Let me just say here that this would be a truly *fantastic* ability to
have!  (Thus my motivation in putting together this note.)

The question was raised as to whether the desired functionality could be
constructed using the existing Stream.collect() and Stream.flatMap()
methods.

Unfortunately, after some experimentation and internal discussions, the
answer was found to be that no, those methods are not sufficient.  I've
attached two example source files (run against the b78 build) showing the
results of trying to get the desired behavior using Stream.collect() and
Stream.flatMap().  Run them.  They are interesting!  :)

Stream.collect() consumes it's entire input stream prior to returning, thus
it is not suitable for infinite input streams, or even for finite but large
input streams (since the user may just want, for example, the first 2
parsed words from a 1 TB stream of Characters.  collect() will parse the
*entire* 1 TB input before the resulting stream gets to the .limit(2)
method downstream.  Not good.)

Stream.flatMap() is much closer to being able to do the trick.  It does
it's job lazily, so can handle large/infinite inputs.  The problem (as
originally raised by Boaz Nahum) is that there is no mechanism within
flatMap to handle the end of the input Stream gracefully.  (This results
from the FlatMapper being 'stateful', but with no way to 'flush' the final
state to produce any hanging output objects implied by that state and
propagate them to the output stream.)

Now there is a whole separate discussion about 'stateful' lambdas and
whether they are good or bad that I won't pretend to fully understand.

However I will point out that some of the lambdas expected to be passed
into collect() are stateful, so maybe it's ok?  I dunno.

Anyway, bottom line, it appears to me that flatMap() is an instance of a
more generalized transform() concept, and that it would be very beneficial
to explicitly allow the type of usage implied by this 'transform()' idea,
and that in fact flatMap() could be implemented as just one instance of
such a transformation.  (But that the desired transform() capability can
*not* be implemented on top of flatMap() or collect()).

The design of Stream.transform() could closely mirror the model used by
Stream.flatMap(), with some added mechanism to allow the final state to be
pulled out of the transformation after the input stream has been exhausted.
 (I can expand on this in more detail if there is interest.)

Thank you for your attention, and let the games begin!


PS: jdk 8 lambda rocks.  Java will once again reign supreme.  Thanks
everyone!

From maurizio.cimadamore at oracle.com  Fri Feb 22 02:40:45 2013
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Fri, 22 Feb 2013 10:40:45 +0000
Subject: hg: lambda/lambda/langtools: 8008537: Missing method reference
	lookup error when unbound search finds a static method
In-Reply-To: <CAA0cW5AAsgLDKJPR-uR5Ro79dy+=tGsq-nSPWNBvNmrU4cPhHA@mail.gmail.com>
References: <20130220192005.A58E947C10@hg.openjdk.java.net>
	<CAA0cW5AmsDPKzOmPnxN4Yvq5VzkbNFzuiU_jpeaEOU_kpe=UNQ@mail.gmail.com>
	<51269166.1010802@oracle.com>
	<CAA0cW5AAsgLDKJPR-uR5Ro79dy+=tGsq-nSPWNBvNmrU4cPhHA@mail.gmail.com>
Message-ID: <51274B2D.5000803@oracle.com>

I think the test - or  the types in the test, to be more precise, might 
be misleading you. The goal of this test is to check provisional 
applicability of method references, a new applicability step described 
in the spec EDR. When method reference happens to be 'stuck' - that is, 
when its target type contains inference variables in the parameter types 
of the functional descriptor (as it happens to be the case here), the 
compiler revert to a much more brittle applicability scheme. It 
essentially uses the target type to perform an arity based match of the 
available methods. So, assuming the target type is:

SAM<Z>

where Z is an inference variable and SAM is declared as follows:

interface SAM<X> {
     m(X x)
}

If you have something like:

Foo::g

whose target is SAM<Z>, the compiler will:

1) Look at the target type
2) See that the method reference is stuck (parameter types of functional 
descriptor contain Z)
3) See if Foo has a method matching with a 'jolly' parameter list (*) 
[where * stands for any type]
4) If the above condition is satisfied, the method is deemed applicable. 
Most specific then follows, and, once a most specific method has been 
selected you will have a precise check with all the inference bells and 
whistles.

Now, if Foo is a class that has two methods:

g()
g(String) //any type will do

The arity-based lookup described in (3) will match both methods.

This shows that, since the arity-based lookup is fuzzy (can match 
methods with different arities due to the bound/unbound lookup 
differences) - it is possible for two target types with different 
arities to both have a match. This _doesn't_ mean that the target type 
will make the method reference checkable - it merely means that the 
provisional applicability step is satisfied (which means the method 
featuring that particular target type as formal argument is applicable).

It is possible that, even removing one of the ambiguous methods you 
still get a compiler error down the road, because when the compiler 
starts to do full type-checking of the method reference it realizes 
something is wrong.

Now, one could argue that if a method reference cannot be type-checked 
against a formal, a method should never be deemed applicable; that's 
possible - and it's the way the compiler used to work (before the 
overload resolution rewrital which happened late last year). However, 
there are situations in which you can't tell as to whether a method 
would be applicable or not unless you look at the target type of the 
method call. And we wanted to preserve the invariant that the outcome of 
overload resolution was still expressible as a function between actual 
argument types and formal argument types. Hence the provisional 
applicability check and the fuzzy arity-based matching.

Of course, all of this only takes place when a method reference is stuck 
- which can only happen if you are calling a generic method.

Maurizio




On 21/02/13 22:27, Ali Ebrahimi wrote:
> Hi again maurizio,
> if i comment u(Sam2) method then we have one answer u(Sam1), correct?
>
> in that case, we woud have u(Sam1<String>) or u(Sam1<TargetType60>)?
>
> I think in any case this is not correct.
>
> u(Sam1<String>)   => TargetType60 s2 = u(TargetType60::n1);
> method u returns String and not compatible with TargetType60.
>
> u(Sam1<TargetType60>) => we missed n1 String parameter and fail at 
> runtime.
>
>
>
>     interface Sam1<X> {
>         void m(X x);
>     }
>
> void n1(String s) { }
>
> static <U> U u(Sam1<U> s) {    s.m((U)null)     return null; }
>
> static void testUnbound() {
>          TargetType60 s2 = u(TargetType60::n1);
> }
>
> main question: what is receiver of this method reff passed to u(Sam1)?
>
> Best Regards,
> Ali Ebrahimi
>
> On Fri, Feb 22, 2013 at 1:58 AM, Maurizio Cimadamore 
> <maurizio.cimadamore at oracle.com 
> <mailto:maurizio.cimadamore at oracle.com>> wrote:
>
>     On 21/02/13 21:16, Ali Ebrahimi wrote:
>>     Hi maurizio,
>>
>>     are you sure this is ambiguous? I don't think so. (u(Sam2)  is
>>     not only answer?)
>>
>>     TargetType60 s2 = u(TargetType60::n1); //ambiguous (u(Sam1),
>>     u(Sam2) apply)
>     They both apply - turned out I've misread the spec - the fact that
>     the method is static/non-static should not affect outcome of
>     method reference resolution. So, if target type has parameters P1
>     ... Pn, we do two lookups:
>
>     *) one (bound) with P1 ... Pn
>     *) one (unbound) with P2 ... Pn
>
>     The first lookup will cause the match in u(Sam1), while the second
>     lookup will match u(Sam2). Hence the ambiguity.
>
>     Maurizio
>
>>
>>
>>     Best Regards,
>>     Ali Ebrahimi
>>
>>     On Wed, Feb 20, 2013 at 11:49 PM, <maurizio.cimadamore at oracle.com
>>     <mailto:maurizio.cimadamore at oracle.com>> wrote:
>>
>>         Changeset: 66476d1c5e64
>>         Author:    mcimadamore
>>         Date:      2013-02-20 19:19 +0000
>>         URL:
>>         http://hg.openjdk.java.net/lambda/lambda/langtools/rev/66476d1c5e64
>>
>>         8008537: Missing method reference lookup error when unbound
>>         search finds a static method
>>
>>         ! src/share/classes/com/sun/tools/javac/comp/Attr.java
>>         ! src/share/classes/com/sun/tools/javac/comp/Resolve.java
>>         !
>>         src/share/classes/com/sun/tools/javac/resources/compiler.properties
>>         ! test/tools/javac/diags/examples.not-yet.txt
>>         ! test/tools/javac/diags/examples/NonStaticCantBeRefFragment.java
>>         ! test/tools/javac/lambda/MethodReference22.java
>>         ! test/tools/javac/lambda/MethodReference22.out
>>         ! test/tools/javac/lambda/MethodReference28.out
>>         ! test/tools/javac/lambda/MethodReference51.out
>>         ! test/tools/javac/lambda/TargetType60.java
>>         ! test/tools/javac/lambda/TargetType60.out
>>
>>
>>
>
>


From peter.levart at gmail.com  Fri Feb 22 04:27:47 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Fri, 22 Feb 2013 13:27:47 +0100
Subject: [8] Review request for 8004970, 8004971, and 8006817: implement
	serialization in lambda metafactory and metafactory fix
In-Reply-To: <511A93AA.4090300@gmail.com>
References: <511A5E68.4070805@oracle.com> <511A93AA.4090300@gmail.com>
Message-ID: <51276443.1000506@gmail.com>

Hi Robert,

What I was trying to say in my previous post is illustrated in the 
following minimal test-case:


package test;

import sun.misc.IOUtils;

import java.io.ByteArrayInputStream;
import java.io.ByteArrayOutputStream;
import java.io.IOException;
import java.io.InputStream;
import java.io.ObjectInputStream;
import java.io.ObjectOutputStream;
import java.io.Serializable;

public class SerializedLambdaTest {

     public interface SerializableRunnable extends Runnable, Serializable {}

     public static class MyCode implements SerializableRunnable {

         private byte[] serialize(Object o) {
             ByteArrayOutputStream baos;
             try (
                 ObjectOutputStream oos =
                     new ObjectOutputStream(baos = new 
ByteArrayOutputStream())
             ) {
                 oos.writeObject(o);
             }
             catch (IOException e) {
                 throw new RuntimeException(e);
             }
             return baos.toByteArray();
         }

         private <T> T deserialize(byte[] bytes) {
             try (
                 ObjectInputStream ois =
                     new ObjectInputStream(new ByteArrayInputStream(bytes))
             ) {
                 return (T) ois.readObject();
             }
             catch (IOException | ClassNotFoundException e) {
                 throw new RuntimeException(e);
             }
         }

         @Override
         public void run() {
             System.out.println("                this: " + this);

             SerializableRunnable deSerializedThis = 
deserialize(serialize(this));
             System.out.println("    deSerializedThis: " + 
deSerializedThis);

             SerializableRunnable runnable = () -> 
{System.out.println("HELLO");};
             System.out.println("            runnable: " + runnable);

             SerializableRunnable deSerializedRunnable = 
deserialize(serialize(runnable));
             System.out.println("deSerializedRunnable: " + 
deSerializedRunnable);
         }
     }

     public static void main(String[] args) throws Exception {
         ClassLoader myCl = new MyClassLoader(
             SerializedLambdaTest.class.getClassLoader()
         );
         Class<?> myCodeClass = Class.forName(
             SerializedLambdaTest.class.getName() + "$MyCode",
             true,
             myCl
         );
         Runnable myCode = (Runnable) myCodeClass.newInstance();
         myCode.run();
     }

     static class MyClassLoader extends ClassLoader {
         MyClassLoader(ClassLoader parent) {
             super(parent);
         }

         @Override
         protected Class<?> loadClass(String name, boolean resolve) 
throws ClassNotFoundException {
             if (name.startsWith("test.")) {
                 synchronized (getClassLoadingLock(name)) {
                     Class<?> c = findLoadedClass(name);
                     if (c == null) {
                         c = findClass(name);
                     }
                     if (resolve) {
                         resolveClass(c);
                     }
                     return c;
                 }
             } else {
                 return super.loadClass(name, resolve);
             }
         }

         @Override
         protected Class<?> findClass(String name) throws 
ClassNotFoundException {
             String path = name.replace('.', '/').concat(".class");
             try (InputStream is = getResourceAsStream(path)) {
                 if (is != null) {
                     byte[] bytes = IOUtils.readFully(is, -1, true);
                     return defineClass(name, bytes, 0, bytes.length);
                 } else {
                     throw new ClassNotFoundException(name);
                 }
             }
             catch (IOException e) {
                 throw new ClassNotFoundException(name, e);
             }
         }
     }
}


... which produces the following output:


                 this: test.SerializedLambdaTest$MyCode at 5e481248
     deSerializedThis: test.SerializedLambdaTest$MyCode at d716361
             runnable: test.SerializedLambdaTest$MyCode$$Lambda$1 at eed1f14
Exception in thread "main" java.lang.ClassCastException: 
test.SerializedLambdaTest$MyCode$$Lambda$2 cannot be cast to 
test.SerializedLambdaTest$SerializableRunnable


If capturing class' Class object is not available at SAM proxy 
serialization time (but only it's name), it can be resolved at that time 
rather than at de-serialization time, when the caller class-loader is 
not obvious. Like for example in this patch:


Index: jdk/src/java/lang/invoke/SerializedLambda.java
===================================================================
--- jdk/src/java/lang/invoke/SerializedLambda.java (date 1361524994000)
+++ jdk/src/java/lang/invoke/SerializedLambda.java (revision )
@@ -24,6 +24,8 @@
   */
  package java.lang.invoke;

+import sun.reflect.Reflection;
+
  import java.io.Serializable;
  import java.lang.reflect.Method;
  import java.security.AccessController;
@@ -39,7 +41,7 @@
   * @see LambdaMetafactory
   */
  public final class SerializedLambda implements Serializable {
-    private final String capturingClass;
+    private final Class<?> capturingClass;
      private final String functionalInterfaceClass;
      private final String functionalInterfaceMethodName;
      private final String functionalInterfaceMethodSignature;
@@ -73,7 +75,7 @@
                              Object[] capturedArgs) throws 
ReflectiveOperationException {
          MethodHandleInfo samMhi = new 
MethodHandleInfo(Objects.requireNonNull(functionalInterface));
          MethodHandleInfo implMhi = new 
MethodHandleInfo(Objects.requireNonNull(implementation));
-        this.capturingClass = 
Objects.requireNonNull(capturingClass).getName();
+        this.capturingClass = Objects.requireNonNull(capturingClass);
          this.capturedArgs = Objects.requireNonNull(capturedArgs).clone();
          this.functionalInterfaceClass = 
samMhi.getDeclaringClass().getName();
          this.functionalInterfaceMethodName = samMhi.getName();
@@ -118,7 +120,17 @@
                              String implMethodSignature,
                              String instantiatedMethodType,
                              Object[] capturedArgs) {
-        this.capturingClass = capturingClass;
+        try {
+            this.capturingClass = Class.forName(
+                capturingClass.replace('/', '.'),
+                false,
+ Reflection.getCallerClass(2).getClassLoader()
+            );
+        }
+        catch (ClassNotFoundException e) {
+            throw (Error) new NoClassDefFoundError(e.getMessage())
+                .initCause(e);
+        }
          this.functionalInterfaceMethodKind = 
functionalInterfaceMethodKind;
          this.functionalInterfaceClass = functionalInterfaceClass;
          this.functionalInterfaceMethodName = 
functionalInterfaceMethodName;
@@ -133,7 +145,7 @@

      /** Get the name of the class that captured this lambda */
      public String getCapturingClass() {
-        return capturingClass;
+        return capturingClass.getName().replace('.', '/');
      }

      /** Get the name of the functional interface class to which this 
lambda has been converted */
@@ -200,9 +212,7 @@
              Method deserialize = AccessController.doPrivileged(new 
PrivilegedExceptionAction<Method>() {
                  @Override
                  public Method run() throws Exception {
-                    Class<?> clazz = 
Class.forName(capturingClass.replace('/', '.'), true,
- Thread.currentThread().getContextClassLoader());
-                    Method m = 
clazz.getDeclaredMethod("$deserializeLambda$", SerializedLambda.class);
+                    Method m = 
capturingClass.getDeclaredMethod("$deserializeLambda$", 
SerializedLambda.class);
                      m.setAccessible(true);
                      return m;
                  }



Regards, Peter


On 02/12/2013 08:10 PM, Peter Levart wrote:
> Hi Robert,
>
> Just a minor note on ClassLoaders.
>
> In SerializedLambda.readResolve(), the capturingClass is resolved from 
> it's name using the current thread's context ClassLoader. I don't know 
> if this is the right thing to do. ObjectInputStream has it's own 
> (pluggable) mechanism for resolving classes, which by default uses the 
> so called "latest user defined loader" (see 
> ObjectInputStream.resolveClass()). It would be better if 
> SerializedLambda kept a reference to j.l.Class object representing 
> capturingClass and leave to the serialization infrastructure do the 
> resolving. But there is a SerializedLambda constructor that only takes 
> a String, hm...
>
> I guess other classes that are resolved inside the capturingClass'  
> $deserializeLambda$ method are using the caprutingClass' class loader, 
> which is ok.
>
> Regards, Peter
>
> On 02/12/2013 04:23 PM, Robert Field wrote:
>> Please review the fixes for CRs:
>>
>>         http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004970
>>
>>         http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004971
>>
>>         http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8006817
>>
>>
>>
>> Webrev:
>>
>>         http://cr.openjdk.java.net/~rfield/8004970
>>
>> Thank,
>> Robert
>>
>>
>


From ali.ebrahimi1781 at gmail.com  Fri Feb 22 04:40:28 2013
From: ali.ebrahimi1781 at gmail.com (Ali Ebrahimi)
Date: Fri, 22 Feb 2013 17:10:28 +0430
Subject: hg: lambda/lambda/langtools: 8008537: Missing method reference
	lookup error when unbound search finds a static method
In-Reply-To: <51274B2D.5000803@oracle.com>
References: <20130220192005.A58E947C10@hg.openjdk.java.net>
	<CAA0cW5AmsDPKzOmPnxN4Yvq5VzkbNFzuiU_jpeaEOU_kpe=UNQ@mail.gmail.com>
	<51269166.1010802@oracle.com>
	<CAA0cW5AAsgLDKJPR-uR5Ro79dy+=tGsq-nSPWNBvNmrU4cPhHA@mail.gmail.com>
	<51274B2D.5000803@oracle.com>
Message-ID: <CAA0cW5B+umHodJ9uTLXmuykgojoEWyWP3xd6n7Xws4BQS+YcVA@mail.gmail.com>

Thanks maurizio,
This test shows that the new scheme sucks in resolving method references in
overloaded generic methods contexts. May be we need better scheme, no?

Best Regards,
Ali Ebrahimi

On Fri, Feb 22, 2013 at 3:10 PM, Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

>  I think the test - or  the types in the test, to be more precise, might
> be misleading you. The goal of this test is to check provisional
> applicability of method references, a new applicability step described in
> the spec EDR. When method reference happens to be 'stuck' - that is, when
> its target type contains inference variables in the parameter types of the
> functional descriptor (as it happens to be the case here), the compiler
> revert to a much more brittle applicability scheme. It essentially uses the
> target type to perform an arity based match of the available methods. So,
> assuming the target type is:
>
> SAM<Z>
>
> where Z is an inference variable and SAM is declared as follows:
>
> interface SAM<X> {
>     m(X x)
> }
>
> If you have something like:
>
> Foo::g
>
> whose target is SAM<Z>, the compiler will:
>
> 1) Look at the target type
> 2) See that the method reference is stuck (parameter types of functional
> descriptor contain Z)
> 3) See if Foo has a method matching with a 'jolly' parameter list (*)
> [where * stands for any type]
> 4) If the above condition is satisfied, the method is deemed applicable.
> Most specific then follows, and, once a most specific method has been
> selected you will have a precise check with all the inference bells and
> whistles.
>
> Now, if Foo is a class that has two methods:
>
> g()
> g(String) //any type will do
>
> The arity-based lookup described in (3) will match both methods.
>
> This shows that, since the arity-based lookup is fuzzy (can match methods
> with different arities due to the bound/unbound lookup differences) - it is
> possible for two target types with different arities to both have a match.
> This _doesn't_ mean that the target type will make the method reference
> checkable - it merely means that the provisional applicability step is
> satisfied (which means the method featuring that particular target type as
> formal argument is applicable).
>
> It is possible that, even removing one of the ambiguous methods you still
> get a compiler error down the road, because when the compiler starts to do
> full type-checking of the method reference it realizes something is wrong.
>
> Now, one could argue that if a method reference cannot be type-checked
> against a formal, a method should never be deemed applicable; that's
> possible - and it's the way the compiler used to work (before the overload
> resolution rewrital which happened late last year). However, there are
> situations in which you can't tell as to whether a method would be
> applicable or not unless you look at the target type of the method call.
> And we wanted to preserve the invariant that the outcome of overload
> resolution was still expressible as a function between actual argument
> types and formal argument types. Hence the provisional applicability check
> and the fuzzy arity-based matching.
>
> Of course, all of this only takes place when a method reference is stuck -
> which can only happen if you are calling a generic method.
>
> Maurizio
>
>
>
>
>
> On 21/02/13 22:27, Ali Ebrahimi wrote:
>
> Hi again maurizio,
> if i comment u(Sam2) method then we have one answer u(Sam1), correct?
>
> in that case, we woud have u(Sam1<String>) or u(Sam1<TargetType60>)?
>
> I think in any case this is not correct.
>
> u(Sam1<String>)   => TargetType60 s2 = u(TargetType60::n1);
> method u returns String and not compatible with TargetType60.
>
> u(Sam1<TargetType60>) => we missed n1 String parameter and fail at runtime.
>
>
>
>     interface Sam1<X> {
>         void m(X x);
>     }
>
> void n1(String s) { }
>
> static <U> U u(Sam1<U> s) {    s.m((U)null)     return null; }
>
> static void testUnbound() {
>          TargetType60 s2 = u(TargetType60::n1);
> }
>
> main question: what is receiver of this method reff passed to u(Sam1)?
>
> Best Regards,
> Ali Ebrahimi
>
> On Fri, Feb 22, 2013 at 1:58 AM, Maurizio Cimadamore <
> maurizio.cimadamore at oracle.com> wrote:
>
>>  On 21/02/13 21:16, Ali Ebrahimi wrote:
>>
>> Hi maurizio,
>>
>> are you sure this is ambiguous? I don't think so. (u(Sam2)  is not only
>> answer?)
>>
>> TargetType60 s2 = u(TargetType60::n1); //ambiguous (u(Sam1), u(Sam2)
>> apply)
>>
>>  They both apply - turned out I've misread the spec - the fact that the
>> method is static/non-static should not affect outcome of method reference
>> resolution. So, if target type has parameters P1 ... Pn, we do two lookups:
>>
>> *) one (bound) with P1 ... Pn
>> *) one (unbound) with P2 ... Pn
>>
>> The first lookup will cause the match in u(Sam1), while the second lookup
>> will match u(Sam2). Hence the ambiguity.
>>
>> Maurizio
>>
>>
>>
>> Best Regards,
>> Ali Ebrahimi
>>
>> On Wed, Feb 20, 2013 at 11:49 PM, <maurizio.cimadamore at oracle.com> wrote:
>>
>>> Changeset: 66476d1c5e64
>>> Author:    mcimadamore
>>> Date:      2013-02-20 19:19 +0000
>>> URL:
>>> http://hg.openjdk.java.net/lambda/lambda/langtools/rev/66476d1c5e64
>>>
>>> 8008537: Missing method reference lookup error when unbound search finds
>>> a static method
>>>
>>> ! src/share/classes/com/sun/tools/javac/comp/Attr.java
>>> ! src/share/classes/com/sun/tools/javac/comp/Resolve.java
>>> ! src/share/classes/com/sun/tools/javac/resources/compiler.properties
>>> ! test/tools/javac/diags/examples.not-yet.txt
>>> ! test/tools/javac/diags/examples/NonStaticCantBeRefFragment.java
>>> ! test/tools/javac/lambda/MethodReference22.java
>>> ! test/tools/javac/lambda/MethodReference22.out
>>> ! test/tools/javac/lambda/MethodReference28.out
>>> ! test/tools/javac/lambda/MethodReference51.out
>>> ! test/tools/javac/lambda/TargetType60.java
>>> ! test/tools/javac/lambda/TargetType60.out
>>>
>>>
>>>
>>
>>
>
>

From maurizio.cimadamore at oracle.com  Fri Feb 22 05:01:13 2013
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Fri, 22 Feb 2013 13:01:13 +0000
Subject: hg: lambda/lambda/langtools: 8008537: Missing method reference
	lookup error when unbound search finds a static method
In-Reply-To: <CAA0cW5B+umHodJ9uTLXmuykgojoEWyWP3xd6n7Xws4BQS+YcVA@mail.gmail.com>
References: <20130220192005.A58E947C10@hg.openjdk.java.net>
	<CAA0cW5AmsDPKzOmPnxN4Yvq5VzkbNFzuiU_jpeaEOU_kpe=UNQ@mail.gmail.com>
	<51269166.1010802@oracle.com>
	<CAA0cW5AAsgLDKJPR-uR5Ro79dy+=tGsq-nSPWNBvNmrU4cPhHA@mail.gmail.com>
	<51274B2D.5000803@oracle.com>
	<CAA0cW5B+umHodJ9uTLXmuykgojoEWyWP3xd6n7Xws4BQS+YcVA@mail.gmail.com>
Message-ID: <51276C19.30807@oracle.com>

On 22/02/13 12:40, Ali Ebrahimi wrote:
> Thanks maurizio,
> This test shows that the new scheme sucks in resolving method 
> references in overloaded generic methods contexts. May be we need 
> better scheme, no?
It depends on what you mean by 'sucks' - depends on what you mean by 
'better'. Depends on what kind of complexity you are willing to embrace 
in order to make things work in extreme cases of cyclic inference.

The EG expressed a view that, in some corner cases where there are 
tricky inference dependencies, an ambiguity error is actually better 
than an over-complex resolution scheme that wouldn't fit in anybody's brain.

This scheme seems a reasonable compromise between complexity and 
usefulness. The compiler works in all 'obvious cases' and on most tricky 
ones. There are cases in which the fuzzy arity based check is not enough 
to disambiguate, and that's ok too. In all the cases we have considered 
while developing the Stream API, we felt this was an acceptable 
compromise. Do you have any use cases in mind that would suggest 
otherwise? If so, could you please forward them to the lambda spec 
mailing list, to make sure the EG is aware of those?

Thanks
Maurizio

>
> Best Regards,
> Ali Ebrahimi
>
> On Fri, Feb 22, 2013 at 3:10 PM, Maurizio Cimadamore 
> <maurizio.cimadamore at oracle.com 
> <mailto:maurizio.cimadamore at oracle.com>> wrote:
>
>     I think the test - or  the types in the test, to be more precise,
>     might be misleading you. The goal of this test is to check
>     provisional applicability of method references, a new
>     applicability step described in the spec EDR. When method
>     reference happens to be 'stuck' - that is, when its target type
>     contains inference variables in the parameter types of the
>     functional descriptor (as it happens to be the case here), the
>     compiler revert to a much more brittle applicability scheme. It
>     essentially uses the target type to perform an arity based match
>     of the available methods. So, assuming the target type is:
>
>     SAM<Z>
>
>     where Z is an inference variable and SAM is declared as follows:
>
>     interface SAM<X> {
>         m(X x)
>     }
>
>     If you have something like:
>
>     Foo::g
>
>     whose target is SAM<Z>, the compiler will:
>
>     1) Look at the target type
>     2) See that the method reference is stuck (parameter types of
>     functional descriptor contain Z)
>     3) See if Foo has a method matching with a 'jolly' parameter list
>     (*) [where * stands for any type]
>     4) If the above condition is satisfied, the method is deemed
>     applicable. Most specific then follows, and, once a most specific
>     method has been selected you will have a precise check with all
>     the inference bells and whistles.
>
>     Now, if Foo is a class that has two methods:
>
>     g()
>     g(String) //any type will do
>
>     The arity-based lookup described in (3) will match both methods.
>
>     This shows that, since the arity-based lookup is fuzzy (can match
>     methods with different arities due to the bound/unbound lookup
>     differences) - it is possible for two target types with different
>     arities to both have a match. This _doesn't_ mean that the target
>     type will make the method reference checkable - it merely means
>     that the provisional applicability step is satisfied (which means
>     the method featuring that particular target type as formal
>     argument is applicable).
>
>     It is possible that, even removing one of the ambiguous methods
>     you still get a compiler error down the road, because when the
>     compiler starts to do full type-checking of the method reference
>     it realizes something is wrong.
>
>     Now, one could argue that if a method reference cannot be
>     type-checked against a formal, a method should never be deemed
>     applicable; that's possible - and it's the way the compiler used
>     to work (before the overload resolution rewrital which happened
>     late last year). However, there are situations in which you can't
>     tell as to whether a method would be applicable or not unless you
>     look at the target type of the method call. And we wanted to
>     preserve the invariant that the outcome of overload resolution was
>     still expressible as a function between actual argument types and
>     formal argument types. Hence the provisional applicability check
>     and the fuzzy arity-based matching.
>
>     Of course, all of this only takes place when a method reference is
>     stuck - which can only happen if you are calling a generic method.
>
>     Maurizio
>
>
>
>
>
>     On 21/02/13 22:27, Ali Ebrahimi wrote:
>>     Hi again maurizio,
>>     if i comment u(Sam2) method then we have one answer u(Sam1), correct?
>>
>>     in that case, we woud have u(Sam1<String>) or u(Sam1<TargetType60>)?
>>
>>     I think in any case this is not correct.
>>
>>     u(Sam1<String>)   => TargetType60 s2 = u(TargetType60::n1);
>>     method u returns String and not compatible with TargetType60.
>>
>>     u(Sam1<TargetType60>) => we missed n1 String parameter and fail
>>     at runtime.
>>
>>
>>
>>         interface Sam1<X> {
>>             void m(X x);
>>         }
>>
>>     void n1(String s) { }
>>
>>     static <U> U u(Sam1<U> s) { s.m((U)null)     return null; }
>>
>>     static void testUnbound() {
>>              TargetType60 s2 = u(TargetType60::n1);
>>     }
>>
>>     main question: what is receiver of this method reff passed to
>>     u(Sam1)?
>>
>>     Best Regards,
>>     Ali Ebrahimi
>>
>>     On Fri, Feb 22, 2013 at 1:58 AM, Maurizio Cimadamore
>>     <maurizio.cimadamore at oracle.com
>>     <mailto:maurizio.cimadamore at oracle.com>> wrote:
>>
>>         On 21/02/13 21:16, Ali Ebrahimi wrote:
>>>         Hi maurizio,
>>>
>>>         are you sure this is ambiguous? I don't think so. (u(Sam2) 
>>>         is not only answer?)
>>>
>>>         TargetType60 s2 = u(TargetType60::n1); //ambiguous (u(Sam1),
>>>         u(Sam2) apply)
>>         They both apply - turned out I've misread the spec - the fact
>>         that the method is static/non-static should not affect
>>         outcome of method reference resolution. So, if target type
>>         has parameters P1 ... Pn, we do two lookups:
>>
>>         *) one (bound) with P1 ... Pn
>>         *) one (unbound) with P2 ... Pn
>>
>>         The first lookup will cause the match in u(Sam1), while the
>>         second lookup will match u(Sam2). Hence the ambiguity.
>>
>>         Maurizio
>>
>>>
>>>
>>>         Best Regards,
>>>         Ali Ebrahimi
>>>
>>>         On Wed, Feb 20, 2013 at 11:49 PM,
>>>         <maurizio.cimadamore at oracle.com
>>>         <mailto:maurizio.cimadamore at oracle.com>> wrote:
>>>
>>>             Changeset: 66476d1c5e64
>>>             Author:    mcimadamore
>>>             Date:      2013-02-20 19:19 +0000
>>>             URL:
>>>             http://hg.openjdk.java.net/lambda/lambda/langtools/rev/66476d1c5e64
>>>
>>>             8008537: Missing method reference lookup error when
>>>             unbound search finds a static method
>>>
>>>             ! src/share/classes/com/sun/tools/javac/comp/Attr.java
>>>             ! src/share/classes/com/sun/tools/javac/comp/Resolve.java
>>>             !
>>>             src/share/classes/com/sun/tools/javac/resources/compiler.properties
>>>             ! test/tools/javac/diags/examples.not-yet.txt
>>>             !
>>>             test/tools/javac/diags/examples/NonStaticCantBeRefFragment.java
>>>             ! test/tools/javac/lambda/MethodReference22.java
>>>             ! test/tools/javac/lambda/MethodReference22.out
>>>             ! test/tools/javac/lambda/MethodReference28.out
>>>             ! test/tools/javac/lambda/MethodReference51.out
>>>             ! test/tools/javac/lambda/TargetType60.java
>>>             ! test/tools/javac/lambda/TargetType60.out
>>>
>>>
>>>
>>
>>
>
>


From maurizio.cimadamore at oracle.com  Fri Feb 22 07:37:21 2013
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Fri, 22 Feb 2013 15:37:21 +0000
Subject: hg: lambda/lambda/langtools: 49 new changesets
Message-ID: <20130222153934.85B9747C77@hg.openjdk.java.net>

Changeset: 2d6789a725a4
Author:    ohrstrom
Date:      2013-01-31 14:01 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/2d6789a725a4

8006872: Stop creating four jars with identical content in the new build system.
Reviewed-by: erikj

! makefiles/BuildLangtools.gmk

Changeset: e81839b32337
Author:    katleman
Date:      2013-02-05 18:55 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/e81839b32337

Merge


Changeset: 6fde20398015
Author:    katleman
Date:      2013-02-07 12:33 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/6fde20398015

Added tag jdk8-b76 for changeset e81839b32337

! .hgtags

Changeset: cbcd9b484759
Author:    vromero
Date:      2013-01-27 19:38 +0000
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/cbcd9b484759

8006944: javac, combo tests should print out the number of threads used
Reviewed-by: mcimadamore

! test/tools/javac/lib/JavacTestingAbstractThreadedTest.java

Changeset: 950d8195a5a4
Author:    jjg
Date:      2013-01-30 09:40 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/950d8195a5a4

8007096: DocLint parsing problems with some comments
Reviewed-by: mcimadamore

! src/share/classes/com/sun/tools/javac/parser/DocCommentParser.java
! src/share/classes/com/sun/tools/javac/parser/JavadocTokenizer.java
+ test/tools/doclint/EndWithIdentifierTest.java
+ test/tools/doclint/EndWithIdentifierTest.out
+ test/tools/doclint/UnfinishedInlineTagTest.java
+ test/tools/doclint/UnfinishedInlineTagTest.out

Changeset: c924291865e5
Author:    jjg
Date:      2013-01-30 09:47 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/c924291865e5

8007034: debug printer for javac internals
Reviewed-by: mcimadamore

+ test/tools/javac/lib/DPrinter.java

Changeset: 8e4c22acebeb
Author:    darcy
Date:      2013-01-31 12:16 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/8e4c22acebeb

8007313: Remove use of {ContainerFor/ContainedBy} from langtools
Reviewed-by: jjg

! test/tools/javac/annotations/typeAnnotations/classfile/CombinationsTargetTest1.java
! test/tools/javac/annotations/typeAnnotations/classfile/CombinationsTargetTest2.java
! test/tools/javac/annotations/typeAnnotations/newlocations/RepeatingTypeAnnotations.java
! test/tools/javac/annotations/typeAnnotations/referenceinfos/Driver.java

Changeset: b7cb3d7ade25
Author:    lana
Date:      2013-01-31 10:23 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/b7cb3d7ade25

Merge


Changeset: 7b269e916e06
Author:    lana
Date:      2013-01-31 14:10 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/7b269e916e06

Merge


Changeset: bec996065c45
Author:    darcy
Date:      2013-01-31 18:58 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/bec996065c45

8007351: Malformed copyright statements in typeAnnotations test directory
Reviewed-by: jjg

! test/tools/javac/annotations/typeAnnotations/TargetTypes.java
! test/tools/javac/annotations/typeAnnotations/TypeProcOnly.java
! test/tools/javac/annotations/typeAnnotations/api/AnnotatedArrayOrder.java
! test/tools/javac/annotations/typeAnnotations/api/ArrayCreationTree.java
! test/tools/javac/annotations/typeAnnotations/api/ArrayPositionConsistency.java
! test/tools/javac/annotations/typeAnnotations/classfile/ClassfileTestHelper.java
! test/tools/javac/annotations/typeAnnotations/classfile/CombinationsTargetTest1.java
! test/tools/javac/annotations/typeAnnotations/classfile/CombinationsTargetTest2.java
! test/tools/javac/annotations/typeAnnotations/classfile/NewTypeArguments.java
! test/tools/javac/annotations/typeAnnotations/classfile/NoTargetAnnotations.java
! test/tools/javac/annotations/typeAnnotations/classfile/TypeCasts.java
! test/tools/javac/annotations/typeAnnotations/classfile/Wildcards.java
! test/tools/javac/annotations/typeAnnotations/failures/target/DotClass.java
! test/tools/javac/annotations/typeAnnotations/newlocations/Varargs.java
! test/tools/javac/annotations/typeAnnotations/packageanno/PackageProcessor.java
! test/tools/javac/annotations/typeAnnotations/packageanno/mypackage/Anno.java
! test/tools/javac/annotations/typeAnnotations/packageanno/mypackage/MyClass.java
! test/tools/javac/annotations/typeAnnotations/packageanno/mypackage/package-info.java
! test/tools/javac/annotations/typeAnnotations/referenceinfos/ClassExtends.java
! test/tools/javac/annotations/typeAnnotations/referenceinfos/ClassTypeParam.java
! test/tools/javac/annotations/typeAnnotations/referenceinfos/Constructors.java
! test/tools/javac/annotations/typeAnnotations/referenceinfos/Driver.java
! test/tools/javac/annotations/typeAnnotations/referenceinfos/ExceptionParameters.java
! test/tools/javac/annotations/typeAnnotations/referenceinfos/Fields.java
! test/tools/javac/annotations/typeAnnotations/referenceinfos/FromSpecification.java
! test/tools/javac/annotations/typeAnnotations/referenceinfos/MethodParameters.java
! test/tools/javac/annotations/typeAnnotations/referenceinfos/MethodReceivers.java
! test/tools/javac/annotations/typeAnnotations/referenceinfos/MethodReturns.java
! test/tools/javac/annotations/typeAnnotations/referenceinfos/MethodThrows.java
! test/tools/javac/annotations/typeAnnotations/referenceinfos/MethodTypeParam.java
! test/tools/javac/annotations/typeAnnotations/referenceinfos/MultiCatch.java
! test/tools/javac/annotations/typeAnnotations/referenceinfos/NestedTypes.java
! test/tools/javac/annotations/typeAnnotations/referenceinfos/NewObjects.java
! test/tools/javac/annotations/typeAnnotations/referenceinfos/ReferenceInfoUtil.java
! test/tools/javac/annotations/typeAnnotations/referenceinfos/RepeatingTypeAnnotations.java
! test/tools/javac/annotations/typeAnnotations/referenceinfos/TypeCasts.java
! test/tools/javac/annotations/typeAnnotations/referenceinfos/TypeTests.java

Changeset: 3ab64e4293a1
Author:    jjg
Date:      2013-01-31 19:19 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/3ab64e4293a1

8007329: minor issues in impl class hierarchry for DCTree.* classes
Reviewed-by: darcy

! src/share/classes/com/sun/tools/javac/tree/DCTree.java

Changeset: 3d97a9a7a82b
Author:    jjg
Date:      2013-01-31 19:31 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/3d97a9a7a82b

8004353: Generated html is wrong for overview.html; content has incorrect css footer class
Reviewed-by: jjg
Contributed-by: roger.riggs at oracle.com

! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexWriter.java

Changeset: 8590c20af3ce
Author:    jjg
Date:      2013-02-01 08:33 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/8590c20af3ce

8007306: DPrinter: improve display of impl-class, internal tag/kind, and external tag/kind
Reviewed-by: mcimadamore

! test/tools/javac/lib/DPrinter.java

Changeset: 6df931ce1a81
Author:    jjg
Date:      2013-02-01 08:36 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/6df931ce1a81

8007305: DPrinter: provide better usage message
Reviewed-by: mcimadamore

! test/tools/javac/lib/DPrinter.java

Changeset: 0b1c88705568
Author:    jjg
Date:      2013-02-01 12:01 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/0b1c88705568

8007344: javac may not make tree end positions and/or doc comments available to processors and listeners
Reviewed-by: darcy

! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java
+ test/tools/javac/api/8007344/Test.java

Changeset: 55cca2f38ee6
Author:    darcy
Date:      2013-02-01 13:01 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/55cca2f38ee6

8001614: Include annotation type to documented supported-ness
Reviewed-by: alanb, jjg, tbell

! make/Makefile-classic
! make/build.properties
+ src/share/classes/jdk/Supported.java

Changeset: 4cc73ec94686
Author:    vromero
Date:      2013-02-02 21:04 +0000
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/4cc73ec94686

8005075: Pool.Method, and Pool.Variable redundant Symbol field should be removed
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Symbol.java
! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java
! src/share/classes/com/sun/tools/javac/jvm/Pool.java

Changeset: a51a8dac0a2f
Author:    vromero
Date:      2013-02-03 02:31 +0000
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/a51a8dac0a2f

7199823: javac generates inner class that can't be verified
Reviewed-by: jjg, mcimadamore

! src/share/classes/com/sun/tools/javac/comp/Lower.java
+ test/tools/javac/7199823/InnerClassCannotBeVerified.java

Changeset: 1690928dc560
Author:    jjg
Date:      2013-02-04 15:30 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/1690928dc560

8007490: NPE from DocumentationTool.run
Reviewed-by: darcy

! src/share/classes/com/sun/tools/javadoc/api/JavadocTool.java
! test/tools/javadoc/api/basic/RunTest.java

Changeset: 62d91c13dce2
Author:    jjg
Date:      2013-02-04 18:14 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/62d91c13dce2

8007492: DocumentationTool cannot locate standard doclet when invoked from JRE
Reviewed-by: darcy

! src/share/classes/com/sun/tools/javadoc/api/JavadocTool.java

Changeset: 10619513f51a
Author:    lana
Date:      2013-02-04 22:38 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/10619513f51a

Merge


Changeset: 2480aec9a3f1
Author:    jjh
Date:      2013-02-05 18:55 +0000
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/2480aec9a3f1

8007504: Remove @ignore from tests that no longer need it
Reviewed-by: mcimadamore

! test/tools/javac/api/T6306137.java
! test/tools/javac/defaultMethods/TestNoBridgeOnDefaults.java
! test/tools/javac/lambda/LambdaCapture06.java
! test/tools/javac/lambda/LambdaExpr15.java

Changeset: 89c664151689
Author:    lana
Date:      2013-02-11 16:15 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/89c664151689

Merge


Changeset: bc24411bcc37
Author:    katleman
Date:      2013-02-14 11:44 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/bc24411bcc37

Added tag jdk8-b77 for changeset 89c664151689

! .hgtags

Changeset: de932285124c
Author:    jjg
Date:      2013-02-05 21:55 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/de932285124c

8007485: test creates .class files in the test/ directory
Reviewed-by: mcimadamore

! test/tools/javac/api/8007344/Test.java

Changeset: 1df20330f6bd
Author:    mcimadamore
Date:      2013-02-06 14:03 +0000
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/1df20330f6bd

8007463: Cleanup inference related classes
Summary: Make Infer.InferenceContext an inner class; adjust bound replacement logic in Type.UndetVar
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Type.java
! src/share/classes/com/sun/tools/javac/code/Types.java
! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/Check.java
! src/share/classes/com/sun/tools/javac/comp/DeferredAttr.java
! src/share/classes/com/sun/tools/javac/comp/Infer.java
! src/share/classes/com/sun/tools/javac/comp/Resolve.java
! src/share/classes/com/sun/tools/javac/util/List.java
! test/tools/javac/generics/inference/7154127/T7154127.out
! test/tools/javac/lib/DPrinter.java

Changeset: 8cdd96f2fdb9
Author:    mcimadamore
Date:      2013-02-06 14:04 +0000
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/8cdd96f2fdb9

8007479: Refactor DeferredAttrContext so that it points to parent context
Summary: Move DeferredAttrNode out of DeferredAttrContext; add support for nested deferred contexts
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/DeferredAttr.java
! src/share/classes/com/sun/tools/javac/comp/Infer.java
! src/share/classes/com/sun/tools/javac/comp/Resolve.java

Changeset: 153d20d0cac5
Author:    jjg
Date:      2013-02-06 07:49 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/153d20d0cac5

8007566: DocLint too aggressive with not allowed here: <p>
Reviewed-by: mcimadamore

! src/share/classes/com/sun/tools/doclint/Checker.java
+ test/tools/doclint/ParaTagTest.java

Changeset: b386b8c45387
Author:    jjh
Date:      2013-02-06 23:10 +0000
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/b386b8c45387

8007698: jtreg test T6306137.java won't compile with ASCII encoding
Reviewed-by: ksrini

! test/tools/javac/api/T6306137.java

Changeset: 5125b9854d07
Author:    darcy
Date:      2013-02-07 20:47 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/5125b9854d07

7195131: Update 2 compiler combo tests for repeating annotations to include package and default use cases
Reviewed-by: darcy
Contributed-by: sonali.goel at oracle.com

! test/tools/javac/annotations/repeatingAnnotations/combo/Helper.java
+ test/tools/javac/annotations/repeatingAnnotations/combo/TargetAnnoCombo.java
+ test/tools/javac/annotations/repeatingAnnotations/combo/TestCaseGenerator.java

Changeset: 762d0af062f5
Author:    vromero
Date:      2013-02-08 09:12 +0000
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/762d0af062f5

7166455: javac doesn't set ACC_STRICT bit on <clinit> for strictfp class
Reviewed-by: mcimadamore

! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/Check.java
! src/share/classes/com/sun/tools/javac/jvm/Gen.java
+ test/tools/javac/7166455/CheckACC_STRICTFlagOnclinitTest.java

Changeset: b1deb90d2e37
Author:    vromero
Date:      2013-02-08 09:15 +0000
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/b1deb90d2e37

8005931: javac doesn't set ACC_STRICT for classes with package access
Reviewed-by: mcimadamore

! src/share/classes/com/sun/tools/javac/parser/JavacParser.java
+ test/tools/javac/8005931/CheckACC_STRICTFlagOnPkgAccessClassTest.java

Changeset: 017e8bdd440f
Author:    vromero
Date:      2013-02-08 09:21 +0000
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/017e8bdd440f

7167125: Two variables after the same operation in a inner class return different results
Reviewed-by: jjg, mcimadamore

! src/share/classes/com/sun/tools/javac/comp/Lower.java
+ test/tools/javac/7167125/DiffResultAfterSameOperationInnerClasses.java

Changeset: 60caf53b98e2
Author:    jjg
Date:      2013-02-08 17:35 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/60caf53b98e2

8007610: javadoc doclint does not work with -private
Reviewed-by: darcy

! src/share/classes/com/sun/tools/javadoc/DocEnv.java
! test/com/sun/javadoc/T6735320/T6735320.java
! test/tools/javadoc/doclint/DocLintTest.java

Changeset: 01af1b5c631d
Author:    darcy
Date:      2013-02-11 13:37 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/01af1b5c631d

8007574: Provide isFunctionalInterface in javax.lang.model
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/model/JavacElements.java
! src/share/classes/javax/lang/model/element/TypeElement.java
! src/share/classes/javax/lang/model/util/Elements.java
+ test/tools/javac/processing/model/util/elements/TestIsFunctionalInterface.java

Changeset: 973646bf043a
Author:    jfranck
Date:      2013-02-12 11:28 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/973646bf043a

8004822: RFE to write language model API tests for repeating annotations based on the spec updates
Reviewed-by: jjg, abuckley
Contributed-by: Matherey Nunez <matherey.nunez at oracle.com>

+ test/tools/javac/processing/model/element/repeatingAnnotations/ElementRepAnnoTester.java
+ test/tools/javac/processing/model/element/repeatingAnnotations/MixRepeatableAndOfficialContainerBasicTest.java
+ test/tools/javac/processing/model/element/repeatingAnnotations/MixRepeatableAndOfficialContainerInheritedA1Test.java
+ test/tools/javac/processing/model/element/repeatingAnnotations/MixRepeatableAndOfficialContainerInheritedA2Test.java
+ test/tools/javac/processing/model/element/repeatingAnnotations/MixRepeatableAndOfficialContainerInheritedB1Test.java
+ test/tools/javac/processing/model/element/repeatingAnnotations/MixRepeatableAndOfficialContainerInheritedB2Test.java
+ test/tools/javac/processing/model/element/repeatingAnnotations/MixSingularAndUnofficialContainerBasicTest.java
+ test/tools/javac/processing/model/element/repeatingAnnotations/MixSingularAndUnofficialContainerInheritedA1Test.java
+ test/tools/javac/processing/model/element/repeatingAnnotations/MixSingularAndUnofficialContainerInheritedA2Test.java
+ test/tools/javac/processing/model/element/repeatingAnnotations/MixSingularAndUnofficialContainerInheritedB1Test.java
+ test/tools/javac/processing/model/element/repeatingAnnotations/MixSingularAndUnofficialContainerInheritedB2Test.java
+ test/tools/javac/processing/model/element/repeatingAnnotations/OfficialContainerBasicTest.java
+ test/tools/javac/processing/model/element/repeatingAnnotations/OfficialContainerInheritedTest.java
+ test/tools/javac/processing/model/element/repeatingAnnotations/RepeatableBasicTest.java
+ test/tools/javac/processing/model/element/repeatingAnnotations/RepeatableInheritedTest.java
+ test/tools/javac/processing/model/element/repeatingAnnotations/RepeatableOfficialContainerBasicTest.java
+ test/tools/javac/processing/model/element/repeatingAnnotations/RepeatableOfficialContainerInheritedTest.java
+ test/tools/javac/processing/model/element/repeatingAnnotations/RepeatableOverrideATest.java
+ test/tools/javac/processing/model/element/repeatingAnnotations/RepeatableOverrideBTest.java
+ test/tools/javac/processing/model/element/repeatingAnnotations/SingularBasicTest.java
+ test/tools/javac/processing/model/element/repeatingAnnotations/SingularInheritedATest.java
+ test/tools/javac/processing/model/element/repeatingAnnotations/SingularInheritedBTest.java
+ test/tools/javac/processing/model/element/repeatingAnnotations/UnofficialContainerBasicTest.java
+ test/tools/javac/processing/model/element/repeatingAnnotations/UnofficialContainerInheritedTest.java
+ test/tools/javac/processing/model/element/repeatingAnnotations/supportingAnnotations/Bar.java
+ test/tools/javac/processing/model/element/repeatingAnnotations/supportingAnnotations/BarContainer.java
+ test/tools/javac/processing/model/element/repeatingAnnotations/supportingAnnotations/BarContainerContainer.java
+ test/tools/javac/processing/model/element/repeatingAnnotations/supportingAnnotations/BarInherited.java
+ test/tools/javac/processing/model/element/repeatingAnnotations/supportingAnnotations/BarInheritedContainer.java
+ test/tools/javac/processing/model/element/repeatingAnnotations/supportingAnnotations/BarInheritedContainerContainer.java
+ test/tools/javac/processing/model/element/repeatingAnnotations/supportingAnnotations/ExpectedBase.java
+ test/tools/javac/processing/model/element/repeatingAnnotations/supportingAnnotations/ExpectedContainer.java
+ test/tools/javac/processing/model/element/repeatingAnnotations/supportingAnnotations/Foo.java
+ test/tools/javac/processing/model/element/repeatingAnnotations/supportingAnnotations/FooInherited.java
+ test/tools/javac/processing/model/element/repeatingAnnotations/supportingAnnotations/UnofficialContainer.java
+ test/tools/javac/processing/model/element/repeatingAnnotations/supportingAnnotations/UnofficialInheritedContainer.java

Changeset: 073696f59241
Author:    vromero
Date:      2013-02-12 13:36 +0000
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/073696f59241

8006334: javap, JavapTask constructor breaks with null pointer exception if parameter options is null
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javap/JavapTask.java
+ test/tools/javap/8006334/JavapTaskCtorFailWithNPE.java

Changeset: 2154ed9ff6c8
Author:    mcimadamore
Date:      2013-02-12 19:25 +0000
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/2154ed9ff6c8

8007464: Add graph inference support
Summary: Add support for more aggressive type-inference scheme
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Source.java
! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/DeferredAttr.java
! src/share/classes/com/sun/tools/javac/comp/Infer.java
+ src/share/classes/com/sun/tools/javac/util/GraphUtils.java
! test/tools/javac/6758789/T6758789b.out
! test/tools/javac/Diagnostics/6799605/T6799605.out
! test/tools/javac/diags/examples/CantApplyDiamond1.java
! test/tools/javac/diags/examples/InferredDoNotConformToEq.java
! test/tools/javac/diags/examples/InferredDoNotConformToUpper.java
! test/tools/javac/diags/examples/WhereFreshTvar.java
! test/tools/javac/generics/7015430/T7015430.out
! test/tools/javac/generics/7151802/T7151802.out
! test/tools/javac/generics/diamond/neg/Neg06.out
! test/tools/javac/generics/inference/6278587/T6278587Neg.java
! test/tools/javac/generics/inference/6638712/T6638712d.out
! test/tools/javac/generics/inference/6638712/T6638712e.out
! test/tools/javac/generics/inference/7154127/T7154127.java
! test/tools/javac/generics/inference/7154127/T7154127.out
! test/tools/javac/generics/inference/7177306/T7177306a.out
! test/tools/javac/generics/inference/7177306/T7177306e.java
! test/tools/javac/generics/inference/7177306/T7177306e.out
! test/tools/javac/generics/odersky/BadTest4.java
! test/tools/javac/lambda/TargetType14.out
! test/tools/javac/lambda/TargetType20.java
- test/tools/javac/lambda/TargetType20.out
! test/tools/javac/lambda/TargetType28.out
! test/tools/javac/lambda/TargetType50.java
- test/tools/javac/lambda/TargetType50.out
! test/tools/javac/lambda/TargetType51.java
! test/tools/javac/lambda/TargetType52.java
! test/tools/javac/lambda/TargetType52.out
+ test/tools/javac/lambda/TargetType53.java
+ test/tools/javac/lambda/TargetType54.java
+ test/tools/javac/lambda/TargetType55.java
+ test/tools/javac/lambda/TargetType56.java
+ test/tools/javac/lambda/TargetType57.java
+ test/tools/javac/lambda/TargetType57.out
+ test/tools/javac/lambda/TargetType58.java
+ test/tools/javac/lambda/TargetType59.java
+ test/tools/javac/lambda/TargetType61.java
+ test/tools/javac/lambda/TargetType62.java

Changeset: bc456436c613
Author:    jjg
Date:      2013-02-12 17:15 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/bc456436c613

8008077: update reference impl for type-annotations
Reviewed-by: jjg
Contributed-by: wmdietl at cs.washington.edu

! src/share/classes/com/sun/tools/classfile/ClassWriter.java
! src/share/classes/com/sun/tools/classfile/TypeAnnotation.java
! src/share/classes/com/sun/tools/javac/code/TargetType.java
! src/share/classes/com/sun/tools/javac/code/TypeAnnotationPosition.java
! src/share/classes/com/sun/tools/javac/code/TypeAnnotations.java
! src/share/classes/com/sun/tools/javac/code/Types.java
! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java
! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java
! src/share/classes/com/sun/tools/javac/parser/JavacParser.java
! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java
! src/share/classes/com/sun/tools/javap/AnnotationWriter.java
+ test/tools/javac/annotations/typeAnnotations/failures/LazyConstantValue.java
+ test/tools/javac/annotations/typeAnnotations/failures/TypeVariable.java
! test/tools/javac/annotations/typeAnnotations/failures/VoidGenericMethod.java
+ test/tools/javac/annotations/typeAnnotations/newlocations/Lambda.java
+ test/tools/javac/annotations/typeAnnotations/referenceinfos/Lambda.java
! test/tools/javac/annotations/typeAnnotations/referenceinfos/MethodParameters.java
! test/tools/javac/annotations/typeAnnotations/referenceinfos/TypeCasts.java

Changeset: aeadaf905d78
Author:    jfranck
Date:      2013-02-13 10:33 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/aeadaf905d78

8007279: Rename javax.l.model.element.Element.getAnnotations(Class) to getAnnotationsByType(Class)
Reviewed-by: darcy, abuckley

! src/share/classes/com/sun/tools/javac/code/Symbol.java
! src/share/classes/javax/lang/model/element/Element.java
! test/tools/javac/processing/model/element/repeatingAnnotations/ElementRepAnnoTester.java

Changeset: d04960f05593
Author:    mcimadamore
Date:      2013-02-13 17:04 +0000
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/d04960f05593

8006345: Report Synthesized Parameters in java.lang.reflect.Parameter API
8006896: ClassReader doesn't see MethodParameters attr for method of anon inner class
8007098: Output Synthesized Parameters to MethodParameters Attributes
Summary: Correctly report synthesized and mandated parameters
Reviewed-by: mcimadamore, jjg
Contributed-by: eric.mccorkle at oracle.com

! src/share/classes/com/sun/tools/classfile/AccessFlags.java
! src/share/classes/com/sun/tools/javac/code/Flags.java
! src/share/classes/com/sun/tools/javac/code/Symbol.java
! src/share/classes/com/sun/tools/javac/comp/Lower.java
! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java
! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java
! src/share/classes/com/sun/tools/javap/AttributeWriter.java

Changeset: 3f9875aa5d67
Author:    lana
Date:      2013-02-13 11:25 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/3f9875aa5d67

Merge


Changeset: a3aa32fe4536
Author:    lana
Date:      2013-02-14 22:11 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/a3aa32fe4536

Merge


Changeset: 5f0731e4e5e6
Author:    bpatel
Date:      2013-01-21 00:45 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/5f0731e4e5e6

8006124: javadoc/doclet should be updated to support profiles
Reviewed-by: jjg

! src/share/classes/com/sun/tools/doclets/formats/html/AbstractPackageIndexWriter.java
+ src/share/classes/com/sun/tools/doclets/formats/html/AbstractProfileIndexWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/ClassWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/FrameOutputWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDoclet.java
! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexFrameWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexWriter.java
+ src/share/classes/com/sun/tools/doclets/formats/html/ProfileIndexFrameWriter.java
+ src/share/classes/com/sun/tools/doclets/formats/html/ProfilePackageFrameWriter.java
+ src/share/classes/com/sun/tools/doclets/formats/html/ProfilePackageIndexFrameWriter.java
+ src/share/classes/com/sun/tools/doclets/formats/html/ProfilePackageWriterImpl.java
+ src/share/classes/com/sun/tools/doclets/formats/html/ProfileWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/WriterFactoryImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlConstants.java
! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/resources/standard.properties
! src/share/classes/com/sun/tools/doclets/internal/toolkit/AbstractDoclet.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java
+ src/share/classes/com/sun/tools/doclets/internal/toolkit/ProfilePackageSummaryWriter.java
+ src/share/classes/com/sun/tools/doclets/internal/toolkit/ProfileSummaryWriter.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/WriterFactory.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/BuilderFactory.java
+ src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ProfilePackageSummaryBuilder.java
+ src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ProfileSummaryBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclet.xml
! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclets.properties
! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/stylesheet.css
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocPaths.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/MetaKeywords.java
+ test/com/sun/javadoc/testProfiles/TestProfiles.java
+ test/com/sun/javadoc/testProfiles/pkg1/Class1Pkg1.java
+ test/com/sun/javadoc/testProfiles/pkg1/Class2Pkg1.java
+ test/com/sun/javadoc/testProfiles/pkg1/Class3Pkg1.java
+ test/com/sun/javadoc/testProfiles/pkg1/Interface1Pkg1.java
+ test/com/sun/javadoc/testProfiles/pkg2/Anno1Pkg2.java
+ test/com/sun/javadoc/testProfiles/pkg2/Anno2Pkg2.java
+ test/com/sun/javadoc/testProfiles/pkg2/Class1Pkg2.java
+ test/com/sun/javadoc/testProfiles/pkg3/Class1Pkg3.java
+ test/com/sun/javadoc/testProfiles/pkg3/Class2Pkg3.java
+ test/com/sun/javadoc/testProfiles/pkg3/Interface1Pkg3.java
+ test/com/sun/javadoc/testProfiles/pkg4/Anno1Pkg4.java
+ test/com/sun/javadoc/testProfiles/pkg4/Class1Pkg4.java
+ test/com/sun/javadoc/testProfiles/pkg5/Class1Pkg5.java
+ test/com/sun/javadoc/testProfiles/pkg5/Interface1Pkg5.java
+ test/com/sun/javadoc/testProfiles/profile-rtjar-includes.txt

Changeset: 475eb15dfdad
Author:    jjg
Date:      2013-01-21 01:27 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/475eb15dfdad

8004182: Add support for profiles in javac
Reviewed-by: mcimadamore

! src/share/classes/com/sun/tools/javac/api/JavacTaskImpl.java
! src/share/classes/com/sun/tools/javac/code/Flags.java
! src/share/classes/com/sun/tools/javac/code/Symtab.java
! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/Check.java
! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java
+ src/share/classes/com/sun/tools/javac/jvm/Profile.java
! src/share/classes/com/sun/tools/javac/jvm/Target.java
! src/share/classes/com/sun/tools/javac/main/Main.java
! src/share/classes/com/sun/tools/javac/main/Option.java
! src/share/classes/com/sun/tools/javac/resources/compiler.properties
! src/share/classes/com/sun/tools/javac/resources/javac.properties
! src/share/classes/com/sun/tools/javac/sym/CreateSymbols.java
+ src/share/classes/com/sun/tools/javac/sym/Profiles.java
! src/share/classes/com/sun/tools/javac/util/AbstractDiagnosticFormatter.java
! src/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.java
+ test/tools/javac/diags/examples/NotInProfile.java
+ test/tools/javac/profiles/ProfileOptionTest.java

Changeset: f91144b7da75
Author:    dholmes
Date:      2013-02-04 18:08 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/f91144b7da75

Merge

! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclets.properties
! src/share/classes/com/sun/tools/javac/code/Flags.java
! src/share/classes/com/sun/tools/javac/code/Symtab.java
! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/Check.java
! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java
! src/share/classes/com/sun/tools/javac/resources/compiler.properties
! src/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.java
- test/tools/javac/annotations/repeatingAnnotations/MissingContainedBy.java
- test/tools/javac/annotations/repeatingAnnotations/MissingContainerFor.java
- test/tools/javac/annotations/repeatingAnnotations/UseWrongContainedBy.java
- test/tools/javac/annotations/repeatingAnnotations/UseWrongContainerFor.java
- test/tools/javac/annotations/repeatingAnnotations/WrongContainedBy.java
- test/tools/javac/annotations/repeatingAnnotations/WrongContainerFor.java
- test/tools/javac/diags/examples/ContainedByDocumentedMismatch.java
- test/tools/javac/diags/examples/ContainedByInheritedMismatch.java
- test/tools/javac/diags/examples/ContainedByNoValue.java
- test/tools/javac/diags/examples/ContainedByNonDefault.java
- test/tools/javac/diags/examples/ContainedByRetentionMismatch.java
- test/tools/javac/diags/examples/ContainedByTargetMismatch.java
- test/tools/javac/diags/examples/ContainedByWrongValueType.java
- test/tools/javac/diags/examples/InferredDoNotConformToLower.java
- test/tools/javac/diags/examples/NoUniqueMaximalInstance.java
- test/tools/javac/diags/examples/WrongContainedBy.java
- test/tools/javac/diags/examples/WrongContainerFor.java
- test/tools/javac/lambda/MethodReference26.out
- test/tools/javac/lambda/TargetType06.out
- test/tools/javac/lambda/TargetType11.out
- test/tools/javac/lambda/TargetType45.out
- test/tools/javac/lambda/VoidCompatibility.out
- test/tools/javac/typeAnnotations/newlocations/BasicTest.java
- test/tools/javac/typeAnnotations/newlocations/BasicTest.out

Changeset: af8417e590f4
Author:    dholmes
Date:      2013-02-17 16:44 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/af8417e590f4

Merge

! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexWriter.java
! src/share/classes/com/sun/tools/javac/code/Flags.java
! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/Check.java
! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java
- test/tools/javac/lambda/TargetType20.out
- test/tools/javac/lambda/TargetType50.out

Changeset: eff030f02ab2
Author:    mcimadamore
Date:      2013-02-22 12:32 +0000
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/eff030f02ab2

merge with jdk8-b78

! .hgtags
! make/Makefile-classic
! make/build.properties
! src/share/classes/com/sun/tools/classfile/AccessFlags.java
! src/share/classes/com/sun/tools/classfile/ClassWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/ClassWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/resources/standard.properties
! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclet.xml
! src/share/classes/com/sun/tools/javac/api/JavacTaskImpl.java
! src/share/classes/com/sun/tools/javac/code/Flags.java
! src/share/classes/com/sun/tools/javac/code/Source.java
! src/share/classes/com/sun/tools/javac/code/Symbol.java
! src/share/classes/com/sun/tools/javac/code/Symtab.java
! src/share/classes/com/sun/tools/javac/code/TargetType.java
! src/share/classes/com/sun/tools/javac/code/Type.java
! src/share/classes/com/sun/tools/javac/code/Types.java
! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/Check.java
! src/share/classes/com/sun/tools/javac/comp/DeferredAttr.java
! src/share/classes/com/sun/tools/javac/comp/Infer.java
! src/share/classes/com/sun/tools/javac/comp/Lower.java
! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java
! src/share/classes/com/sun/tools/javac/comp/Resolve.java
! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java
! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java
! src/share/classes/com/sun/tools/javac/jvm/Gen.java
! src/share/classes/com/sun/tools/javac/jvm/Pool.java
! src/share/classes/com/sun/tools/javac/jvm/Target.java
! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java
! src/share/classes/com/sun/tools/javac/main/Main.java
! src/share/classes/com/sun/tools/javac/main/Option.java
! src/share/classes/com/sun/tools/javac/parser/DocCommentParser.java
! src/share/classes/com/sun/tools/javac/parser/JavacParser.java
! src/share/classes/com/sun/tools/javac/resources/compiler.properties
! src/share/classes/com/sun/tools/javac/resources/javac.properties
! src/share/classes/com/sun/tools/javac/sym/CreateSymbols.java
! src/share/classes/com/sun/tools/javac/tree/DCTree.java
! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java
! src/share/classes/com/sun/tools/javac/util/AbstractDiagnosticFormatter.java
! src/share/classes/com/sun/tools/javac/util/List.java
! src/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.java
! src/share/classes/com/sun/tools/javadoc/DocEnv.java
! src/share/classes/com/sun/tools/javap/AttributeWriter.java
! src/share/classes/com/sun/tools/javap/JavapTask.java
! test/tools/javac/6758789/T6758789b.out
! test/tools/javac/Diagnostics/6799605/T6799605.out
! test/tools/javac/defaultMethods/TestNoBridgeOnDefaults.java
! test/tools/javac/diags/examples/CantApplyDiamond1.java
! test/tools/javac/diags/examples/InferredDoNotConformToEq.java
! test/tools/javac/diags/examples/InferredDoNotConformToUpper.java
! test/tools/javac/diags/examples/WhereFreshTvar.java
! test/tools/javac/generics/7015430/T7015430_1.out
! test/tools/javac/generics/7015430/T7015430_2.out
! test/tools/javac/generics/diamond/neg/Neg06.out
! test/tools/javac/generics/inference/6278587/T6278587Neg.java
! test/tools/javac/generics/inference/6638712/T6638712d.out
! test/tools/javac/generics/inference/6638712/T6638712e.out
! test/tools/javac/generics/inference/7154127/T7154127.java
! test/tools/javac/generics/inference/7154127/T7154127.out
! test/tools/javac/generics/inference/7177306/T7177306e.java
! test/tools/javac/generics/odersky/BadTest4.java
! test/tools/javac/lambda/LambdaCapture06.java
! test/tools/javac/lambda/LambdaExpr15.java
! test/tools/javac/lambda/TargetType14.out
! test/tools/javac/lambda/TargetType20.java
! test/tools/javac/lambda/TargetType28.out
! test/tools/javac/lambda/TargetType50.java
! test/tools/javac/lambda/TargetType52.java
! test/tools/javac/lambda/TargetType53.java
! test/tools/javac/lambda/TargetType54.java
! test/tools/javac/lambda/TargetType55.java
! test/tools/javac/lambda/TargetType56.java
! test/tools/javac/lambda/TargetType57.java
! test/tools/javac/lambda/TargetType57.out
! test/tools/javac/lambda/TargetType58.java
! test/tools/javac/lambda/TargetType59.java
! test/tools/javac/lambda/TargetType61.java
! test/tools/javac/lambda/TargetType62.java

Changeset: 4a803280d79d
Author:    mcimadamore
Date:      2013-02-22 15:36 +0000
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/4a803280d79d

8008723: Graph Inference: bad graph calculation leads to assertion error

Also fixed some merge issues:
*) Removed spurious char from examples-not-yet.txt
*) Re-added ignored test

! src/share/classes/com/sun/tools/javac/comp/Infer.java
! test/tools/javac/diags/examples.not-yet.txt
! test/tools/javac/lambda/TargetType53.java
! test/tools/javac/lambda/TargetType54.java
! test/tools/javac/lambda/TargetType58.java
! test/tools/javac/lambda/TargetType59.java
! test/tools/javac/lambda/TargetType62.java


From maurizio.cimadamore at oracle.com  Fri Feb 22 07:41:16 2013
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Fri, 22 Feb 2013 15:41:16 +0000
Subject: hg: lambda/lambda: 9 new changesets
Message-ID: <20130222154116.DD2CB47C78@hg.openjdk.java.net>

Changeset: ffb4d2e95140
Author:    erikj
Date:      2013-02-15 10:40 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/rev/ffb4d2e95140

8005879: Add -DMAC_OS_X_VERSION_MAX_ALLOWED=1070 to builds on Mac
Reviewed-by: ohair

! common/autoconf/generated-configure.sh
! common/autoconf/spec.gmk.in
! common/autoconf/toolchain.m4

Changeset: b0642df54d63
Author:    erikj
Date:      2013-02-18 10:46 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/rev/b0642df54d63

Merge


Changeset: b80abec66e70
Author:    bpatel
Date:      2013-01-21 00:29 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/rev/b80abec66e70

8006124: javadoc/doclet should be updated to support profiles
Reviewed-by: jjg, dholmes

! common/makefiles/javadoc/Javadoc.gmk

Changeset: 7ed0c9db6943
Author:    dholmes
Date:      2013-01-21 01:50 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/rev/7ed0c9db6943

8004265: Add build support for Compact Profiles
Reviewed-by: erikj, ohair

! NewMakefile.gmk
! common/autoconf/generated-configure.sh
! common/makefiles/Main.gmk

Changeset: 2f8fd30f02e6
Author:    dholmes
Date:      2013-01-22 19:30 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/rev/2f8fd30f02e6

Merge

! common/autoconf/generated-configure.sh

Changeset: bebeaa04ab8e
Author:    dholmes
Date:      2013-02-04 18:08 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/rev/bebeaa04ab8e

Merge

! common/autoconf/generated-configure.sh
! common/makefiles/javadoc/Javadoc.gmk

Changeset: 28071e4ca1de
Author:    dholmes
Date:      2013-02-17 16:44 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/rev/28071e4ca1de

Merge

! common/autoconf/generated-configure.sh
! common/makefiles/Main.gmk

Changeset: fd1a5574cf68
Author:    dholmes
Date:      2013-02-18 15:35 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/rev/fd1a5574cf68

Merge

! common/autoconf/generated-configure.sh

Changeset: f97b9845b851
Author:    mcimadamore
Date:      2013-02-22 14:30 +0000
URL:       http://hg.openjdk.java.net/lambda/lambda/rev/f97b9845b851

merge with jdk8-b78

! common/autoconf/generated-configure.sh
! common/makefiles/javadoc/Javadoc.gmk


From maurizio.cimadamore at oracle.com  Fri Feb 22 07:41:42 2013
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Fri, 22 Feb 2013 15:41:42 +0000
Subject: hg: lambda/lambda/jdk: 23 new changesets
Message-ID: <20130222154618.4196D47C80@hg.openjdk.java.net>

Changeset: 90707943f83c
Author:    erikj
Date:      2013-02-15 10:41 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/90707943f83c

8005879: Add -DMAC_OS_X_VERSION_MAX_ALLOWED=1070 to builds on Mac
Reviewed-by: ohair

! make/common/Defs-macosx.gmk

Changeset: 9a693ebd5595
Author:    erikj
Date:      2013-02-18 10:48 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/9a693ebd5595

Merge

- src/macosx/classes/sun/lwawt/macosx/EventDispatchAccess.java
- src/share/classes/java/time/PeriodParser.java
- src/share/classes/java/time/calendar/ChronoDateImpl.java
- src/share/classes/java/time/calendar/HijrahChrono.java
- src/share/classes/java/time/calendar/HijrahDate.java
- src/share/classes/java/time/calendar/HijrahDeviationReader.java
- src/share/classes/java/time/calendar/HijrahEra.java
- src/share/classes/java/time/calendar/JapaneseChrono.java
- src/share/classes/java/time/calendar/JapaneseDate.java
- src/share/classes/java/time/calendar/JapaneseEra.java
- src/share/classes/java/time/calendar/MinguoChrono.java
- src/share/classes/java/time/calendar/MinguoDate.java
- src/share/classes/java/time/calendar/MinguoEra.java
- src/share/classes/java/time/calendar/Ser.java
- src/share/classes/java/time/calendar/ThaiBuddhistChrono.java
- src/share/classes/java/time/calendar/ThaiBuddhistDate.java
- src/share/classes/java/time/calendar/ThaiBuddhistEra.java
- src/share/classes/java/time/calendar/package-info.java
- src/share/classes/java/time/format/DateTimeFormatters.java
- src/share/classes/java/time/format/DateTimePrintException.java
- src/share/classes/java/time/temporal/Chrono.java
- src/share/classes/java/time/temporal/ChronoLocalDate.java
- src/share/classes/java/time/temporal/ChronoLocalDateTime.java
- src/share/classes/java/time/temporal/ChronoLocalDateTimeImpl.java
- src/share/classes/java/time/temporal/ChronoZonedDateTime.java
- src/share/classes/java/time/temporal/ChronoZonedDateTimeImpl.java
- src/share/classes/java/time/temporal/Era.java
- src/share/classes/java/time/temporal/ISOChrono.java
- src/share/classes/java/time/temporal/ISOEra.java
- src/share/classes/java/time/temporal/ISOFields.java
- src/share/classes/java/time/temporal/MonthDay.java
- src/share/classes/java/time/temporal/OffsetDate.java
- src/share/classes/java/time/temporal/OffsetDateTime.java
- src/share/classes/java/time/temporal/OffsetTime.java
- src/share/classes/java/time/temporal/Ser.java
- src/share/classes/java/time/temporal/SimplePeriod.java
- src/share/classes/java/time/temporal/TemporalAdder.java
- src/share/classes/java/time/temporal/TemporalSubtractor.java
- src/share/classes/java/time/temporal/Year.java
- src/share/classes/java/time/temporal/YearMonth.java
- src/share/classes/sun/util/calendar/TzIDOldMapping.java
- test/java/time/META-INF/services/java.time.temporal.Chrono
- test/java/time/tck/java/time/calendar/CopticChrono.java
- test/java/time/tck/java/time/calendar/CopticDate.java
- test/java/time/tck/java/time/calendar/CopticEra.java
- test/java/time/tck/java/time/calendar/TestChronoLocalDate.java
- test/java/time/tck/java/time/calendar/TestChronoLocalDateTime.java
- test/java/time/tck/java/time/calendar/TestHijrahChrono.java
- test/java/time/tck/java/time/calendar/TestJapaneseChrono.java
- test/java/time/tck/java/time/calendar/TestMinguoChrono.java
- test/java/time/tck/java/time/calendar/TestServiceLoader.java
- test/java/time/tck/java/time/calendar/TestThaiBuddhistChrono.java
- test/java/time/tck/java/time/format/TCKDateTimePrintException.java
- test/java/time/tck/java/time/temporal/TCKISOFields.java
- test/java/time/tck/java/time/temporal/TCKMonthDay.java
- test/java/time/tck/java/time/temporal/TCKOffsetDate.java
- test/java/time/tck/java/time/temporal/TCKOffsetDateTime.java
- test/java/time/tck/java/time/temporal/TCKOffsetTime.java
- test/java/time/tck/java/time/temporal/TCKSimplePeriod.java
- test/java/time/tck/java/time/temporal/TCKYear.java
- test/java/time/tck/java/time/temporal/TCKYearMonth.java
- test/java/time/tck/java/time/temporal/TestChrono.java
- test/java/time/tck/java/time/temporal/TestISOChrono.java
- test/java/time/test/java/time/TestPeriodParser.java
- test/java/time/test/java/time/format/TestDateTimeFormatters.java
- test/java/time/test/java/time/format/TestDateTimePrintException.java
- test/java/time/test/java/time/format/TestPadParserDecorator.java
- test/java/time/test/java/time/format/TestZoneIdParser.java
- test/java/time/test/java/time/temporal/TestISOChronoImpl.java
- test/java/time/test/java/time/temporal/TestMonthDay.java
- test/java/time/test/java/time/temporal/TestOffsetDate.java
- test/java/time/test/java/time/temporal/TestOffsetDateTime.java
- test/java/time/test/java/time/temporal/TestOffsetDateTime_instants.java
- test/java/time/test/java/time/temporal/TestOffsetTime.java
- test/java/time/test/java/time/temporal/TestYear.java
- test/java/time/test/java/time/temporal/TestYearMonth.java

Changeset: fb7e3edf22b2
Author:    erikj
Date:      2013-02-18 11:26 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/fb7e3edf22b2

8008294: build-infra: Build-infra closed fails on solaris 11.1
Reviewed-by: ohrstrom, dholmes, tbell

! makefiles/CompileDemos.gmk
! makefiles/CompileNativeLibraries.gmk

Changeset: a23b0df73324
Author:    erikj
Date:      2013-02-18 11:27 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/a23b0df73324

8008295: build-infra: Cleanup in Import.gmk
Reviewed-by: ohrstrom, tbell

! makefiles/Import.gmk

Changeset: 32549d339437
Author:    bpatel
Date:      2013-01-21 00:31 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/32549d339437

8006124: javadoc/doclet should be updated to support profiles
Reviewed-by: jjg, dholmes

! make/docs/Makefile

Changeset: 80afadbf967d
Author:    alanb
Date:      2013-01-21 01:46 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/80afadbf967d

8004182: Add support for profiles in javac
Reviewed-by: dholmes

! make/common/Release.gmk

Changeset: 353b88963430
Author:    dholmes
Date:      2013-01-21 21:54 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/353b88963430

8006651: build-infra: Import.gmk needs to add support for the minimal VM
Reviewed-by: erikj, ohair

! makefiles/Import.gmk

Changeset: 7096f51288ab
Author:    dholmes
Date:      2013-01-21 23:17 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/7096f51288ab

8004265: Add build support for Compact Profiles
Reviewed-by: erikj, ohair

! make/tools/src/build/tools/jarreorder/JarReorder.java
! makefiles/BuildJdk.gmk
! makefiles/CreateJars.gmk
! makefiles/Images.gmk
+ makefiles/ProfileNames.gmk
+ makefiles/Profiles.gmk

Changeset: ccd0aceb1190
Author:    alanb
Date:      2013-01-21 23:20 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/ccd0aceb1190

8003255: (profiles) Update JAR file specification to support profiles
Reviewed-by: dholmes, mchung, ksrini

! src/share/classes/java/net/URLClassLoader.java
! src/share/classes/java/util/jar/Attributes.java
+ src/share/classes/java/util/jar/UnsupportedProfileException.java
! src/share/classes/sun/launcher/LauncherHelper.java
! src/share/classes/sun/launcher/resources/launcher.properties
! src/share/classes/sun/misc/URLClassPath.java
! src/share/classes/sun/tools/jar/Main.java
! src/share/classes/sun/tools/jar/resources/jar.properties
+ test/java/net/URLClassLoader/profiles/Basic.java
+ test/java/net/URLClassLoader/profiles/Lib.java
+ test/java/net/URLClassLoader/profiles/basic.sh
+ test/tools/jar/AddAndUpdateProfile.java
+ test/tools/launcher/profiles/Basic.java
+ test/tools/launcher/profiles/Logging.java
+ test/tools/launcher/profiles/Main.java

Changeset: c024147205f6
Author:    alanb
Date:      2013-01-21 23:21 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/c024147205f6

8003256: (profiles) Add support for profile identification
Reviewed-by: dholmes, mchung, ksrini

! make/java/version/Makefile
! makefiles/GensrcMisc.gmk
! src/share/classes/sun/misc/Version.java.template
+ test/tools/launcher/profiles/VersionCheck.java

Changeset: 4b3434f5f509
Author:    alanb
Date:      2013-01-21 23:23 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/4b3434f5f509

8004931: add/removePropertyChangeListener should not exist in subset Profiles of Java SE
Reviewed-by: dholmes, mchung, ksrini

+ make/tools/src/build/tools/RemoveMethods.java
! makefiles/Tools.gmk
! src/share/classes/java/util/jar/Pack200.java
! src/share/classes/java/util/logging/LogManager.java
+ test/java/util/logging/Reflect.java
+ test/tools/pack200/NoBeans.java
+ test/tools/pack200/Reflect.java

Changeset: d9cfe581c8fe
Author:    alanb
Date:      2013-01-21 23:35 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/d9cfe581c8fe

8004502: Compact Profiles contents
Reviewed-by: dholmes, mchung

+ makefiles/profile-includes.txt
+ makefiles/profile-rtjar-includes.txt
+ test/java/lang/SecurityManager/NoAWT.java
+ test/java/security/cert/CertStore/NoLDAP.java
+ test/javax/management/remote/mandatory/connection/NoIIOP.java
+ test/javax/naming/InitialContext/NoApplet.java
+ test/sun/net/www/protocol/http/NoNTLM.java
+ test/sun/security/ssl/sanity/ciphersuites/NoKerberos.java

Changeset: d1b29d290ebd
Author:    dholmes
Date:      2013-01-22 19:31 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/d1b29d290ebd

Merge


Changeset: 0918d6d9c18b
Author:    dholmes
Date:      2013-01-22 20:04 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/0918d6d9c18b

8006667: Merge issue: Profile attribute need to be examined before custom attributes
Summary: swap profile checking and FXHelper checking
Reviewed-by: alanb

! src/share/classes/sun/launcher/LauncherHelper.java

Changeset: 77668918a388
Author:    dholmes
Date:      2013-02-04 18:08 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/77668918a388

Merge

! make/docs/Makefile
! makefiles/CreateJars.gmk
! makefiles/GensrcMisc.gmk
! makefiles/Tools.gmk
! src/share/classes/sun/misc/URLClassPath.java
- test/java/rmi/activation/ActivationSystem/unregisterGroup/CallbackInterface.java
- test/java/rmi/activation/ActivationSystem/unregisterGroup/Callback_Stub.java
- test/java/rmi/activation/ActivationSystem/unregisterGroup/UnregisterGroup_Stub.java

Changeset: f308a689c049
Author:    dholmes
Date:      2013-02-17 16:44 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/f308a689c049

Merge

! makefiles/Tools.gmk
- src/macosx/classes/sun/lwawt/macosx/EventDispatchAccess.java
- src/share/classes/java/lang/annotation/ContainedBy.java
- src/share/classes/java/lang/annotation/ContainerFor.java
- src/share/classes/java/time/PeriodParser.java
- src/share/classes/java/time/calendar/ChronoDateImpl.java
- src/share/classes/java/time/calendar/HijrahChrono.java
- src/share/classes/java/time/calendar/HijrahDate.java
- src/share/classes/java/time/calendar/HijrahDeviationReader.java
- src/share/classes/java/time/calendar/HijrahEra.java
- src/share/classes/java/time/calendar/JapaneseChrono.java
- src/share/classes/java/time/calendar/JapaneseDate.java
- src/share/classes/java/time/calendar/JapaneseEra.java
- src/share/classes/java/time/calendar/MinguoChrono.java
- src/share/classes/java/time/calendar/MinguoDate.java
- src/share/classes/java/time/calendar/MinguoEra.java
- src/share/classes/java/time/calendar/Ser.java
- src/share/classes/java/time/calendar/ThaiBuddhistChrono.java
- src/share/classes/java/time/calendar/ThaiBuddhistDate.java
- src/share/classes/java/time/calendar/ThaiBuddhistEra.java
- src/share/classes/java/time/calendar/package-info.java
- src/share/classes/java/time/format/DateTimeFormatters.java
- src/share/classes/java/time/format/DateTimePrintException.java
- src/share/classes/java/time/temporal/Chrono.java
- src/share/classes/java/time/temporal/ChronoLocalDate.java
- src/share/classes/java/time/temporal/ChronoLocalDateTime.java
- src/share/classes/java/time/temporal/ChronoLocalDateTimeImpl.java
- src/share/classes/java/time/temporal/ChronoZonedDateTime.java
- src/share/classes/java/time/temporal/ChronoZonedDateTimeImpl.java
- src/share/classes/java/time/temporal/Era.java
- src/share/classes/java/time/temporal/ISOChrono.java
- src/share/classes/java/time/temporal/ISOEra.java
- src/share/classes/java/time/temporal/ISOFields.java
- src/share/classes/java/time/temporal/MonthDay.java
- src/share/classes/java/time/temporal/OffsetDate.java
- src/share/classes/java/time/temporal/OffsetDateTime.java
- src/share/classes/java/time/temporal/OffsetTime.java
- src/share/classes/java/time/temporal/Ser.java
- src/share/classes/java/time/temporal/SimplePeriod.java
- src/share/classes/java/time/temporal/TemporalAdder.java
- src/share/classes/java/time/temporal/TemporalSubtractor.java
- src/share/classes/java/time/temporal/Year.java
- src/share/classes/java/time/temporal/YearMonth.java
- src/share/classes/sun/util/calendar/TzIDOldMapping.java
- test/java/net/URL/abnormal_http_urls
- test/java/net/URL/ftp_urls
- test/java/net/URL/jar_urls
- test/java/net/URL/normal_http_urls
- test/java/net/URL/runconstructor.sh
- test/java/net/URL/share_file_urls
- test/java/net/URL/win32_file_urls
- test/java/time/META-INF/services/java.time.temporal.Chrono
- test/java/time/tck/java/time/calendar/CopticChrono.java
- test/java/time/tck/java/time/calendar/CopticDate.java
- test/java/time/tck/java/time/calendar/CopticEra.java
- test/java/time/tck/java/time/calendar/TestChronoLocalDate.java
- test/java/time/tck/java/time/calendar/TestChronoLocalDateTime.java
- test/java/time/tck/java/time/calendar/TestHijrahChrono.java
- test/java/time/tck/java/time/calendar/TestJapaneseChrono.java
- test/java/time/tck/java/time/calendar/TestMinguoChrono.java
- test/java/time/tck/java/time/calendar/TestServiceLoader.java
- test/java/time/tck/java/time/calendar/TestThaiBuddhistChrono.java
- test/java/time/tck/java/time/format/TCKDateTimePrintException.java
- test/java/time/tck/java/time/temporal/TCKISOFields.java
- test/java/time/tck/java/time/temporal/TCKMonthDay.java
- test/java/time/tck/java/time/temporal/TCKOffsetDate.java
- test/java/time/tck/java/time/temporal/TCKOffsetDateTime.java
- test/java/time/tck/java/time/temporal/TCKOffsetTime.java
- test/java/time/tck/java/time/temporal/TCKSimplePeriod.java
- test/java/time/tck/java/time/temporal/TCKYear.java
- test/java/time/tck/java/time/temporal/TCKYearMonth.java
- test/java/time/tck/java/time/temporal/TestChrono.java
- test/java/time/tck/java/time/temporal/TestISOChrono.java
- test/java/time/test/java/time/TestPeriodParser.java
- test/java/time/test/java/time/format/TestDateTimeFormatters.java
- test/java/time/test/java/time/format/TestDateTimePrintException.java
- test/java/time/test/java/time/format/TestPadParserDecorator.java
- test/java/time/test/java/time/format/TestZoneIdParser.java
- test/java/time/test/java/time/temporal/TestISOChronoImpl.java
- test/java/time/test/java/time/temporal/TestMonthDay.java
- test/java/time/test/java/time/temporal/TestOffsetDate.java
- test/java/time/test/java/time/temporal/TestOffsetDateTime.java
- test/java/time/test/java/time/temporal/TestOffsetDateTime_instants.java
- test/java/time/test/java/time/temporal/TestOffsetTime.java
- test/java/time/test/java/time/temporal/TestYear.java
- test/java/time/test/java/time/temporal/TestYearMonth.java
- test/sun/net/www/EncDec.doc
- test/sun/net/www/MarkResetTest.java
- test/sun/net/www/MarkResetTest.sh
- test/sun/security/util/Oid/S11N.sh
- test/sun/security/util/Oid/SerialTest.java

Changeset: 16c684b2ab82
Author:    alanb
Date:      2013-02-18 08:57 +0000
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/16c684b2ab82

8007436: (profiles) Add JSR-310 to Compact Profiles contents
Reviewed-by: dholmes, erikj

! makefiles/profile-includes.txt
! makefiles/profile-rtjar-includes.txt

Changeset: c24bc91caa67
Author:    dholmes
Date:      2013-02-18 15:35 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/c24bc91caa67

Merge

! makefiles/Import.gmk

Changeset: b46c75e221c7
Author:    dholmes
Date:      2013-02-19 06:27 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/b46c75e221c7

8008424: Isolate PROFILE make variable from incidental setting in the environment
Reviewed-by: erikj, alanb

! makefiles/BuildJdk.gmk

Changeset: 6f4615fd32da
Author:    alanb
Date:      2013-02-19 11:08 +0000
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/6f4615fd32da

8007097: (profiles) Build needs test to ensure that profile definitions are updated
Reviewed-by: dholmes, erikj

- make/tools/src/build/tools/RemoveMethods.java
+ make/tools/src/build/tools/classfile/RemoveMethods.java
+ make/tools/src/build/tools/deps/CheckDeps.java
+ make/tools/src/build/tools/deps/refs.allowed
! makefiles/Images.gmk
! makefiles/Tools.gmk
! makefiles/profile-rtjar-includes.txt

Changeset: 033f2707ef32
Author:    alanb
Date:      2013-02-19 11:32 +0000
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/033f2707ef32

Merge


Changeset: 00b7535d743f
Author:    dholmes
Date:      2013-02-19 17:32 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/00b7535d743f

8008481: Dependency analyzer needs exclusion for profile builds with JFR disabled
Reviewed-by: alanb

! make/tools/src/build/tools/deps/refs.allowed

Changeset: ecc9a27d4b83
Author:    mcimadamore
Date:      2013-02-22 14:33 +0000
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/ecc9a27d4b83

merge with jdk8-b78

! make/common/Release.gmk
! make/docs/Makefile


From maurizio.cimadamore at oracle.com  Fri Feb 22 08:45:45 2013
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Fri, 22 Feb 2013 16:45:45 +0000
Subject: hg: lambda/lambda/jdk: 8005968: Write tests for static methods in
	interfaces
Message-ID: <20130222164606.51F6647C8C@hg.openjdk.java.net>

Changeset: 1dd294588d0c
Author:    mcimadamore
Date:      2013-02-22 16:45 +0000
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/1dd294588d0c

8005968: Write tests for static methods in interfaces
Reviewed-by: mcimadamore
Contributed-by: sonali.goel at oracle.com

+ combo-tests/tests/tools/javac/lambda/StaticMethodTest.java


From maurizio.cimadamore at oracle.com  Fri Feb 22 08:58:41 2013
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Fri, 22 Feb 2013 16:58:41 +0000
Subject: hg: lambda/lambda/langtools: 8008708: Regression: separate
	compilation causes crash in wildcards inference logic
Message-ID: <20130222165848.3EEA947C99@hg.openjdk.java.net>

Changeset: 37abd4f2b379
Author:    mcimadamore
Date:      2013-02-22 16:57 +0000
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/37abd4f2b379

8008708: Regression: separate compilation causes crash in wildcards inference logic

! src/share/classes/com/sun/tools/javac/code/Types.java
+ test/tools/javac/lambda/MethodReference64.java
+ test/tools/javac/lambda/MethodReference64.out
+ test/tools/javac/lambda/TargetType65.java
+ test/tools/javac/lambda/separate/Foo.java
+ test/tools/javac/lambda/separate/Test.java


From brian.goetz at oracle.com  Fri Feb 22 09:34:14 2013
From: brian.goetz at oracle.com (brian.goetz at oracle.com)
Date: Fri, 22 Feb 2013 17:34:14 +0000
Subject: hg: lambda/lambda/jdk: Fixes for out-of-memory;
	aggressively null task and spliterator references on task completion,
	don't retain child tasks at all in ForEach
Message-ID: <20130222173441.D0B4B47CC4@hg.openjdk.java.net>

Changeset: 9df184b39d16
Author:    briangoetz
Date:      2013-02-22 12:33 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/9df184b39d16

Fixes for out-of-memory; aggressively null task and spliterator references on task completion, don't retain child tasks at all in ForEach

! src/share/classes/java/util/stream/AbstractTask.java
! src/share/classes/java/util/stream/FindOp.java
! src/share/classes/java/util/stream/NodeUtils.java
! src/share/classes/java/util/stream/OpUtils.java
! src/share/classes/java/util/stream/SliceOp.java


From zhong.j.yu at gmail.com  Fri Feb 22 09:44:24 2013
From: zhong.j.yu at gmail.com (Zhong Yu)
Date: Fri, 22 Feb 2013 11:44:24 -0600
Subject: Generalized transformation of a Stream<X> into a Stream<Y>, with
	lazy evaluation and stateful transformation functions
In-Reply-To: <CAKJVG8Yazqxoo4n+v=Q_Ebph5Rfbde2aRWbX7CkL2P+WcGNeXg@mail.gmail.com>
References: <CAKJVG8Yazqxoo4n+v=Q_Ebph5Rfbde2aRWbX7CkL2P+WcGNeXg@mail.gmail.com>
Message-ID: <CACuKZqFjQQKZ2SO55fj82M1ZVMqjWdwXaf42fuPNu4B_uO9mxQ@mail.gmail.com>

A cheap workaround I can think of is to append a sentinel EOF object
at the end of stream; the flat mapper reacts to EOF and conclude its
job. This is in line with the idiom of parsing InputStreams.

Zhong Yu

From brian.goetz at oracle.com  Fri Feb 22 10:00:09 2013
From: brian.goetz at oracle.com (brian.goetz at oracle.com)
Date: Fri, 22 Feb 2013 18:00:09 +0000
Subject: hg: lambda/lambda/jdk: Rename FoldOp to ReduceOp
Message-ID: <20130222180031.78D8947CC6@hg.openjdk.java.net>

Changeset: 5c97c99f2d72
Author:    briangoetz
Date:      2013-02-22 12:59 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/5c97c99f2d72

Rename FoldOp to ReduceOp

! src/share/classes/java/util/stream/Collectors.java
! src/share/classes/java/util/stream/DoublePipeline.java
- src/share/classes/java/util/stream/FoldOp.java
! src/share/classes/java/util/stream/IntPipeline.java
! src/share/classes/java/util/stream/LongPipeline.java
+ src/share/classes/java/util/stream/ReduceOp.java
! src/share/classes/java/util/stream/ReferencePipeline.java


From paul.sandoz at oracle.com  Fri Feb 22 10:09:48 2013
From: paul.sandoz at oracle.com (paul.sandoz at oracle.com)
Date: Fri, 22 Feb 2013 18:09:48 +0000
Subject: hg: lambda/lambda/jdk: 3 new changesets
Message-ID: <20130222181024.1B75C47CC7@hg.openjdk.java.net>

Changeset: c08707396c40
Author:    psandoz
Date:      2013-02-22 18:41 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/c08707396c40

Spliterator updates
Contributed-by: Doug Lea <dl at cs.oswego.edu>

! src/share/classes/java/util/concurrent/ArrayBlockingQueue.java
! src/share/classes/java/util/concurrent/ConcurrentLinkedDeque.java
! src/share/classes/java/util/concurrent/PriorityBlockingQueue.java

Changeset: 8c3211b22686
Author:    psandoz
Date:      2013-02-22 18:53 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/8c3211b22686

- Consolidate array-based and iterator-based spliterators into
java.util.Spliterators.
- Update primitive array-based and iterator-based spliterators.

! src/share/classes/java/io/BufferedReader.java
! src/share/classes/java/lang/CharSequence.java
! src/share/classes/java/nio/file/DirectoryStream.java
! src/share/classes/java/nio/file/Files.java
! src/share/classes/java/util/Arrays.java
! src/share/classes/java/util/BitSet.java
! src/share/classes/java/util/Collection.java
! src/share/classes/java/util/Collections.java
! src/share/classes/java/util/HashMap.java
! src/share/classes/java/util/LinkedHashSet.java
! src/share/classes/java/util/LinkedList.java
! src/share/classes/java/util/List.java
+ src/share/classes/java/util/PrimitiveIterator.java
! src/share/classes/java/util/Set.java
! src/share/classes/java/util/SortedSet.java
+ src/share/classes/java/util/Spliterators.java
! src/share/classes/java/util/concurrent/ArrayBlockingQueue.java
! src/share/classes/java/util/concurrent/ConcurrentLinkedDeque.java
! src/share/classes/java/util/concurrent/ConcurrentLinkedQueue.java
! src/share/classes/java/util/concurrent/CopyOnWriteArrayList.java
! src/share/classes/java/util/concurrent/CopyOnWriteArraySet.java
! src/share/classes/java/util/concurrent/LinkedBlockingDeque.java
! src/share/classes/java/util/concurrent/LinkedBlockingQueue.java
! src/share/classes/java/util/concurrent/LinkedTransferQueue.java
! src/share/classes/java/util/concurrent/PriorityBlockingQueue.java
! src/share/classes/java/util/concurrent/SynchronousQueue.java
! src/share/classes/java/util/stream/DoublePipeline.java
! src/share/classes/java/util/stream/DoubleStream.java
! src/share/classes/java/util/stream/IntPipeline.java
! src/share/classes/java/util/stream/IntStream.java
! src/share/classes/java/util/stream/LongPipeline.java
! src/share/classes/java/util/stream/LongStream.java
! src/share/classes/java/util/stream/Nodes.java
! src/share/classes/java/util/stream/ReferencePipeline.java
! src/share/classes/java/util/stream/SpinedBuffer.java
- src/share/classes/java/util/stream/Spliterators.java
! src/share/classes/java/util/stream/Stream.java
+ src/share/classes/java/util/stream/StreamSpliterators.java
! src/share/classes/java/util/stream/Streams.java
! test-ng/bootlib/java/util/stream/DoubleStreamTestData.java
! test-ng/bootlib/java/util/stream/DoubleStreamTestDataProvider.java
! test-ng/bootlib/java/util/stream/DoubleStreamTestScenario.java
! test-ng/bootlib/java/util/stream/IntStreamTestData.java
! test-ng/bootlib/java/util/stream/IntStreamTestDataProvider.java
! test-ng/bootlib/java/util/stream/IntStreamTestScenario.java
! test-ng/bootlib/java/util/stream/LambdaTestHelpers.java
! test-ng/bootlib/java/util/stream/LongStreamTestData.java
! test-ng/bootlib/java/util/stream/LongStreamTestDataProvider.java
! test-ng/bootlib/java/util/stream/LongStreamTestScenario.java
! test-ng/bootlib/java/util/stream/OpTestCase.java
! test-ng/bootlib/java/util/stream/StreamTestDataProvider.java
! test-ng/boottests/java/util/stream/DoubleNodeTest.java
! test-ng/boottests/java/util/stream/IntNodeTest.java
! test-ng/boottests/java/util/stream/LongNodeTest.java
! test-ng/boottests/java/util/stream/SpinedBufferTest.java
! test-ng/tests/org/openjdk/tests/java/lang/CharSequenceStreamTest.java
! test-ng/tests/org/openjdk/tests/java/util/BitsetStreamTest.java
! test-ng/tests/org/openjdk/tests/java/util/stream/CollectionAndMapModifyStreamTest.java
! test-ng/tests/org/openjdk/tests/java/util/stream/FindAnyOpTest.java
! test-ng/tests/org/openjdk/tests/java/util/stream/FindFirstOpTest.java
! test-ng/tests/org/openjdk/tests/java/util/stream/MatchOpTest.java
! test-ng/tests/org/openjdk/tests/java/util/stream/SortedOpTest.java
! test/java/util/stream/Stream/IntegerStreamTest.java
! test/java/util/stream/Streams/BasicTest.java

Changeset: 418a74c46029
Author:    psandoz
Date:      2013-02-22 19:01 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/418a74c46029

Automated merge with http://hg.openjdk.java.net/lambda/lambda//jdk

! src/share/classes/java/util/stream/DoublePipeline.java
! src/share/classes/java/util/stream/IntPipeline.java
! src/share/classes/java/util/stream/LongPipeline.java
! src/share/classes/java/util/stream/ReferencePipeline.java
- src/share/classes/java/util/stream/Spliterators.java


From brian.goetz at oracle.com  Fri Feb 22 10:20:12 2013
From: brian.goetz at oracle.com (brian.goetz at oracle.com)
Date: Fri, 22 Feb 2013 18:20:12 +0000
Subject: hg: lambda/lambda/jdk: 2 new changesets
Message-ID: <20130222182049.8322847CC9@hg.openjdk.java.net>

Changeset: 752249e6e1d9
Author:    briangoetz
Date:      2013-02-22 13:17 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/752249e6e1d9

Doc nits based on review comments

! src/share/classes/java/util/stream/DistinctOp.java
! src/share/classes/java/util/stream/IntermediateOp.java
! src/share/classes/java/util/stream/StatefulOp.java
! src/share/classes/java/util/stream/Stream.java
! src/share/classes/java/util/stream/TerminalOp.java

Changeset: 9b2d5bf5f4d9
Author:    briangoetz
Date:      2013-02-22 13:20 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/9b2d5bf5f4d9

Merge

- src/share/classes/java/util/stream/Spliterators.java
! src/share/classes/java/util/stream/Stream.java


From ricky.clarkson at gmail.com  Fri Feb 22 12:23:32 2013
From: ricky.clarkson at gmail.com (Ricky Clarkson)
Date: Fri, 22 Feb 2013 17:23:32 -0300
Subject: To reuse a stream
Message-ID: <CAOBi2H-u8NZ-4sYZ1COSmZhAs1cnNNzREVzUe2iKmQUvrDL8tA@mail.gmail.com>

Hi,

If I run the following:

IntStream numbers = Streams.intRange(2, Integer.MAX_VALUE);
IntStream primes = numbers.filter(x -> x < 3 ||
numbers.limit(x).noneMatch(y -> x % y == 0));
primes.limit(100).forEach(System.out::println);

I get an IllegalStateException at the forEach call: Stream is already
linked to a child stream, which was a surprise.  I guessed that the problem
is that I'm using the same stream twice recursively.  The following works
fine:

IntStream numbers = Streams.intRange(2, Integer.MAX_VALUE);
IntStream primes = numbers.filter(x -> x < 3 || Streams.intRange(2, x -
1).noneMatch(y -> x % y == 0));
primes.limit(100).forEach(System.out::println);

This seems an odd design, I wouldn't naturally expect such a Stream to have
a problem with concurrent/recursive use.  It means that a Stream is an
object I need to protect/manage the ownership of, like an Iterator, and not
so much like an Iterable, even if the underlying data source is immutable.
 Is this deliberate?  If so will there be another abstraction that can be
used and shared more freely?

Ricky.

From brian.goetz at oracle.com  Fri Feb 22 13:01:22 2013
From: brian.goetz at oracle.com (Brian Goetz)
Date: Fri, 22 Feb 2013 16:01:22 -0500
Subject: To reuse a stream
In-Reply-To: <CAOBi2H-u8NZ-4sYZ1COSmZhAs1cnNNzREVzUe2iKmQUvrDL8tA@mail.gmail.com>
References: <CAOBi2H-u8NZ-4sYZ1COSmZhAs1cnNNzREVzUe2iKmQUvrDL8tA@mail.gmail.com>
Message-ID: <5127DCA2.2090805@oracle.com>

The fundamental question here is: whether a Stream is more like an 
Iterable, or an Iterator.  And it has been definitively answered -- the 
latter.

We flirted with a design that put Stream methods on Iterable, and it had 
all sorts of problems, many of which come down to: a Stream has no clue 
what its source is or whether it is repeatable -- and shouldn't.  (Note 
that the specification for iterator() in Iterable isn't even clear on 
this either.)

The word "stream" indicates a flow; the values flow by, and once a value 
has gone by, its gone.

If your source is repeatable (say, an immutable collection), then you 
don't need a new abstraction -- just keep calling c.stream() on your 
collection.

More generally, you can always use Supplier to add the level of 
indirection you seek:

   Supplier<IntStream> streamMaker
       = () -> Streams.intRange(2, MAX_VALUE);

And then you can call streamMaker.get() as many times as you like. 
There's no need for a StreamMaker / StreamSource / Streamable abstraction.


On 2/22/2013 3:23 PM, Ricky Clarkson wrote:
> Hi,
>
> If I run the following:
>
> IntStream numbers = Streams.intRange(2, Integer.MAX_VALUE);
> IntStream primes = numbers.filter(x -> x < 3 ||
> numbers.limit(x).noneMatch(y -> x % y == 0));
> primes.limit(100).forEach(System.out::println);
>
> I get an IllegalStateException at the forEach call: Stream is already
> linked to a child stream, which was a surprise.  I guessed that the problem
> is that I'm using the same stream twice recursively.  The following works
> fine:
>
> IntStream numbers = Streams.intRange(2, Integer.MAX_VALUE);
> IntStream primes = numbers.filter(x -> x < 3 || Streams.intRange(2, x -
> 1).noneMatch(y -> x % y == 0));
> primes.limit(100).forEach(System.out::println);
>
> This seems an odd design, I wouldn't naturally expect such a Stream to have
> a problem with concurrent/recursive use.  It means that a Stream is an
> object I need to protect/manage the ownership of, like an Iterator, and not
> so much like an Iterable, even if the underlying data source is immutable.
>   Is this deliberate?  If so will there be another abstraction that can be
> used and shared more freely?
>
> Ricky.
>

From ricky.clarkson at gmail.com  Fri Feb 22 13:06:24 2013
From: ricky.clarkson at gmail.com (Ricky Clarkson)
Date: Fri, 22 Feb 2013 18:06:24 -0300
Subject: To reuse a stream
In-Reply-To: <5127DCA2.2090805@oracle.com>
References: <CAOBi2H-u8NZ-4sYZ1COSmZhAs1cnNNzREVzUe2iKmQUvrDL8tA@mail.gmail.com>
	<5127DCA2.2090805@oracle.com>
Message-ID: <CAOBi2H-BVzUGZGhVuZL2Pq9FiEvpFs1vavKhAyX-ZqYAfXAwrQ@mail.gmail.com>

Thank you for the answer, a Supplier does indeed work for what I want.


On Fri, Feb 22, 2013 at 6:01 PM, Brian Goetz <brian.goetz at oracle.com> wrote:

> The fundamental question here is: whether a Stream is more like an
> Iterable, or an Iterator.  And it has been definitively answered -- the
> latter.
>
> We flirted with a design that put Stream methods on Iterable, and it had
> all sorts of problems, many of which come down to: a Stream has no clue
> what its source is or whether it is repeatable -- and shouldn't.  (Note
> that the specification for iterator() in Iterable isn't even clear on this
> either.)
>
> The word "stream" indicates a flow; the values flow by, and once a value
> has gone by, its gone.
>
> If your source is repeatable (say, an immutable collection), then you
> don't need a new abstraction -- just keep calling c.stream() on your
> collection.
>
> More generally, you can always use Supplier to add the level of
> indirection you seek:
>
>   Supplier<IntStream> streamMaker
>       = () -> Streams.intRange(2, MAX_VALUE);
>
> And then you can call streamMaker.get() as many times as you like. There's
> no need for a StreamMaker / StreamSource / Streamable abstraction.
>
>
>
> On 2/22/2013 3:23 PM, Ricky Clarkson wrote:
>
>> Hi,
>>
>> If I run the following:
>>
>> IntStream numbers = Streams.intRange(2, Integer.MAX_VALUE);
>> IntStream primes = numbers.filter(x -> x < 3 ||
>> numbers.limit(x).noneMatch(y -> x % y == 0));
>> primes.limit(100).forEach(**System.out::println);
>>
>> I get an IllegalStateException at the forEach call: Stream is already
>> linked to a child stream, which was a surprise.  I guessed that the
>> problem
>> is that I'm using the same stream twice recursively.  The following works
>> fine:
>>
>> IntStream numbers = Streams.intRange(2, Integer.MAX_VALUE);
>> IntStream primes = numbers.filter(x -> x < 3 || Streams.intRange(2, x -
>> 1).noneMatch(y -> x % y == 0));
>> primes.limit(100).forEach(**System.out::println);
>>
>> This seems an odd design, I wouldn't naturally expect such a Stream to
>> have
>> a problem with concurrent/recursive use.  It means that a Stream is an
>> object I need to protect/manage the ownership of, like an Iterator, and
>> not
>> so much like an Iterable, even if the underlying data source is immutable.
>>   Is this deliberate?  If so will there be another abstraction that can be
>> used and shared more freely?
>>
>> Ricky.
>>
>>

From brian.goetz at oracle.com  Fri Feb 22 13:59:44 2013
From: brian.goetz at oracle.com (brian.goetz at oracle.com)
Date: Fri, 22 Feb 2013 21:59:44 +0000
Subject: hg: lambda/lambda/jdk: Simplify TerminalSink and AccumulatingSink
	protocols;
	replace explicit clear-state calls with more aggressive nulling of
	intermediate containers
Message-ID: <20130222220008.DB2D747D2B@hg.openjdk.java.net>

Changeset: f2d99a1cee33
Author:    briangoetz
Date:      2013-02-22 16:59 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/f2d99a1cee33

Simplify TerminalSink and AccumulatingSink protocols; replace explicit clear-state calls with more aggressive nulling of intermediate containers

! src/share/classes/java/util/stream/DistinctOp.java
! src/share/classes/java/util/stream/FindOp.java
! src/share/classes/java/util/stream/ForEachOp.java
! src/share/classes/java/util/stream/OpUtils.java
! src/share/classes/java/util/stream/ReduceOp.java
! src/share/classes/java/util/stream/TerminalSink.java


From dhananjay.nene at gmail.com  Fri Feb 22 14:08:20 2013
From: dhananjay.nene at gmail.com (Dhananjay Nene)
Date: Sat, 23 Feb 2013 03:38:20 +0530
Subject: How to return the result of a map? Are there any predefined
	collectors?
Message-ID: <CAD2aR4P3PoZDjbf5ziadFwrxx0wUMXPMVUfqgex1pjOLHmRN3Q@mail.gmail.com>

I am using build b78

The result of a sequence of map operations is a Stream<T>. However I needed
to cast the functions explicitly as follows

Stream<Integer> doubles =
Arrays.asList(1,2,3,4).stream().map((Function<Integer, Integer>) n -> n *
2).map((Function<Integer, Integer>) n -> n + 1);

Q1. Is there a way to avoid the cast Function<Integer, Integer> here?

Also I wanted to convert the stream into a List. I understood the way to do
so is using a collector. Google searches led me to believe there is a
function toList() which should help. However I couldn't find a method
"toList" on Stream. Neither could I easily locate it anywhere in the java
docs.

Q2. Are there any predefined collectors I could use ? eg. in this case to
convert a Stream<Int> into a List<Int>

I did take a shot at implementing a collector as follows :

public class ListCollector<T> implements Collector<T, List<T>> {
    class ListSupplier<T> implements Supplier<List<T>> {
        private List<T> list = new LinkedList<T>();
        @Override
        public List<T> get() {
            return this.list;
        }
    }

    class ListBiConsumer<T> implements BiConsumer<List<T>, T> {
        @Override
        public void accept(List<T> ts, T t) {
            ts.add(t);
        }
    }

    public class ListBinaryOperator<T> implements BinaryOperator<List<T>> {
        @Override
        public List<T> apply(List<T> ts, List<T> ts2) {
            ts.addAll(ts2);
            return ts;
        }
    }
    private ListSupplier<T> supplier = new ListSupplier<T>();
    private BiConsumer<List<T>,T> accumulator = new ListBiConsumer<T>();
    private BinaryOperator<List<T>> combiner = new ListBinaryOperator<T>();

    @Override
    public Supplier<List<T>> resultSupplier() {
        return this.supplier;
    }

    @Override
    public BiConsumer<List<T>, T> accumulator() {
        return this.accumulator;
    }

    @Override
    public BinaryOperator<List<T>> combiner() {
        return combiner;
    }

}

Q3. Is that a reasonable implementation of a collector. I was particularly
unsure of the scope at which a collector gets created and destroyed. Is
declaring (and instantiating) a LinkedList once per instance of collector
reasonable?

Thanks
Dhananjay

From brian.goetz at oracle.com  Fri Feb 22 14:16:53 2013
From: brian.goetz at oracle.com (Brian Goetz)
Date: Fri, 22 Feb 2013 17:16:53 -0500
Subject: How to return the result of a map? Are there any predefined
	collectors?
In-Reply-To: <CAD2aR4P3PoZDjbf5ziadFwrxx0wUMXPMVUfqgex1pjOLHmRN3Q@mail.gmail.com>
References: <CAD2aR4P3PoZDjbf5ziadFwrxx0wUMXPMVUfqgex1pjOLHmRN3Q@mail.gmail.com>
Message-ID: <5127EE55.1030005@oracle.com>

> The result of a sequence of map operations is a Stream<T>. However I needed
> to cast the functions explicitly as follows
>
> Stream<Integer> doubles =
> Arrays.asList(1,2,3,4).stream().map((Function<Integer, Integer>) n -> n *
> 2).map((Function<Integer, Integer>) n -> n + 1);
>
> Q1. Is there a way to avoid the cast Function<Integer, Integer> here?

Yes -- just don't do it.  Without the cast, it will select the override 
map(ToIntFunction<Integer>), which will get you out of boxed land, and 
return an IntStream.

You can do even better by:

   Streams.intRange(0, 5)  // IntStream
          .map(x -> x*2)   // IntStream
          .map(x -> x+1)   // IntStream

and there's no boxing at all.

> Also I wanted to convert the stream into a List. I understood the way to do
> so is using a collector. Google searches led me to believe there is a
> function toList() which should help. However I couldn't find a method
> "toList" on Stream. Neither could I easily locate it anywhere in the java
> docs.

   .collect(Collectors.toList())

If you have an IntStream and you want to put it into a List<Integer>:

List<Integer> list =
   intStream.boxed()  // Stream<Integer>
            .collect(Collectors.toList());

> Q2. Are there any predefined collectors I could use ? eg. in this case to
> convert a Stream<Int> into a List<Int>

See above -- Collectors.toList() or .toCollection(ctor).

Or, you can use the explicit form of Collect:

   stream.collect(ArrayList::new, ArrayList::add, ArrayList::addAll);


From brian.goetz at oracle.com  Fri Feb 22 14:20:46 2013
From: brian.goetz at oracle.com (Brian Goetz)
Date: Fri, 22 Feb 2013 17:20:46 -0500
Subject: How to return the result of a map? Are there any predefined
	collectors?
In-Reply-To: <5127EE55.1030005@oracle.com>
References: <CAD2aR4P3PoZDjbf5ziadFwrxx0wUMXPMVUfqgex1pjOLHmRN3Q@mail.gmail.com>
	<5127EE55.1030005@oracle.com>
Message-ID: <5127EF3E.1090206@oracle.com>

Or, since your problem is all dealing in integers anyway, you can avoid 
boxing entirely by using IntStream.toArray(), which will return an int[].

On 2/22/2013 5:16 PM, Brian Goetz wrote:
>> The result of a sequence of map operations is a Stream<T>. However I needed
>> to cast the functions explicitly as follows
>>
>> Stream<Integer> doubles =
>> Arrays.asList(1,2,3,4).stream().map((Function<Integer, Integer>) n -> n *
>> 2).map((Function<Integer, Integer>) n -> n + 1);
>>
>> Q1. Is there a way to avoid the cast Function<Integer, Integer> here?
>
> Yes -- just don't do it.  Without the cast, it will select the override
> map(ToIntFunction<Integer>), which will get you out of boxed land, and
> return an IntStream.
>
> You can do even better by:
>
>     Streams.intRange(0, 5)  // IntStream
>            .map(x -> x*2)   // IntStream
>            .map(x -> x+1)   // IntStream
>
> and there's no boxing at all.
>
>> Also I wanted to convert the stream into a List. I understood the way to do
>> so is using a collector. Google searches led me to believe there is a
>> function toList() which should help. However I couldn't find a method
>> "toList" on Stream. Neither could I easily locate it anywhere in the java
>> docs.
>
>     .collect(Collectors.toList())
>
> If you have an IntStream and you want to put it into a List<Integer>:
>
> List<Integer> list =
>     intStream.boxed()  // Stream<Integer>
>              .collect(Collectors.toList());
>
>> Q2. Are there any predefined collectors I could use ? eg. in this case to
>> convert a Stream<Int> into a List<Int>
>
> See above -- Collectors.toList() or .toCollection(ctor).
>
> Or, you can use the explicit form of Collect:
>
>     stream.collect(ArrayList::new, ArrayList::add, ArrayList::addAll);
>
>

From brian.goetz at oracle.com  Fri Feb 22 14:51:50 2013
From: brian.goetz at oracle.com (brian.goetz at oracle.com)
Date: Fri, 22 Feb 2013 22:51:50 +0000
Subject: hg: lambda/lambda/jdk: Inline away XxxBox classes in ReduceOp
Message-ID: <20130222225212.F296647D34@hg.openjdk.java.net>

Changeset: 1ad34774128e
Author:    briangoetz
Date:      2013-02-22 17:51 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/1ad34774128e

Inline away XxxBox classes in ReduceOp

! src/share/classes/java/util/stream/ReduceOp.java


From dhananjay.nene at gmail.com  Fri Feb 22 15:24:36 2013
From: dhananjay.nene at gmail.com (Dhananjay Nene)
Date: Sat, 23 Feb 2013 04:54:36 +0530
Subject: How should a newbie search for information before posting questions?
Message-ID: <CAD2aR4NXsAA71pUiLj5sL_1BccVOn78KvcL2M6gCvtEp+KyFDQ@mail.gmail.com>

I am not sure if this is the list to post newbie questions. I do attempt to
work quite a bit before posting a question, but it still means I might be
ending up posting some seemingly silly questions.  Are there any FAQs or
documents I should read upfront ? I have read the state of the lambda, and
generally try to search on the javadocs and list archives and even
stackoverflow, but thats a rather imprecise way of locating information.
Anything other references I should be checking up before posting questions
here?

Thanks
Dhananjay

From brian.goetz at oracle.com  Fri Feb 22 15:25:19 2013
From: brian.goetz at oracle.com (brian.goetz at oracle.com)
Date: Fri, 22 Feb 2013 23:25:19 +0000
Subject: hg: lambda/lambda/jdk: fix javadoc warnings
Message-ID: <20130222232541.4E1CB47D37@hg.openjdk.java.net>

Changeset: 50fa347587d2
Author:    briangoetz
Date:      2013-02-22 18:25 -0500
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/50fa347587d2

fix javadoc warnings

! src/share/classes/java/util/stream/IntStream.java
! src/share/classes/java/util/stream/Stream.java
! src/share/classes/java/util/stream/Streams.java
! src/share/classes/java/util/stream/package-info.java


From dhananjay.nene at gmail.com  Fri Feb 22 15:27:09 2013
From: dhananjay.nene at gmail.com (Dhananjay Nene)
Date: Sat, 23 Feb 2013 04:57:09 +0530
Subject: Where has the map method on Optional moved?
Message-ID: <CAD2aR4OeHOG+E9=mgZRZo2kM5TktjqTrv4ZuLiCsJKWnNHorQQ@mail.gmail.com>

It seemed to be there on the Optional class in b61 but is missing now. Is
there some way to run map/flatMap operations on an Optional?

Thanks
Dhananjay

From robert.field at oracle.com  Fri Feb 22 19:05:30 2013
From: robert.field at oracle.com (Robert Field)
Date: Fri, 22 Feb 2013 19:05:30 -0800
Subject: [8] Review request for 8004970, 8004971, and 8006817: implement
	serialization in lambda metafactory and metafactory fix
In-Reply-To: <51276443.1000506@gmail.com>
References: <511A5E68.4070805@oracle.com> <511A93AA.4090300@gmail.com>
	<51276443.1000506@gmail.com>
Message-ID: <512831FA.40801@oracle.com>

Thanks much Peter, we are investigating this issue and your suggestion.

-Robert

On 02/22/13 04:27, Peter Levart wrote:
> Hi Robert,
>
> What I was trying to say in my previous post is illustrated in the 
> following minimal test-case:
>
>
> package test;
>
> import sun.misc.IOUtils;
>
> import java.io.ByteArrayInputStream;
> import java.io.ByteArrayOutputStream;
> import java.io.IOException;
> import java.io.InputStream;
> import java.io.ObjectInputStream;
> import java.io.ObjectOutputStream;
> import java.io.Serializable;
>
> public class SerializedLambdaTest {
>
>     public interface SerializableRunnable extends Runnable, 
> Serializable {}
>
>     public static class MyCode implements SerializableRunnable {
>
>         private byte[] serialize(Object o) {
>             ByteArrayOutputStream baos;
>             try (
>                 ObjectOutputStream oos =
>                     new ObjectOutputStream(baos = new 
> ByteArrayOutputStream())
>             ) {
>                 oos.writeObject(o);
>             }
>             catch (IOException e) {
>                 throw new RuntimeException(e);
>             }
>             return baos.toByteArray();
>         }
>
>         private <T> T deserialize(byte[] bytes) {
>             try (
>                 ObjectInputStream ois =
>                     new ObjectInputStream(new ByteArrayInputStream(bytes))
>             ) {
>                 return (T) ois.readObject();
>             }
>             catch (IOException | ClassNotFoundException e) {
>                 throw new RuntimeException(e);
>             }
>         }
>
>         @Override
>         public void run() {
>             System.out.println("                this: " + this);
>
>             SerializableRunnable deSerializedThis = 
> deserialize(serialize(this));
>             System.out.println("    deSerializedThis: " + 
> deSerializedThis);
>
>             SerializableRunnable runnable = () -> 
> {System.out.println("HELLO");};
>             System.out.println("            runnable: " + runnable);
>
>             SerializableRunnable deSerializedRunnable = 
> deserialize(serialize(runnable));
>             System.out.println("deSerializedRunnable: " + 
> deSerializedRunnable);
>         }
>     }
>
>     public static void main(String[] args) throws Exception {
>         ClassLoader myCl = new MyClassLoader(
>             SerializedLambdaTest.class.getClassLoader()
>         );
>         Class<?> myCodeClass = Class.forName(
>             SerializedLambdaTest.class.getName() + "$MyCode",
>             true,
>             myCl
>         );
>         Runnable myCode = (Runnable) myCodeClass.newInstance();
>         myCode.run();
>     }
>
>     static class MyClassLoader extends ClassLoader {
>         MyClassLoader(ClassLoader parent) {
>             super(parent);
>         }
>
>         @Override
>         protected Class<?> loadClass(String name, boolean resolve) 
> throws ClassNotFoundException {
>             if (name.startsWith("test.")) {
>                 synchronized (getClassLoadingLock(name)) {
>                     Class<?> c = findLoadedClass(name);
>                     if (c == null) {
>                         c = findClass(name);
>                     }
>                     if (resolve) {
>                         resolveClass(c);
>                     }
>                     return c;
>                 }
>             } else {
>                 return super.loadClass(name, resolve);
>             }
>         }
>
>         @Override
>         protected Class<?> findClass(String name) throws 
> ClassNotFoundException {
>             String path = name.replace('.', '/').concat(".class");
>             try (InputStream is = getResourceAsStream(path)) {
>                 if (is != null) {
>                     byte[] bytes = IOUtils.readFully(is, -1, true);
>                     return defineClass(name, bytes, 0, bytes.length);
>                 } else {
>                     throw new ClassNotFoundException(name);
>                 }
>             }
>             catch (IOException e) {
>                 throw new ClassNotFoundException(name, e);
>             }
>         }
>     }
> }
>
>
> ... which produces the following output:
>
>
>                 this: test.SerializedLambdaTest$MyCode at 5e481248
>     deSerializedThis: test.SerializedLambdaTest$MyCode at d716361
>             runnable: test.SerializedLambdaTest$MyCode$$Lambda$1 at eed1f14
> Exception in thread "main" java.lang.ClassCastException: 
> test.SerializedLambdaTest$MyCode$$Lambda$2 cannot be cast to 
> test.SerializedLambdaTest$SerializableRunnable
>
>
> If capturing class' Class object is not available at SAM proxy 
> serialization time (but only it's name), it can be resolved at that 
> time rather than at de-serialization time, when the caller 
> class-loader is not obvious. Like for example in this patch:
>
>
> Index: jdk/src/java/lang/invoke/SerializedLambda.java
> ===================================================================
> --- jdk/src/java/lang/invoke/SerializedLambda.java (date 1361524994000)
> +++ jdk/src/java/lang/invoke/SerializedLambda.java (revision )
> @@ -24,6 +24,8 @@
>   */
>  package java.lang.invoke;
>
> +import sun.reflect.Reflection;
> +
>  import java.io.Serializable;
>  import java.lang.reflect.Method;
>  import java.security.AccessController;
> @@ -39,7 +41,7 @@
>   * @see LambdaMetafactory
>   */
>  public final class SerializedLambda implements Serializable {
> -    private final String capturingClass;
> +    private final Class<?> capturingClass;
>      private final String functionalInterfaceClass;
>      private final String functionalInterfaceMethodName;
>      private final String functionalInterfaceMethodSignature;
> @@ -73,7 +75,7 @@
>                              Object[] capturedArgs) throws 
> ReflectiveOperationException {
>          MethodHandleInfo samMhi = new 
> MethodHandleInfo(Objects.requireNonNull(functionalInterface));
>          MethodHandleInfo implMhi = new 
> MethodHandleInfo(Objects.requireNonNull(implementation));
> -        this.capturingClass = 
> Objects.requireNonNull(capturingClass).getName();
> +        this.capturingClass = Objects.requireNonNull(capturingClass);
>          this.capturedArgs = Objects.requireNonNull(capturedArgs).clone();
>          this.functionalInterfaceClass = 
> samMhi.getDeclaringClass().getName();
>          this.functionalInterfaceMethodName = samMhi.getName();
> @@ -118,7 +120,17 @@
>                              String implMethodSignature,
>                              String instantiatedMethodType,
>                              Object[] capturedArgs) {
> -        this.capturingClass = capturingClass;
> +        try {
> +            this.capturingClass = Class.forName(
> +                capturingClass.replace('/', '.'),
> +                false,
> + Reflection.getCallerClass(2).getClassLoader()
> +            );
> +        }
> +        catch (ClassNotFoundException e) {
> +            throw (Error) new NoClassDefFoundError(e.getMessage())
> +                .initCause(e);
> +        }
>          this.functionalInterfaceMethodKind = 
> functionalInterfaceMethodKind;
>          this.functionalInterfaceClass = functionalInterfaceClass;
>          this.functionalInterfaceMethodName = 
> functionalInterfaceMethodName;
> @@ -133,7 +145,7 @@
>
>      /** Get the name of the class that captured this lambda */
>      public String getCapturingClass() {
> -        return capturingClass;
> +        return capturingClass.getName().replace('.', '/');
>      }
>
>      /** Get the name of the functional interface class to which this 
> lambda has been converted */
> @@ -200,9 +212,7 @@
>              Method deserialize = AccessController.doPrivileged(new 
> PrivilegedExceptionAction<Method>() {
>                  @Override
>                  public Method run() throws Exception {
> -                    Class<?> clazz = 
> Class.forName(capturingClass.replace('/', '.'), true,
> - Thread.currentThread().getContextClassLoader());
> -                    Method m = 
> clazz.getDeclaredMethod("$deserializeLambda$", SerializedLambda.class);
> +                    Method m = 
> capturingClass.getDeclaredMethod("$deserializeLambda$", 
> SerializedLambda.class);
>                      m.setAccessible(true);
>                      return m;
>                  }
>
>
>
> Regards, Peter
>
>
> On 02/12/2013 08:10 PM, Peter Levart wrote:
>> Hi Robert,
>>
>> Just a minor note on ClassLoaders.
>>
>> In SerializedLambda.readResolve(), the capturingClass is resolved 
>> from it's name using the current thread's context ClassLoader. I 
>> don't know if this is the right thing to do. ObjectInputStream has 
>> it's own (pluggable) mechanism for resolving classes, which by 
>> default uses the so called "latest user defined loader" (see 
>> ObjectInputStream.resolveClass()). It would be better if 
>> SerializedLambda kept a reference to j.l.Class object representing 
>> capturingClass and leave to the serialization infrastructure do the 
>> resolving. But there is a SerializedLambda constructor that only 
>> takes a String, hm...
>>
>> I guess other classes that are resolved inside the capturingClass'  
>> $deserializeLambda$ method are using the caprutingClass' class 
>> loader, which is ok.
>>
>> Regards, Peter
>>
>> On 02/12/2013 04:23 PM, Robert Field wrote:
>>> Please review the fixes for CRs:
>>>
>>>         http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004970
>>>
>>>         http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004971
>>>
>>>         http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8006817
>>>
>>>
>>>
>>> Webrev:
>>>
>>>         http://cr.openjdk.java.net/~rfield/8004970
>>>
>>> Thank,
>>> Robert
>>>
>>>
>>
>


From spullara at gmail.com  Fri Feb 22 21:09:25 2013
From: spullara at gmail.com (Sam Pullara)
Date: Fri, 22 Feb 2013 21:09:25 -0800
Subject: Build issues
Message-ID: <CAMUF1SkbNA+0k7MEuhMuoumppKedkd9=yh02uN-w3-U2CRJx5g@mail.gmail.com>

I'm getting this error when it asks me to rerun configure:

checking size of int *... 8
configure: error: The tested number of bits in the target (64) differs
from the number of bits expected to be found in the target (32)
configure exiting with result code 1

Anyone else?

Sam

From forax at univ-mlv.fr  Sat Feb 23 01:10:57 2013
From: forax at univ-mlv.fr (Remi Forax)
Date: Sat, 23 Feb 2013 10:10:57 +0100
Subject: How should a newbie search for information before posting
	questions?
In-Reply-To: <CAD2aR4NXsAA71pUiLj5sL_1BccVOn78KvcL2M6gCvtEp+KyFDQ@mail.gmail.com>
References: <CAD2aR4NXsAA71pUiLj5sL_1BccVOn78KvcL2M6gCvtEp+KyFDQ@mail.gmail.com>
Message-ID: <512887A1.3070501@univ-mlv.fr>

On 02/23/2013 12:24 AM, Dhananjay Nene wrote:
> I am not sure if this is the list to post newbie questions. I do attempt to
> work quite a bit before posting a question, but it still means I might be
> ending up posting some seemingly silly questions.  Are there any FAQs or
> documents I should read upfront ? I have read the state of the lambda, and
> generally try to search on the javadocs and list archives and even
> stackoverflow, but thats a rather imprecise way of locating information.
> Anything other references I should be checking up before posting questions
> here?
>
> Thanks
> Dhananjay
>

http://www.lambdafaq.org/

cheers,
R?mi


From forax at univ-mlv.fr  Sat Feb 23 02:51:41 2013
From: forax at univ-mlv.fr (Remi Forax)
Date: Sat, 23 Feb 2013 11:51:41 +0100
Subject: Code review request
In-Reply-To: <512672E6.1050708@oracle.com>
References: <512672E6.1050708@oracle.com>
Message-ID: <51289F3D.1010609@univ-mlv.fr>

On 02/21/2013 08:17 PM, Brian Goetz wrote:
> At
>   http://cr.openjdk.java.net/~briangoetz/jdk-8008670/webrev/
>
> I've posted a webrev for about half the classes in java.util.stream. 
> None of these are public classes, so there are no public API issues 
> here, but plenty of internal API issues, naming issues (ooh, a 
> bikeshed), and code quality issues.
>

Hi Brian,

All protected fields should not be protected but package visible.
Classes are package private so there is no need to use a modifier which 
offer a wider visibility.
The same is true for constructors.

For default method, some of them are marked public, some of them are not,
what the coding convention said ?

Code convention again, there is a lot of if/else with no curly braces, 
or only curly braces
on the if part but not on the else part.
Also, when a if block ends with a return, there is no need to use 'else',

if (result != null) {
    foundResult(result);
    return result;
}
else
    return null;

can be simply written:

if (result != null) {
    foundResult(result);
    return result;
}
return null;


All inner class should not have private constructors, like by example 
FindOp.FindTask, because
the compiler will have to generate a special accessor for them when they 
are called from
the outer class.

In AbstractShortCircuitTask:
It's not clear that cancel and sharedResult can be accessed directly 
given that they both have methods that acts as getter and setter.
If they can be accessed directly, I think it's better to declare them 
private and to use getters.

Depending on the ops, some of them do nullcheks of arguments at creating 
time (ForEachOp) , some of them don't (FindOp).
In ForEachUntilOp, the 'consumer' is checked but 'until' is not.

in ForEachOp, most of the keyword protected are not needed, 
ForEachUntilOp which inherits from ForEachOp is in the same package.

In ForEachUntilOp, the constructor should be private (like for all the 
other ops).

In MatchOp, line 110, I think the compiler bug is fixed now ?
The enum MatchKind should not be public and all constructor of all inner 
classes should not be private.

In OpsUtils, some static methods are public and some are not,

in Tripwire:
   enabled should be in uppercase (ENABLED).
   method trip() should be:
      public static void trip(Class<?> trippingClass, String msg)

cheers,
R?mi


From david.holmes at oracle.com  Sun Feb 24 19:07:48 2013
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 25 Feb 2013 13:07:48 +1000
Subject: Code review request
In-Reply-To: <51289F3D.1010609@univ-mlv.fr>
References: <512672E6.1050708@oracle.com> <51289F3D.1010609@univ-mlv.fr>
Message-ID: <512AD584.2080902@oracle.com>

On 23/02/2013 8:51 PM, Remi Forax wrote:
> On 02/21/2013 08:17 PM, Brian Goetz wrote:
>> At
>>   http://cr.openjdk.java.net/~briangoetz/jdk-8008670/webrev/
>>
>> I've posted a webrev for about half the classes in java.util.stream.
>> None of these are public classes, so there are no public API issues
>> here, but plenty of internal API issues, naming issues (ooh, a
>> bikeshed), and code quality issues.
>>
>
> Hi Brian,
>
> All protected fields should not be protected but package visible.
> Classes are package private so there is no need to use a modifier which
> offer a wider visibility.
> The same is true for constructors.

I believe some of these may end up being public (TBD), in which case 
better to define member accessibility as if they were already public as 
it greatly simplifies the changes needed later.

David
-----


> For default method, some of them are marked public, some of them are not,
> what the coding convention said ?
>
> Code convention again, there is a lot of if/else with no curly braces,
> or only curly braces
> on the if part but not on the else part.
> Also, when a if block ends with a return, there is no need to use 'else',
>
> if (result != null) {
>     foundResult(result);
>     return result;
> }
> else
>     return null;
>
> can be simply written:
>
> if (result != null) {
>     foundResult(result);
>     return result;
> }
> return null;
>
>
> All inner class should not have private constructors, like by example
> FindOp.FindTask, because
> the compiler will have to generate a special accessor for them when they
> are called from
> the outer class.
>
> In AbstractShortCircuitTask:
> It's not clear that cancel and sharedResult can be accessed directly
> given that they both have methods that acts as getter and setter.
> If they can be accessed directly, I think it's better to declare them
> private and to use getters.
>
> Depending on the ops, some of them do nullcheks of arguments at creating
> time (ForEachOp) , some of them don't (FindOp).
> In ForEachUntilOp, the 'consumer' is checked but 'until' is not.
>
> in ForEachOp, most of the keyword protected are not needed,
> ForEachUntilOp which inherits from ForEachOp is in the same package.
>
> In ForEachUntilOp, the constructor should be private (like for all the
> other ops).
>
> In MatchOp, line 110, I think the compiler bug is fixed now ?
> The enum MatchKind should not be public and all constructor of all inner
> classes should not be private.
>
> In OpsUtils, some static methods are public and some are not,
>
> in Tripwire:
>    enabled should be in uppercase (ENABLED).
>    method trip() should be:
>       public static void trip(Class<?> trippingClass, String msg)
>
> cheers,
> R?mi
>

From forax at univ-mlv.fr  Mon Feb 25 01:03:24 2013
From: forax at univ-mlv.fr (Remi Forax)
Date: Mon, 25 Feb 2013 10:03:24 +0100
Subject: Code review request
In-Reply-To: <512AD584.2080902@oracle.com>
References: <512672E6.1050708@oracle.com> <51289F3D.1010609@univ-mlv.fr>
	<512AD584.2080902@oracle.com>
Message-ID: <512B28DC.7050101@univ-mlv.fr>

On 02/25/2013 04:07 AM, David Holmes wrote:
> On 23/02/2013 8:51 PM, Remi Forax wrote:
>> On 02/21/2013 08:17 PM, Brian Goetz wrote:
>>> At
>>>   http://cr.openjdk.java.net/~briangoetz/jdk-8008670/webrev/
>>>
>>> I've posted a webrev for about half the classes in java.util.stream.
>>> None of these are public classes, so there are no public API issues
>>> here, but plenty of internal API issues, naming issues (ooh, a
>>> bikeshed), and code quality issues.
>>>
>>
>> Hi Brian,
>>
>> All protected fields should not be protected but package visible.
>> Classes are package private so there is no need to use a modifier which
>> offer a wider visibility.
>> The same is true for constructors.
>
> I believe some of these may end up being public (TBD), in which case 
> better to define member accessibility as if they were already public 
> as it greatly simplifies the changes needed later.
>
> David
> -----

Given that the release of jdk9 is at least two years from now, this API 
will change, one will come with a GPU pipeline (Sumatra?) or with a 
flattened bytecode pipeline (my pet project), so trying to figure out 
now what should be public or not is like predicting the future in a 
crystal ball. I think it's better to let all members package private and 
see later.
BTW, I have no problem with protected methods, my main concern is 
protected fields or protected inner classes.

R?mi

>
>
>> For default method, some of them are marked public, some of them are 
>> not,
>> what the coding convention said ?
>>
>> Code convention again, there is a lot of if/else with no curly braces,
>> or only curly braces
>> on the if part but not on the else part.
>> Also, when a if block ends with a return, there is no need to use 
>> 'else',
>>
>> if (result != null) {
>>     foundResult(result);
>>     return result;
>> }
>> else
>>     return null;
>>
>> can be simply written:
>>
>> if (result != null) {
>>     foundResult(result);
>>     return result;
>> }
>> return null;
>>
>>
>> All inner class should not have private constructors, like by example
>> FindOp.FindTask, because
>> the compiler will have to generate a special accessor for them when they
>> are called from
>> the outer class.
>>
>> In AbstractShortCircuitTask:
>> It's not clear that cancel and sharedResult can be accessed directly
>> given that they both have methods that acts as getter and setter.
>> If they can be accessed directly, I think it's better to declare them
>> private and to use getters.
>>
>> Depending on the ops, some of them do nullcheks of arguments at creating
>> time (ForEachOp) , some of them don't (FindOp).
>> In ForEachUntilOp, the 'consumer' is checked but 'until' is not.
>>
>> in ForEachOp, most of the keyword protected are not needed,
>> ForEachUntilOp which inherits from ForEachOp is in the same package.
>>
>> In ForEachUntilOp, the constructor should be private (like for all the
>> other ops).
>>
>> In MatchOp, line 110, I think the compiler bug is fixed now ?
>> The enum MatchKind should not be public and all constructor of all inner
>> classes should not be private.
>>
>> In OpsUtils, some static methods are public and some are not,
>>
>> in Tripwire:
>>    enabled should be in uppercase (ENABLED).
>>    method trip() should be:
>>       public static void trip(Class<?> trippingClass, String msg)
>>
>> cheers,
>> R?mi
>>


From paul.sandoz at oracle.com  Mon Feb 25 04:28:36 2013
From: paul.sandoz at oracle.com (paul.sandoz at oracle.com)
Date: Mon, 25 Feb 2013 12:28:36 +0000
Subject: hg: lambda/lambda/jdk: 4 new changesets
Message-ID: <20130225123028.315E647E1F@hg.openjdk.java.net>

Changeset: b8d764bb3215
Author:    psandoz
Date:      2013-02-25 10:18 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/b8d764bb3215

- If something is SORTED it should also be ORDERED.
- Reuse the reduce operation rather than a Sink.
Contributed-by: Brian Goetz <brian.goetz at oracle.com>

! src/share/classes/java/util/stream/DistinctOp.java

Changeset: ccf54b3cd35b
Author:    psandoz
Date:      2013-02-25 12:21 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/ccf54b3cd35b

Move reduce functionality in OpUtils to ReduceOp.

! src/share/classes/java/util/stream/DistinctOp.java
! src/share/classes/java/util/stream/OpUtils.java
! src/share/classes/java/util/stream/ReduceOp.java

Changeset: 12dac52b2230
Author:    psandoz
Date:      2013-02-25 12:21 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/12dac52b2230

Move forEach functionality from OpUtils to ForEachOp.

! src/share/classes/java/util/stream/DistinctOp.java
! src/share/classes/java/util/stream/DoublePipeline.java
! src/share/classes/java/util/stream/ForEachOp.java
! src/share/classes/java/util/stream/ForEachUntilOp.java
! src/share/classes/java/util/stream/IntPipeline.java
! src/share/classes/java/util/stream/LongPipeline.java
! src/share/classes/java/util/stream/OpUtils.java
! src/share/classes/java/util/stream/ReferencePipeline.java

Changeset: e343f811b2b4
Author:    psandoz
Date:      2013-02-25 13:27 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/e343f811b2b4

Remove OpUtils and move evaluateSequential to a default method on
PipelineHelper.

- src/share/classes/java/util/stream/OpUtils.java
! src/share/classes/java/util/stream/PipelineHelper.java
! src/share/classes/java/util/stream/SliceOp.java
! src/share/classes/java/util/stream/StatefulOp.java


From paul.sandoz at oracle.com  Mon Feb 25 04:53:15 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 25 Feb 2013 13:53:15 +0100
Subject: Build issues
In-Reply-To: <CAMUF1SkbNA+0k7MEuhMuoumppKedkd9=yh02uN-w3-U2CRJx5g@mail.gmail.com>
References: <CAMUF1SkbNA+0k7MEuhMuoumppKedkd9=yh02uN-w3-U2CRJx5g@mail.gmail.com>
Message-ID: <9B25AE7B-65B2-42EA-92D9-5575671BC992@oracle.com>

Hi Sam.

See here, in case you are using mac ports:

http://mail.openjdk.java.net/pipermail/lambda-dev/2013-January/007705.html

Paul.

On Feb 23, 2013, at 6:09 AM, Sam Pullara <spullara at gmail.com> wrote:

> I'm getting this error when it asks me to rerun configure:
> 
> checking size of int *... 8
> configure: error: The tested number of bits in the target (64) differs
> from the number of bits expected to be found in the target (32)
> configure exiting with result code 1
> 
> Anyone else?
> 
> Sam
> 


From paul.sandoz at oracle.com  Mon Feb 25 05:12:59 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 25 Feb 2013 14:12:59 +0100
Subject: Where has the map method on Optional moved?
In-Reply-To: <CAD2aR4OeHOG+E9=mgZRZo2kM5TktjqTrv4ZuLiCsJKWnNHorQQ@mail.gmail.com>
References: <CAD2aR4OeHOG+E9=mgZRZo2kM5TktjqTrv4ZuLiCsJKWnNHorQQ@mail.gmail.com>
Message-ID: <5C64FDEE-13CC-4256-A09E-82614ACD4ADB@oracle.com>

Hi Dhananjay,

It is not missing it was removed.

java.util.Optional has a narrower scope that optional things in other languages. We are not trying to shoe-horn in an option monad.

Paul.

On Feb 23, 2013, at 12:27 AM, Dhananjay Nene <dhananjay.nene at gmail.com> wrote:

> It seemed to be there on the Optional class in b61 but is missing now. Is
> there some way to run map/flatMap operations on an Optional?
> 
> Thanks
> Dhananjay
> 


From maurizio.cimadamore at oracle.com  Mon Feb 25 08:02:03 2013
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Mon, 25 Feb 2013 16:02:03 +0000
Subject: hg: lambda/lambda/langtools: Cleanup:
Message-ID: <20130225160209.12AA247E32@hg.openjdk.java.net>

Changeset: 2912d9b3bbff
Author:    mcimadamore
Date:      2013-02-25 16:01 +0000
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/2912d9b3bbff

Cleanup:
*) minimize diffs with JDK 8 master
*) cleanup unused features:
  - private methods in interfaces
  - 'package' as a modifier

! src/share/classes/com/sun/tools/javac/code/Flags.java
! src/share/classes/com/sun/tools/javac/code/Source.java
! src/share/classes/com/sun/tools/javac/comp/Check.java
! src/share/classes/com/sun/tools/javac/jvm/CRTable.java
! src/share/classes/com/sun/tools/javac/parser/JavacParser.java
! src/share/classes/com/sun/tools/javac/resources/compiler.properties
! test/tools/javac/annotations/typeAnnotations/failures/AnnotatedPackage2.out
- test/tools/javac/defaultMethods/package/TestPackageAsModifier.java
- test/tools/javac/defaultMethods/private/Private01.java
! test/tools/javac/defaultMethods/syntax/TestDefaultMethodsSyntax.java
! test/tools/javac/diags/examples.not-yet.txt


From robert.field at oracle.com  Mon Feb 25 09:24:46 2013
From: robert.field at oracle.com (Robert Field)
Date: Mon, 25 Feb 2013 09:24:46 -0800
Subject: [8] Review request for 8008770: SerializedLambda incorrect class
	loader for lambda deserializing class
Message-ID: <512B9E5E.6000706@oracle.com>

Please review the fixes for CRs:

        http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8008770

Webrev:

        http://cr.openjdk.java.net/~rfield/8008770_2/

Thank,
Robert




From paul.sandoz at oracle.com  Mon Feb 25 09:22:59 2013
From: paul.sandoz at oracle.com (paul.sandoz at oracle.com)
Date: Mon, 25 Feb 2013 17:22:59 +0000
Subject: hg: lambda/lambda/jdk: - ensure constructors of private inner classes
	are package private
Message-ID: <20130225172325.6C98D47E3B@hg.openjdk.java.net>

Changeset: 3e50294c68ea
Author:    psandoz
Date:      2013-02-25 18:11 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/3e50294c68ea

- ensure constructors of private inner classes are package private
- ensure classes, where appropriate, are marked as final.
- misc cleanups for access of classes and fields.

! src/share/classes/java/util/stream/AbstractPipeline.java
! src/share/classes/java/util/stream/AbstractSpinedBuffer.java
! src/share/classes/java/util/stream/Collector.java
! src/share/classes/java/util/stream/Collectors.java
! src/share/classes/java/util/stream/ConcurrentCollectors.java
! src/share/classes/java/util/stream/DistinctOp.java
! src/share/classes/java/util/stream/DoublePipeline.java
! src/share/classes/java/util/stream/FindOp.java
! src/share/classes/java/util/stream/ForEachOp.java
! src/share/classes/java/util/stream/IntPipeline.java
! src/share/classes/java/util/stream/LongPipeline.java
! src/share/classes/java/util/stream/MatchOp.java
! src/share/classes/java/util/stream/Node.java
! src/share/classes/java/util/stream/NodeUtils.java
! src/share/classes/java/util/stream/Nodes.java
! src/share/classes/java/util/stream/ReduceOp.java
! src/share/classes/java/util/stream/Sink.java
! src/share/classes/java/util/stream/SliceOp.java
! src/share/classes/java/util/stream/SortedOp.java
! src/share/classes/java/util/stream/SpinedBuffer.java
! src/share/classes/java/util/stream/StreamSpliterators.java
! src/share/classes/java/util/stream/Streams.java
! src/share/classes/java/util/stream/TerminalOp.java
! src/share/classes/java/util/stream/Tripwire.java


From paul.sandoz at oracle.com  Mon Feb 25 09:31:32 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 25 Feb 2013 18:31:32 +0100
Subject: Code review request
In-Reply-To: <51289F3D.1010609@univ-mlv.fr>
References: <512672E6.1050708@oracle.com> <51289F3D.1010609@univ-mlv.fr>
Message-ID: <458B2D62-336C-429C-B835-DEEC7031004B@oracle.com>

Hi Remi,

Thanks for the feedback i have addressed some of this, mostly related to inner classes, in following change set to the lambda repo:

http://hg.openjdk.java.net/lambda/lambda/jdk/rev/3e50294c68ea

We can update the webrev next week.


On Feb 23, 2013, at 11:51 AM, Remi Forax <forax at univ-mlv.fr> wrote:

> On 02/21/2013 08:17 PM, Brian Goetz wrote:
>> At
>>  http://cr.openjdk.java.net/~briangoetz/jdk-8008670/webrev/
>> 
>> I've posted a webrev for about half the classes in java.util.stream. None of these are public classes, so there are no public API issues here, but plenty of internal API issues, naming issues (ooh, a bikeshed), and code quality issues.
>> 
> 
> Hi Brian,
> 
> All protected fields should not be protected but package visible.
> Classes are package private so there is no need to use a modifier which offer a wider visibility.
> The same is true for constructors.
> 

I agree with this, if there are no further objections i will fix in the lambda repo towards the end of the week.


> For default method, some of them are marked public, some of them are not,
> what the coding convention said ?
> 

AFAICT "public" was only on two such default methods, so i have removed that modifier.


> Code convention again, there is a lot of if/else with no curly braces, or only curly braces
> on the if part but not on the else part.
> Also, when a if block ends with a return, there is no need to use 'else',
> 
> if (result != null) {
>   foundResult(result);
>   return result;
> }
> else
>   return null;
> 
> can be simply written:
> 
> if (result != null) {
>   foundResult(result);
>   return result;
> }
> return null;
> 

Regarding code conventions i would prefer to auto-format all code to ensure consistency, as to what that consistency is, well we could argue until heat death of the universe :-) I am fine as long as it is consistent and easy to hit Alt-Cmd-L or what ever it is in ones favourite IDE.


> 
> All inner class should not have private constructors, like by example FindOp.FindTask, because
> the compiler will have to generate a special accessor for them when they are called from
> the outer class.
> 

I have made changes to all inner classes to conform to this. I have also marked all classes as final where appropriate.


> In AbstractShortCircuitTask:
> It's not clear that cancel and sharedResult can be accessed directly given that they both have methods that acts as getter and setter.
> If they can be accessed directly, I think it's better to declare them private and to use getters.
> 

They should be private, they are not accessed outside of that class. I will fix.


> Depending on the ops, some of them do nullcheks of arguments at creating time (ForEachOp) , some of them don't (FindOp).
> In ForEachUntilOp, the 'consumer' is checked but 'until' is not.
> 

OK, there are probably lots of missing null checks in the code...


> in ForEachOp, most of the keyword protected are not needed, ForEachUntilOp which inherits from ForEachOp is in the same package.
> 


> In ForEachUntilOp, the constructor should be private (like for all the other ops).
> 

Done.


> In MatchOp, line 110, I think the compiler bug is fixed now ?

Not yet, i can still reproduce it.


> The enum MatchKind should not be public and all constructor of all inner classes should not be private.
> 

Done.


> In OpsUtils, some static methods are public and some are not,
> 

OpUtils is now gone in the lambda repo. The forEach and reduce functionality is moved into the corresponding op classes. The static method has been moved to a default method on PipelineHelper.


> in Tripwire:
>  enabled should be in uppercase (ENABLED).
>  method trip() should be:
>     public static void trip(Class<?> trippingClass, String msg)
> 

Done. I also made the field and method package private.

Thanks,
Paul.


From paul.sandoz at oracle.com  Mon Feb 25 09:44:56 2013
From: paul.sandoz at oracle.com (paul.sandoz at oracle.com)
Date: Mon, 25 Feb 2013 17:44:56 +0000
Subject: hg: lambda/lambda/jdk: JavaDoc improvements.
Message-ID: <20130225174518.6E08A47E45@hg.openjdk.java.net>

Changeset: 6dbfee22c2ff
Author:    psandoz
Date:      2013-02-25 18:44 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/6dbfee22c2ff

JavaDoc improvements.

! src/share/classes/java/util/stream/PipelineHelper.java
! src/share/classes/java/util/stream/StreamShape.java


From paul.sandoz at oracle.com  Mon Feb 25 09:51:59 2013
From: paul.sandoz at oracle.com (paul.sandoz at oracle.com)
Date: Mon, 25 Feb 2013 17:51:59 +0000
Subject: hg: lambda/lambda/jdk: Fix JavaDoc reference to method.
Message-ID: <20130225175211.5918E47E48@hg.openjdk.java.net>

Changeset: 05e2d3863cec
Author:    psandoz
Date:      2013-02-25 18:51 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/05e2d3863cec

Fix JavaDoc reference to method.

! src/share/classes/java/util/Map.java


From paul.sandoz at oracle.com  Mon Feb 25 09:55:06 2013
From: paul.sandoz at oracle.com (paul.sandoz at oracle.com)
Date: Mon, 25 Feb 2013 17:55:06 +0000
Subject: hg: lambda/lambda/jdk: Update JavaDoc to use BiConsumer.
Message-ID: <20130225175518.1C31A47E4B@hg.openjdk.java.net>

Changeset: a37adffb0ec1
Author:    psandoz
Date:      2013-02-25 18:54 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/a37adffb0ec1

Update JavaDoc to use BiConsumer.

! src/share/classes/java/util/Map.java


From david.holmes at oracle.com  Mon Feb 25 13:45:47 2013
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 26 Feb 2013 07:45:47 +1000
Subject: Code review request
In-Reply-To: <458B2D62-336C-429C-B835-DEEC7031004B@oracle.com>
References: <512672E6.1050708@oracle.com> <51289F3D.1010609@univ-mlv.fr>
	<458B2D62-336C-429C-B835-DEEC7031004B@oracle.com>
Message-ID: <512BDB8B.9070005@oracle.com>

On 26/02/2013 3:31 AM, Paul Sandoz wrote:
> Hi Remi,
>
> Thanks for the feedback i have addressed some of this, mostly related to
> inner classes, in following change set to the lambda repo:
>
> http://hg.openjdk.java.net/lambda/lambda/jdk/rev/3e50294c68ea

I see a lot of private things that are now package-access. Is that 
because they are now being used within the package?

The access modifiers document intended usage even if there is limited 
accessibility to the class defining the member. The idea that a class 
restricted to package-access should have member access modifiers 
restricted to package-only or else private, is just plain wrong in my 
view. Each type should have a public, protected and private API. The 
exposure of the type within a package is a separate matter. 
Package-access then becomes a limited-sharing mechanism.

David

> We can update the webrev next week.
>
>
> On Feb 23, 2013, at 11:51 AM, Remi Forax <forax at univ-mlv.fr
> <mailto:forax at univ-mlv.fr>> wrote:
>
>> On 02/21/2013 08:17 PM, Brian Goetz wrote:
>>> At
>>> http://cr.openjdk.java.net/~briangoetz/jdk-8008670/webrev/
>>>
>>> I've posted a webrev for about half the classes in java.util.stream.
>>> None of these are public classes, so there are no public API issues
>>> here, but plenty of internal API issues, naming issues (ooh, a
>>> bikeshed), and code quality issues.
>>>
>>
>> Hi Brian,
>>
>> All protected fields should not be protected but package visible.
>> Classes are package private so there is no need to use a modifier
>> which offer a wider visibility.
>> The same is true for constructors.
>>
>
> I agree with this, if there are no further objections i will fix in the
> lambda repo towards the end of the week.
>
>
>> For default method, some of them are marked public, some of them are not,
>> what the coding convention said ?
>>
>
> AFAICT "public" was only on two such default methods, so i have removed
> that modifier.
>
>
>> Code convention again, there is a lot of if/else with no curly braces,
>> or only curly braces
>> on the if part but not on the else part.
>> Also, when a if block ends with a return, there is no need to use 'else',
>>
>> if (result != null) {
>>   foundResult(result);
>>   return result;
>> }
>> else
>>   return null;
>>
>> can be simply written:
>>
>> if (result != null) {
>>   foundResult(result);
>>   return result;
>> }
>> return null;
>>
>
> Regarding code conventions i would prefer to auto-format all code to
> ensure consistency, as to what that consistency is, well we could argue
> until heat death of the universe :-) I am fine as long as it is
> consistent and easy to hit Alt-Cmd-L or what ever it is in ones
> favourite IDE.
>
>
>>
>> All inner class should not have private constructors, like by example
>> FindOp.FindTask, because
>> the compiler will have to generate a special accessor for them when
>> they are called from
>> the outer class.
>>
>
> I have made changes to all inner classes to conform to this. I have also
> marked all classes as final where appropriate.
>
>
>> In AbstractShortCircuitTask:
>> It's not clear that cancel and sharedResult can be accessed directly
>> given that they both have methods that acts as getter and setter.
>> If they can be accessed directly, I think it's better to declare them
>> private and to use getters.
>>
>
> They should be private, they are not accessed outside of that class. I
> will fix.
>
>
>> Depending on the ops, some of them do nullcheks of arguments at
>> creating time (ForEachOp) , some of them don't (FindOp).
>> In ForEachUntilOp, the 'consumer' is checked but 'until' is not.
>>
>
> OK, there are probably lots of missing null checks in the code...
>
>
>> in ForEachOp, most of the keyword protected are not needed,
>> ForEachUntilOp which inherits from ForEachOp is in the same package.
>>
>
>
>> In ForEachUntilOp, the constructor should be private (like for all the
>> other ops).
>>
>
> Done.
>
>
>> In MatchOp, line 110, I think the compiler bug is fixed now ?
>
> Not yet, i can still reproduce it.
>
>
>> The enum MatchKind should not be public and all constructor of all
>> inner classes should not be private.
>>
>
> Done.
>
>
>> In OpsUtils, some static methods are public and some are not,
>>
>
> OpUtils is now gone in the lambda repo. The forEach and reduce
> functionality is moved into the corresponding op classes. The static
> method has been moved to a default method on PipelineHelper.
>
>
>> in Tripwire:
>>  enabled should be in uppercase (ENABLED).
>>  method trip() should be:
>>     public static void trip(Class<?> trippingClass, String msg)
>>
>
> Done. I also made the field and method package private.
>
> Thanks,
> Paul.
>

From jed at wesleysmith.io  Mon Feb 25 21:12:01 2013
From: jed at wesleysmith.io (Jed Wesley-Smith)
Date: Tue, 26 Feb 2013 16:12:01 +1100
Subject: Where has the map method on Optional moved?
In-Reply-To: <5C64FDEE-13CC-4256-A09E-82614ACD4ADB@oracle.com>
References: <CAD2aR4OeHOG+E9=mgZRZo2kM5TktjqTrv4ZuLiCsJKWnNHorQQ@mail.gmail.com>
	<5C64FDEE-13CC-4256-A09E-82614ACD4ADB@oracle.com>
Message-ID: <CAN3nywD33uRJL545Np=NVmUbGQvF_Jq5su0nH=yCUywRy8Y5mg@mail.gmail.com>

Hi Paul,

You don't get a choice, it is a (or forms a) monad, you just removed
the useful methods (map/flatMap aka fmap/bind). This leaves clients to
implement them (or the functionality) in an ad-hoc and possibly buggy
form themselves.

It is a monad if there exists some pair of functions:

A -> Option<A>
Option<A> -> (A -> Option<B>) -> Option<B>

The first is Optional.of, the second is currently:

Optional<A> a = ?
Optional<B> b = ?
Function<A, Optional<B> f = ?
if (a.isPresent) {
  b = f.apply(a.get());
} else {
  b = Optional.empty();
}

rather than:

Optional<A> a = ?
Function<A, Optional<B> f = ?
final Optional<B> b = a.flatMap(f);

cheers,
jed.

On 26 February 2013 00:12, Paul Sandoz <paul.sandoz at oracle.com> wrote:
> Hi Dhananjay,
>
> It is not missing it was removed.
>
> java.util.Optional has a narrower scope that optional things in other languages. We are not trying to shoe-horn in an option monad.
>
> Paul.
>
> On Feb 23, 2013, at 12:27 AM, Dhananjay Nene <dhananjay.nene at gmail.com> wrote:
>
>> It seemed to be there on the Optional class in b61 but is missing now. Is
>> there some way to run map/flatMap operations on an Optional?
>>
>> Thanks
>> Dhananjay
>>
>
>

From forax at univ-mlv.fr  Mon Feb 25 23:12:28 2013
From: forax at univ-mlv.fr (=?utf-8?B?UmVtaSBGb3JheA==?=)
Date: Tue, 26 Feb 2013 08:12:28 +0100
Subject: =?utf-8?B?UmU6IFs4XSBSZXZpZXcgcmVxdWVzdCBmb3IgODAwODc3MDogU2VyaWFsaXplZExhbWJkYSBpbmNvcnJlY3QgY2xhc3MJbG9hZGVyIGZvciBsYW1iZGEgZGVzZXJpYWxpemluZyBjbGFzcw==?=
Message-ID: <201302260712.r1Q7CPEu003780@monge.univ-mlv.fr>

Looks good :)

Sent from my Phone

----- Reply message -----
From: "Robert Field" <robert.field at oracle.com>
To: <lambda-dev at openjdk.java.net>
Subject: [8] Review request for 8008770: SerializedLambda incorrect class	loader for lambda deserializing class
Date: Mon, Feb 25, 2013 18:24


Please review the fixes for CRs:

        http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8008770

Webrev:

        http://cr.openjdk.java.net/~rfield/8008770_2/

Thank,
Robert





From paul.sandoz at oracle.com  Tue Feb 26 02:37:58 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 26 Feb 2013 11:37:58 +0100
Subject: Where has the map method on Optional moved?
In-Reply-To: <CAN3nywD33uRJL545Np=NVmUbGQvF_Jq5su0nH=yCUywRy8Y5mg@mail.gmail.com>
References: <CAD2aR4OeHOG+E9=mgZRZo2kM5TktjqTrv4ZuLiCsJKWnNHorQQ@mail.gmail.com>
	<5C64FDEE-13CC-4256-A09E-82614ACD4ADB@oracle.com>
	<CAN3nywD33uRJL545Np=NVmUbGQvF_Jq5su0nH=yCUywRy8Y5mg@mail.gmail.com>
Message-ID: <BB68FEFB-F7EB-4067-9247-3E5F108B3878@oracle.com>

Hi Jed,

An Optional.flatMap is somewhat different to Stream.flatMap(FlatMapper ). Should we also add filter, forEach and reduce methods to have some parity to that of Stream? that is what i am getting at when i used the expression "shoe-horn".

Stream.flatMap has been through a number of renames/redesigns and has very recently somewhat circled back on itself *and* we have added the following convenience method to Stream<T>:

    default <R> Stream<R> flatMap(Function<T, Stream<? extends R>> mapper) {
        return flatMap((T t, Consumer<R> sink) -> mapper.apply(t).sequential().forEach(sink));
    }

Since we are using the "flatMap" name it was felt important to have one method follow the pattern expected of it.

Hmm... maybe under such circumstances it is OK to add an Optional.flatMap ? Or alternatively choose a completely different name to disassociate from Stream e.g. like Guava's Optional.transform.

Paul.

On Feb 26, 2013, at 6:12 AM, Jed Wesley-Smith <jed at wesleysmith.io> wrote:

> Hi Paul,
> 
> You don't get a choice, it is a (or forms a) monad, you just removed
> the useful methods (map/flatMap aka fmap/bind). This leaves clients to
> implement them (or the functionality) in an ad-hoc and possibly buggy
> form themselves.
> 
> It is a monad if there exists some pair of functions:
> 
> A -> Option<A>
> Option<A> -> (A -> Option<B>) -> Option<B>
> 
> The first is Optional.of, the second is currently:
> 
> Optional<A> a = ?
> Optional<B> b = ?
> Function<A, Optional<B> f = ?
> if (a.isPresent) {
>  b = f.apply(a.get());
> } else {
>  b = Optional.empty();
> }
> 
> rather than:
> 
> Optional<A> a = ?
> Function<A, Optional<B> f = ?
> final Optional<B> b = a.flatMap(f);
> 
> cheers,
> jed.
> 
> On 26 February 2013 00:12, Paul Sandoz <paul.sandoz at oracle.com> wrote:
>> Hi Dhananjay,
>> 
>> It is not missing it was removed.
>> 
>> java.util.Optional has a narrower scope that optional things in other languages. We are not trying to shoe-horn in an option monad.
>> 
>> Paul.
>> 
>> On Feb 23, 2013, at 12:27 AM, Dhananjay Nene <dhananjay.nene at gmail.com> wrote:
>> 
>>> It seemed to be there on the Optional class in b61 but is missing now. Is
>>> there some way to run map/flatMap operations on an Optional?
>>> 
>>> Thanks
>>> Dhananjay
>>> 
>> 
>> 


From jed at wesleysmith.io  Tue Feb 26 03:33:01 2013
From: jed at wesleysmith.io (Jed Wesley-Smith)
Date: Tue, 26 Feb 2013 22:33:01 +1100
Subject: Where has the map method on Optional moved?
In-Reply-To: <BB68FEFB-F7EB-4067-9247-3E5F108B3878@oracle.com>
References: <CAD2aR4OeHOG+E9=mgZRZo2kM5TktjqTrv4ZuLiCsJKWnNHorQQ@mail.gmail.com>
	<5C64FDEE-13CC-4256-A09E-82614ACD4ADB@oracle.com>
	<CAN3nywD33uRJL545Np=NVmUbGQvF_Jq5su0nH=yCUywRy8Y5mg@mail.gmail.com>
	<BB68FEFB-F7EB-4067-9247-3E5F108B3878@oracle.com>
Message-ID: <CAN3nywDHm3e_rb8HT4+nMmtVGdVMRdhdOWqwPDfMKe07Rs3cTg@mail.gmail.com>

FlatMapper is a bizarre Frankensteinian beast, relying as it does on
mutation to do all of its things. It would be a service to all to
rename it to something ? anything ? else, as it does not resemble the
notion of flatMap/bind that other functional programming languages or
libraries implement.

As to consistency across the interfaces, Java doesn't have the ability
to generalise across Optional and Stream, lacking Higher Kinded Types.
The fact that Stream has named some feature that resembles a monadic
bind flatMap ideally should not then preclude the ability for Optional
to also have this feature.

As to additional potential functionality, you are quite correct, the
restriction of inheritance/OO to be the sole mechanism for adorning
functionality on a data-structure means that the temptation exists to
implement it directly, and these (filter/fold/reduce/foreach etc) are
all sensible suggestions. I do not profess to have definitive answers
to these library design decisions, given the constraints that the
designs are under. I am nevertheless obligated to point out that these
things _are_ monads, or that they form applicative functors ? these
are just simple properties that arise from the data-structure.

My personal preference would be to attempt to give Optional as much of
the functionality it can support ? that has been what we've tried to
do with our version*. We have certainly found that supporting monad,
functor and applicative syntax has been useful ? and that things like
fold are general enough to allow you to build everything else
regardless.

cheers,
jed.

* https://bitbucket.org/atlassian/fugue/src/master/src/main/java/com/atlassian/fugue/Option.java

On 26 February 2013 21:37, Paul Sandoz <paul.sandoz at oracle.com> wrote:
> Hi Jed,
>
> An Optional.flatMap is somewhat different to Stream.flatMap(FlatMapper ). Should we also add filter, forEach and reduce methods to have some parity to that of Stream? that is what i am getting at when i used the expression "shoe-horn".
>
> Stream.flatMap has been through a number of renames/redesigns and has very recently somewhat circled back on itself *and* we have added the following convenience method to Stream<T>:
>
>     default <R> Stream<R> flatMap(Function<T, Stream<? extends R>> mapper) {
>         return flatMap((T t, Consumer<R> sink) -> mapper.apply(t).sequential().forEach(sink));
>     }
>
> Since we are using the "flatMap" name it was felt important to have one method follow the pattern expected of it.
>
> Hmm... maybe under such circumstances it is OK to add an Optional.flatMap ? Or alternatively choose a completely different name to disassociate from Stream e.g. like Guava's Optional.transform.
>
> Paul.
>
> On Feb 26, 2013, at 6:12 AM, Jed Wesley-Smith <jed at wesleysmith.io> wrote:
>
>> Hi Paul,
>>
>> You don't get a choice, it is a (or forms a) monad, you just removed
>> the useful methods (map/flatMap aka fmap/bind). This leaves clients to
>> implement them (or the functionality) in an ad-hoc and possibly buggy
>> form themselves.
>>
>> It is a monad if there exists some pair of functions:
>>
>> A -> Option<A>
>> Option<A> -> (A -> Option<B>) -> Option<B>
>>
>> The first is Optional.of, the second is currently:
>>
>> Optional<A> a = ?
>> Optional<B> b = ?
>> Function<A, Optional<B> f = ?
>> if (a.isPresent) {
>>  b = f.apply(a.get());
>> } else {
>>  b = Optional.empty();
>> }
>>
>> rather than:
>>
>> Optional<A> a = ?
>> Function<A, Optional<B> f = ?
>> final Optional<B> b = a.flatMap(f);
>>
>> cheers,
>> jed.
>>
>> On 26 February 2013 00:12, Paul Sandoz <paul.sandoz at oracle.com> wrote:
>>> Hi Dhananjay,
>>>
>>> It is not missing it was removed.
>>>
>>> java.util.Optional has a narrower scope that optional things in other languages. We are not trying to shoe-horn in an option monad.
>>>
>>> Paul.
>>>
>>> On Feb 23, 2013, at 12:27 AM, Dhananjay Nene <dhananjay.nene at gmail.com> wrote:
>>>
>>>> It seemed to be there on the Optional class in b61 but is missing now. Is
>>>> there some way to run map/flatMap operations on an Optional?
>>>>
>>>> Thanks
>>>> Dhananjay
>>>>
>>>
>>>
>
>

From paul.sandoz at oracle.com  Tue Feb 26 03:49:32 2013
From: paul.sandoz at oracle.com (paul.sandoz at oracle.com)
Date: Tue, 26 Feb 2013 11:49:32 +0000
Subject: hg: lambda/lambda/jdk: Use for loop.
Message-ID: <20130226115040.42A7B47413@hg.openjdk.java.net>

Changeset: 487a4fb5b187
Author:    psandoz
Date:      2013-02-26 12:45 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/487a4fb5b187

Use for loop.

! src/share/classes/java/util/Map.java


From paul.sandoz at oracle.com  Tue Feb 26 04:40:07 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 26 Feb 2013 13:40:07 +0100
Subject: Where has the map method on Optional moved?
In-Reply-To: <CAN3nywDHm3e_rb8HT4+nMmtVGdVMRdhdOWqwPDfMKe07Rs3cTg@mail.gmail.com>
References: <CAD2aR4OeHOG+E9=mgZRZo2kM5TktjqTrv4ZuLiCsJKWnNHorQQ@mail.gmail.com>
	<5C64FDEE-13CC-4256-A09E-82614ACD4ADB@oracle.com>
	<CAN3nywD33uRJL545Np=NVmUbGQvF_Jq5su0nH=yCUywRy8Y5mg@mail.gmail.com>
	<BB68FEFB-F7EB-4067-9247-3E5F108B3878@oracle.com>
	<CAN3nywDHm3e_rb8HT4+nMmtVGdVMRdhdOWqwPDfMKe07Rs3cTg@mail.gmail.com>
Message-ID: <7B9F8A51-D98C-435E-9628-117D92736AAC@oracle.com>

On Feb 26, 2013, at 12:33 PM, Jed Wesley-Smith <jed at wesleysmith.io> wrote:
> FlatMapper is a bizarre Frankensteinian beast, relying as it does on
> mutation to do all of its things.

You mean mutation as in mutation of state? or mutation in the sense of Frankensteinian mutation due to indirection?


> It would be a service to all to
> rename it to something ? anything ? else, as it does not resemble the
> notion of flatMap/bind that other functional programming languages or
> libraries implement.
> 
> As to consistency across the interfaces, Java doesn't have the ability
> to generalise across Optional and Stream, lacking Higher Kinded Types.
> The fact that Stream has named some feature that resembles a monadic
> bind flatMap ideally should not then preclude the ability for Optional
> to also have this feature.
> 
> As to additional potential functionality, you are quite correct, the
> restriction of inheritance/OO to be the sole mechanism for adorning
> functionality on a data-structure means that the temptation exists to
> implement it directly, and these (filter/fold/reduce/foreach etc) are
> all sensible suggestions. I do not profess to have definitive answers
> to these library design decisions, given the constraints that the
> designs are under.

The problem being Optional would stick out like a sore thumb. It's not a Stream. There is no direct way to get a Stream from it and if there were, which is quite easy to do, it would not give you what you really want.



> I am nevertheless obligated to point out that these
> things _are_ monads, or that they form applicative functors ? these
> are just simple properties that arise from the data-structure.
> 
> My personal preference would be to attempt to give Optional as much of
> the functionality it can support ? that has been what we've tried to
> do with our version*. We have certainly found that supporting monad,
> functor and applicative syntax has been useful ? and that things like
> fold are general enough to allow you to build everything else
> regardless.
> 

I can see the value in adding a bind/map method but i don't see the value in turning Optional into fully fledged Stream-but-not-Stream-like thing. I think that would be taking the API in the wrong direction.

Paul.

 
> cheers,
> jed.
> 
> * https://bitbucket.org/atlassian/fugue/src/master/src/main/java/com/atlassian/fugue/Option.java
> 
> On 26 February 2013 21:37, Paul Sandoz <paul.sandoz at oracle.com> wrote:
>> Hi Jed,
>> 
>> An Optional.flatMap is somewhat different to Stream.flatMap(FlatMapper ). Should we also add filter, forEach and reduce methods to have some parity to that of Stream? that is what i am getting at when i used the expression "shoe-horn".
>> 
>> Stream.flatMap has been through a number of renames/redesigns and has very recently somewhat circled back on itself *and* we have added the following convenience method to Stream<T>:
>> 
>>    default <R> Stream<R> flatMap(Function<T, Stream<? extends R>> mapper) {
>>        return flatMap((T t, Consumer<R> sink) -> mapper.apply(t).sequential().forEach(sink));
>>    }
>> 
>> Since we are using the "flatMap" name it was felt important to have one method follow the pattern expected of it.
>> 
>> Hmm... maybe under such circumstances it is OK to add an Optional.flatMap ? Or alternatively choose a completely different name to disassociate from Stream e.g. like Guava's Optional.transform.
>> 
>> Paul.
>> 
>> On Feb 26, 2013, at 6:12 AM, Jed Wesley-Smith <jed at wesleysmith.io> wrote:
>> 
>>> Hi Paul,
>>> 
>>> You don't get a choice, it is a (or forms a) monad, you just removed
>>> the useful methods (map/flatMap aka fmap/bind). This leaves clients to
>>> implement them (or the functionality) in an ad-hoc and possibly buggy
>>> form themselves.
>>> 
>>> It is a monad if there exists some pair of functions:
>>> 
>>> A -> Option<A>
>>> Option<A> -> (A -> Option<B>) -> Option<B>
>>> 
>>> The first is Optional.of, the second is currently:
>>> 
>>> Optional<A> a = ?
>>> Optional<B> b = ?
>>> Function<A, Optional<B> f = ?
>>> if (a.isPresent) {
>>> b = f.apply(a.get());
>>> } else {
>>> b = Optional.empty();
>>> }
>>> 
>>> rather than:
>>> 
>>> Optional<A> a = ?
>>> Function<A, Optional<B> f = ?
>>> final Optional<B> b = a.flatMap(f);
>>> 
>>> cheers,
>>> jed.
>>> 
>>> On 26 February 2013 00:12, Paul Sandoz <paul.sandoz at oracle.com> wrote:
>>>> Hi Dhananjay,
>>>> 
>>>> It is not missing it was removed.
>>>> 
>>>> java.util.Optional has a narrower scope that optional things in other languages. We are not trying to shoe-horn in an option monad.
>>>> 
>>>> Paul.
>>>> 
>>>> On Feb 23, 2013, at 12:27 AM, Dhananjay Nene <dhananjay.nene at gmail.com> wrote:
>>>> 
>>>>> It seemed to be there on the Optional class in b61 but is missing now. Is
>>>>> there some way to run map/flatMap operations on an Optional?
>>>>> 
>>>>> Thanks
>>>>> Dhananjay
>>>>> 
>>>> 
>>>> 
>> 
>> 


From paul.sandoz at oracle.com  Tue Feb 26 05:11:50 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 26 Feb 2013 14:11:50 +0100
Subject: Code review request
In-Reply-To: <512BDB8B.9070005@oracle.com>
References: <512672E6.1050708@oracle.com> <51289F3D.1010609@univ-mlv.fr>
	<458B2D62-336C-429C-B835-DEEC7031004B@oracle.com>
	<512BDB8B.9070005@oracle.com>
Message-ID: <958F39D3-EB3A-4FD2-ABAF-5109BDDD8D49@oracle.com>


On Feb 25, 2013, at 10:45 PM, David Holmes <david.holmes at oracle.com> wrote:

> On 26/02/2013 3:31 AM, Paul Sandoz wrote:
>> Hi Remi,
>> 
>> Thanks for the feedback i have addressed some of this, mostly related to
>> inner classes, in following change set to the lambda repo:
>> 
>> http://hg.openjdk.java.net/lambda/lambda/jdk/rev/3e50294c68ea
> 
> I see a lot of private things that are now package-access.

I presume you mean on constructors of private inner classes?


> Is that because they are now being used within the package?
> 

No, it is to avoid the creation of a synthetic package private constructor called by enclosing class to construct the inner class.


> The access modifiers document intended usage even if there is limited accessibility to the class defining the member. The idea that a class restricted to package-access should have member access modifiers restricted to package-only or else private, is just plain wrong in my view. Each type should have a public, protected and private API. The exposure of the type within a package is a separate matter. Package-access then becomes a limited-sharing mechanism.
> 

For private inner classes i took the view that protected on fields offered little value, but paused for top level classes.

There are not many use-cases in the JDK at least for the packages i browsed. The class java.util.concurrent.atomic.Striped64 does not bother with protected.

I am leaning towards the opinion that protected is just noise in these cases since the compiler offers no protection.

Paul.

From forax at univ-mlv.fr  Tue Feb 26 05:40:37 2013
From: forax at univ-mlv.fr (Remi Forax)
Date: Tue, 26 Feb 2013 14:40:37 +0100
Subject: Code review request
In-Reply-To: <958F39D3-EB3A-4FD2-ABAF-5109BDDD8D49@oracle.com>
References: <512672E6.1050708@oracle.com> <51289F3D.1010609@univ-mlv.fr>
	<458B2D62-336C-429C-B835-DEEC7031004B@oracle.com>
	<512BDB8B.9070005@oracle.com>
	<958F39D3-EB3A-4FD2-ABAF-5109BDDD8D49@oracle.com>
Message-ID: <512CBB55.7080301@univ-mlv.fr>

On 02/26/2013 02:11 PM, Paul Sandoz wrote:
> On Feb 25, 2013, at 10:45 PM, David Holmes <david.holmes at oracle.com> wrote:
>
>> On 26/02/2013 3:31 AM, Paul Sandoz wrote:
>>> Hi Remi,
>>>
>>> Thanks for the feedback i have addressed some of this, mostly related to
>>> inner classes, in following change set to the lambda repo:
>>>
>>> http://hg.openjdk.java.net/lambda/lambda/jdk/rev/3e50294c68ea
>> I see a lot of private things that are now package-access.
> I presume you mean on constructors of private inner classes?
>
>
>> Is that because they are now being used within the package?
>>
> No, it is to avoid the creation of a synthetic package private constructor called by enclosing class to construct the inner class.
>
>
>> The access modifiers document intended usage even if there is limited accessibility to the class defining the member. The idea that a class restricted to package-access should have member access modifiers restricted to package-only or else private, is just plain wrong in my view. Each type should have a public, protected and private API. The exposure of the type within a package is a separate matter. Package-access then becomes a limited-sharing mechanism.
>>
> For private inner classes i took the view that protected on fields offered little value, but paused for top level classes.
>
> There are not many use-cases in the JDK at least for the packages i browsed. The class java.util.concurrent.atomic.Striped64 does not bother with protected.
>
> I am leaning towards the opinion that protected is just noise in these cases since the compiler offers no protection.

amen :)

>
> Paul.

R?mi


From forax at univ-mlv.fr  Tue Feb 26 05:50:11 2013
From: forax at univ-mlv.fr (Remi Forax)
Date: Tue, 26 Feb 2013 14:50:11 +0100
Subject: Code review request
In-Reply-To: <458B2D62-336C-429C-B835-DEEC7031004B@oracle.com>
References: <512672E6.1050708@oracle.com> <51289F3D.1010609@univ-mlv.fr>
	<458B2D62-336C-429C-B835-DEEC7031004B@oracle.com>
Message-ID: <512CBD93.1080805@univ-mlv.fr>

On 02/25/2013 06:31 PM, Paul Sandoz wrote:
> Hi Remi,
>
> Thanks for the feedback i have addressed some of this, mostly related to inner classes, in following change set to the lambda repo:
>
> http://hg.openjdk.java.net/lambda/lambda/jdk/rev/3e50294c68ea
>
> We can update the webrev next week.

<nitpicking mode="on">

There are still some methods that are declared 'default public' and some 
that are declared just with 'default'.

I propose the following code convention for abstract/default method in 
interface.
All methods in interface are marked public (just because we may support 
private static method in jdk9),
default method should be 'public default' and not 'default public', like 
we have public static, visibility modifier first,
and abstract methods in the same interface should be declared only 'public'.

R?mi
...


From david at hartveld.net  Tue Feb 26 05:57:54 2013
From: david at hartveld.net (David Hartveld)
Date: Tue, 26 Feb 2013 14:57:54 +0100
Subject: Stream.flatMap reference ambiguity
Message-ID: <CAKjJbnrbVM1BTJEydWDvcy5Fgbi0NYH9bRvE-+u+yjyfR+NjOw@mail.gmail.com>

Hi all,

I just ran into the following problem with flatMap: the compiler
(lambda-b78) is not able to infer the correct overload for flatMap.

The code:

List<String> ss = new ArrayList<>();
ss.stream().flatMap((x, sink) -> {
for (String s : x.split(",")) {
 sink.accept(s);
}
});

The compiler output:

FlatMapTest.java:[38,28] reference to flatMap is ambiguous
both method flatMap(java.util.stream.FlatMapper.ToLong<? super T>) in
java.util.stream.Stream and method
flatMap(java.util.stream.FlatMapper.ToDouble<? super T>) in
java.util.stream.Stream match
FlatMapTest.java:[40,37] method accept in interface
java.util.function.LongConsumer cannot be applied to given types;
required: long
found: java.lang.String
reason: argument mismatch; java.lang.String cannot be converted to long

This can be solved by typing the lambda parameters (actually, exactly that
is done in the default implementation of Stream.flatMap(Function<T,
Stream<? extends R>>).

Is this a bug/unimplemented inference situation? If not, I would prefer a
rename of the flatMap overloads that return a primitive stream (these cause
the ambiguity, right?). I think it is confusing that, when using the Stream
API (or any other coherent API), you have to specify types in some lambdas,
and not in others - I find this confusing, and it probably is even more so
for less advanced programmers.

Thanks in advance for a great-looking update to the JDK!

Regards,
David Hartveld

From maurizio.cimadamore at oracle.com  Tue Feb 26 06:15:35 2013
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Tue, 26 Feb 2013 14:15:35 +0000
Subject: Stream.flatMap reference ambiguity
In-Reply-To: <CAKjJbnrbVM1BTJEydWDvcy5Fgbi0NYH9bRvE-+u+yjyfR+NjOw@mail.gmail.com>
References: <CAKjJbnrbVM1BTJEydWDvcy5Fgbi0NYH9bRvE-+u+yjyfR+NjOw@mail.gmail.com>
Message-ID: <512CC387.9000406@oracle.com>

On 26/02/13 13:57, David Hartveld wrote:
> Hi all,
>
> I just ran into the following problem with flatMap: the compiler
> (lambda-b78) is not able to infer the correct overload for flatMap.
>
> The code:
>
> List<String> ss = new ArrayList<>();
> ss.stream().flatMap((x, sink) -> {
> for (String s : x.split(",")) {
>   sink.accept(s);
> }
> });

The compiler is correct, at least according to the spec. the two SAMs 
are like:

@FunctionalInterface

        69      interface ToLong<T> {

        70          /**

        71           * Accept an input element and emit zero or more output elements into the provided {@code LongConsumer}

        72           * @param element The input element

        73           * @param sink A {@code LongConsumer} to receive the output elements

        74           */

        75          void flattenInto(T element, LongConsumer sink);

        76      }


and

@FunctionalInterface

        83      interface ToDouble<T> {

        84          /**

        85           * Accept an input element and emit zero or more output elements into the provided {@code DoubleConsumer}

        86           * @param element The input element

        87           * @param sink A {@code DoubleConsumer} to receive the output elements

        88           */

        89          void flattenInto(T element, DoubleConsumer sink);

        90      }


Both descriptors are void, so the compiler cannot use the usual trick of 
picking the SAM with the most specific return type. Another problem is 
that the return-type trick is currently only applied if the descriptor 
parameter lists match - which is also not the case here. I think this 
calls for some sort of API refactoring.

Maurizio
>
> The compiler output:
>
> FlatMapTest.java:[38,28] reference to flatMap is ambiguous
> both method flatMap(java.util.stream.FlatMapper.ToLong<? super T>) in
> java.util.stream.Stream and method
> flatMap(java.util.stream.FlatMapper.ToDouble<? super T>) in
> java.util.stream.Stream match
> FlatMapTest.java:[40,37] method accept in interface
> java.util.function.LongConsumer cannot be applied to given types;
> required: long
> found: java.lang.String
> reason: argument mismatch; java.lang.String cannot be converted to long
>
> This can be solved by typing the lambda parameters (actually, exactly that
> is done in the default implementation of Stream.flatMap(Function<T,
> Stream<? extends R>>).
>
> Is this a bug/unimplemented inference situation? If not, I would prefer a
> rename of the flatMap overloads that return a primitive stream (these cause
> the ambiguity, right?). I think it is confusing that, when using the Stream
> API (or any other coherent API), you have to specify types in some lambdas,
> and not in others - I find this confusing, and it probably is even more so
> for less advanced programmers.
>
> Thanks in advance for a great-looking update to the JDK!
>
> Regards,
> David Hartveld
>


From paul.sandoz at oracle.com  Tue Feb 26 06:21:40 2013
From: paul.sandoz at oracle.com (paul.sandoz at oracle.com)
Date: Tue, 26 Feb 2013 14:21:40 +0000
Subject: hg: lambda/lambda/jdk: Fix license headers.
Message-ID: <20130226142201.5F2E14741A@hg.openjdk.java.net>

Changeset: 74ded82f6a9b
Author:    psandoz
Date:      2013-02-26 15:21 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/74ded82f6a9b

Fix license headers.

! src/share/classes/java/util/concurrent/ArrayBlockingQueue.java
! src/share/classes/java/util/concurrent/ConcurrentLinkedDeque.java
! src/share/classes/java/util/concurrent/PriorityBlockingQueue.java


From paul.sandoz at oracle.com  Tue Feb 26 07:24:09 2013
From: paul.sandoz at oracle.com (paul.sandoz at oracle.com)
Date: Tue, 26 Feb 2013 15:24:09 +0000
Subject: hg: lambda/lambda/jdk: Updates to LinkedList and Vector spliterators.
Message-ID: <20130226152438.614264741C@hg.openjdk.java.net>

Changeset: 0b8d535e6869
Author:    psandoz
Date:      2013-02-26 16:24 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/0b8d535e6869

Updates to LinkedList and Vector spliterators.
Contributed-by: Doug Lea <dl at cs.oswego.edu>

! src/share/classes/java/util/LinkedList.java
! src/share/classes/java/util/Vector.java


From paul.sandoz at oracle.com  Tue Feb 26 07:41:14 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 26 Feb 2013 16:41:14 +0100
Subject: Code review request
In-Reply-To: <512CBD93.1080805@univ-mlv.fr>
References: <512672E6.1050708@oracle.com> <51289F3D.1010609@univ-mlv.fr>
	<458B2D62-336C-429C-B835-DEEC7031004B@oracle.com>
	<512CBD93.1080805@univ-mlv.fr>
Message-ID: <20D89B20-0604-45E9-AAA7-38F74298C77A@oracle.com>


On Feb 26, 2013, at 2:50 PM, Remi Forax <forax at univ-mlv.fr> wrote:

> On 02/25/2013 06:31 PM, Paul Sandoz wrote:
>> Hi Remi,
>> 
>> Thanks for the feedback i have addressed some of this, mostly related to inner classes, in following change set to the lambda repo:
>> 
>> http://hg.openjdk.java.net/lambda/lambda/jdk/rev/3e50294c68ea
>> 
>> We can update the webrev next week.
> 
> <nitpicking mode="on">
> 
> There are still some methods that are declared 'default public'

Where?


> and some that are declared just with 'default'.
> 

> I propose the following code convention for abstract/default method in interface.
> All methods in interface are marked public (just because we may support private static method in jdk9),
> default method should be 'public default' and not 'default public', like we have public static, visibility modifier first,
> and abstract methods in the same interface should be declared only 'public'.
> 

I do not relish your proposal of changing all abstract methods in interfaces to be declared redundantly public because of potential future features, even if such features are highly likely, we should have that discussion when those feature arrive.

The source in the java.util.function package uses "public default" for default methods. That source has been through a round of reviews strongly indicating this was the preferred approach. Mike, is that so?

Paul.

From scolebourne at joda.org  Tue Feb 26 07:59:25 2013
From: scolebourne at joda.org (Stephen Colebourne)
Date: Tue, 26 Feb 2013 15:59:25 +0000
Subject: Code review request
In-Reply-To: <20D89B20-0604-45E9-AAA7-38F74298C77A@oracle.com>
References: <512672E6.1050708@oracle.com> <51289F3D.1010609@univ-mlv.fr>
	<458B2D62-336C-429C-B835-DEEC7031004B@oracle.com>
	<512CBD93.1080805@univ-mlv.fr>
	<20D89B20-0604-45E9-AAA7-38F74298C77A@oracle.com>
Message-ID: <CACzrW9AG_wcjiQnQecUo6wCc9V6B1rdBpF0Sh_Gjpogj7KwD=A@mail.gmail.com>

On 26 February 2013 15:41, Paul Sandoz <paul.sandoz at oracle.com> wrote:
> On Feb 26, 2013, at 2:50 PM, Remi Forax <forax at univ-mlv.fr> wrote:
>> I propose the following code convention for abstract/default method in interface.
>> All methods in interface are marked public (just because we may support private static method in jdk9),
>> default method should be 'public default' and not 'default public', like we have public static, visibility modifier first,
>> and abstract methods in the same interface should be declared only 'public'.
>
> I do not relish your proposal of changing all abstract methods in interfaces to be declared redundantly public because of potential future features, even if such features are highly likely, we should have that discussion when those feature arrive.

I am also of the opinion that abstract interface methods should now
explicitly be declared "public". I'd strongly recommend at least
starting with all methods within any interface that has a default
method.

Stephen

From forax at univ-mlv.fr  Tue Feb 26 08:02:46 2013
From: forax at univ-mlv.fr (Remi Forax)
Date: Tue, 26 Feb 2013 17:02:46 +0100
Subject: Code review request
In-Reply-To: <20D89B20-0604-45E9-AAA7-38F74298C77A@oracle.com>
References: <512672E6.1050708@oracle.com> <51289F3D.1010609@univ-mlv.fr>
	<458B2D62-336C-429C-B835-DEEC7031004B@oracle.com>
	<512CBD93.1080805@univ-mlv.fr>
	<20D89B20-0604-45E9-AAA7-38F74298C77A@oracle.com>
Message-ID: <512CDCA6.9040408@univ-mlv.fr>

On 02/26/2013 04:41 PM, Paul Sandoz wrote:
> On Feb 26, 2013, at 2:50 PM, Remi Forax <forax at univ-mlv.fr> wrote:
>
>> On 02/25/2013 06:31 PM, Paul Sandoz wrote:
>>> Hi Remi,
>>>
>>> Thanks for the feedback i have addressed some of this, mostly related to inner classes, in following change set to the lambda repo:
>>>
>>> http://hg.openjdk.java.net/lambda/lambda/jdk/rev/3e50294c68ea
>>>
>>> We can update the webrev next week.
>> <nitpicking mode="on">
>>
>> There are still some methods that are declared 'default public'
> Where?

sorry, read the wrong line in the patch.

>
>
>> and some that are declared just with 'default'.
>>
>> I propose the following code convention for abstract/default method in interface.
>> All methods in interface are marked public (just because we may support private static method in jdk9),
>> default method should be 'public default' and not 'default public', like we have public static, visibility modifier first,
>> and abstract methods in the same interface should be declared only 'public'.
>>
> I do not relish your proposal of changing all abstract methods in interfaces to be declared redundantly public because of potential future features, even if such features are highly likely, we should have that discussion when those feature arrive.

I was thinking to update only interfaces having default methods in it.
Not all interfaces of the world :)

>
> The source in the java.util.function package uses "public default" for default methods. That source has been through a round of reviews strongly indicating this was the preferred approach. Mike, is that so?
>
> Paul.
>

R?mi


From paul.sandoz at oracle.com  Tue Feb 26 08:36:32 2013
From: paul.sandoz at oracle.com (paul.sandoz at oracle.com)
Date: Tue, 26 Feb 2013 16:36:32 +0000
Subject: hg: lambda/lambda/jdk: Fork left and compute on right in loop to
	avoid potential stack overflows with
Message-ID: <20130226163654.E8E974741E@hg.openjdk.java.net>

Changeset: eadbf7bcb6f8
Author:    psandoz
Date:      2013-02-26 17:34 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/eadbf7bcb6f8

Fork left and compute on right in loop to avoid potential stack overflows with
right-balanced trees (e.g. those created from iterator-based spliterators).

! src/share/classes/java/util/stream/NodeUtils.java


From zhong.j.yu at gmail.com  Tue Feb 26 09:06:09 2013
From: zhong.j.yu at gmail.com (Zhong Yu)
Date: Tue, 26 Feb 2013 11:06:09 -0600
Subject: Stream.flatMap reference ambiguity
In-Reply-To: <CAKjJbnrbVM1BTJEydWDvcy5Fgbi0NYH9bRvE-+u+yjyfR+NjOw@mail.gmail.com>
References: <CAKjJbnrbVM1BTJEydWDvcy5Fgbi0NYH9bRvE-+u+yjyfR+NjOw@mail.gmail.com>
Message-ID: <CACuKZqEB0xMhgrUOHbb5yV=zJ6NW1s1wVVXKpejFS75EsDdZYw@mail.gmail.com>

On Tue, Feb 26, 2013 at 7:57 AM, David Hartveld <david at hartveld.net> wrote:
> Hi all,
>
> I just ran into the following problem with flatMap: the compiler
> (lambda-b78) is not able to infer the correct overload for flatMap.
>
> The code:
>
> List<String> ss = new ArrayList<>();
> ss.stream().flatMap((x, sink) -> {
> for (String s : x.split(",")) {
>  sink.accept(s);
> }
> });

This example is not very realistic, since the result of flatMap() is
not used, the code doesn't really do anything. What if it's assigned
to a `Stream<String>`?

> The compiler output:
>
> FlatMapTest.java:[38,28] reference to flatMap is ambiguous
> both method flatMap(java.util.stream.FlatMapper.ToLong<? super T>) in
> java.util.stream.Stream and method
> flatMap(java.util.stream.FlatMapper.ToDouble<? super T>) in
> java.util.stream.Stream match
> FlatMapTest.java:[40,37] method accept in interface
> java.util.function.LongConsumer cannot be applied to given types;
> required: long
> found: java.lang.String
> reason: argument mismatch; java.lang.String cannot be converted to long
>
> This can be solved by typing the lambda parameters (actually, exactly that
> is done in the default implementation of Stream.flatMap(Function<T,
> Stream<? extends R>>).
>
> Is this a bug/unimplemented inference situation? If not, I would prefer a
> rename of the flatMap overloads that return a primitive stream (these cause
> the ambiguity, right?). I think it is confusing that, when using the Stream
> API (or any other coherent API), you have to specify types in some lambdas,
> and not in others - I find this confusing, and it probably is even more so
> for less advanced programmers.
>
> Thanks in advance for a great-looking update to the JDK!
>
> Regards,
> David Hartveld
>

From maurizio.cimadamore at oracle.com  Tue Feb 26 09:26:33 2013
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Tue, 26 Feb 2013 17:26:33 +0000
Subject: Stream.flatMap reference ambiguity
In-Reply-To: <CACuKZqEB0xMhgrUOHbb5yV=zJ6NW1s1wVVXKpejFS75EsDdZYw@mail.gmail.com>
References: <CAKjJbnrbVM1BTJEydWDvcy5Fgbi0NYH9bRvE-+u+yjyfR+NjOw@mail.gmail.com>
	<CACuKZqEB0xMhgrUOHbb5yV=zJ6NW1s1wVVXKpejFS75EsDdZYw@mail.gmail.com>
Message-ID: <512CF049.5070303@oracle.com>

On 26/02/13 17:06, Zhong Yu wrote:
> On Tue, Feb 26, 2013 at 7:57 AM, David Hartveld <david at hartveld.net> wrote:
>> Hi all,
>>
>> I just ran into the following problem with flatMap: the compiler
>> (lambda-b78) is not able to infer the correct overload for flatMap.
>>
>> The code:
>>
>> List<String> ss = new ArrayList<>();
>> ss.stream().flatMap((x, sink) -> {
>> for (String s : x.split(",")) {
>>   sink.accept(s);
>> }
>> });
> This example is not very realistic, since the result of flatMap() is
> not used, the code doesn't really do anything. What if it's assigned
> to a `Stream<String>`?
I would expect the compiler to issue the same ambiguity - overload 
resolution does not depend on target type of the method call; once most 
specific method has been selected, you can look at the target to perform 
type-inference. But not before then.

Maurizio
>
>> The compiler output:
>>
>> FlatMapTest.java:[38,28] reference to flatMap is ambiguous
>> both method flatMap(java.util.stream.FlatMapper.ToLong<? super T>) in
>> java.util.stream.Stream and method
>> flatMap(java.util.stream.FlatMapper.ToDouble<? super T>) in
>> java.util.stream.Stream match
>> FlatMapTest.java:[40,37] method accept in interface
>> java.util.function.LongConsumer cannot be applied to given types;
>> required: long
>> found: java.lang.String
>> reason: argument mismatch; java.lang.String cannot be converted to long
>>
>> This can be solved by typing the lambda parameters (actually, exactly that
>> is done in the default implementation of Stream.flatMap(Function<T,
>> Stream<? extends R>>).
>>
>> Is this a bug/unimplemented inference situation? If not, I would prefer a
>> rename of the flatMap overloads that return a primitive stream (these cause
>> the ambiguity, right?). I think it is confusing that, when using the Stream
>> API (or any other coherent API), you have to specify types in some lambdas,
>> and not in others - I find this confusing, and it probably is even more so
>> for less advanced programmers.
>>
>> Thanks in advance for a great-looking update to the JDK!
>>
>> Regards,
>> David Hartveld
>>


From spullara at gmail.com  Tue Feb 26 09:24:49 2013
From: spullara at gmail.com (Sam Pullara)
Date: Tue, 26 Feb 2013 09:24:49 -0800
Subject: Stream.flatMap reference ambiguity
In-Reply-To: <CACuKZqEB0xMhgrUOHbb5yV=zJ6NW1s1wVVXKpejFS75EsDdZYw@mail.gmail.com>
References: <CAKjJbnrbVM1BTJEydWDvcy5Fgbi0NYH9bRvE-+u+yjyfR+NjOw@mail.gmail.com>
	<CACuKZqEB0xMhgrUOHbb5yV=zJ6NW1s1wVVXKpejFS75EsDdZYw@mail.gmail.com>
Message-ID: <5786C373-3FC8-4DCD-A977-464F1DF8F617@gmail.com>

Doesn't help. You need to specify the types. It would be great if this were fixed either in the API or in the inference engine:

      List<String> ss = new ArrayList<>();
      ss.stream().flatMap((String x, Consumer<String> sink) -> {
        for (String s : x.split(",")) {
          sink.accept(s);
        }
      });

Sam

On Feb 26, 2013, at 9:06 AM, Zhong Yu <zhong.j.yu at gmail.com> wrote:

> On Tue, Feb 26, 2013 at 7:57 AM, David Hartveld <david at hartveld.net> wrote:
>> Hi all,
>> 
>> I just ran into the following problem with flatMap: the compiler
>> (lambda-b78) is not able to infer the correct overload for flatMap.
>> 
>> The code:
>> 
>> List<String> ss = new ArrayList<>();
>> ss.stream().flatMap((x, sink) -> {
>> for (String s : x.split(",")) {
>> sink.accept(s);
>> }
>> });
> 
> This example is not very realistic, since the result of flatMap() is
> not used, the code doesn't really do anything. What if it's assigned
> to a `Stream<String>`?
> 
>> The compiler output:
>> 
>> FlatMapTest.java:[38,28] reference to flatMap is ambiguous
>> both method flatMap(java.util.stream.FlatMapper.ToLong<? super T>) in
>> java.util.stream.Stream and method
>> flatMap(java.util.stream.FlatMapper.ToDouble<? super T>) in
>> java.util.stream.Stream match
>> FlatMapTest.java:[40,37] method accept in interface
>> java.util.function.LongConsumer cannot be applied to given types;
>> required: long
>> found: java.lang.String
>> reason: argument mismatch; java.lang.String cannot be converted to long
>> 
>> This can be solved by typing the lambda parameters (actually, exactly that
>> is done in the default implementation of Stream.flatMap(Function<T,
>> Stream<? extends R>>).
>> 
>> Is this a bug/unimplemented inference situation? If not, I would prefer a
>> rename of the flatMap overloads that return a primitive stream (these cause
>> the ambiguity, right?). I think it is confusing that, when using the Stream
>> API (or any other coherent API), you have to specify types in some lambdas,
>> and not in others - I find this confusing, and it probably is even more so
>> for less advanced programmers.
>> 
>> Thanks in advance for a great-looking update to the JDK!
>> 
>> Regards,
>> David Hartveld
>> 
> 


From maurizio.cimadamore at oracle.com  Tue Feb 26 10:09:08 2013
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Tue, 26 Feb 2013 18:09:08 +0000
Subject: Stream.flatMap reference ambiguity
In-Reply-To: <5786C373-3FC8-4DCD-A977-464F1DF8F617@gmail.com>
References: <CAKjJbnrbVM1BTJEydWDvcy5Fgbi0NYH9bRvE-+u+yjyfR+NjOw@mail.gmail.com>
	<CACuKZqEB0xMhgrUOHbb5yV=zJ6NW1s1wVVXKpejFS75EsDdZYw@mail.gmail.com>
	<5786C373-3FC8-4DCD-A977-464F1DF8F617@gmail.com>
Message-ID: <512CFA44.5010100@oracle.com>

On 26/02/13 17:24, Sam Pullara wrote:
> Doesn't help. You need to specify the types. It would be great if this were fixed either in the API or in the inference engine:
>
>        List<String> ss = new ArrayList<>();
>        ss.stream().flatMap((String x, Consumer<String> sink) -> {
>          for (String s : x.split(",")) {
>            sink.accept(s);
>          }
>        });
Never say never ;-)

Turns out that my first stab at the code was wrong as it didn't take 
into account something that we have included in the spec: if a lambda 
contains errors (i.e. as a result of the choice of bad parameter types 
from the target) the method is not applicable.

Now - in this example there are three potentially applicable methods 
(after provisional applicability):

1) <R> Stream<R> flatMap(FlatMapper<? super T, R> mapper) // (T, Consumer<R>)void
2)IntStream flatMap(FlatMapper.ToInt<? super T> mapper); // (int, IntConsumer)void
3)LongStream flatMap(FlatMapper.ToLong<? super T> mapper); // (long, LongConsumer)void
4)DoubleStream flatMap(FlatMapper.ToDouble<? super T> mapper); // (double, DoubleConsumer)void

  

the first parameter type inferred from the descriptor is interesting: it 
can be either T (the type of the Stream, String in this case), int, long 
or double. But if you look at the code, it contains this snippet:

x.split(",")


This will only compile when x has type String - which means only method 
(1) is applicable, no ambiguity should be issued.

I'm actually in the process of updating the compiler to reflect that 
rule in the spec, and I found that it compiles this example just fine, 
even w/o explicit types. I'll push a patch soon.

Maurizio





> Sam
>
> On Feb 26, 2013, at 9:06 AM, Zhong Yu <zhong.j.yu at gmail.com> wrote:
>
>> On Tue, Feb 26, 2013 at 7:57 AM, David Hartveld <david at hartveld.net> wrote:
>>> Hi all,
>>>
>>> I just ran into the following problem with flatMap: the compiler
>>> (lambda-b78) is not able to infer the correct overload for flatMap.
>>>
>>> The code:
>>>
>>> List<String> ss = new ArrayList<>();
>>> ss.stream().flatMap((x, sink) -> {
>>> for (String s : x.split(",")) {
>>> sink.accept(s);
>>> }
>>> });
>> This example is not very realistic, since the result of flatMap() is
>> not used, the code doesn't really do anything. What if it's assigned
>> to a `Stream<String>`?
>>
>>> The compiler output:
>>>
>>> FlatMapTest.java:[38,28] reference to flatMap is ambiguous
>>> both method flatMap(java.util.stream.FlatMapper.ToLong<? super T>) in
>>> java.util.stream.Stream and method
>>> flatMap(java.util.stream.FlatMapper.ToDouble<? super T>) in
>>> java.util.stream.Stream match
>>> FlatMapTest.java:[40,37] method accept in interface
>>> java.util.function.LongConsumer cannot be applied to given types;
>>> required: long
>>> found: java.lang.String
>>> reason: argument mismatch; java.lang.String cannot be converted to long
>>>
>>> This can be solved by typing the lambda parameters (actually, exactly that
>>> is done in the default implementation of Stream.flatMap(Function<T,
>>> Stream<? extends R>>).
>>>
>>> Is this a bug/unimplemented inference situation? If not, I would prefer a
>>> rename of the flatMap overloads that return a primitive stream (these cause
>>> the ambiguity, right?). I think it is confusing that, when using the Stream
>>> API (or any other coherent API), you have to specify types in some lambdas,
>>> and not in others - I find this confusing, and it probably is even more so
>>> for less advanced programmers.
>>>
>>> Thanks in advance for a great-looking update to the JDK!
>>>
>>> Regards,
>>> David Hartveld
>>>
>


From daniel.smith at oracle.com  Tue Feb 26 10:59:16 2013
From: daniel.smith at oracle.com (Dan Smith)
Date: Tue, 26 Feb 2013 11:59:16 -0700
Subject: Stream.flatMap reference ambiguity
In-Reply-To: <512CFA44.5010100@oracle.com>
References: <CAKjJbnrbVM1BTJEydWDvcy5Fgbi0NYH9bRvE-+u+yjyfR+NjOw@mail.gmail.com>
	<CACuKZqEB0xMhgrUOHbb5yV=zJ6NW1s1wVVXKpejFS75EsDdZYw@mail.gmail.com>
	<5786C373-3FC8-4DCD-A977-464F1DF8F617@gmail.com>
	<512CFA44.5010100@oracle.com>
Message-ID: <D7E726AB-4970-4648-9D6B-7D5B01115735@oracle.com>

On Feb 26, 2013, at 11:09 AM, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:

> Now - in this example there are three potentially applicable methods 
> (after provisional applicability):
> 
> 1) <R> Stream<R> flatMap(FlatMapper<? super T, R> mapper) // (T, Consumer<R>)void
> 2)IntStream flatMap(FlatMapper.ToInt<? super T> mapper); // (int, IntConsumer)void
> 3)LongStream flatMap(FlatMapper.ToLong<? super T> mapper); // (long, LongConsumer)void
> 4)DoubleStream flatMap(FlatMapper.ToDouble<? super T> mapper); // (double, DoubleConsumer)void
> 
> 
> 
> the first parameter type inferred from the descriptor is interesting: it 
> can be either T (the type of the Stream, String in this case), int, long 
> or double. But if you look at the code, it contains this snippet:
> 
> x.split(",")
> 
> 
> This will only compile when x has type String - which means only method 
> (1) is applicable, no ambiguity should be issued.

Correct.  The invocation of "split" should disambiguate (as well as the invocation of 'accept' with a String).

I think the core problem is the API (in general, it's best to avoid overloading with functional interfaces that have different parameter types), but this is an interesting example in any case.

David, this is actually something we've had a hard time predicting user expectations on.  You get the more powerful inference, but at the cost of more fragile code.  As a programmer, are you okay with that?  (Other interested parties are free to chime in, too.)

Here's the original example, which should compile:

List<String> ss = new ArrayList<>();
ss.stream().flatMap((x, sink) -> {
  for (String s : x.split(",")) {
    sink.accept(s);
  }
});

If I refactor (maybe for debugging) to something like this, it won't compile anymore, due to ambiguity:

List<String> ss = new ArrayList<>();
ss.stream().flatMap((x, sink) -> sink.accept(x));

If I add some logging code, it might compile again:

List<String> ss = new ArrayList<>();
ss.stream().flatMap((x, sink) -> {
  if (x.startsWith("a")) System.out.println(x);
  sink.accept(x));
});

The key is that the first example uses methods that make it clear that 'x' is a String (or that 'sink' is not an IntConsumer/LongConsumer/DoubleConsumer).

?Dan

From daniel.smith at oracle.com  Tue Feb 26 11:10:36 2013
From: daniel.smith at oracle.com (Dan Smith)
Date: Tue, 26 Feb 2013 12:10:36 -0700
Subject: Code review request
In-Reply-To: <CACzrW9AG_wcjiQnQecUo6wCc9V6B1rdBpF0Sh_Gjpogj7KwD=A@mail.gmail.com>
References: <512672E6.1050708@oracle.com> <51289F3D.1010609@univ-mlv.fr>
	<458B2D62-336C-429C-B835-DEEC7031004B@oracle.com>
	<512CBD93.1080805@univ-mlv.fr>
	<20D89B20-0604-45E9-AAA7-38F74298C77A@oracle.com>
	<CACzrW9AG_wcjiQnQecUo6wCc9V6B1rdBpF0Sh_Gjpogj7KwD=A@mail.gmail.com>
Message-ID: <52375EE4-4C1E-42A6-AFD4-6A33C7EA9900@oracle.com>

On Feb 26, 2013, at 8:59 AM, Stephen Colebourne <scolebourne at joda.org> wrote:

> On 26 February 2013 15:41, Paul Sandoz <paul.sandoz at oracle.com> wrote:
>> On Feb 26, 2013, at 2:50 PM, Remi Forax <forax at univ-mlv.fr> wrote:
>>> I propose the following code convention for abstract/default method in interface.
>>> All methods in interface are marked public (just because we may support private static method in jdk9),
>>> default method should be 'public default' and not 'default public', like we have public static, visibility modifier first,
>>> and abstract methods in the same interface should be declared only 'public'.
>> 
>> I do not relish your proposal of changing all abstract methods in interfaces to be declared redundantly public because of potential future features, even if such features are highly likely, we should have that discussion when those feature arrive.
> 
> I am also of the opinion that abstract interface methods should now
> explicitly be declared "public". I'd strongly recommend at least
> starting with all methods within any interface that has a default
> method.

Just to be clear, everything in an interface is public in Java 8, just like it has always been.  Default methods don't have anything to do with access flags.  (We've talked about the fact that they _enable_ and _encourage_ a separate feature to support different accessibilities in interfaces, but that is still a separate feature, and is not planned as part of Java 8.)

The more relevant coding convention debate to be had, if any, is whether "abstract" should be used on abstract methods, now that not every method in an interface is "abstract".

?Dan

From zhong.j.yu at gmail.com  Tue Feb 26 12:03:37 2013
From: zhong.j.yu at gmail.com (Zhong Yu)
Date: Tue, 26 Feb 2013 14:03:37 -0600
Subject: Stream.flatMap reference ambiguity
In-Reply-To: <D7E726AB-4970-4648-9D6B-7D5B01115735@oracle.com>
References: <CAKjJbnrbVM1BTJEydWDvcy5Fgbi0NYH9bRvE-+u+yjyfR+NjOw@mail.gmail.com>
	<CACuKZqEB0xMhgrUOHbb5yV=zJ6NW1s1wVVXKpejFS75EsDdZYw@mail.gmail.com>
	<5786C373-3FC8-4DCD-A977-464F1DF8F617@gmail.com>
	<512CFA44.5010100@oracle.com>
	<D7E726AB-4970-4648-9D6B-7D5B01115735@oracle.com>
Message-ID: <CACuKZqHY86LmbHk+58e-s4zZK3UHD3ZEjJcRXe8SwEz89M2ZCQ@mail.gmail.com>

On Tue, Feb 26, 2013 at 12:59 PM, Dan Smith <daniel.smith at oracle.com> wrote:
> On Feb 26, 2013, at 11:09 AM, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
>
>> Now - in this example there are three potentially applicable methods
>> (after provisional applicability):
>>
>> 1) <R> Stream<R> flatMap(FlatMapper<? super T, R> mapper) // (T, Consumer<R>)void
>> 2)IntStream flatMap(FlatMapper.ToInt<? super T> mapper); // (int, IntConsumer)void
>> 3)LongStream flatMap(FlatMapper.ToLong<? super T> mapper); // (long, LongConsumer)void
>> 4)DoubleStream flatMap(FlatMapper.ToDouble<? super T> mapper); // (double, DoubleConsumer)void
>>
>>
>>
>> the first parameter type inferred from the descriptor is interesting: it
>> can be either T (the type of the Stream, String in this case), int, long
>> or double. But if you look at the code, it contains this snippet:
>>
>> x.split(",")
>>
>>
>> This will only compile when x has type String - which means only method
>> (1) is applicable, no ambiguity should be issued.
>
> Correct.  The invocation of "split" should disambiguate (as well as the invocation of 'accept' with a String).
>
> I think the core problem is the API (in general, it's best to avoid overloading with functional interfaces that have different parameter types), but this is an interesting example in any case.
>
> David, this is actually something we've had a hard time predicting user expectations on.  You get the more powerful inference, but at the cost of more fragile code.  As a programmer, are you okay with that?  (Other interested parties are free to chime in, too.)
>
> Here's the original example, which should compile:
>
> List<String> ss = new ArrayList<>();
> ss.stream().flatMap((x, sink) -> {
>   for (String s : x.split(",")) {
>     sink.accept(s);
>   }
> });
>
> If I refactor (maybe for debugging) to something like this, it won't compile anymore, due to ambiguity:
>
> List<String> ss = new ArrayList<>();
> ss.stream().flatMap((x, sink) -> sink.accept(x));

wait... since x must be String (or supertype of), sink cannot be
IntConsumer, therefore flatMap(FlatMapper.ToInt) cannot apply,
correct?

> If I add some logging code, it might compile again:
>
> List<String> ss = new ArrayList<>();
> ss.stream().flatMap((x, sink) -> {
>   if (x.startsWith("a")) System.out.println(x);
>   sink.accept(x));
> });
>
> The key is that the first example uses methods that make it clear that 'x' is a String (or that 'sink' is not an IntConsumer/LongConsumer/DoubleConsumer).
>
> ?Dan

From daniel.smith at oracle.com  Tue Feb 26 13:05:36 2013
From: daniel.smith at oracle.com (Dan Smith)
Date: Tue, 26 Feb 2013 14:05:36 -0700
Subject: Stream.flatMap reference ambiguity
In-Reply-To: <CACuKZqHY86LmbHk+58e-s4zZK3UHD3ZEjJcRXe8SwEz89M2ZCQ@mail.gmail.com>
References: <CAKjJbnrbVM1BTJEydWDvcy5Fgbi0NYH9bRvE-+u+yjyfR+NjOw@mail.gmail.com>
	<CACuKZqEB0xMhgrUOHbb5yV=zJ6NW1s1wVVXKpejFS75EsDdZYw@mail.gmail.com>
	<5786C373-3FC8-4DCD-A977-464F1DF8F617@gmail.com>
	<512CFA44.5010100@oracle.com>
	<D7E726AB-4970-4648-9D6B-7D5B01115735@oracle.com>
	<CACuKZqHY86LmbHk+58e-s4zZK3UHD3ZEjJcRXe8SwEz89M2ZCQ@mail.gmail.com>
Message-ID: <B7303454-050B-495C-851D-D0ABABD8B64D@oracle.com>

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

> On Tue, Feb 26, 2013 at 12:59 PM, Dan Smith <daniel.smith at oracle.com> wrote:
>> On Feb 26, 2013, at 11:09 AM, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
>> 
>>> Now - in this example there are three potentially applicable methods
>>> (after provisional applicability):
>>> 
>>> 1) <R> Stream<R> flatMap(FlatMapper<? super T, R> mapper) // (T, Consumer<R>)void
>>> 2)IntStream flatMap(FlatMapper.ToInt<? super T> mapper); // (int, IntConsumer)void
>>> 3)LongStream flatMap(FlatMapper.ToLong<? super T> mapper); // (long, LongConsumer)void
>>> 4)DoubleStream flatMap(FlatMapper.ToDouble<? super T> mapper); // (double, DoubleConsumer)void
>>> 
>>> 
>>> 
>>> the first parameter type inferred from the descriptor is interesting: it
>>> can be either T (the type of the Stream, String in this case), int, long
>>> or double. But if you look at the code, it contains this snippet:
>>> 
>>> x.split(",")
>>> 
>>> 
>>> This will only compile when x has type String - which means only method
>>> (1) is applicable, no ambiguity should be issued.
>> 
>> Correct.  The invocation of "split" should disambiguate (as well as the invocation of 'accept' with a String).
>> 
>> I think the core problem is the API (in general, it's best to avoid overloading with functional interfaces that have different parameter types), but this is an interesting example in any case.
>> 
>> David, this is actually something we've had a hard time predicting user expectations on.  You get the more powerful inference, but at the cost of more fragile code.  As a programmer, are you okay with that?  (Other interested parties are free to chime in, too.)
>> 
>> Here's the original example, which should compile:
>> 
>> List<String> ss = new ArrayList<>();
>> ss.stream().flatMap((x, sink) -> {
>>  for (String s : x.split(",")) {
>>    sink.accept(s);
>>  }
>> });
>> 
>> If I refactor (maybe for debugging) to something like this, it won't compile anymore, due to ambiguity:
>> 
>> List<String> ss = new ArrayList<>();
>> ss.stream().flatMap((x, sink) -> sink.accept(x));
> 
> wait... since x must be String (or supertype of), sink cannot be
> IntConsumer, therefore flatMap(FlatMapper.ToInt) cannot apply,
> correct?

You're right.  I was going off of Maurizio's description of the method signatures, but looking at the sources, 'x' is always a String.

The descriptors in question are:
(String, Consumer<R>)->void (R is inferred)
(String, IntConsumer)->void
(String, LongConsumer)->void
(String, DoubleConsumer)->void

(Which makes a lot more sense.  I was having a hard time picturing what these methods are supposed to do...)

So, "x.split" does _not_ disambiguate, but "sink.accept(s)" does.  And the way to lose that disambiguation would be to avoid calling 'accept', again maybe as part of a debugging exercise:

List<String> ss = new ArrayList<>();
ss.stream().flatMap((x, sink) -> {
 for (String s : x.split(",")) {
   //sink.accept(s);
  System.out.println(s);
 }
});

Repeating: this sort of brittleness is something we think is probably acceptable in the language, but I'm happy to hear "real-world" feedback about whether the trade-offs are worth it.  (And, in this specific instance, this is probably a part of the API that should be tweaked.)

?Dan

From jed at wesleysmith.io  Tue Feb 26 13:05:46 2013
From: jed at wesleysmith.io (Jed Wesley-Smith)
Date: Wed, 27 Feb 2013 08:05:46 +1100
Subject: Where has the map method on Optional moved?
In-Reply-To: <7B9F8A51-D98C-435E-9628-117D92736AAC@oracle.com>
References: <CAD2aR4OeHOG+E9=mgZRZo2kM5TktjqTrv4ZuLiCsJKWnNHorQQ@mail.gmail.com>
	<5C64FDEE-13CC-4256-A09E-82614ACD4ADB@oracle.com>
	<CAN3nywD33uRJL545Np=NVmUbGQvF_Jq5su0nH=yCUywRy8Y5mg@mail.gmail.com>
	<BB68FEFB-F7EB-4067-9247-3E5F108B3878@oracle.com>
	<CAN3nywDHm3e_rb8HT4+nMmtVGdVMRdhdOWqwPDfMKe07Rs3cTg@mail.gmail.com>
	<7B9F8A51-D98C-435E-9628-117D92736AAC@oracle.com>
Message-ID: <CAN3nywAOFG5vqMMAS6+AsrYEuePWhp+73=3TwCtPdccHisdtKA@mail.gmail.com>

On 26 February 2013 23:40, Paul Sandoz <paul.sandoz at oracle.com> wrote:
> On Feb 26, 2013, at 12:33 PM, Jed Wesley-Smith <jed at wesleysmith.io> wrote:
>> FlatMapper is a bizarre Frankensteinian beast, relying as it does on
>> mutation to do all of its things.
>
> You mean mutation as in mutation of state? or mutation in the sense of Frankensteinian mutation due to indirection?

Mutation of state ? FlatMapper is passed things that it accumulates internally.

The usual form of flatMap/bind is to return the thing being mapped
across. No mutation is required (at least at the interface level,
under the covers local mutation is ok).

>> It would be a service to all to
>> rename it to something ? anything ? else, as it does not resemble the
>> notion of flatMap/bind that other functional programming languages or
>> libraries implement.
>>
>> As to consistency across the interfaces, Java doesn't have the ability
>> to generalise across Optional and Stream, lacking Higher Kinded Types.
>> The fact that Stream has named some feature that resembles a monadic
>> bind flatMap ideally should not then preclude the ability for Optional
>> to also have this feature.
>>
>> As to additional potential functionality, you are quite correct, the
>> restriction of inheritance/OO to be the sole mechanism for adorning
>> functionality on a data-structure means that the temptation exists to
>> implement it directly, and these (filter/fold/reduce/foreach etc) are
>> all sensible suggestions. I do not profess to have definitive answers
>> to these library design decisions, given the constraints that the
>> designs are under.
>
> The problem being Optional would stick out like a sore thumb. It's not a Stream. There is no direct way to get a Stream from it and if there were, which is quite easy to do, it would not give you what you really want.

I don't understand why that is a consideration. Stream is not the only
monadic thing in the world, there are many others, Future for instance
is an obvious one.

Optional has little to do with Stream. It can be seen as a collection
of zero or one elements and therefore could implement Iterable, but
this is not necessary. More useful would be the fold catamorphism:

interface Option<A> {
  B fold(Supplier<B> ifNone, Function<A, B> ifSome);
}

This is a jack of all trades combinator that can be used to implement
almost any other functionality you want.

cheers,
jed.

From zhong.j.yu at gmail.com  Tue Feb 26 13:57:49 2013
From: zhong.j.yu at gmail.com (Zhong Yu)
Date: Tue, 26 Feb 2013 15:57:49 -0600
Subject: Stream.flatMap reference ambiguity
In-Reply-To: <D7E726AB-4970-4648-9D6B-7D5B01115735@oracle.com>
References: <CAKjJbnrbVM1BTJEydWDvcy5Fgbi0NYH9bRvE-+u+yjyfR+NjOw@mail.gmail.com>
	<CACuKZqEB0xMhgrUOHbb5yV=zJ6NW1s1wVVXKpejFS75EsDdZYw@mail.gmail.com>
	<5786C373-3FC8-4DCD-A977-464F1DF8F617@gmail.com>
	<512CFA44.5010100@oracle.com>
	<D7E726AB-4970-4648-9D6B-7D5B01115735@oracle.com>
Message-ID: <CACuKZqFLeaifJGvmBjnujfNHfFsaZrYJZVrZe8i6XgBhbz4wXQ@mail.gmail.com>

On Tue, Feb 26, 2013 at 12:59 PM, Dan Smith <daniel.smith at oracle.com> wrote:
> On Feb 26, 2013, at 11:09 AM, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
>
>> Now - in this example there are three potentially applicable methods
>> (after provisional applicability):
>>
>> 1) <R> Stream<R> flatMap(FlatMapper<? super T, R> mapper) // (T, Consumer<R>)void
>> 2)IntStream flatMap(FlatMapper.ToInt<? super T> mapper); // (int, IntConsumer)void
>> 3)LongStream flatMap(FlatMapper.ToLong<? super T> mapper); // (long, LongConsumer)void
>> 4)DoubleStream flatMap(FlatMapper.ToDouble<? super T> mapper); // (double, DoubleConsumer)void
>>
>>
>>
>> the first parameter type inferred from the descriptor is interesting: it
>> can be either T (the type of the Stream, String in this case), int, long
>> or double. But if you look at the code, it contains this snippet:
>>
>> x.split(",")
>>
>>
>> This will only compile when x has type String - which means only method
>> (1) is applicable, no ambiguity should be issued.
>
> Correct.  The invocation of "split" should disambiguate (as well as the invocation of 'accept' with a String).
>
> I think the core problem is the API (in general, it's best to avoid overloading with functional interfaces that have different parameter types),

I don't quite understand what you mean, can you clarify?

> but this is an interesting example in any case.
>
> David, this is actually something we've had a hard time predicting user expectations on.  You get the more powerful inference, but at the cost of more fragile code.  As a programmer, are you okay with that?  (Other interested parties are free to chime in, too.)
>
> Here's the original example, which should compile:
>
> List<String> ss = new ArrayList<>();
> ss.stream().flatMap((x, sink) -> {
>   for (String s : x.split(",")) {
>     sink.accept(s);
>   }
> });
>
> If I refactor (maybe for debugging) to something like this, it won't compile anymore, due to ambiguity:
>
> List<String> ss = new ArrayList<>();
> ss.stream().flatMap((x, sink) -> sink.accept(x));
>
> If I add some logging code, it might compile again:
>
> List<String> ss = new ArrayList<>();
> ss.stream().flatMap((x, sink) -> {
>   if (x.startsWith("a")) System.out.println(x);
>   sink.accept(x));
> });
>
> The key is that the first example uses methods that make it clear that 'x' is a String (or that 'sink' is not an IntConsumer/LongConsumer/DoubleConsumer).
>
> ?Dan

From maurizio.cimadamore at oracle.com  Tue Feb 26 14:51:42 2013
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Tue, 26 Feb 2013 22:51:42 +0000
Subject: Stream.flatMap reference ambiguity
In-Reply-To: <B7303454-050B-495C-851D-D0ABABD8B64D@oracle.com>
References: <CAKjJbnrbVM1BTJEydWDvcy5Fgbi0NYH9bRvE-+u+yjyfR+NjOw@mail.gmail.com>
	<CACuKZqEB0xMhgrUOHbb5yV=zJ6NW1s1wVVXKpejFS75EsDdZYw@mail.gmail.com>
	<5786C373-3FC8-4DCD-A977-464F1DF8F617@gmail.com>
	<512CFA44.5010100@oracle.com>
	<D7E726AB-4970-4648-9D6B-7D5B01115735@oracle.com>
	<CACuKZqHY86LmbHk+58e-s4zZK3UHD3ZEjJcRXe8SwEz89M2ZCQ@mail.gmail.com>
	<B7303454-050B-495C-851D-D0ABABD8B64D@oracle.com>
Message-ID: <512D3C7E.3080707@oracle.com>

On 26/02/13 21:05, Dan Smith wrote:
> So, "x.split" does_not_  disambiguate, but "sink.accept(s)" does
You are right - sorry for the confusion; it seems like I've confused the 
FlatMapper.ToXYZ interfaces with the FlatMapper.ofXYZToXYZ interfaces.

Maurizio

From daniel.smith at oracle.com  Tue Feb 26 16:23:47 2013
From: daniel.smith at oracle.com (Dan Smith)
Date: Tue, 26 Feb 2013 17:23:47 -0700
Subject: Stream.flatMap reference ambiguity
In-Reply-To: <CACuKZqFLeaifJGvmBjnujfNHfFsaZrYJZVrZe8i6XgBhbz4wXQ@mail.gmail.com>
References: <CAKjJbnrbVM1BTJEydWDvcy5Fgbi0NYH9bRvE-+u+yjyfR+NjOw@mail.gmail.com>
	<CACuKZqEB0xMhgrUOHbb5yV=zJ6NW1s1wVVXKpejFS75EsDdZYw@mail.gmail.com>
	<5786C373-3FC8-4DCD-A977-464F1DF8F617@gmail.com>
	<512CFA44.5010100@oracle.com>
	<D7E726AB-4970-4648-9D6B-7D5B01115735@oracle.com>
	<CACuKZqFLeaifJGvmBjnujfNHfFsaZrYJZVrZe8i6XgBhbz4wXQ@mail.gmail.com>
Message-ID: <6FE7EF9B-859A-41E1-A9FD-A45F3D9E4A6E@oracle.com>

On Feb 26, 2013, at 2:57 PM, Zhong Yu <zhong.j.yu at gmail.com> wrote:

>> I think the core problem is the API (in general, it's best to avoid overloading with functional interfaces that have different parameter types),
> 
> I don't quite understand what you mean, can you clarify?

The type of the second parameter of the lambda depends on the overload resolution choice -- it may be a Consumer<String>, or a IntConsumer, or a LongConsumer, or a DoubleConsumer.  So overload resolution is given four different possible typings of the parameters of the lambda, and is asked to choose the "best" one.

As I've pointed out, this is a pretty brittle situation, and while the compiler is able to do a certain degree of disambiguation, there's a good chance that clients of the API will encounter ambiguities.

For example:

stream.flatMap((x, sink) -> sink.accept(x.length()));

'x.length()' is an int, meaning the intent is probably to represent an IntConsumer; but the compiler is not equipped to make that sort of judgement, and would be equally happy with a LongConsumer, or a DoubleConsumer, or a Consumer<Integer>, ...

Hence, API designers should generally avoid overloading that relies on disambiguating between functional interfaces of the same arity that have different parameter types.

?Dan

From zhong.j.yu at gmail.com  Tue Feb 26 16:42:04 2013
From: zhong.j.yu at gmail.com (Zhong Yu)
Date: Tue, 26 Feb 2013 18:42:04 -0600
Subject: Stream.flatMap reference ambiguity
In-Reply-To: <6FE7EF9B-859A-41E1-A9FD-A45F3D9E4A6E@oracle.com>
References: <CAKjJbnrbVM1BTJEydWDvcy5Fgbi0NYH9bRvE-+u+yjyfR+NjOw@mail.gmail.com>
	<CACuKZqEB0xMhgrUOHbb5yV=zJ6NW1s1wVVXKpejFS75EsDdZYw@mail.gmail.com>
	<5786C373-3FC8-4DCD-A977-464F1DF8F617@gmail.com>
	<512CFA44.5010100@oracle.com>
	<D7E726AB-4970-4648-9D6B-7D5B01115735@oracle.com>
	<CACuKZqFLeaifJGvmBjnujfNHfFsaZrYJZVrZe8i6XgBhbz4wXQ@mail.gmail.com>
	<6FE7EF9B-859A-41E1-A9FD-A45F3D9E4A6E@oracle.com>
Message-ID: <CACuKZqGgrPn67sgO=TCqS8u-yqjjZ6geGNjfdtFiC22uq3_5rQ@mail.gmail.com>

On Tue, Feb 26, 2013 at 6:23 PM, Dan Smith <daniel.smith at oracle.com> wrote:
> On Feb 26, 2013, at 2:57 PM, Zhong Yu <zhong.j.yu at gmail.com> wrote:
>
>>> I think the core problem is the API (in general, it's best to avoid overloading with functional interfaces that have different parameter types),
>>
>> I don't quite understand what you mean, can you clarify?
>
> The type of the second parameter of the lambda depends on the overload resolution choice -- it may be a Consumer<String>, or a IntConsumer, or a LongConsumer, or a DoubleConsumer.  So overload resolution is given four different possible typings of the parameters of the lambda, and is asked to choose the "best" one.
>
> As I've pointed out, this is a pretty brittle situation, and while the compiler is able to do a certain degree of disambiguation, there's a good chance that clients of the API will encounter ambiguities.
>
> For example:
>
> stream.flatMap((x, sink) -> sink.accept(x.length()));
>
> 'x.length()' is an int, meaning the intent is probably to represent an IntConsumer; but the compiler is not equipped to make that sort of judgement, and would be equally happy with a LongConsumer, or a DoubleConsumer, or a Consumer<Integer>, ...
>
> Hence, API designers should generally avoid overloading that relies on disambiguating between functional interfaces of the same arity that have different parameter types.

What I'm confused about is that the sentence sounds like it's ok to
overload with functional interfaces that have _same_ parameter types.
Or is that just outright nonsense? So did you simply mean "no overload
with functional interfaces of the same arity"?

Zhong Yu

From zhong.j.yu at gmail.com  Tue Feb 26 18:55:42 2013
From: zhong.j.yu at gmail.com (Zhong Yu)
Date: Tue, 26 Feb 2013 20:55:42 -0600
Subject: IntBinaryOperator.applyAsInt()
Message-ID: <CACuKZqGjtc1dJukq=vRfY-SvmqiL4=SWeJvQMLCfytb+zbjpfA@mail.gmail.com>

       public interface IntBinaryOperator {

           public int applyAsInt(int left, int right);

The method name seems quite verbose; any reason why it's not simply "apply"?

Same for Long, Double, and Unary.

Zhong Yu

From paul.sandoz at oracle.com  Wed Feb 27 01:45:32 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 27 Feb 2013 10:45:32 +0100
Subject: Stream.flatMap reference ambiguity
In-Reply-To: <6FE7EF9B-859A-41E1-A9FD-A45F3D9E4A6E@oracle.com>
References: <CAKjJbnrbVM1BTJEydWDvcy5Fgbi0NYH9bRvE-+u+yjyfR+NjOw@mail.gmail.com>
	<CACuKZqEB0xMhgrUOHbb5yV=zJ6NW1s1wVVXKpejFS75EsDdZYw@mail.gmail.com>
	<5786C373-3FC8-4DCD-A977-464F1DF8F617@gmail.com>
	<512CFA44.5010100@oracle.com>
	<D7E726AB-4970-4648-9D6B-7D5B01115735@oracle.com>
	<CACuKZqFLeaifJGvmBjnujfNHfFsaZrYJZVrZe8i6XgBhbz4wXQ@mail.gmail.com>
	<6FE7EF9B-859A-41E1-A9FD-A45F3D9E4A6E@oracle.com>
Message-ID: <4B09357B-1EEB-4C65-9C5E-3D3CD1E71C39@oracle.com>


On Feb 27, 2013, at 1:23 AM, Dan Smith <daniel.smith at oracle.com> wrote:

> On Feb 26, 2013, at 2:57 PM, Zhong Yu <zhong.j.yu at gmail.com> wrote:
> 
>>> I think the core problem is the API (in general, it's best to avoid overloading with functional interfaces that have different parameter types),
>> 
>> I don't quite understand what you mean, can you clarify?
> 
> The type of the second parameter of the lambda depends on the overload resolution choice -- it may be a Consumer<String>, or a IntConsumer, or a LongConsumer, or a DoubleConsumer.  So overload resolution is given four different possible typings of the parameters of the lambda, and is asked to choose the "best" one.
> 
> As I've pointed out, this is a pretty brittle situation, and while the compiler is able to do a certain degree of disambiguation, there's a good chance that clients of the API will encounter ambiguities.
> 
> For example:
> 
> stream.flatMap((x, sink) -> sink.accept(x.length()));
> 
> 'x.length()' is an int, meaning the intent is probably to represent an IntConsumer; but the compiler is not equipped to make that sort of judgement, and would be equally happy with a LongConsumer, or a DoubleConsumer, or a Consumer<Integer>, ...
> 
> Hence, API designers should generally avoid overloading that relies on disambiguating between functional interfaces of the same arity that have different parameter types.
> 

So could we do either (or both) of the following:

- change the Int/Long/DoubleConsumer.accept methods to be acceptInt/Long/Double

- change the flatMap methods to be flatMapInt etc.

?

We don't always disambiguate the method name of the functional interface from its primitive specialization counterpart e.g. when the return type is void. What you say above suggests that we should since other APIs using these interfaces are gonna rub up against similar issues.

Paul.

From paul.sandoz at oracle.com  Wed Feb 27 02:50:15 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 27 Feb 2013 11:50:15 +0100
Subject: Where has the map method on Optional moved?
In-Reply-To: <CAN3nywAOFG5vqMMAS6+AsrYEuePWhp+73=3TwCtPdccHisdtKA@mail.gmail.com>
References: <CAD2aR4OeHOG+E9=mgZRZo2kM5TktjqTrv4ZuLiCsJKWnNHorQQ@mail.gmail.com>
	<5C64FDEE-13CC-4256-A09E-82614ACD4ADB@oracle.com>
	<CAN3nywD33uRJL545Np=NVmUbGQvF_Jq5su0nH=yCUywRy8Y5mg@mail.gmail.com>
	<BB68FEFB-F7EB-4067-9247-3E5F108B3878@oracle.com>
	<CAN3nywDHm3e_rb8HT4+nMmtVGdVMRdhdOWqwPDfMKe07Rs3cTg@mail.gmail.com>
	<7B9F8A51-D98C-435E-9628-117D92736AAC@oracle.com>
	<CAN3nywAOFG5vqMMAS6+AsrYEuePWhp+73=3TwCtPdccHisdtKA@mail.gmail.com>
Message-ID: <4090FAE8-4B73-4891-B9B2-41123B868F2A@oracle.com>


On Feb 26, 2013, at 10:05 PM, Jed Wesley-Smith <jed at wesleysmith.io> wrote:

> On 26 February 2013 23:40, Paul Sandoz <paul.sandoz at oracle.com> wrote:
>> On Feb 26, 2013, at 12:33 PM, Jed Wesley-Smith <jed at wesleysmith.io> wrote:
>>> FlatMapper is a bizarre Frankensteinian beast, relying as it does on
>>> mutation to do all of its things.
>> 
>> You mean mutation as in mutation of state? or mutation in the sense of Frankensteinian mutation due to indirection?
> 
> Mutation of state ? FlatMapper is passed things that it accumulates internally.
> 

FlatMapper impls should pass 0 or more mapped elements downstream via the consumer. For example:

List<List<String>> ll = ...
List<String> l = ll.stream().flatMap((l, c) -> l.forEach(c)).collect(toList());

FlatMapper is less convenient than the corresponding Stream based method but is more efficient when one does not have a Stream, or Collection, handy.


> The usual form of flatMap/bind is to return the thing being mapped
> across. No mutation is required (at least at the interface level,
> under the covers local mutation is ok).
> 
>>> It would be a service to all to
>>> rename it to something ? anything ? else, as it does not resemble the
>>> notion of flatMap/bind that other functional programming languages or
>>> libraries implement.
>>> 
>>> As to consistency across the interfaces, Java doesn't have the ability
>>> to generalise across Optional and Stream, lacking Higher Kinded Types.
>>> The fact that Stream has named some feature that resembles a monadic
>>> bind flatMap ideally should not then preclude the ability for Optional
>>> to also have this feature.
>>> 
>>> As to additional potential functionality, you are quite correct, the
>>> restriction of inheritance/OO to be the sole mechanism for adorning
>>> functionality on a data-structure means that the temptation exists to
>>> implement it directly, and these (filter/fold/reduce/foreach etc) are
>>> all sensible suggestions. I do not profess to have definitive answers
>>> to these library design decisions, given the constraints that the
>>> designs are under.
>> 
>> The problem being Optional would stick out like a sore thumb. It's not a Stream. There is no direct way to get a Stream from it and if there were, which is quite easy to do, it would not give you what you really want.
> 
> I don't understand why that is a consideration. Stream is not the only
> monadic thing in the world, there are many others, Future for instance
> is an obvious one.

I am sure if we look hard enough we can find monads everywhere! :-) 

Joking aside this is a slippery slope and i don't think we are ready to systematically modify the JDK APIs in this direction.

The goal is to create an API for bulk modification of data, sequentially and in parallel, leveraging the new language features. The goal is not to create a functionally-oriented Java.


> 
> Optional has little to do with Stream. It can be seen as a collection
> of zero or one elements and therefore could implement Iterable, but
> this is not necessary. More useful would be the fold catamorphism:
> 
> interface Option<A> {
>  B fold(Supplier<B> ifNone, Function<A, B> ifSome);
> }
> 
> This is a jack of all trades combinator that can be used to implement
> almost any other functionality you want.
> 

I personally like it. But i don't think we are gonna go there for JDK 8.

Paul.

From paul.sandoz at oracle.com  Wed Feb 27 03:18:35 2013
From: paul.sandoz at oracle.com (paul.sandoz at oracle.com)
Date: Wed, 27 Feb 2013 11:18:35 +0000
Subject: hg: lambda/lambda/jdk: Remove redundant variable and assignment.
Message-ID: <20130227111933.7E66F4745E@hg.openjdk.java.net>

Changeset: 9619ab4afc70
Author:    psandoz
Date:      2013-02-27 12:16 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/9619ab4afc70

Remove redundant variable and assignment.

! src/share/classes/java/util/Vector.java


From maurizio.cimadamore at oracle.com  Wed Feb 27 04:04:59 2013
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Wed, 27 Feb 2013 12:04:59 +0000
Subject: hg: lambda/lambda/langtools: 8009131: Overload: javac should discard
	methods that lead to errors in lambdas with implicit parameter types
Message-ID: <20130227120511.6934047460@hg.openjdk.java.net>

Changeset: b0d74332d31f
Author:    mcimadamore
Date:      2013-02-27 12:04 +0000
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/b0d74332d31f

8009131: Overload: javac should discard methods that lead to errors in lambdas with implicit parameter types

! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/resources/compiler.properties
! test/tools/javac/diags/examples.not-yet.txt
! test/tools/javac/lambda/BadRecovery.out
! test/tools/javac/lambda/TargetType01.java
- test/tools/javac/lambda/TargetType01.out
! test/tools/javac/lambda/TargetType43.out
+ test/tools/javac/lambda/TargetType66.java
+ test/tools/javac/lambda/TargetType66.out


From david at hartveld.net  Wed Feb 27 06:43:40 2013
From: david at hartveld.net (David Hartveld)
Date: Wed, 27 Feb 2013 15:43:40 +0100
Subject: Stream.flatMap reference ambiguity
In-Reply-To: <4B09357B-1EEB-4C65-9C5E-3D3CD1E71C39@oracle.com>
References: <CAKjJbnrbVM1BTJEydWDvcy5Fgbi0NYH9bRvE-+u+yjyfR+NjOw@mail.gmail.com>
	<CACuKZqEB0xMhgrUOHbb5yV=zJ6NW1s1wVVXKpejFS75EsDdZYw@mail.gmail.com>
	<5786C373-3FC8-4DCD-A977-464F1DF8F617@gmail.com>
	<512CFA44.5010100@oracle.com>
	<D7E726AB-4970-4648-9D6B-7D5B01115735@oracle.com>
	<CACuKZqFLeaifJGvmBjnujfNHfFsaZrYJZVrZe8i6XgBhbz4wXQ@mail.gmail.com>
	<6FE7EF9B-859A-41E1-A9FD-A45F3D9E4A6E@oracle.com>
	<4B09357B-1EEB-4C65-9C5E-3D3CD1E71C39@oracle.com>
Message-ID: <CAKjJbnoG_iqQCozDePFk3RgOyCvHuiO7hCmvOQEbxEcPHoHt8Q@mail.gmail.com>

As an API user, I think that it is important to limit the situations in
which ambiguity can occur. Better to change the API design, versus having
to disambiguate 'by hand' as API user. If this has to happen at the cost of
renaming some methods to a longer form (e.g. flatMap -> flatMapToInts, or
apply -> applyAsInt - and these are just examples), I would prefer that.
Why? Because I'd rather type a few extra letters to make my goal explicit
(i.e., specialize the stream to e.g. an IntStream), than to do that
implicitly by specifying types.
BTW, this also makes the code less 'brittle', making it much more forgiving
to refactorings, which is, I think also a big plus.

If the names are changed, it is probably good to document why these differ
in the final documentation (similar to the reasons why there are
specialized streams for primitives in the first place):
- Needed for disambiguation between regular and specialized flatMap
- Makes explicit the specialization to different stream types
- Rationale for this choice: why better than which alternatives?

Regards,
David


On Wed, Feb 27, 2013 at 10:45 AM, Paul Sandoz <paul.sandoz at oracle.com>wrote:

>
> On Feb 27, 2013, at 1:23 AM, Dan Smith <daniel.smith at oracle.com> wrote:
>
> > On Feb 26, 2013, at 2:57 PM, Zhong Yu <zhong.j.yu at gmail.com> wrote:
> >
> >>> I think the core problem is the API (in general, it's best to avoid
> overloading with functional interfaces that have different parameter types),
> >>
> >> I don't quite understand what you mean, can you clarify?
> >
> > The type of the second parameter of the lambda depends on the overload
> resolution choice -- it may be a Consumer<String>, or a IntConsumer, or a
> LongConsumer, or a DoubleConsumer.  So overload resolution is given four
> different possible typings of the parameters of the lambda, and is asked to
> choose the "best" one.
> >
> > As I've pointed out, this is a pretty brittle situation, and while the
> compiler is able to do a certain degree of disambiguation, there's a good
> chance that clients of the API will encounter ambiguities.
> >
> > For example:
> >
> > stream.flatMap((x, sink) -> sink.accept(x.length()));
> >
> > 'x.length()' is an int, meaning the intent is probably to represent an
> IntConsumer; but the compiler is not equipped to make that sort of
> judgement, and would be equally happy with a LongConsumer, or a
> DoubleConsumer, or a Consumer<Integer>, ...
> >
> > Hence, API designers should generally avoid overloading that relies on
> disambiguating between functional interfaces of the same arity that have
> different parameter types.
> >
>
> So could we do either (or both) of the following:
>
> - change the Int/Long/DoubleConsumer.accept methods to be
> acceptInt/Long/Double
>
> - change the flatMap methods to be flatMapInt etc.
>
> ?
>
> We don't always disambiguate the method name of the functional interface
> from its primitive specialization counterpart e.g. when the return type is
> void. What you say above suggests that we should since other APIs using
> these interfaces are gonna rub up against similar issues.
>
> Paul.
>
>

From boaznahum at gmail.com  Wed Feb 27 07:10:11 2013
From: boaznahum at gmail.com (Boaz Nahum)
Date: Wed, 27 Feb 2013 17:10:11 +0200
Subject: Why cant I add my own intermidate operation
Message-ID: <CAB_DFWYk3a_W27n+L3axO9sudR5eW0BsHM8OuPUyEtfCYsU2Vg@mail.gmail.com>

Many and I asked before how can I do that and that (for example producing
stream of parser tokens from stream, that cant be done by #collect, because
we have no way to know where the input stream is ended)

I understand that not any wish can be satisfied.

But why not provide a tiny  'gate' to add my pipeline, something like
already done:

 public <E_NEXT, S_NEXT extends BaseStream<E_NEXT, S_NEXT>> S_NEXT
pipeline(IntermediateOp<E_OUT, E_NEXT> newOp) {

That all I need(I know I can do there many mistakes, write it
inefficient,but still it is better than nothing).

Today I need to break the pipeline (at least syntactically)

My feeling is that 'Stream' is so difficult to extend. Why *so many
interfaces such as IntermediateOp* and TerminalOp are  not public ?

Thanks
Boaz

From zhong.j.yu at gmail.com  Wed Feb 27 07:37:47 2013
From: zhong.j.yu at gmail.com (Zhong Yu)
Date: Wed, 27 Feb 2013 09:37:47 -0600
Subject: Stream.flatMap reference ambiguity
In-Reply-To: <4B09357B-1EEB-4C65-9C5E-3D3CD1E71C39@oracle.com>
References: <CAKjJbnrbVM1BTJEydWDvcy5Fgbi0NYH9bRvE-+u+yjyfR+NjOw@mail.gmail.com>
	<CACuKZqEB0xMhgrUOHbb5yV=zJ6NW1s1wVVXKpejFS75EsDdZYw@mail.gmail.com>
	<5786C373-3FC8-4DCD-A977-464F1DF8F617@gmail.com>
	<512CFA44.5010100@oracle.com>
	<D7E726AB-4970-4648-9D6B-7D5B01115735@oracle.com>
	<CACuKZqFLeaifJGvmBjnujfNHfFsaZrYJZVrZe8i6XgBhbz4wXQ@mail.gmail.com>
	<6FE7EF9B-859A-41E1-A9FD-A45F3D9E4A6E@oracle.com>
	<4B09357B-1EEB-4C65-9C5E-3D3CD1E71C39@oracle.com>
Message-ID: <CACuKZqHw=KByjYfaZVzqS+CJh2hitTVu3zbFdyUDnQgnmnX5jg@mail.gmail.com>

On Wed, Feb 27, 2013 at 3:45 AM, Paul Sandoz <paul.sandoz at oracle.com> wrote:
>
> On Feb 27, 2013, at 1:23 AM, Dan Smith <daniel.smith at oracle.com> wrote:
>
>> On Feb 26, 2013, at 2:57 PM, Zhong Yu <zhong.j.yu at gmail.com> wrote:
>>
>>>> I think the core problem is the API (in general, it's best to avoid overloading with functional interfaces that have different parameter types),
>>>
>>> I don't quite understand what you mean, can you clarify?
>>
>> The type of the second parameter of the lambda depends on the overload resolution choice -- it may be a Consumer<String>, or a IntConsumer, or a LongConsumer, or a DoubleConsumer.  So overload resolution is given four different possible typings of the parameters of the lambda, and is asked to choose the "best" one.
>>
>> As I've pointed out, this is a pretty brittle situation, and while the compiler is able to do a certain degree of disambiguation, there's a good chance that clients of the API will encounter ambiguities.
>>
>> For example:
>>
>> stream.flatMap((x, sink) -> sink.accept(x.length()));
>>
>> 'x.length()' is an int, meaning the intent is probably to represent an IntConsumer; but the compiler is not equipped to make that sort of judgement, and would be equally happy with a LongConsumer, or a DoubleConsumer, or a Consumer<Integer>, ...
>>
>> Hence, API designers should generally avoid overloading that relies on disambiguating between functional interfaces of the same arity that have different parameter types.
>>
>
> So could we do either (or both) of the following:
>
> - change the Int/Long/DoubleConsumer.accept methods to be acceptInt/Long/Double

I don't like this solution. It defers disambiguation to the lambda
body. The lambda body may not invoke the functional method (for
example, the functional object is simply stored, or passed to another
method).

And it is very odd to have an `acceptInt` method in `IntConsumer`, the
redundancy of "Int" seems inexplicable to a casual viewer of that
interface.

> - change the flatMap methods to be flatMapInt etc.

If people who do a lot of primitive stuff don't object...

> We don't always disambiguate the method name of the functional interface from its primitive specialization counterpart e.g. when the return type is void. What you say above suggests that we should since other APIs using these interfaces are gonna rub up against similar issues.
>
> Paul.
>

From spullara at gmail.com  Wed Feb 27 08:18:54 2013
From: spullara at gmail.com (Sam Pullara)
Date: Wed, 27 Feb 2013 08:18:54 -0800
Subject: Stream.flatMap reference ambiguity
In-Reply-To: <CACuKZqHw=KByjYfaZVzqS+CJh2hitTVu3zbFdyUDnQgnmnX5jg@mail.gmail.com>
References: <CAKjJbnrbVM1BTJEydWDvcy5Fgbi0NYH9bRvE-+u+yjyfR+NjOw@mail.gmail.com>
	<CACuKZqEB0xMhgrUOHbb5yV=zJ6NW1s1wVVXKpejFS75EsDdZYw@mail.gmail.com>
	<5786C373-3FC8-4DCD-A977-464F1DF8F617@gmail.com>
	<512CFA44.5010100@oracle.com>
	<D7E726AB-4970-4648-9D6B-7D5B01115735@oracle.com>
	<CACuKZqFLeaifJGvmBjnujfNHfFsaZrYJZVrZe8i6XgBhbz4wXQ@mail.gmail.com>
	<6FE7EF9B-859A-41E1-A9FD-A45F3D9E4A6E@oracle.com>
	<4B09357B-1EEB-4C65-9C5E-3D3CD1E71C39@oracle.com>
	<CACuKZqHw=KByjYfaZVzqS+CJh2hitTVu3zbFdyUDnQgnmnX5jg@mail.gmail.com>
Message-ID: <6331940786530855807@unknownmsgid>

The primitive versions are also much more discoverable in completion lists.

Sam

All my photos are panoramas.

On Feb 27, 2013, at 7:40 AM, Zhong Yu <zhong.j.yu at gmail.com> wrote:

> On Wed, Feb 27, 2013 at 3:45 AM, Paul Sandoz <paul.sandoz at oracle.com> wrote:
>>
>> On Feb 27, 2013, at 1:23 AM, Dan Smith <daniel.smith at oracle.com> wrote:
>>
>>> On Feb 26, 2013, at 2:57 PM, Zhong Yu <zhong.j.yu at gmail.com> wrote:
>>>
>>>>> I think the core problem is the API (in general, it's best to avoid overloading with functional interfaces that have different parameter types),
>>>>
>>>> I don't quite understand what you mean, can you clarify?
>>>
>>> The type of the second parameter of the lambda depends on the overload resolution choice -- it may be a Consumer<String>, or a IntConsumer, or a LongConsumer, or a DoubleConsumer.  So overload resolution is given four different possible typings of the parameters of the lambda, and is asked to choose the "best" one.
>>>
>>> As I've pointed out, this is a pretty brittle situation, and while the compiler is able to do a certain degree of disambiguation, there's a good chance that clients of the API will encounter ambiguities.
>>>
>>> For example:
>>>
>>> stream.flatMap((x, sink) -> sink.accept(x.length()));
>>>
>>> 'x.length()' is an int, meaning the intent is probably to represent an IntConsumer; but the compiler is not equipped to make that sort of judgement, and would be equally happy with a LongConsumer, or a DoubleConsumer, or a Consumer<Integer>, ...
>>>
>>> Hence, API designers should generally avoid overloading that relies on disambiguating between functional interfaces of the same arity that have different parameter types.
>>
>> So could we do either (or both) of the following:
>>
>> - change the Int/Long/DoubleConsumer.accept methods to be acceptInt/Long/Double
>
> I don't like this solution. It defers disambiguation to the lambda
> body. The lambda body may not invoke the functional method (for
> example, the functional object is simply stored, or passed to another
> method).
>
> And it is very odd to have an `acceptInt` method in `IntConsumer`, the
> redundancy of "Int" seems inexplicable to a casual viewer of that
> interface.
>
>> - change the flatMap methods to be flatMapInt etc.
>
> If people who do a lot of primitive stuff don't object...
>
>> We don't always disambiguate the method name of the functional interface from its primitive specialization counterpart e.g. when the return type is void. What you say above suggests that we should since other APIs using these interfaces are gonna rub up against similar issues.
>>
>> Paul.
>

From paul.sandoz at oracle.com  Wed Feb 27 08:46:40 2013
From: paul.sandoz at oracle.com (paul.sandoz at oracle.com)
Date: Wed, 27 Feb 2013 16:46:40 +0000
Subject: hg: lambda/lambda/jdk: First go at docs on Streams and lazy/non-lazy
	spliterators of sources.
Message-ID: <20130227164703.30B3E47470@hg.openjdk.java.net>

Changeset: e27acedff205
Author:    psandoz
Date:      2013-02-27 17:46 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/e27acedff205

First go at docs on Streams and lazy/non-lazy spliterators of sources.

! src/share/classes/java/util/stream/Streams.java
! src/share/classes/java/util/stream/package-info.java


From mike.duigou at oracle.com  Wed Feb 27 09:21:00 2013
From: mike.duigou at oracle.com (mike.duigou at oracle.com)
Date: Wed, 27 Feb 2013 17:21:00 +0000
Subject: hg: lambda/lambda/jdk: remove extraneous period in @see
Message-ID: <20130227172125.0AD4B47471@hg.openjdk.java.net>

Changeset: b3e0b5001b69
Author:    mduigou
Date:      2013-02-26 16:42 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/b3e0b5001b69

remove extraneous period in @see

! src/share/classes/java/util/function/BinaryOperator.java
! src/share/classes/java/util/function/ToDoubleBiFunction.java


From maurizio.cimadamore at oracle.com  Wed Feb 27 10:09:52 2013
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Wed, 27 Feb 2013 18:09:52 +0000
Subject: hg: lambda/lambda/langtools: 8009154: Missing cast in method
	reference bridge leads to NoSuchMethodError
Message-ID: <20130227180958.E2CEF47474@hg.openjdk.java.net>

Changeset: 94993bc21d7a
Author:    mcimadamore
Date:      2013-02-27 18:09 +0000
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/94993bc21d7a

8009154: Missing cast in method reference bridge leads to NoSuchMethodError

! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java
+ test/tools/javac/lambda/MethodReference65.java


From eric.caspole at amd.com  Wed Feb 27 10:57:23 2013
From: eric.caspole at amd.com (Eric Caspole)
Date: Wed, 27 Feb 2013 13:57:23 -0500
Subject: New bigger bytecode for small lambda in b79
Message-ID: <512E5713.5040806@amd.com>

Hi Lambda people,
I am not sure if this is lambda specific or not, but this is what we 
found. For a small test case like this:

	  java.util.stream.Streams.intRange(FROM, SIZ, 
STEP).parallel().forEach(p -> {ary[p]+= inc;});

The bytecode of the lambda is different this week. It all works but we 
were wondering why it is so much bigger. This new bytecode also happens 
in the lambda-8-b79-linux-x64-25_feb_2013.tar.gz snapshot.

Regards,
Eric


Old bytecode of lambda from last week:

   private void lambda$0(int, int);
     flags: ACC_PRIVATE, ACC_SYNTHETIC
     Code:
       stack=4, locals=3, args_size=3
          0: aload_0
          1: getfield      #3                  // Field ary:[I
          4: iload_2
          5: dup2
          6: iaload
          7: iload_1
          8: iadd
          9: iastore
         10: return
       LineNumberTable:
         line 57: 0


New bytecode generated since about Friday:

   private void lambda$0(int, int);
     flags: ACC_PRIVATE, ACC_SYNTHETIC
     Code:
       stack=4, locals=4, args_size=3
          0: aload_0
          1: getfield      #3                  // Field ary:[I
          4: astore_3
          5: aload_3
          6: iload_2
          7: aload_3
          8: iload_2
          9: iaload
         10: iload_1
         11: iadd
         12: dup_x2
         13: iastore
         14: pop
         15: return
       LineNumberTable:
         line 57: 0


From maurizio.cimadamore at oracle.com  Wed Feb 27 11:08:51 2013
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Wed, 27 Feb 2013 19:08:51 +0000
Subject: New bigger bytecode for small lambda in b79
In-Reply-To: <512E5713.5040806@amd.com>
References: <512E5713.5040806@amd.com>
Message-ID: <512E59C3.3080507@oracle.com>

I don't think this is lambda specific - probably related to this:

http://hg.openjdk.java.net/jdk8/tl/langtools/rev/017e8bdd440f

Will dig further.
Thanks for the report.

Maurizio

On 27/02/13 18:57, Eric Caspole wrote:
> Hi Lambda people,
> I am not sure if this is lambda specific or not, but this is what we
> found. For a small test case like this:
>
> 	  java.util.stream.Streams.intRange(FROM, SIZ,
> STEP).parallel().forEach(p -> {ary[p]+= inc;});
>
> The bytecode of the lambda is different this week. It all works but we
> were wondering why it is so much bigger. This new bytecode also happens
> in the lambda-8-b79-linux-x64-25_feb_2013.tar.gz snapshot.
>
> Regards,
> Eric
>
>
> Old bytecode of lambda from last week:
>
>     private void lambda$0(int, int);
>       flags: ACC_PRIVATE, ACC_SYNTHETIC
>       Code:
>         stack=4, locals=3, args_size=3
>            0: aload_0
>            1: getfield      #3                  // Field ary:[I
>            4: iload_2
>            5: dup2
>            6: iaload
>            7: iload_1
>            8: iadd
>            9: iastore
>           10: return
>         LineNumberTable:
>           line 57: 0
>
>
> New bytecode generated since about Friday:
>
>     private void lambda$0(int, int);
>       flags: ACC_PRIVATE, ACC_SYNTHETIC
>       Code:
>         stack=4, locals=4, args_size=3
>            0: aload_0
>            1: getfield      #3                  // Field ary:[I
>            4: astore_3
>            5: aload_3
>            6: iload_2
>            7: aload_3
>            8: iload_2
>            9: iaload
>           10: iload_1
>           11: iadd
>           12: dup_x2
>           13: iastore
>           14: pop
>           15: return
>         LineNumberTable:
>           line 57: 0
>
>


From daniel.smith at oracle.com  Wed Feb 27 11:11:32 2013
From: daniel.smith at oracle.com (Dan Smith)
Date: Wed, 27 Feb 2013 12:11:32 -0700
Subject: Stream.flatMap reference ambiguity
In-Reply-To: <CACuKZqGgrPn67sgO=TCqS8u-yqjjZ6geGNjfdtFiC22uq3_5rQ@mail.gmail.com>
References: <CAKjJbnrbVM1BTJEydWDvcy5Fgbi0NYH9bRvE-+u+yjyfR+NjOw@mail.gmail.com>
	<CACuKZqEB0xMhgrUOHbb5yV=zJ6NW1s1wVVXKpejFS75EsDdZYw@mail.gmail.com>
	<5786C373-3FC8-4DCD-A977-464F1DF8F617@gmail.com>
	<512CFA44.5010100@oracle.com>
	<D7E726AB-4970-4648-9D6B-7D5B01115735@oracle.com>
	<CACuKZqFLeaifJGvmBjnujfNHfFsaZrYJZVrZe8i6XgBhbz4wXQ@mail.gmail.com>
	<6FE7EF9B-859A-41E1-A9FD-A45F3D9E4A6E@oracle.com>
	<CACuKZqGgrPn67sgO=TCqS8u-yqjjZ6geGNjfdtFiC22uq3_5rQ@mail.gmail.com>
Message-ID: <8EDBC11E-C290-412A-BEBC-7F1840050E51@oracle.com>

On Feb 26, 2013, at 5:42 PM, Zhong Yu <zhong.j.yu at gmail.com> wrote:

> What I'm confused about is that the sentence sounds like it's ok to
> overload with functional interfaces that have _same_ parameter types.
> Or is that just outright nonsense? So did you simply mean "no overload
> with functional interfaces of the same arity"?

Same parameter types, different returns.  See, for example, Stream.map.  The overload resolution logic is able to disambiguate based on what gets returned.  (That's a much easier problem that trying to choose the best types for lambda parameters based on an arbitrary block of code.)

?Dan

From forax at univ-mlv.fr  Wed Feb 27 11:33:45 2013
From: forax at univ-mlv.fr (Remi Forax)
Date: Wed, 27 Feb 2013 20:33:45 +0100
Subject: New bigger bytecode for small lambda in b79
In-Reply-To: <512E59C3.3080507@oracle.com>
References: <512E5713.5040806@amd.com> <512E59C3.3080507@oracle.com>
Message-ID: <512E5F99.5020306@univ-mlv.fr>

On 02/27/2013 08:08 PM, Maurizio Cimadamore wrote:
> I don't think this is lambda specific - probably related to this:
>
> http://hg.openjdk.java.net/jdk8/tl/langtools/rev/017e8bdd440f
>
> Will dig further.
> Thanks for the report.
>
> Maurizio

just reading the bytecode,

            0: aload_0             0: aload_0
            1: getfield      #3    1: getfield      #3
                                   4: astore_3     // stored in a local variable, should not
                                   5: aload_3
            4: iload_2             6: iload_2
            5: dup2                7: aload_3      // equivalent, dup2 is just shorter
                                   8: iload_2
            6: iaload              9: iaload
            7: iload_1            10: iload_1
            8: iadd               11: iadd
                                  12: dup_x2      // WTF ? see 14
            9: iastore            13: iastore
                                  14: pop         // we remove the duped value.
           10: return             15: return

The astore3 is due to the fact that a local variable is introduced, because of that, dup2 is not used later.
The dup_x2 bytecode means that the compiler doesn't know that the result value of array[i]++ is not used,
so the result is duplicated and then pop.

R?mi

>
> On 27/02/13 18:57, Eric Caspole wrote:
>> Hi Lambda people,
>> I am not sure if this is lambda specific or not, but this is what we
>> found. For a small test case like this:
>>
>> 	  java.util.stream.Streams.intRange(FROM, SIZ,
>> STEP).parallel().forEach(p -> {ary[p]+= inc;});
>>
>> The bytecode of the lambda is different this week. It all works but we
>> were wondering why it is so much bigger. This new bytecode also happens
>> in the lambda-8-b79-linux-x64-25_feb_2013.tar.gz snapshot.
>>
>> Regards,
>> Eric
>>
>>
>> Old bytecode of lambda from last week:
>>
>>      private void lambda$0(int, int);
>>        flags: ACC_PRIVATE, ACC_SYNTHETIC
>>        Code:
>>          stack=4, locals=3, args_size=3
>>             0: aload_0
>>             1: getfield      #3                  // Field ary:[I
>>             4: iload_2
>>             5: dup2
>>             6: iaload
>>             7: iload_1
>>             8: iadd
>>             9: iastore
>>            10: return
>>          LineNumberTable:
>>            line 57: 0
>>
>>
>> New bytecode generated since about Friday:
>>
>>      private void lambda$0(int, int);
>>        flags: ACC_PRIVATE, ACC_SYNTHETIC
>>        Code:
>>          stack=4, locals=4, args_size=3
>>             0: aload_0
>>             1: getfield      #3                  // Field ary:[I
>>             4: astore_3
>>             5: aload_3
>>             6: iload_2
>>             7: aload_3
>>             8: iload_2
>>             9: iaload
>>            10: iload_1
>>            11: iadd
>>            12: dup_x2
>>            13: iastore
>>            14: pop
>>            15: return
>>          LineNumberTable:
>>            line 57: 0
>>
>>
>


From maurizio.cimadamore at oracle.com  Wed Feb 27 11:56:22 2013
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Wed, 27 Feb 2013 19:56:22 +0000
Subject: hg: lambda/lambda/langtools: 8009129: Illegal access error when
	calling method reference
Message-ID: <20130227195628.7745F4747D@hg.openjdk.java.net>

Changeset: 992e484da75e
Author:    mcimadamore
Date:      2013-02-27 19:56 +0000
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/992e484da75e

8009129: Illegal access error when calling method reference

! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java
! src/share/classes/com/sun/tools/javac/resources/compiler.properties
! src/share/classes/com/sun/tools/javac/tree/JCTree.java
+ test/tools/javac/lambda/inaccessibleMref01/InaccessibleMref01.java
+ test/tools/javac/lambda/inaccessibleMref01/InaccessibleMref01.out
+ test/tools/javac/lambda/inaccessibleMref01/p1/C.java
+ test/tools/javac/lambda/inaccessibleMref02/InaccessibleMref02.java
+ test/tools/javac/lambda/inaccessibleMref02/p1/C.java


From maurizio.cimadamore at oracle.com  Wed Feb 27 11:59:58 2013
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Wed, 27 Feb 2013 19:59:58 +0000
Subject: b73: IllegalAccessError: tried to access class
	java.util.stream.BaseStream
In-Reply-To: <50F6C48F.7000904@oracle.com>
References: <50F6C48F.7000904@oracle.com>
Message-ID: <512E65BE.9060209@oracle.com>

Sorry for resurrecting this old thread - I've fixed this working around 
a 292 bug by introducing a compiler-generated bridge.

Maurizio

On 16/01/13 15:17, Dmitry Bessonov wrote:
> import java.util.Arrays;
> import java.util.stream.Stream;
>
> public class IllegalAccessErrorTest {
>
>       public static void main(String[] args) {
>
>           Stream stream = Arrays.asList("a", "b").stream();
>           System.err.println("iterator = " + stream.iterator());
>           Iterable iterable = stream::iterator;
>           System.err.println("iterable = " + iterable);
>       }
> }
>
> when compiled/run on b73 the output is:
>
>
> iterator = java.util.stream.ReferencePipeline$6 at 3256a5
> Exception in thread "main" java.lang.IllegalAccessError: tried to access
> class java.util.stream.BaseStream from class IllegalAccessErrorTest
>       at IllegalAccessErrorTest.main(IllegalAccessErrorTest.java:10)
>
>
> with b72 no exceptions are seen
>
> -Dmitry
>
>


From mike.duigou at oracle.com  Wed Feb 27 12:48:28 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Wed, 27 Feb 2013 12:48:28 -0800
Subject: IntBinaryOperator.applyAsInt()
In-Reply-To: <CACuKZqGjtc1dJukq=vRfY-SvmqiL4=SWeJvQMLCfytb+zbjpfA@mail.gmail.com>
References: <CACuKZqGjtc1dJukq=vRfY-SvmqiL4=SWeJvQMLCfytb+zbjpfA@mail.gmail.com>
Message-ID: <552A5DE6-87A4-43DA-94BB-71D8F8268476@oracle.com>

The source of the naming approach is to handle overloads that differ only in the return type. The EG opted to resolve the problem by naming the versions of these methods for primitive types with the "AsXYZ" naming. This ensures that within the same class there won't be overloads fighting over the return type.

Mike

On Feb 26 2013, at 18:55 , Zhong Yu wrote:

>       public interface IntBinaryOperator {
> 
>           public int applyAsInt(int left, int right);
> 
> The method name seems quite verbose; any reason why it's not simply "apply"?
> 
> Same for Long, Double, and Unary.
> 
> Zhong Yu
> 


From mike.duigou at oracle.com  Wed Feb 27 16:48:24 2013
From: mike.duigou at oracle.com (mike.duigou at oracle.com)
Date: Thu, 28 Feb 2013 00:48:24 +0000
Subject: hg: lambda/lambda/jdk: fix test breakages
Message-ID: <20130228004852.CF87247492@hg.openjdk.java.net>

Changeset: dbb23cb1711d
Author:    mduigou
Date:      2013-02-27 16:47 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/dbb23cb1711d

fix test breakages

! test/java/util/Collection/MOAT.java
! test/java/util/function/FunctionsTest.java
! test/java/util/function/PredicatesTest.java
! test/java/util/stream/Stream/EmployeeStreamTest.java
! test/java/util/stream/Stream/IntegerStreamTest.java
! test/java/util/stream/Stream/StringBuilderStreamTest.java


From mike.duigou at oracle.com  Wed Feb 27 18:21:31 2013
From: mike.duigou at oracle.com (mike.duigou at oracle.com)
Date: Thu, 28 Feb 2013 02:21:31 +0000
Subject: hg: lambda/lambda/jdk: restore lambda bits lost in jsr166 merge
Message-ID: <20130228022152.0091A4749F@hg.openjdk.java.net>

Changeset: 575749b77035
Author:    mduigou
Date:      2013-02-27 16:50 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/575749b77035

restore lambda bits lost in jsr166 merge
Contributed-by: akhil.arora at oracle.com

! src/share/classes/java/util/concurrent/CopyOnWriteArrayList.java
! test/java/util/CollectionExtensionMethods/testlibrary/CollectionAsserts.java


From mike.duigou at oracle.com  Wed Feb 27 20:06:30 2013
From: mike.duigou at oracle.com (mike.duigou at oracle.com)
Date: Thu, 28 Feb 2013 04:06:30 +0000
Subject: hg: lambda/lambda/jdk: test fixes
Message-ID: <20130228040655.9B421474A3@hg.openjdk.java.net>

Changeset: af323ffe1aa7
Author:    mduigou
Date:      2013-02-27 20:06 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/af323ffe1aa7

test fixes

! test/java/util/stream/Streams/BasicTest.java


From boaznahum at gmail.com  Wed Feb 27 23:17:44 2013
From: boaznahum at gmail.com (Boaz Nahum)
Date: Thu, 28 Feb 2013 09:17:44 +0200
Subject: Generalized transformation of a Stream<X> into a Stream<Y>, with
	lazy evaluation and stateful transformation functions
In-Reply-To: <CAKJVG8Yazqxoo4n+v=Q_Ebph5Rfbde2aRWbX7CkL2P+WcGNeXg@mail.gmail.com>
References: <CAKJVG8Yazqxoo4n+v=Q_Ebph5Rfbde2aRWbX7CkL2P+WcGNeXg@mail.gmail.com>
Message-ID: <CAB_DFWYjDoS8x0qwWKhghx-kg_3OH2-q4k-9WuzzpH1PVFKESQ@mail.gmail.com>

PS: jdk 8 lambda rocks.  Java will once again reign supreme.  Thanks

> everyone!
>
> No doubt about that !

Wil transform also support terminal operation - like #collect. The latest
is almost perfect - but again there is no point to do final processing.

Any way, thanks. I am happily waiting.

Boaz

From maurizio.cimadamore at oracle.com  Thu Feb 28 04:24:31 2013
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Thu, 28 Feb 2013 12:24:31 +0000
Subject: Java 7 -> Java8 code breakage scenarios
In-Reply-To: <CAB_DFWbz8FaSzLi8qT07PNiJATZTRmeoWBgVaJ-w3N8Ama6mNA@mail.gmail.com>
References: <F04E82B8-7AE4-4AD5-82FF-7BE4E64E4F0D@oracle.com>
	<452ED23A-4228-4A2C-A1AA-0C323CE3485E@oracle.com>
	<CAMUF1SnC_6WvyepvYVED7rdxdyJsVyK=UK++AGpfJWZ31gsC2w@mail.gmail.com>
	<51251BDA.8050305@oracle.com>
	<B0882479-248C-42DD-B59C-EB0DD7227130@oracle.com>
	<51253C96.4030109@oracle.com>
	<2E447BAC-0344-4579-AA3F-27BC62FBB049@oracle.com>
	<OF54837934.BDA2DC5E-ON65257B1C.0064A1D6-65257B1D.001B0437@in.ibm.com>
	<CAMUF1Skzg+nik=M-w9MoSoaGksWJgsHWOj-nAGc0sd9uDHkpGA@mail.gmail.com>
	<OFE810291D.83FEA351-ON65257B1F.005E9BBB-65257B1F.00614E7D@in.ibm.com>
	<CAB_DFWYifGmyaTzNZvddxzS1HW5WuLHXb6TiD4hrvqFt-fh=Sw@mail.gmail.com>
	<512E870F.6000605@oracle.com>
	<CAB_DFWYupcaNsQ39S+H5LaPEAM9mKJBhwgOoNX68TRxM7cNaWA@mail.gmail.com>
	<512F31F1.1030504@oracle.com>
	<CAB_DFWbz8FaSzLi8qT07PNiJATZTRmeoWBgVaJ-w3N8Ama6mNA@mail.gmail.com>
Message-ID: <512F4C7F.80101@oracle.com>

On 28/02/13 11:45, Boaz Nahum wrote:
>>   From your email I guessed you had to workaround new bugs. I probably have
>> mis-interpreted. Good to know that everything is looking almost sane on
>> your part.
>>
>>
>> Yes, I hardy can read my own English ...
> Actually, One of dependencies problem I reported may be consider as bug,
> because the missing dependency cause a compiler crash. You helped me to
> find it, see thread:
>
> http://mail.openjdk.java.net/pipermail/compiler-dev/2013-February/005625.html
>
> Once the dependency was added the crash disappeared.
>
> I will trace back all other issues, But it will take some time.
[moving to lambda-dev, which is more appropriate]
I've tried to reproduce something like what you described:

//A.java
public interface A {
     void m();
}

//B.java
public class B implements A {
     @Override
     public void m() { }

     public static void n() { }
}


//C.java
public class C {
     void test(B b) {
         B.n();
     }
}


I've compiled A, B, then only kept classfile for B.class.

Then I tried to compile C.java against B.class - I only got an error 
message like this:

C.java:3: error: cannot access A
         B.n();
          ^
   class file for A not found
1 error

The message goes away if you compile with -source 7. That's 
understandable, no default method lookup in JDK 7.

However I could not reproduce any crash. So it seems like some 
ingredient is missing...

Maurizio

>
> Thanks
> Boaz


From maurizio.cimadamore at oracle.com  Thu Feb 28 04:29:46 2013
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Thu, 28 Feb 2013 12:29:46 +0000
Subject: Java 7 -> Java8 code breakage scenarios
In-Reply-To: <512F4C7F.80101@oracle.com>
References: <F04E82B8-7AE4-4AD5-82FF-7BE4E64E4F0D@oracle.com>
	<452ED23A-4228-4A2C-A1AA-0C323CE3485E@oracle.com>
	<CAMUF1SnC_6WvyepvYVED7rdxdyJsVyK=UK++AGpfJWZ31gsC2w@mail.gmail.com>
	<51251BDA.8050305@oracle.com>
	<B0882479-248C-42DD-B59C-EB0DD7227130@oracle.com>
	<51253C96.4030109@oracle.com>
	<2E447BAC-0344-4579-AA3F-27BC62FBB049@oracle.com>
	<OF54837934.BDA2DC5E-ON65257B1C.0064A1D6-65257B1D.001B0437@in.ibm.com>
	<CAMUF1Skzg+nik=M-w9MoSoaGksWJgsHWOj-nAGc0sd9uDHkpGA@mail.gmail.com>
	<OFE810291D.83FEA351-ON65257B1F.005E9BBB-65257B1F.00614E7D@in.ibm.com>
	<CAB_DFWYifGmyaTzNZvddxzS1HW5WuLHXb6TiD4hrvqFt-fh=Sw@mail.gmail.com>
	<512E870F.6000605@oracle.com>
	<CAB_DFWYupcaNsQ39S+H5LaPEAM9mKJBhwgOoNX68TRxM7cNaWA@mail.gmail.com>
	<512F31F1.1030504@oracle.com>
	<CAB_DFWbz8FaSzLi8qT07PNiJATZTRmeoWBgVaJ-w3N8Ama6mNA@mail.gmail.com>
	<512F4C7F.80101@oracle.com>
Message-ID: <512F4DBA.3050506@oracle.com>

On 28/02/13 12:24, Maurizio Cimadamore wrote:
> On 28/02/13 11:45, Boaz Nahum wrote:
>>>   From your email I guessed you had to workaround new bugs. I 
>>> probably have
>>> mis-interpreted. Good to know that everything is looking almost sane on
>>> your part.
>>>
>>>
>>> Yes, I hardy can read my own English ...
>> Actually, One of dependencies problem I reported may be consider as bug,
>> because the missing dependency cause a compiler crash. You helped me to
>> find it, see thread:
>>
>> http://mail.openjdk.java.net/pipermail/compiler-dev/2013-February/005625.html 
>>
>>
>> Once the dependency was added the crash disappeared.
>>
>> I will trace back all other issues, But it will take some time.
> [moving to lambda-dev, which is more appropriate]
> I've tried to reproduce something like what you described:
>
> //A.java
> public interface A {
>     void m();
> }
>
> //B.java
> public class B implements A {
>     @Override
>     public void m() { }
>
>     public static void n() { }
> }
>
>
> //C.java
> public class C {
>     void test(B b) {
>         B.n();
>     }
> }
>
>
> I've compiled A, B, then only kept classfile for B.class.
>
> Then I tried to compile C.java against B.class - I only got an error 
> message like this:
>
> C.java:3: error: cannot access A
>         B.n();
>          ^
>   class file for A not found
> 1 error
>
> The message goes away if you compile with -source 7. That's 
> understandable, no default method lookup in JDK 7.
>
> However I could not reproduce any crash. So it seems like some 
> ingredient is missing...
>
> Maurizio
>
>>
>> Thanks
>> Boaz
>
Hehe - this did the trick:

//B.java
public class B implements A {
     @Override
     public void m() { }

     public static Object n() { return null; }
}


//C.java
public class C {
     void test(B b) {
         Tester.m(B.n());
     }
}

class Tester {
     static void m(Object o) { }
}

I got this:

An exception has occurred in the compiler (1.8.0-internal). Please file 
a bug at the Java Developer Connection 
(http://java.sun.com/webapps/bugreport)  after checking the Bug Parade 
for duplicates. Include your program and the following diagnostic in 
your report.  Thank you.
java.lang.NullPointerException
     at 
com.sun.tools.javac.comp.Flow$FlowAnalyzer.visitApply(Flow.java:1196)
     at 
com.sun.tools.javac.tree.JCTree$JCMethodInvocation.accept(JCTree.java:1440)
     at com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49)
     at com.sun.tools.javac.tree.TreeScanner.visitExec(TreeScanner.java:174)
     at 
com.sun.tools.javac.tree.JCTree$JCExpressionStatement.accept(JCTree.java:1271)
     at com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49)
     at com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:57)
     at com.sun.tools.javac.comp.Flow$FlowAnalyzer.visitBlock(Flow.java:959)
     at com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:884)
     at com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49)
     at 
com.sun.tools.javac.comp.Flow$FlowAnalyzer.visitMethodDef(Flow.java:926)
     at com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(JCTree.java:771)
     at com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49)
     at 
com.sun.tools.javac.comp.Flow$FlowAnalyzer.visitClassDef(Flow.java:889)
     at com.sun.tools.javac.tree.JCTree$JCClassDecl.accept(JCTree.java:686)
     at com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49)
     at 
com.sun.tools.javac.comp.Flow$FlowAnalyzer.analyzeTree(Flow.java:1276)
     at 
com.sun.tools.javac.comp.Flow$FlowAnalyzer.analyzeTree(Flow.java:1266)
     at com.sun.tools.javac.comp.Flow.analyzeTree(Flow.java:212)
     at com.sun.tools.javac.main.JavaCompiler.flow(JavaCompiler.java:1330)
     at com.sun.tools.javac.main.JavaCompiler.flow(JavaCompiler.java:1304)
     at 
com.sun.tools.javac.main.JavaCompiler.compile2(JavaCompiler.java:909)
     at com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:868)
     at com.sun.tools.javac.main.Main.compile(Main.java:517)
     at com.sun.tools.javac.main.Main.compile(Main.java:376)
     at com.sun.tools.javac.main.Main.compile(Main.java:365)
     at com.sun.tools.javac.main.Main.compile(Main.java:356)
     at com.sun.tools.javac.Main.compile(Main.java:77)
     at com.sun.tools.javac.Main.main(Main.java:62)

Which is the very one you got. If you'd be so kind to give me some 
details about the other stack trace you were getting (Types.rank) so 
that I can come up with some test case (i.e. what is the code that 
triggered it).

Maurizio

From boaznahum at gmail.com  Thu Feb 28 04:58:52 2013
From: boaznahum at gmail.com (Boaz Nahum)
Date: Thu, 28 Feb 2013 14:58:52 +0200
Subject: Java 7 -> Java8 code breakage scenarios
In-Reply-To: <512F4C7F.80101@oracle.com>
References: <F04E82B8-7AE4-4AD5-82FF-7BE4E64E4F0D@oracle.com>
	<452ED23A-4228-4A2C-A1AA-0C323CE3485E@oracle.com>
	<CAMUF1SnC_6WvyepvYVED7rdxdyJsVyK=UK++AGpfJWZ31gsC2w@mail.gmail.com>
	<51251BDA.8050305@oracle.com>
	<B0882479-248C-42DD-B59C-EB0DD7227130@oracle.com>
	<51253C96.4030109@oracle.com>
	<2E447BAC-0344-4579-AA3F-27BC62FBB049@oracle.com>
	<OF54837934.BDA2DC5E-ON65257B1C.0064A1D6-65257B1D.001B0437@in.ibm.com>
	<CAMUF1Skzg+nik=M-w9MoSoaGksWJgsHWOj-nAGc0sd9uDHkpGA@mail.gmail.com>
	<OFE810291D.83FEA351-ON65257B1F.005E9BBB-65257B1F.00614E7D@in.ibm.com>
	<CAB_DFWYifGmyaTzNZvddxzS1HW5WuLHXb6TiD4hrvqFt-fh=Sw@mail.gmail.com>
	<512E870F.6000605@oracle.com>
	<CAB_DFWYupcaNsQ39S+H5LaPEAM9mKJBhwgOoNX68TRxM7cNaWA@mail.gmail.com>
	<512F31F1.1030504@oracle.com>
	<CAB_DFWbz8FaSzLi8qT07PNiJATZTRmeoWBgVaJ-w3N8Ama6mNA@mail.gmail.com>
	<512F4C7F.80101@oracle.com>
Message-ID: <CAB_DFWY=cBdEdgV2uNXzAu+b=nyrBK4gMZcddCcokdVyFrStaw@mail.gmail.com>

No. The crash case is much more complicated. I will re-produce it.

On Thu, Feb 28, 2013 at 2:24 PM, Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

> On 28/02/13 11:45, Boaz Nahum wrote:
>
>>   From your email I guessed you had to workaround new bugs. I probably
>>> have
>>> mis-interpreted. Good to know that everything is looking almost sane on
>>> your part.
>>>
>>>
>>> Yes, I hardy can read my own English ...
>>>
>> Actually, One of dependencies problem I reported may be consider as bug,
>> because the missing dependency cause a compiler crash. You helped me to
>> find it, see thread:
>>
>> http://mail.openjdk.java.net/**pipermail/compiler-dev/2013-**
>> February/005625.html<http://mail.openjdk.java.net/pipermail/compiler-dev/2013-February/005625.html>
>>
>> Once the dependency was added the crash disappeared.
>>
>> I will trace back all other issues, But it will take some time.
>>
> [moving to lambda-dev, which is more appropriate]
> I've tried to reproduce something like what you described:
>
> //A.java
> public interface A {
>     void m();
> }
>
> //B.java
> public class B implements A {
>     @Override
>     public void m() { }
>
>     public static void n() { }
> }
>
>
> //C.java
> public class C {
>     void test(B b) {
>         B.n();
>     }
> }
>
>
> I've compiled A, B, then only kept classfile for B.class.
>
> Then I tried to compile C.java against B.class - I only got an error
> message like this:
>
> C.java:3: error: cannot access A
>         B.n();
>          ^
>   class file for A not found
> 1 error
>
> The message goes away if you compile with -source 7. That's
> understandable, no default method lookup in JDK 7.
>
> However I could not reproduce any crash. So it seems like some ingredient
> is missing...
>
> Maurizio
>
>
>> Thanks
>> Boaz
>>
>
>

From boaznahum at gmail.com  Thu Feb 28 05:24:11 2013
From: boaznahum at gmail.com (Boaz Nahum)
Date: Thu, 28 Feb 2013 15:24:11 +0200
Subject: Java 7 -> Java8 code breakage scenarios
In-Reply-To: <512F4DBA.3050506@oracle.com>
References: <F04E82B8-7AE4-4AD5-82FF-7BE4E64E4F0D@oracle.com>
	<452ED23A-4228-4A2C-A1AA-0C323CE3485E@oracle.com>
	<CAMUF1SnC_6WvyepvYVED7rdxdyJsVyK=UK++AGpfJWZ31gsC2w@mail.gmail.com>
	<51251BDA.8050305@oracle.com>
	<B0882479-248C-42DD-B59C-EB0DD7227130@oracle.com>
	<51253C96.4030109@oracle.com>
	<2E447BAC-0344-4579-AA3F-27BC62FBB049@oracle.com>
	<OF54837934.BDA2DC5E-ON65257B1C.0064A1D6-65257B1D.001B0437@in.ibm.com>
	<CAMUF1Skzg+nik=M-w9MoSoaGksWJgsHWOj-nAGc0sd9uDHkpGA@mail.gmail.com>
	<OFE810291D.83FEA351-ON65257B1F.005E9BBB-65257B1F.00614E7D@in.ibm.com>
	<CAB_DFWYifGmyaTzNZvddxzS1HW5WuLHXb6TiD4hrvqFt-fh=Sw@mail.gmail.com>
	<512E870F.6000605@oracle.com>
	<CAB_DFWYupcaNsQ39S+H5LaPEAM9mKJBhwgOoNX68TRxM7cNaWA@mail.gmail.com>
	<512F31F1.1030504@oracle.com>
	<CAB_DFWbz8FaSzLi8qT07PNiJATZTRmeoWBgVaJ-w3N8Ama6mNA@mail.gmail.com>
	<512F4C7F.80101@oracle.com> <512F4DBA.3050506@oracle.com>
Message-ID: <CAB_DFWanURB-3u7tiM7AfeZEBk2nhMSD5gDW2uxo37LY-Ah97w@mail.gmail.com>

//C.java

> public class C {
>     void test(B b) {
>         Tester.m(B.n());
>     }
> }
>
> Which is the very one you got. If you'd be so kind to give me some details
> about the other stack trace you were getting (Types.rank) so that I can
> come up with some test case (i.e. what is the code that triggered it).
>
> Maurizio
>
Yes exactly. If you named B.n() instead of inline it in the method call
then you got 'normal' error message.
The 'rank' exception - I'm working on it.

Thanks !!!
Boaz

From maurizio.cimadamore at oracle.com  Thu Feb 28 05:46:20 2013
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Thu, 28 Feb 2013 13:46:20 +0000
Subject: Java 7 -> Java8 code breakage scenarios
In-Reply-To: <CAB_DFWanURB-3u7tiM7AfeZEBk2nhMSD5gDW2uxo37LY-Ah97w@mail.gmail.com>
References: <F04E82B8-7AE4-4AD5-82FF-7BE4E64E4F0D@oracle.com>
	<452ED23A-4228-4A2C-A1AA-0C323CE3485E@oracle.com>
	<CAMUF1SnC_6WvyepvYVED7rdxdyJsVyK=UK++AGpfJWZ31gsC2w@mail.gmail.com>
	<51251BDA.8050305@oracle.com>
	<B0882479-248C-42DD-B59C-EB0DD7227130@oracle.com>
	<51253C96.4030109@oracle.com>
	<2E447BAC-0344-4579-AA3F-27BC62FBB049@oracle.com>
	<OF54837934.BDA2DC5E-ON65257B1C.0064A1D6-65257B1D.001B0437@in.ibm.com>
	<CAMUF1Skzg+nik=M-w9MoSoaGksWJgsHWOj-nAGc0sd9uDHkpGA@mail.gmail.com>
	<OFE810291D.83FEA351-ON65257B1F.005E9BBB-65257B1F.00614E7D@in.ibm.com>
	<CAB_DFWYifGmyaTzNZvddxzS1HW5WuLHXb6TiD4hrvqFt-fh=Sw@mail.gmail.com>
	<512E870F.6000605@oracle.com>
	<CAB_DFWYupcaNsQ39S+H5LaPEAM9mKJBhwgOoNX68TRxM7cNaWA@mail.gmail.com>
	<512F31F1.1030504@oracle.com>
	<CAB_DFWbz8FaSzLi8qT07PNiJATZTRmeoWBgVaJ-w3N8Ama6mNA@mail.gmail.com>
	<512F4C7F.80101@oracle.com> <512F4DBA.3050506@oracle.com>
	<CAB_DFWanURB-3u7tiM7AfeZEBk2nhMSD5gDW2uxo37LY-Ah97w@mail.gmail.com>
Message-ID: <512F5FAC.1060704@oracle.com>

On 28/02/13 13:24, Boaz Nahum wrote:
> //C.java
>
>> public class C {
>>      void test(B b) {
>>          Tester.m(B.n());
>>      }
>> }
>>
>> Which is the very one you got. If you'd be so kind to give me some details
>> about the other stack trace you were getting (Types.rank) so that I can
>> come up with some test case (i.e. what is the code that triggered it).
>>
>> Maurizio
>>
> Yes exactly. If you named B.n() instead of inline it in the method call
> then you got 'normal' error message.
> The 'rank' exception - I'm working on it.
>
> Thanks !!!
> Boaz
>
I believe I got at the bottom of the issue - when a completion error 
(i.e. missing classfile) occurs in a nested context (i.e. method call), 
the compiler doesn't always report the error, because of some of the 
intricacies associated with lambda type-checking and nested method 
calls. Those errors should ALWAYS be reported, as a missing classfile 
error is a really bad condition that shouldn't be skipped. The fact that 
the compiler is not reporting them in certain cases lead javac to think 
that everything is ok, so that the subsequent compilation step can be 
executed - which is not true. Hence all the spurious crashes.

Maurizio

From paul.sandoz at oracle.com  Thu Feb 28 07:12:40 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 28 Feb 2013 16:12:40 +0100
Subject: Why cant I add my own intermidate operation
In-Reply-To: <CAB_DFWYk3a_W27n+L3axO9sudR5eW0BsHM8OuPUyEtfCYsU2Vg@mail.gmail.com>
References: <CAB_DFWYk3a_W27n+L3axO9sudR5eW0BsHM8OuPUyEtfCYsU2Vg@mail.gmail.com>
Message-ID: <00439C01-CAB5-48D4-8692-E743FCA34598@oracle.com>

Hi Boaz,

Unfortunately the internals are not ready to open as an SPI, more time is required to do that, time that we don't have for JDK 8. What is there now could well change in the future and we don't want to be stuck with it.

That tiny 'gate' you are referring while tiny from a method on Stream perspective is far from tiny otherwise as it opens up access to other internal classes, such as Sink and Node, and opens up concepts of stream flags, sequential and parallel implementations.


On Feb 27, 2013, at 4:10 PM, Boaz Nahum <boaznahum at gmail.com> wrote:

> Many and I asked before how can I do that and that (for example producing
> stream of parser tokens from stream, that cant be done by #collect, because
> we have no way to know where the input stream is ended)
> 

As a workaround you can concatenate:

  Streams.concat(s, Collections.singletonList(TERMINATOR).stream());

If you look at the code for that it uses the "escape-hatch" spliterator. There might be similar tricks you can apply.

Paul.

> I understand that not any wish can be satisfied.
> 
> But why not provide a tiny  'gate' to add my pipeline, something like
> already done:
> 
> public <E_NEXT, S_NEXT extends BaseStream<E_NEXT, S_NEXT>> S_NEXT
> pipeline(IntermediateOp<E_OUT, E_NEXT> newOp) {
> 
> That all I need(I know I can do there many mistakes, write it
> inefficient,but still it is better than nothing).
> 
> Today I need to break the pipeline (at least syntactically)
> 
> My feeling is that 'Stream' is so difficult to extend. Why *so many
> interfaces such as IntermediateOp* and TerminalOp are  not public ?
> 
> Thanks
> Boaz
> 


From boaznahum at gmail.com  Thu Feb 28 07:32:28 2013
From: boaznahum at gmail.com (Boaz Nahum)
Date: Thu, 28 Feb 2013 17:32:28 +0200
Subject: Java 7 -> Java8 code breakage scenarios
In-Reply-To: <512F5FAC.1060704@oracle.com>
References: <F04E82B8-7AE4-4AD5-82FF-7BE4E64E4F0D@oracle.com>
	<452ED23A-4228-4A2C-A1AA-0C323CE3485E@oracle.com>
	<CAMUF1SnC_6WvyepvYVED7rdxdyJsVyK=UK++AGpfJWZ31gsC2w@mail.gmail.com>
	<51251BDA.8050305@oracle.com>
	<B0882479-248C-42DD-B59C-EB0DD7227130@oracle.com>
	<51253C96.4030109@oracle.com>
	<2E447BAC-0344-4579-AA3F-27BC62FBB049@oracle.com>
	<OF54837934.BDA2DC5E-ON65257B1C.0064A1D6-65257B1D.001B0437@in.ibm.com>
	<CAMUF1Skzg+nik=M-w9MoSoaGksWJgsHWOj-nAGc0sd9uDHkpGA@mail.gmail.com>
	<OFE810291D.83FEA351-ON65257B1F.005E9BBB-65257B1F.00614E7D@in.ibm.com>
	<CAB_DFWYifGmyaTzNZvddxzS1HW5WuLHXb6TiD4hrvqFt-fh=Sw@mail.gmail.com>
	<512E870F.6000605@oracle.com>
	<CAB_DFWYupcaNsQ39S+H5LaPEAM9mKJBhwgOoNX68TRxM7cNaWA@mail.gmail.com>
	<512F31F1.1030504@oracle.com>
	<CAB_DFWbz8FaSzLi8qT07PNiJATZTRmeoWBgVaJ-w3N8Ama6mNA@mail.gmail.com>
	<512F4C7F.80101@oracle.com> <512F4DBA.3050506@oracle.com>
	<CAB_DFWanURB-3u7tiM7AfeZEBk2nhMSD5gDW2uxo37LY-Ah97w@mail.gmail.com>
	<512F5FAC.1060704@oracle.com>
Message-ID: <CAB_DFWZOc9fsJ44kcjUc-Jpu7=NeXKLsGH29cC9rMX0W4AHPpQ@mail.gmail.com>

So can I stop my efforts reproducing 'rank' crash ?
Actually I reproduce it, But I'm not able to isolate the case - I can
easily build JDK and test it.

But if you want me to continue retry - no problem.

Boaz


On Thu, Feb 28, 2013 at 3:46 PM, Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

> On 28/02/13 13:24, Boaz Nahum wrote:
>
>> //C.java
>>
>>  public class C {
>>>      void test(B b) {
>>>          Tester.m(B.n());
>>>      }
>>> }
>>>
>>> Which is the very one you got. If you'd be so kind to give me some
>>> details
>>> about the other stack trace you were getting (Types.rank) so that I can
>>> come up with some test case (i.e. what is the code that triggered it).
>>>
>>> Maurizio
>>>
>>>  Yes exactly. If you named B.n() instead of inline it in the method call
>> then you got 'normal' error message.
>> The 'rank' exception - I'm working on it.
>>
>> Thanks !!!
>> Boaz
>>
>>  I believe I got at the bottom of the issue - when a completion error
> (i.e. missing classfile) occurs in a nested context (i.e. method call), the
> compiler doesn't always report the error, because of some of the
> intricacies associated with lambda type-checking and nested method calls.
> Those errors should ALWAYS be reported, as a missing classfile error is a
> really bad condition that shouldn't be skipped. The fact that the compiler
> is not reporting them in certain cases lead javac to think that everything
> is ok, so that the subsequent compilation step can be executed - which is
> not true. Hence all the spurious crashes.
>
> Maurizio
>

From maurizio.cimadamore at oracle.com  Thu Feb 28 07:40:42 2013
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Thu, 28 Feb 2013 15:40:42 +0000
Subject: Java 7 -> Java8 code breakage scenarios
In-Reply-To: <CAB_DFWZOc9fsJ44kcjUc-Jpu7=NeXKLsGH29cC9rMX0W4AHPpQ@mail.gmail.com>
References: <F04E82B8-7AE4-4AD5-82FF-7BE4E64E4F0D@oracle.com>
	<CAMUF1SnC_6WvyepvYVED7rdxdyJsVyK=UK++AGpfJWZ31gsC2w@mail.gmail.com>
	<51251BDA.8050305@oracle.com>
	<B0882479-248C-42DD-B59C-EB0DD7227130@oracle.com>
	<51253C96.4030109@oracle.com>
	<2E447BAC-0344-4579-AA3F-27BC62FBB049@oracle.com>
	<OF54837934.BDA2DC5E-ON65257B1C.0064A1D6-65257B1D.001B0437@in.ibm.com>
	<CAMUF1Skzg+nik=M-w9MoSoaGksWJgsHWOj-nAGc0sd9uDHkpGA@mail.gmail.com>
	<OFE810291D.83FEA351-ON65257B1F.005E9BBB-65257B1F.00614E7D@in.ibm.com>
	<CAB_DFWYifGmyaTzNZvddxzS1HW5WuLHXb6TiD4hrvqFt-fh=Sw@mail.gmail.com>
	<512E870F.6000605@oracle.com>
	<CAB_DFWYupcaNsQ39S+H5LaPEAM9mKJBhwgOoNX68TRxM7cNaWA@mail.gmail.com>
	<512F31F1.1030504@oracle.com>
	<CAB_DFWbz8FaSzLi8qT07PNiJATZTRmeoWBgVaJ-w3N8Ama6mNA@mail.gmail.com>
	<512F4C7F.80101@oracle.com> <512F4DBA.3050506@oracle.com>
	<CAB_DFWanURB-3u7tiM7AfeZEBk2nhMSD5gDW2uxo37LY-Ah97w@mail.gmail.com>
	<512F5FAC.1060704@oracle.com>
	<CAB_DFWZOc9fsJ44kcjUc-Jpu7=NeXKLsGH29cC9rMX0W4AHPpQ@mail.gmail!
	.com>
Message-ID: <512F7A7A.3050300@oracle.com>

On 28/02/13 15:32, Boaz Nahum wrote:
> So can I stop my efforts reproducing 'rank' crash ?
> Actually I reproduce it, But I'm not able to isolate the case - I can
> easily build JDK and test it.
>
> But if you want me to continue retry - no problem.
Let's do this. I will soon push a patch for the first crash in Flow. You 
can try if that patch also solves the other failure. That would help 
immensely.

Thanks
Maurizio
>
> Boaz
>
>
> On Thu, Feb 28, 2013 at 3:46 PM, Maurizio Cimadamore <
> maurizio.cimadamore at oracle.com> wrote:
>
>> On 28/02/13 13:24, Boaz Nahum wrote:
>>
>>> //C.java
>>>
>>>   public class C {
>>>>       void test(B b) {
>>>>           Tester.m(B.n());
>>>>       }
>>>> }
>>>>
>>>> Which is the very one you got. If you'd be so kind to give me some
>>>> details
>>>> about the other stack trace you were getting (Types.rank) so that I can
>>>> come up with some test case (i.e. what is the code that triggered it).
>>>>
>>>> Maurizio
>>>>
>>>>   Yes exactly. If you named B.n() instead of inline it in the method call
>>> then you got 'normal' error message.
>>> The 'rank' exception - I'm working on it.
>>>
>>> Thanks !!!
>>> Boaz
>>>
>>>   I believe I got at the bottom of the issue - when a completion error
>> (i.e. missing classfile) occurs in a nested context (i.e. method call), the
>> compiler doesn't always report the error, because of some of the
>> intricacies associated with lambda type-checking and nested method calls.
>> Those errors should ALWAYS be reported, as a missing classfile error is a
>> really bad condition that shouldn't be skipped. The fact that the compiler
>> is not reporting them in certain cases lead javac to think that everything
>> is ok, so that the subsequent compilation step can be executed - which is
>> not true. Hence all the spurious crashes.
>>
>> Maurizio
>>


From pbenedict at apache.org  Thu Feb 28 07:42:16 2013
From: pbenedict at apache.org (Paul Benedict)
Date: Thu, 28 Feb 2013 09:42:16 -0600
Subject: hg: lambda/lambda/jdk: JavaDoc improvements.
In-Reply-To: <20130225174518.6E08A47E45@hg.openjdk.java.net>
References: <20130225174518.6E08A47E45@hg.openjdk.java.net>
Message-ID: <CABLGb9x+TQ8i30knce4gNbtf-WBQMrn2Sanz9kqxxUyUr6turQ@mail.gmail.com>

BTW, I noticed most javadoc added in the lambda repository exceeds the 80
character width that the Oracle/Sun coding conventions mandate. Not just
this commit but all javadoc commits really.

http://www.oracle.com/technetwork/java/codeconventions-150003.pdf

Is the 80 character limit is no longer applicable for JDK development?

Paul

On Mon, Feb 25, 2013 at 11:44 AM, <paul.sandoz at oracle.com> wrote:

> Changeset: 6dbfee22c2ff
> Author:    psandoz
> Date:      2013-02-25 18:44 +0100
> URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/6dbfee22c2ff
>
> JavaDoc improvements.
>
> ! src/share/classes/java/util/stream/PipelineHelper.java
> ! src/share/classes/java/util/stream/StreamShape.java
>
>
>

From boaznahum at gmail.com  Thu Feb 28 07:45:23 2013
From: boaznahum at gmail.com (Boaz Nahum)
Date: Thu, 28 Feb 2013 17:45:23 +0200
Subject: Java 7 -> Java8 code breakage scenarios
In-Reply-To: <512F7A7A.3050300@oracle.com>
References: <F04E82B8-7AE4-4AD5-82FF-7BE4E64E4F0D@oracle.com>
	<CAMUF1SnC_6WvyepvYVED7rdxdyJsVyK=UK++AGpfJWZ31gsC2w@mail.gmail.com>
	<51251BDA.8050305@oracle.com>
	<B0882479-248C-42DD-B59C-EB0DD7227130@oracle.com>
	<51253C96.4030109@oracle.com>
	<2E447BAC-0344-4579-AA3F-27BC62FBB049@oracle.com>
	<OF54837934.BDA2DC5E-ON65257B1C.0064A1D6-65257B1D.001B0437@in.ibm.com>
	<CAMUF1Skzg+nik=M-w9MoSoaGksWJgsHWOj-nAGc0sd9uDHkpGA@mail.gmail.com>
	<OFE810291D.83FEA351-ON65257B1F.005E9BBB-65257B1F.00614E7D@in.ibm.com>
	<CAB_DFWYifGmyaTzNZvddxzS1HW5WuLHXb6TiD4hrvqFt-fh=Sw@mail.gmail.com>
	<512E870F.6000605@oracle.com>
	<CAB_DFWYupcaNsQ39S+H5LaPEAM9mKJBhwgOoNX68TRxM7cNaWA@mail.gmail.com>
	<512F31F1.1030504@oracle.com>
	<CAB_DFWbz8FaSzLi8qT07PNiJATZTRmeoWBgVaJ-w3N8Ama6mNA@mail.gmail.com>
	<512F4C7F.80101@oracle.com> <512F4DBA.3050506@oracle.com>
	<CAB_DFWanURB-3u7tiM7AfeZEBk2nhMSD5gDW2uxo37LY-Ah97w@mail.gmail.com>
	<512F5FAC.1060704@oracle.com>
	<CAB_DFWZOc9fsJ44kcjUc-Jpu7=NeXKLsGH29cC9rMX0W4AHPpQ@mail.gmail.com>
	<512F7A7A.3050300@oracle.com>
Message-ID: <CAB_DFWYSB+yyfMcDMbpmEy6ihd8HcvM2NEgv8OT6dyTVDtXvuQ@mail.gmail.com>

Great. So just notify me.
Boaz


On Thu, Feb 28, 2013 at 5:40 PM, Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

> On 28/02/13 15:32, Boaz Nahum wrote:
>
>> So can I stop my efforts reproducing 'rank' crash ?
>> Actually I reproduce it, But I'm not able to isolate the case - I can
>> easily build JDK and test it.
>>
>> But if you want me to continue retry - no problem.
>>
> Let's do this. I will soon push a patch for the first crash in Flow. You
> can try if that patch also solves the other failure. That would help
> immensely.
>
> Thanks
> Maurizio
>
>
>> Boaz
>>
>>
>> On Thu, Feb 28, 2013 at 3:46 PM, Maurizio Cimadamore <
>> maurizio.cimadamore at oracle.com**> wrote:
>>
>>  On 28/02/13 13:24, Boaz Nahum wrote:
>>>
>>>  //C.java
>>>>
>>>>   public class C {
>>>>
>>>>>       void test(B b) {
>>>>>           Tester.m(B.n());
>>>>>       }
>>>>> }
>>>>>
>>>>> Which is the very one you got. If you'd be so kind to give me some
>>>>> details
>>>>> about the other stack trace you were getting (Types.rank) so that I can
>>>>> come up with some test case (i.e. what is the code that triggered it).
>>>>>
>>>>> Maurizio
>>>>>
>>>>>   Yes exactly. If you named B.n() instead of inline it in the method
>>>>> call
>>>>>
>>>> then you got 'normal' error message.
>>>> The 'rank' exception - I'm working on it.
>>>>
>>>> Thanks !!!
>>>> Boaz
>>>>
>>>>   I believe I got at the bottom of the issue - when a completion error
>>>>
>>> (i.e. missing classfile) occurs in a nested context (i.e. method call),
>>> the
>>> compiler doesn't always report the error, because of some of the
>>> intricacies associated with lambda type-checking and nested method calls.
>>> Those errors should ALWAYS be reported, as a missing classfile error is a
>>> really bad condition that shouldn't be skipped. The fact that the
>>> compiler
>>> is not reporting them in certain cases lead javac to think that
>>> everything
>>> is ok, so that the subsequent compilation step can be executed - which is
>>> not true. Hence all the spurious crashes.
>>>
>>> Maurizio
>>>
>>>
>

From maurizio.cimadamore at oracle.com  Thu Feb 28 07:54:35 2013
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Thu, 28 Feb 2013 15:54:35 +0000
Subject: hg: lambda/lambda/langtools: 8009227: Certain diagnostics should not
	be deferred
Message-ID: <20130228155440.6CBD4474B4@hg.openjdk.java.net>

Changeset: 35a325f9c83e
Author:    mcimadamore
Date:      2013-02-28 15:54 +0000
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/35a325f9c83e

8009227: Certain diagnostics should not be deferred

! src/share/classes/com/sun/tools/javac/comp/Check.java
! src/share/classes/com/sun/tools/javac/comp/DeferredAttr.java
! src/share/classes/com/sun/tools/javac/util/JCDiagnostic.java
! src/share/classes/com/sun/tools/javac/util/Log.java
! test/tools/javac/diags/examples.not-yet.txt
+ test/tools/javac/lambda/abort/CompletionFailure.java


From maurizio.cimadamore at oracle.com  Thu Feb 28 07:54:58 2013
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Thu, 28 Feb 2013 15:54:58 +0000
Subject: Java 7 -> Java8 code breakage scenarios
In-Reply-To: <CAB_DFWYSB+yyfMcDMbpmEy6ihd8HcvM2NEgv8OT6dyTVDtXvuQ@mail.gmail.com>
References: <F04E82B8-7AE4-4AD5-82FF-7BE4E64E4F0D@oracle.com>
	<B0882479-248C-42DD-B59C-EB0DD7227130@oracle.com>
	<51253C96.4030109@oracle.com>
	<2E447BAC-0344-4579-AA3F-27BC62FBB049@oracle.com>
	<OF54837934.BDA2DC5E-ON65257B1C.0064A1D6-65257B1D.001B0437@in.ibm.com>
	<CAMUF1Skzg+nik=M-w9MoSoaGksWJgsHWOj-nAGc0sd9uDHkpGA@mail.gmail.com>
	<OFE810291D.83FEA351-ON65257B1F.005E9BBB-65257B1F.00614E7D@in.ibm.com>
	<CAB_DFWYifGmyaTzNZvddxzS1HW5WuLHXb6TiD4hrvqFt-fh=Sw@mail.gmail.com>
	<512E870F.6000605@oracle.com>
	<CAB_DFWYupcaNsQ39S+H5LaPEAM9mKJBhwgOoNX68TRxM7cNaWA@mail.gmail.com>
	<512F31F1.1030504@oracle.com>
	<CAB_DFWbz8FaSzLi8qT07PNiJATZTRmeoWBgVaJ-w3N8Ama6mNA@mail.gmail.com>
	<512F4C7F.80101@oracle.com> <512F4DBA.3050506@oracle.com>
	<CAB_DFWanURB-3u7tiM7AfeZEBk2nhMSD5gDW2uxo37LY-Ah97w@mail.gmail.com>
	<512F5FAC.1060704@oracle.com>
	<CAB_DFWZOc9fsJ44kcjUc-Jpu7=NeXKLsGH29cC9rMX0W4AHPpQ@mail.gmail.com>
	<512F7A7A.3050300@oracle.com>
	<CAB_DFWYSB+yyfMcDMbpmEy6ihd8HcvM2NEgv8OT6dyTVDtXvuQ@mail.gmail!
	.com>
Message-ID: <512F7DD2.6000608@oracle.com>

On 28/02/13 15:45, Boaz Nahum wrote:
> Great. So just notify me.
> Boaz
Fix pushed. ;-)

Maurizio
>
>
> On Thu, Feb 28, 2013 at 5:40 PM, Maurizio Cimadamore 
> <maurizio.cimadamore at oracle.com 
> <mailto:maurizio.cimadamore at oracle.com>> wrote:
>
>     On 28/02/13 15:32, Boaz Nahum wrote:
>
>         So can I stop my efforts reproducing 'rank' crash ?
>         Actually I reproduce it, But I'm not able to isolate the case
>         - I can
>         easily build JDK and test it.
>
>         But if you want me to continue retry - no problem.
>
>     Let's do this. I will soon push a patch for the first crash in
>     Flow. You can try if that patch also solves the other failure.
>     That would help immensely.
>
>     Thanks
>     Maurizio
>
>
>         Boaz
>
>
>         On Thu, Feb 28, 2013 at 3:46 PM, Maurizio Cimadamore <
>         maurizio.cimadamore at oracle.com
>         <mailto:maurizio.cimadamore at oracle.com>> wrote:
>
>             On 28/02/13 13:24, Boaz Nahum wrote:
>
>                 //C.java
>
>                   public class C {
>
>                           void test(B b) {
>                               Tester.m(B.n());
>                           }
>                     }
>
>                     Which is the very one you got. If you'd be so kind
>                     to give me some
>                     details
>                     about the other stack trace you were getting
>                     (Types.rank) so that I can
>                     come up with some test case (i.e. what is the code
>                     that triggered it).
>
>                     Maurizio
>
>                       Yes exactly. If you named B.n() instead of
>                     inline it in the method call
>
>                 then you got 'normal' error message.
>                 The 'rank' exception - I'm working on it.
>
>                 Thanks !!!
>                 Boaz
>
>                   I believe I got at the bottom of the issue - when a
>                 completion error
>
>             (i.e. missing classfile) occurs in a nested context (i.e.
>             method call), the
>             compiler doesn't always report the error, because of some
>             of the
>             intricacies associated with lambda type-checking and
>             nested method calls.
>             Those errors should ALWAYS be reported, as a missing
>             classfile error is a
>             really bad condition that shouldn't be skipped. The fact
>             that the compiler
>             is not reporting them in certain cases lead javac to think
>             that everything
>             is ok, so that the subsequent compilation step can be
>             executed - which is
>             not true. Hence all the spurious crashes.
>
>             Maurizio
>
>
>


From paul.sandoz at oracle.com  Thu Feb 28 07:55:00 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 28 Feb 2013 16:55:00 +0100
Subject: hg: lambda/lambda/jdk: JavaDoc improvements.
In-Reply-To: <CABLGb9x+TQ8i30knce4gNbtf-WBQMrn2Sanz9kqxxUyUr6turQ@mail.gmail.com>
References: <20130225174518.6E08A47E45@hg.openjdk.java.net>
	<CABLGb9x+TQ8i30knce4gNbtf-WBQMrn2Sanz9kqxxUyUr6turQ@mail.gmail.com>
Message-ID: <4A23B98C-946B-49EB-AD54-52D1494CEBB8@oracle.com>


On Feb 28, 2013, at 4:42 PM, Paul Benedict <pbenedict at apache.org> wrote:

> BTW, I noticed most javadoc added in the lambda repository exceeds the 80 character width that the Oracle/Sun coding conventions mandate. Not just this commit but all javadoc commits really.
> 
> http://www.oracle.com/technetwork/java/codeconventions-150003.pdf
> 
> Is the 80 character limit is no longer applicable for JDK development?
> 

Thanks for noticing that. Drat , i was using the vertical bar in my IDE as a guide and it was set at the incorrect position, i will update.

Paul.


> Paul
> 
> On Mon, Feb 25, 2013 at 11:44 AM, <paul.sandoz at oracle.com> wrote:
> Changeset: 6dbfee22c2ff
> Author:    psandoz
> Date:      2013-02-25 18:44 +0100
> URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/6dbfee22c2ff
> 
> JavaDoc improvements.
> 
> ! src/share/classes/java/util/stream/PipelineHelper.java
> ! src/share/classes/java/util/stream/StreamShape.java
> 
> 
> 


From maurizio.cimadamore at oracle.com  Thu Feb 28 07:56:42 2013
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Thu, 28 Feb 2013 15:56:42 +0000
Subject: Java 7 -> Java8 code breakage scenarios
In-Reply-To: <512F7DD2.6000608@oracle.com>
References: <F04E82B8-7AE4-4AD5-82FF-7BE4E64E4F0D@oracle.com>
	<51253C96.4030109@oracle.com>
	<2E447BAC-0344-4579-AA3F-27BC62FBB049@oracle.com>
	<OF54837934.BDA2DC5E-ON65257B1C.0064A1D6-65257B1D.001B0437@in.ibm.com>
	<CAMUF1Skzg+nik=M-w9MoSoaGksWJgsHWOj-nAGc0sd9uDHkpGA@mail.gmail.com>
	<OFE810291D.83FEA351-ON65257B1F.005E9BBB-65257B1F.00614E7D@in.ibm.com>
	<CAB_DFWYifGmyaTzNZvddxzS1HW5WuLHXb6TiD4hrvqFt-fh=Sw@mail.gmail.com>
	<512E870F.6000605@oracle.com>
	<CAB_DFWYupcaNsQ39S+H5LaPEAM9mKJBhwgOoNX68TRxM7cNaWA@mail.gmail.com>
	<512F31F1.1030504@oracle.com>
	<CAB_DFWbz8FaSzLi8qT07PNiJATZTRmeoWBgVaJ-w3N8Ama6mNA@mail.gmail.com>
	<512F4C7F.80101@oracle.com> <512F4DBA.3050506@oracle.com>
	<CAB_DFWanURB-3u7tiM7AfeZEBk2nhMSD5gDW2uxo37LY-Ah97w@mail.gmail.com>
	<512F5FAC.1060704@oracle.com>
	<CAB_DFWZOc9fsJ44kcjUc-Jpu7=NeXKLsGH29cC9rMX0W4AHPpQ@mail.gmail.com>
	<512F7A7A.3050300@oracle.com>
	<CAB_DFWYSB+yyfMcDMbpmEy6ihd8HcvM2NEgv8OT6dyTVDtXvuQ@mail.gmail.com>
	<512F7DD2.6000608@oracle.com>
Message-ID: <512F7E3A.4060105@oracle.com>

On 28/02/13 15:54, Maurizio Cimadamore wrote:
> On 28/02/13 15:45, Boaz Nahum wrote:
>> Great. So just notify me.
>> Boaz
> Fix pushed. ;-)
>
Btw - to clarify; the fix doesn't remove the need for the extra 
dependency - but it allows the compiler to fail gracefully with the 
'class file for XYZ not found' message.

Maurizio

> Maurizio
>>
>>
>> On Thu, Feb 28, 2013 at 5:40 PM, Maurizio Cimadamore 
>> <maurizio.cimadamore at oracle.com 
>> <mailto:maurizio.cimadamore at oracle.com>> wrote:
>>
>>     On 28/02/13 15:32, Boaz Nahum wrote:
>>
>>         So can I stop my efforts reproducing 'rank' crash ?
>>         Actually I reproduce it, But I'm not able to isolate the case
>>         - I can
>>         easily build JDK and test it.
>>
>>         But if you want me to continue retry - no problem.
>>
>>     Let's do this. I will soon push a patch for the first crash in
>>     Flow. You can try if that patch also solves the other failure.
>>     That would help immensely.
>>
>>     Thanks
>>     Maurizio
>>
>>
>>         Boaz
>>
>>
>>         On Thu, Feb 28, 2013 at 3:46 PM, Maurizio Cimadamore <
>>         maurizio.cimadamore at oracle.com
>>         <mailto:maurizio.cimadamore at oracle.com>> wrote:
>>
>>             On 28/02/13 13:24, Boaz Nahum wrote:
>>
>>                 //C.java
>>
>>                   public class C {
>>
>>                           void test(B b) {
>>                               Tester.m(B.n());
>>                           }
>>                     }
>>
>>                     Which is the very one you got. If you'd be so
>>                     kind to give me some
>>                     details
>>                     about the other stack trace you were getting
>>                     (Types.rank) so that I can
>>                     come up with some test case (i.e. what is the
>>                     code that triggered it).
>>
>>                     Maurizio
>>
>>                       Yes exactly. If you named B.n() instead of
>>                     inline it in the method call
>>
>>                 then you got 'normal' error message.
>>                 The 'rank' exception - I'm working on it.
>>
>>                 Thanks !!!
>>                 Boaz
>>
>>                   I believe I got at the bottom of the issue - when a
>>                 completion error
>>
>>             (i.e. missing classfile) occurs in a nested context (i.e.
>>             method call), the
>>             compiler doesn't always report the error, because of some
>>             of the
>>             intricacies associated with lambda type-checking and
>>             nested method calls.
>>             Those errors should ALWAYS be reported, as a missing
>>             classfile error is a
>>             really bad condition that shouldn't be skipped. The fact
>>             that the compiler
>>             is not reporting them in certain cases lead javac to
>>             think that everything
>>             is ok, so that the subsequent compilation step can be
>>             executed - which is
>>             not true. Hence all the spurious crashes.
>>
>>             Maurizio
>>
>>
>>
>


From paul.sandoz at oracle.com  Thu Feb 28 08:36:06 2013
From: paul.sandoz at oracle.com (paul.sandoz at oracle.com)
Date: Thu, 28 Feb 2013 16:36:06 +0000
Subject: hg: lambda/lambda/jdk: Format JavaDoc to 80 character width limit
Message-ID: <20130228163641.BD508474B8@hg.openjdk.java.net>

Changeset: 871862c719a5
Author:    psandoz
Date:      2013-02-28 17:35 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/871862c719a5

Format JavaDoc to 80 character width limit

! src/share/classes/java/util/stream/Streams.java


From paul.sandoz at oracle.com  Thu Feb 28 09:35:38 2013
From: paul.sandoz at oracle.com (paul.sandoz at oracle.com)
Date: Thu, 28 Feb 2013 17:35:38 +0000
Subject: hg: lambda/lambda/jdk: Format JavaDoc to 80 character width limit
Message-ID: <20130228173611.AB4C4474BB@hg.openjdk.java.net>

Changeset: 9ccdccc3c754
Author:    psandoz
Date:      2013-02-28 18:35 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/9ccdccc3c754

Format JavaDoc to 80 character width limit

! src/share/classes/java/util/stream/AbstractShortCircuitTask.java
! src/share/classes/java/util/stream/AbstractTask.java
! src/share/classes/java/util/stream/BaseStream.java
! src/share/classes/java/util/stream/FindOp.java
! src/share/classes/java/util/stream/ForEachOp.java
! src/share/classes/java/util/stream/ForEachUntilOp.java
! src/share/classes/java/util/stream/IntermediateOp.java
! src/share/classes/java/util/stream/MatchOp.java
! src/share/classes/java/util/stream/Node.java
! src/share/classes/java/util/stream/PipelineHelper.java
! src/share/classes/java/util/stream/Sink.java
! src/share/classes/java/util/stream/StatefulOp.java
! src/share/classes/java/util/stream/StreamOpFlag.java
! src/share/classes/java/util/stream/StreamShape.java
! src/share/classes/java/util/stream/TerminalOp.java
! src/share/classes/java/util/stream/Tripwire.java


From boaznahum at gmail.com  Thu Feb 28 09:53:31 2013
From: boaznahum at gmail.com (Boaz Nahum)
Date: Thu, 28 Feb 2013 19:53:31 +0200
Subject: Java 7 -> Java8 code breakage scenarios
In-Reply-To: <512F7E3A.4060105@oracle.com>
References: <F04E82B8-7AE4-4AD5-82FF-7BE4E64E4F0D@oracle.com>
	<51253C96.4030109@oracle.com>
	<2E447BAC-0344-4579-AA3F-27BC62FBB049@oracle.com>
	<OF54837934.BDA2DC5E-ON65257B1C.0064A1D6-65257B1D.001B0437@in.ibm.com>
	<CAMUF1Skzg+nik=M-w9MoSoaGksWJgsHWOj-nAGc0sd9uDHkpGA@mail.gmail.com>
	<OFE810291D.83FEA351-ON65257B1F.005E9BBB-65257B1F.00614E7D@in.ibm.com>
	<CAB_DFWYifGmyaTzNZvddxzS1HW5WuLHXb6TiD4hrvqFt-fh=Sw@mail.gmail.com>
	<512E870F.6000605@oracle.com>
	<CAB_DFWYupcaNsQ39S+H5LaPEAM9mKJBhwgOoNX68TRxM7cNaWA@mail.gmail.com>
	<512F31F1.1030504@oracle.com>
	<CAB_DFWbz8FaSzLi8qT07PNiJATZTRmeoWBgVaJ-w3N8Ama6mNA@mail.gmail.com>
	<512F4C7F.80101@oracle.com> <512F4DBA.3050506@oracle.com>
	<CAB_DFWanURB-3u7tiM7AfeZEBk2nhMSD5gDW2uxo37LY-Ah97w@mail.gmail.com>
	<512F5FAC.1060704@oracle.com>
	<CAB_DFWZOc9fsJ44kcjUc-Jpu7=NeXKLsGH29cC9rMX0W4AHPpQ@mail.gmail.com>
	<512F7A7A.3050300@oracle.com>
	<CAB_DFWYSB+yyfMcDMbpmEy6ihd8HcvM2NEgv8OT6dyTVDtXvuQ@mail.gmail.com>
	<512F7DD2.6000608@oracle.com> <512F7E3A.4060105@oracle.com>
Message-ID: <CAB_DFWb6Uy=Cmx6BYXT2jT+587VcaEvmrX2aaqyqXAZCur1B4w@mail.gmail.com>

On my site, indeed both crashes were replaced by compiler error message.
But the message so unrelated to the location of error (but still it helps
quickly solve the error).
let me explain, assume the below hierarchy

I1 {}
I2 extends I1 {}

C1 implement I2 {
  String getName();
}

C2 extends C1 {}

Test {
   test(C2 module) {

     label.setText(module.getName());

   }
}
---------------------------
When compiling Test and I1 is missing then I got error message

   [javac] Test.java:26: error: cannot access I1
   [javac]         label.setText(module.getName());
   [javac]                                       ^
   [javac]   class file for I1 not found

Don't get me wrong. I'm happy, What I have done in two days, takes me 15
minutes with the new fix.


Btw - to clarify; the fix doesn't remove the need for the extra dependency
> - but it allows the compiler to fail gracefully with the 'class file for
> XYZ not found' message.
>
Good enough for me.

SO MANY THANKS
Boaz

From maurizio.cimadamore at oracle.com  Thu Feb 28 10:02:41 2013
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Thu, 28 Feb 2013 18:02:41 +0000
Subject: Java 7 -> Java8 code breakage scenarios
In-Reply-To: <CAB_DFWb6Uy=Cmx6BYXT2jT+587VcaEvmrX2aaqyqXAZCur1B4w@mail.gmail.com>
References: <F04E82B8-7AE4-4AD5-82FF-7BE4E64E4F0D@oracle.com>
	<OF54837934.BDA2DC5E-ON65257B1C.0064A1D6-65257B1D.001B0437@in.ibm.com>
	<CAMUF1Skzg+nik=M-w9MoSoaGksWJgsHWOj-nAGc0sd9uDHkpGA@mail.gmail.com>
	<OFE810291D.83FEA351-ON65257B1F.005E9BBB-65257B1F.00614E7D@in.ibm.com>
	<CAB_DFWYifGmyaTzNZvddxzS1HW5WuLHXb6TiD4hrvqFt-fh=Sw@mail.gmail.com>
	<512E870F.6000605@oracle.com>
	<CAB_DFWYupcaNsQ39S+H5LaPEAM9mKJBhwgOoNX68TRxM7cNaWA@mail.gmail.com>
	<512F31F1.1030504@oracle.com>
	<CAB_DFWbz8FaSzLi8qT07PNiJATZTRmeoWBgVaJ-w3N8Ama6mNA@mail.gmail.com>
	<512F4C7F.80101@oracle.com> <512F4DBA.3050506@oracle.com>
	<CAB_DFWanURB-3u7tiM7AfeZEBk2nhMSD5gDW2uxo37LY-Ah97w@mail.gmail.com>
	<512F5FAC.1060704@oracle.com>
	<CAB_DFWZOc9fsJ44kcjUc-Jpu7=NeXKLsGH29cC9rMX0W4AHPpQ@mail.gmail.com>
	<512F7A7A.3050300@oracle.com>
	<CAB_DFWYSB+yyfMcDMbpmEy6ihd8HcvM2NEgv8OT6dyTVDtXvuQ@mail.gmail.com>
	<512F7DD2.6000608@oracle.com> <512F7E3A.4060105@oracle.com>
	<CAB_DFWb6Uy=Cmx6BYXT2jT+587VcaEvmrX2aaqyqXAZCur1B4w@mail.gmail.!
	com>
Message-ID: <512F9BC1.6090607@oracle.com>

On 28/02/13 17:53, Boaz Nahum wrote:
> On my site, indeed both crashes were replaced by compiler error message.
> But the message so unrelated to the location of error (but still it helps
> quickly solve the error).
> let me explain, assume the below hierarchy
I'm glad the fix got rid of both crashes!

As for the location of the error message, I think this is one of those 
cases where the error message is too cryptic. The rationale about the 
message being generated there is that the logic for scanning supertypes 
is lazy - you only get there if you need it - and in your case the 
method call is triggering it. However I agree that the error message 
doesn't give much info in order to understand what's going on. If it 
said something like:

    [javac] Test.java:26: error: cannot access supertype of C2
    [javac]         label.setText(module.getName());
    [javac]                                       ^
    [javac]   class file for interface I1 not found


I think it'd be more helpful, even with current location.

Maurizio
>
> I1 {}
> I2 extends I1 {}
>
> C1 implement I2 {
>    String getName();
> }
>
> C2 extends C1 {}
>
> Test {
>     test(C2 module) {
>
>       label.setText(module.getName());
>
>     }
> }
> ---------------------------
> When compiling Test and I1 is missing then I got error message
>
>     [javac] Test.java:26: error: cannot access I1
>     [javac]         label.setText(module.getName());
>     [javac]                                       ^
>     [javac]   class file for I1 not found
>
> Don't get me wrong. I'm happy, What I have done in two days, takes me 15
> minutes with the new fix.
>
>
> Btw - to clarify; the fix doesn't remove the need for the extra dependency
>> - but it allows the compiler to fail gracefully with the 'class file for
>> XYZ not found' message.
>>
> Good enough for me.
>
> SO MANY THANKS
> Boaz
>


From robert.j.saulnier at gmail.com  Thu Feb 28 12:12:33 2013
From: robert.j.saulnier at gmail.com (Robert J. Saulnier)
Date: Thu, 28 Feb 2013 16:12:33 -0400
Subject: Collectors.LongStatistics Min/Max Values
Message-ID: <CAJ8S3uytAQeg-9YvGb12HHmMxpSXp5hbNHTOb+-kY-zmroOZRA@mail.gmail.com>

I'm guessing this was already discussed.

Why does the following print "min=0" instead of "min=1"?

List<Long> nums = Arrays.asList(1L, 2L, 3L);

Collectors.LongStatistics stats =
nums.stream().collect(Collectors.toLongStatistics());

System.out.println("min=" + stats.getMin());

Same issue with max if all the numbers are negative.

From mike.duigou at oracle.com  Thu Feb 28 13:02:05 2013
From: mike.duigou at oracle.com (mike.duigou at oracle.com)
Date: Thu, 28 Feb 2013 21:02:05 +0000
Subject: hg: lambda/lambda/jdk: restore lambda bits lost in jsr166 merge
Message-ID: <20130228210228.A14B8474C6@hg.openjdk.java.net>

Changeset: 74949845c660
Author:    mduigou
Date:      2013-02-28 12:59 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/74949845c660

restore lambda bits lost in jsr166 merge
Contributed-by: Akhil Arora <akhil.arora at oracle.com>

! src/share/classes/java/util/concurrent/ThreadLocalRandom.java
- test-ng/tests/org/openjdk/tests/java/util/RandomStreamTest.java


From uschindler at apache.org  Thu Feb 28 13:07:13 2013
From: uschindler at apache.org (Uwe Schindler)
Date: Thu, 28 Feb 2013 22:07:13 +0100
Subject: Regression in JDK8 build 78: javac complains about missing
	Class#isAnnotationPresent
Message-ID: <013701ce15f7$94dd9ca0$be98d5e0$@apache.org>

Hi,

we tried to build Apache Lucene with JDK8 b78  today (Java(TM) SE Runtime Environment (build 1.8.0-ea-b78)), so we can use the new features of e.g. doclint on javac and javadocs (see related mails on javadoc-dev at openjdk.java.net). Unfortunately those bugs are fixed, but suddenly, the source code of Apache Lucene and Apache Solr no longer compiles, although valid in JDK6, JDK7 and earlier JDK8 builds. We get the following error:

    [javac] Compiling 113 source files to C:\Users\Uwe Schindler\Projects\lucene\trunk-lusolr3\lucene\build\test-framework\classes\java
    [javac] C:\Users\Uwe Schindler\Projects\lucene\trunk-lusolr3\lucene\test-framework\src\java\org\apache\lucene\util\TestRuleSetupAndRestoreClassEnv.java:134: error: cannot find symbol
    [javac]     if (targetClass.isAnnotationPresent(SuppressCodecs.class)) {
    [javac]                    ^
    [javac]   symbol:   method isAnnotationPresent(Class<SuppressCodecs>)
    [javac]   location: variable targetClass of type Class<?>
    [javac] Note: Some input files use or override a deprecated API.
    [javac] Note: Recompile with -Xlint:deprecation for details.
    [javac] 1 error


This method exists since Java 5, but a recent commit in JDK 8 (http://hg.openjdk.java.net/jdk8/awt/jdk/rev/e04467fa13af) seems to cause this. The implementations were removed from the concrete classes, only the new default implementation on the interface should be used. Unfortunately, the compiler (javac) does not understand this and fails to compile. -target and -source is 1.6.

>From the javadocs issues I know that currently the response times on new bugs on bugs.sun.com is > 3 weeks, so I contact you directly.

Please include my eMail address into the responses, as I am not subscribed to both lists,

Uwe

-----
Uwe Schindler
uschindler at apache.org 
Apache Lucene PMC Member / Committer
Bremen, Germany
http://lucene.apache.org/




From joe.darcy at oracle.com  Thu Feb 28 13:16:41 2013
From: joe.darcy at oracle.com (Joe Darcy)
Date: Thu, 28 Feb 2013 13:16:41 -0800
Subject: Regression in JDK8 build 78: javac complains about missing
	Class#isAnnotationPresent
In-Reply-To: <013701ce15f7$94dd9ca0$be98d5e0$@apache.org>
References: <013701ce15f7$94dd9ca0$be98d5e0$@apache.org>
Message-ID: <512FC939.1030001@oracle.com>

Hello Uwe,

One of the warnings you should have received from javac is JDK 8 is 
something along the lines of "using -source 6 without setting 
-bootclasspath."

     https://blogs.oracle.com/darcy/entry/bootclasspath_older_source

If follow this long-standing recommendation,

     https://blogs.oracle.com/darcy/entry/how_to_cross_compile_for

then your existing code should compile.

Thanks for trying out the JDK 8 builds on Lucene,

-Joe

On 2/28/2013 1:07 PM, Uwe Schindler wrote:
> Hi,
>
> we tried to build Apache Lucene with JDK8 b78  today (Java(TM) SE Runtime Environment (build 1.8.0-ea-b78)), so we can use the new features of e.g. doclint on javac and javadocs (see related mails on javadoc-dev at openjdk.java.net). Unfortunately those bugs are fixed, but suddenly, the source code of Apache Lucene and Apache Solr no longer compiles, although valid in JDK6, JDK7 and earlier JDK8 builds. We get the following error:
>
>      [javac] Compiling 113 source files to C:\Users\Uwe Schindler\Projects\lucene\trunk-lusolr3\lucene\build\test-framework\classes\java
>      [javac] C:\Users\Uwe Schindler\Projects\lucene\trunk-lusolr3\lucene\test-framework\src\java\org\apache\lucene\util\TestRuleSetupAndRestoreClassEnv.java:134: error: cannot find symbol
>      [javac]     if (targetClass.isAnnotationPresent(SuppressCodecs.class)) {
>      [javac]                    ^
>      [javac]   symbol:   method isAnnotationPresent(Class<SuppressCodecs>)
>      [javac]   location: variable targetClass of type Class<?>
>      [javac] Note: Some input files use or override a deprecated API.
>      [javac] Note: Recompile with -Xlint:deprecation for details.
>      [javac] 1 error
>
>
> This method exists since Java 5, but a recent commit in JDK 8 (http://hg.openjdk.java.net/jdk8/awt/jdk/rev/e04467fa13af) seems to cause this. The implementations were removed from the concrete classes, only the new default implementation on the interface should be used. Unfortunately, the compiler (javac) does not understand this and fails to compile. -target and -source is 1.6.
>
> >From the javadocs issues I know that currently the response times on new bugs on bugs.sun.com is > 3 weeks, so I contact you directly.
>
> Please include my eMail address into the responses, as I am not subscribed to both lists,
>
> Uwe
>
> -----
> Uwe Schindler
> uschindler at apache.org
> Apache Lucene PMC Member / Committer
> Bremen, Germany
> http://lucene.apache.org/
>
>
>
>


From boaznahum at gmail.com  Thu Feb 28 13:18:21 2013
From: boaznahum at gmail.com (Boaz Nahum)
Date: Thu, 28 Feb 2013 23:18:21 +0200
Subject: Why cant I add my own intermidate operation
In-Reply-To: <00439C01-CAB5-48D4-8692-E743FCA34598@oracle.com>
References: <CAB_DFWYk3a_W27n+L3axO9sudR5eW0BsHM8OuPUyEtfCYsU2Vg@mail.gmail.com>
	<00439C01-CAB5-48D4-8692-E743FCA34598@oracle.com>
Message-ID: <CAB_DFWY9PA5jzRM50Uzkpx7agBKufVErr40s5ZeFB7LdQAOHeQ@mail.gmail.com>

Thank.

Indeed TERMINATOR and flatMap(FlatMapper) solve all my problems.

On Thu, Feb 28, 2013 at 5:12 PM, Paul Sandoz <paul.sandoz at oracle.com> wrote:

> Hi Boaz,
>
> Unfortunately the internals are not ready to open as an SPI, more time is
> required to do that, time that we don't have for JDK 8. What is there now
> could well change in the future and we don't want to be stuck with it.
>
> That tiny 'gate' you are referring while tiny from a method on Stream
> perspective is far from tiny otherwise as it opens up access to other
> internal classes, such as Sink and Node, and opens up concepts of stream
> flags, sequential and parallel implementations.
>
>
> On Feb 27, 2013, at 4:10 PM, Boaz Nahum <boaznahum at gmail.com> wrote:
>
> > Many and I asked before how can I do that and that (for example producing
> > stream of parser tokens from stream, that cant be done by #collect,
> because
> > we have no way to know where the input stream is ended)
> >
>
> As a workaround you can concatenate:
>
>   Streams.concat(s, Collections.singletonList(TERMINATOR).stream());
>
> If you look at the code for that it uses the "escape-hatch" spliterator.
> There might be similar tricks you can apply.
>
> Paul.
>
> > I understand that not any wish can be satisfied.
> >
> > But why not provide a tiny  'gate' to add my pipeline, something like
> > already done:
> >
> > public <E_NEXT, S_NEXT extends BaseStream<E_NEXT, S_NEXT>> S_NEXT
> > pipeline(IntermediateOp<E_OUT, E_NEXT> newOp) {
> >
> > That all I need(I know I can do there many mistakes, write it
> > inefficient,but still it is better than nothing).
> >
> > Today I need to break the pipeline (at least syntactically)
> >
> > My feeling is that 'Stream' is so difficult to extend. Why *so many
> > interfaces such as IntermediateOp* and TerminalOp are  not public ?
> >
> > Thanks
> > Boaz
> >
>
>
>

From uschindler at apache.org  Thu Feb 28 13:31:24 2013
From: uschindler at apache.org (Uwe Schindler)
Date: Thu, 28 Feb 2013 22:31:24 +0100
Subject: Regression in JDK8 build 78: javac complains about missing
	Class#isAnnotationPresent
In-Reply-To: <512FC939.1030001@oracle.com>
References: <013701ce15f7$94dd9ca0$be98d5e0$@apache.org>
	<512FC939.1030001@oracle.com>
Message-ID: <013801ce15fa$f5cb1ee0$e1615ca0$@apache.org>

Hi Joe,

I know about this warning and it generally appears on Java 7, but it was *not* printed out in that case (8b78)! The log I posted was the complete printout from javac.

In any case, we use other tools to ensure that the code works with JDK 1.6 (e.g. animal-sniffer plugin) and our final release versions of Lucene are compiled and release binaries created using JDK6. But some people may still want to compile the code with recent Java versions, including JDK8. 

This is clearly a backwards break and a regression, sorry. With Oracle's current practice to stop supporting older JDKs (like Java 6 from now on), how can anybody with a recent JDK compile this open source project (without crazy bootclasspath tricks, just to compile it)? If this does no longer work at all, you can nuke -source and -target from the possible javac cmd-line options. 

I will open a new bug report on bugs.sun.com and hope for an "official" response.

Uwe

-----
Uwe Schindler
uschindler at apache.org 
Apache Lucene PMC Member / Committer
Bremen, Germany
http://lucene.apache.org/


> -----Original Message-----
> From: Joe Darcy [mailto:joe.darcy at oracle.com]
> Sent: Thursday, February 28, 2013 10:17 PM
> To: Uwe Schindler
> Cc: compiler-dev at openjdk.java.net; lambda-dev at openjdk.java.net
> Subject: Re: Regression in JDK8 build 78: javac complains about missing
> Class#isAnnotationPresent
> 
> Hello Uwe,
> 
> One of the warnings you should have received from javac is JDK 8 is
> something along the lines of "using -source 6 without setting -
> bootclasspath."
> 
>      https://blogs.oracle.com/darcy/entry/bootclasspath_older_source
> 
> If follow this long-standing recommendation,
> 
>      https://blogs.oracle.com/darcy/entry/how_to_cross_compile_for
> 
> then your existing code should compile.
> 
> Thanks for trying out the JDK 8 builds on Lucene,
> 
> -Joe
> 
> On 2/28/2013 1:07 PM, Uwe Schindler wrote:
> > Hi,
> >
> > we tried to build Apache Lucene with JDK8 b78  today (Java(TM) SE
> Runtime Environment (build 1.8.0-ea-b78)), so we can use the new features
> of e.g. doclint on javac and javadocs (see related mails on javadoc-
> dev at openjdk.java.net). Unfortunately those bugs are fixed, but suddenly,
> the source code of Apache Lucene and Apache Solr no longer compiles,
> although valid in JDK6, JDK7 and earlier JDK8 builds. We get the following
> error:
> >
> >      [javac] Compiling 113 source files to C:\Users\Uwe
> Schindler\Projects\lucene\trunk-lusolr3\lucene\build\test-
> framework\classes\java
> >      [javac] C:\Users\Uwe Schindler\Projects\lucene\trunk-
> lusolr3\lucene\test-
> framework\src\java\org\apache\lucene\util\TestRuleSetupAndRestoreClass
> Env.java:134: error: cannot find symbol
> >      [javac]     if (targetClass.isAnnotationPresent(SuppressCodecs.class)) {
> >      [javac]                    ^
> >      [javac]   symbol:   method isAnnotationPresent(Class<SuppressCodecs>)
> >      [javac]   location: variable targetClass of type Class<?>
> >      [javac] Note: Some input files use or override a deprecated API.
> >      [javac] Note: Recompile with -Xlint:deprecation for details.
> >      [javac] 1 error
> >
> >
> > This method exists since Java 5, but a recent commit in JDK 8
> (http://hg.openjdk.java.net/jdk8/awt/jdk/rev/e04467fa13af) seems to
> cause this. The implementations were removed from the concrete classes,
> only the new default implementation on the interface should be used.
> Unfortunately, the compiler (javac) does not understand this and fails to
> compile. -target and -source is 1.6.
> >
> > >From the javadocs issues I know that currently the response times on
> new bugs on bugs.sun.com is > 3 weeks, so I contact you directly.
> >
> > Please include my eMail address into the responses, as I am not
> > subscribed to both lists,
> >
> > Uwe
> >
> > -----
> > Uwe Schindler
> > uschindler at apache.org
> > Apache Lucene PMC Member / Committer
> > Bremen, Germany
> > http://lucene.apache.org/
> >
> >
> >
> >


From mike.duigou at oracle.com  Thu Feb 28 13:45:24 2013
From: mike.duigou at oracle.com (mike.duigou at oracle.com)
Date: Thu, 28 Feb 2013 21:45:24 +0000
Subject: hg: lambda/lambda/jdk: add Stream of zip entries
Message-ID: <20130228214537.E5B30474D0@hg.openjdk.java.net>

Changeset: 3f73ae4dc13f
Author:    mduigou
Date:      2013-02-28 13:45 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/3f73ae4dc13f

add Stream of zip entries
Contributed-by: Akhil Arora <akhil.arora at oracle.com>

! src/share/classes/java/util/zip/ZipFile.java
+ test/java/util/zip/ZipFile/StreamZipEntriesTest.java


From mike.duigou at oracle.com  Thu Feb 28 14:09:19 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Thu, 28 Feb 2013 14:09:19 -0800
Subject: CFV: New Lambda Project Committer: Akhil Arora
Message-ID: <76D178E6-DF94-4F06-81C8-5132FA1248BE@oracle.com>

I hereby nominate Akhil Arora for lambda Committer.

Akhil has been working on the core lambdafication efforts and has also made several infrastructure contributions.

http://hg.openjdk.java.net/lambda/lambda/jdk/log?rev=akhil
http://hg.openjdk.java.net/lambda/lambda/jdk/log?rev=akhil.arora%40oracle.com

Votes are due by March 7, 2013 12:00 UTC. (2013-03-07T1200Z)

Only current Lambda Committers [1] are eligible to vote on this nomination.  Votes must be cast in the open by replying to
to this mailing list.

For Lazy Consensus voting instructions, see [2].

Mike Duigou


[1]http://openjdk.java.net/census#lambda
[2]http://openjdk.java.net/projects/#committer-vote

From mike.duigou at oracle.com  Thu Feb 28 14:13:22 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Thu, 28 Feb 2013 14:13:22 -0800
Subject: CFV: New Lambda Project Committer: Akhil Arora
In-Reply-To: <76D178E6-DF94-4F06-81C8-5132FA1248BE@oracle.com>
References: <76D178E6-DF94-4F06-81C8-5132FA1248BE@oracle.com>
Message-ID: <86A48F6C-2FF6-4F45-978A-FDA6E4ED889B@oracle.com>

Vote: Yes 

(obviously)

On Feb 28 2013, at 14:09 , Mike Duigou wrote:

> I hereby nominate Akhil Arora for lambda Committer.
> 
> Akhil has been working on the core lambdafication efforts and has also made several infrastructure contributions.
> 
> http://hg.openjdk.java.net/lambda/lambda/jdk/log?rev=akhil
> http://hg.openjdk.java.net/lambda/lambda/jdk/log?rev=akhil.arora%40oracle.com
> 
> Votes are due by March 7, 2013 12:00 UTC. (2013-03-07T1200Z)
> 
> Only current Lambda Committers [1] are eligible to vote on this nomination.  Votes must be cast in the open by replying to
> to this mailing list.
> 
> For Lazy Consensus voting instructions, see [2].
> 
> Mike Duigou
> 
> 
> [1]http://openjdk.java.net/census#lambda
> [2]http://openjdk.java.net/projects/#committer-vote
> 


From maurizio.cimadamore at oracle.com  Thu Feb 28 14:14:53 2013
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Thu, 28 Feb 2013 22:14:53 +0000
Subject: Regression in JDK8 build 78: javac complains about missing
	Class#isAnnotationPresent
In-Reply-To: <013801ce15fa$f5cb1ee0$e1615ca0$@apache.org>
References: <013701ce15f7$94dd9ca0$be98d5e0$@apache.org>
	<512FC939.1030001@oracle.com>
	<013801ce15fa$f5cb1ee0$e1615ca0$@apache.org>
Message-ID: <512FD6DD.8030403@oracle.com>

On 28/02/13 21:31, Uwe Schindler wrote:
> I know about this warning and it generally appears on Java 7, but it was*not*  printed out in that case (8b78)! The log I posted was the complete printout from javac.
This warning is a Xlint warning - so it's possible that you are 
compiling the project with a custom set of Xlint warnings that doesn't 
include this category (called 'options').

Maurizio

From henry.jen at oracle.com  Thu Feb 28 14:15:53 2013
From: henry.jen at oracle.com (Henry Jen)
Date: Thu, 28 Feb 2013 14:15:53 -0800
Subject: CFV: New Lambda Project Committer: Akhil Arora
In-Reply-To: <76D178E6-DF94-4F06-81C8-5132FA1248BE@oracle.com>
References: <76D178E6-DF94-4F06-81C8-5132FA1248BE@oracle.com>
Message-ID: <2A2021C4-51FC-480B-9A2D-D8C1BBE13118@oracle.com>

Vote: yes

Cheers,
Henry

From uschindler at apache.org  Thu Feb 28 14:36:57 2013
From: uschindler at apache.org (Uwe Schindler)
Date: Thu, 28 Feb 2013 23:36:57 +0100
Subject: Regression in JDK8 build 78: javac complains about missing
	Class#isAnnotationPresent
In-Reply-To: <512FD6DD.8030403@oracle.com>
References: <013701ce15f7$94dd9ca0$be98d5e0$@apache.org>
	<512FC939.1030001@oracle.com>
	<013801ce15fa$f5cb1ee0$e1615ca0$@apache.org>
	<512FD6DD.8030403@oracle.com>
Message-ID: <015001ce1604$1def37e0$59cda7a0$@apache.org>

Thanks Maurizio,

 

that?s true, somebody added the ?Xlint:-options tot he ANT build file.

 

This is still no answer to the source of the problem, making again a new Oracle Java version unusable to compile millions of open source projects (Lucene is just an example) ? this status quo seems to repeat on every new major version. Last time it was the serious Hotspot bug corrumpting loops in Java7 GA. Every public Java project has somewhere in their build file ?-target 1.6 -source 1.6? (or another older version), because otherwise you cannot run the generated class files with older Java versions. Compiling with a custom bootclasspath is a good idea to *validate* that your code actually is compliant. But if you need to use the bootclasspath, you need to have the older JDK version installed - in that case you could compile with it, too. 

 

The intention here is to just ?test? the class files with newer JDK versions which is now impossible, without hacking the whole build in an incompatible way. If this is not fixed, we will suggest to users, not to upgrade to JDK8 once it is out ? because we cannot test the class files with JDK 8 (and we have already seen lots of hotspot issues making Apache Lucene crash/fail). The same procedure as every year ? ahm Java version.

 

Of course to produce Java 6 class file format, one could use only ?-target 1.6? and don?t pass ?-source 1.6? (so let it default to 1.8), but this does not help if you build your project with Apache Ant (maybe doesn?t help with Maven, too):

 

   [javac] Compiling 113 source files to C:\Users\Uwe Schindler\Projects\lucene\trunk-lusolr3\lucene\build\test-framework\classes\java

    [javac]

    [javac]           WARNING

    [javac]

    [javac] The -source switch defaults to 1.8 in JDK 1.8.

    [javac] If you specify -target 1.6 you now must also specify -source 1.6.

    [javac] Ant will implicitly add -source 1.6 for you.  Please change your build file.

 

So you no longer have the chance to produce javac 1.6 compliant class files without bootclasspath (using common build tools like Apache ANT). This makes JDK8 unusable.

 

Sorry for complaining,

But that?s a major regression!

 

Uwe

 

-----

Uwe Schindler

uschindler at apache.org 

Apache Lucene PMC Member / Committer

Bremen, Germany

http://lucene.apache.org/

 

From: Maurizio Cimadamore [mailto:maurizio.cimadamore at oracle.com] 
Sent: Thursday, February 28, 2013 11:15 PM
To: Uwe Schindler
Cc: 'Joe Darcy'; lambda-dev at openjdk.java.net; compiler-dev at openjdk.java.net
Subject: Re: Regression in JDK8 build 78: javac complains about missing Class#isAnnotationPresent

 

On 28/02/13 21:31, Uwe Schindler wrote:

I know about this warning and it generally appears on Java 7, but it was *not* printed out in that case (8b78)! The log I posted was the complete printout from javac.

This warning is a Xlint warning - so it's possible that you are compiling the project with a custom set of Xlint warnings that doesn't include this category (called 'options').

Maurizio


From niels.nwx at gmail.com  Thu Feb 28 14:49:55 2013
From: niels.nwx at gmail.com (Niels Nonsense)
Date: Thu, 28 Feb 2013 23:49:55 +0100
Subject: Collectors.LongStatistics Min/Max Values
In-Reply-To: <CAJ8S3uytAQeg-9YvGb12HHmMxpSXp5hbNHTOb+-kY-zmroOZRA@mail.gmail.com>
References: <CAJ8S3uytAQeg-9YvGb12HHmMxpSXp5hbNHTOb+-kY-zmroOZRA@mail.gmail.com>
Message-ID: <CAJYzo6Z4jyJiuJFASqCqfJfP0uRPenwJoZ7nQrP+SusNYDugCQ@mail.gmail.com>

The accept method of LongStatistics should be rewritten as:
@Override
public void accept(long value) {
    sum += value;
    min = count == 0 ? value : Math.min(min, value);
    max = Math.max(max, value);
    ++count;
}
Similar for combine and the other primitives.

2013/2/28 Robert J. Saulnier <robert.j.saulnier at gmail.com>

> I'm guessing this was already discussed.
>
> Why does the following print "min=0" instead of "min=1"?
>
> List<Long> nums = Arrays.asList(1L, 2L, 3L);
>
> Collectors.LongStatistics stats =
> nums.stream().collect(Collectors.toLongStatistics());
>
> System.out.println("min=" + stats.getMin());
>
> Same issue with max if all the numbers are negative.
>
>

From niels.nwx at gmail.com  Thu Feb 28 14:53:14 2013
From: niels.nwx at gmail.com (Niels Nonsense)
Date: Thu, 28 Feb 2013 23:53:14 +0100
Subject: Collectors.LongStatistics Min/Max Values
In-Reply-To: <CAJYzo6Z4jyJiuJFASqCqfJfP0uRPenwJoZ7nQrP+SusNYDugCQ@mail.gmail.com>
References: <CAJ8S3uytAQeg-9YvGb12HHmMxpSXp5hbNHTOb+-kY-zmroOZRA@mail.gmail.com>
	<CAJYzo6Z4jyJiuJFASqCqfJfP0uRPenwJoZ7nQrP+SusNYDugCQ@mail.gmail.com>
Message-ID: <CAJYzo6YY_OJTDFPsveyX0-AG_Zg+=v_Pmd2mr6an+S3_Eq9EUw@mail.gmail.com>

And similar for max of course, saw your note about negative numbers late.

2013/2/28 Niels Nonsense <niels.nwx at gmail.com>

> The accept method of LongStatistics should be rewritten as:
> @Override
> public void accept(long value) {
>     sum += value;
>     min = count == 0 ? value : Math.min(min, value);
>     max = count == 0 ? value : Math.max(max, value);
>     ++count;
> }
> Similar for combine and the other primitives.
>
> 2013/2/28 Robert J. Saulnier <robert.j.saulnier at gmail.com>
>
> I'm guessing this was already discussed.
>>
>> Why does the following print "min=0" instead of "min=1"?
>>
>> List<Long> nums = Arrays.asList(1L, 2L, 3L);
>>
>> Collectors.LongStatistics stats =
>> nums.stream().collect(Collectors.toLongStatistics());
>>
>> System.out.println("min=" + stats.getMin());
>>
>> Same issue with max if all the numbers are negative.
>>
>>
>

From jonathan.gibbons at oracle.com  Thu Feb 28 16:04:00 2013
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Thu, 28 Feb 2013 16:04:00 -0800
Subject: Regression in JDK8 build 78: javac complains about missing
	Class#isAnnotationPresent
In-Reply-To: <015001ce1604$1def37e0$59cda7a0$@apache.org>
References: <013701ce15f7$94dd9ca0$be98d5e0$@apache.org>
	<512FC939.1030001@oracle.com>
	<013801ce15fa$f5cb1ee0$e1615ca0$@apache.org>
	<512FD6DD.8030403@oracle.com>
	<015001ce1604$1def37e0$59cda7a0$@apache.org>
Message-ID: <512FF070.1060706@oracle.com>

Uwe,

I think you have a good point here.

This is not so much a compiler issue as a compatibility issue regarding 
changes to an API.

The problem in this case is that the impl of a method was *moved* to 
being a default method on an interface.  A safer, more compatible 
solution would have been to have added the method to the interface but 
not delete it from its original location.

-- Jon


On 02/28/2013 02:36 PM, Uwe Schindler wrote:
> Thanks Maurizio,
>
>   
>
> that?s true, somebody added the ?Xlint:-options tot he ANT build file.
>
>   
>
> This is still no answer to the source of the problem, making again a new Oracle Java version unusable to compile millions of open source projects (Lucene is just an example) ? this status quo seems to repeat on every new major version. Last time it was the serious Hotspot bug corrumpting loops in Java7 GA. Every public Java project has somewhere in their build file ?-target 1.6 -source 1.6? (or another older version), because otherwise you cannot run the generated class files with older Java versions. Compiling with a custom bootclasspath is a good idea to *validate* that your code actually is compliant. But if you need to use the bootclasspath, you need to have the older JDK version installed - in that case you could compile with it, too.
>
>   
>
> The intention here is to just ?test? the class files with newer JDK versions which is now impossible, without hacking the whole build in an incompatible way. If this is not fixed, we will suggest to users, not to upgrade to JDK8 once it is out ? because we cannot test the class files with JDK 8 (and we have already seen lots of hotspot issues making Apache Lucene crash/fail). The same procedure as every year ? ahm Java version.
>
>   
>
> Of course to produce Java 6 class file format, one could use only ?-target 1.6? and don?t pass ?-source 1.6? (so let it default to 1.8), but this does not help if you build your project with Apache Ant (maybe doesn?t help with Maven, too):
>
>   
>
>     [javac] Compiling 113 source files to C:\Users\Uwe Schindler\Projects\lucene\trunk-lusolr3\lucene\build\test-framework\classes\java
>
>      [javac]
>
>      [javac]           WARNING
>
>      [javac]
>
>      [javac] The -source switch defaults to 1.8 in JDK 1.8.
>
>      [javac] If you specify -target 1.6 you now must also specify -source 1.6.
>
>      [javac] Ant will implicitly add -source 1.6 for you.  Please change your build file.
>
>   
>
> So you no longer have the chance to produce javac 1.6 compliant class files without bootclasspath (using common build tools like Apache ANT). This makes JDK8 unusable.
>
>   
>
> Sorry for complaining,
>
> But that?s a major regression!
>
>   
>
> Uwe
>
>   
>
> -----
>
> Uwe Schindler
>
> uschindler at apache.org
>
> Apache Lucene PMC Member / Committer
>
> Bremen, Germany
>
> http://lucene.apache.org/
>
>   
>
> From: Maurizio Cimadamore [mailto:maurizio.cimadamore at oracle.com]
> Sent: Thursday, February 28, 2013 11:15 PM
> To: Uwe Schindler
> Cc: 'Joe Darcy'; lambda-dev at openjdk.java.net; compiler-dev at openjdk.java.net
> Subject: Re: Regression in JDK8 build 78: javac complains about missing Class#isAnnotationPresent
>
>   
>
> On 28/02/13 21:31, Uwe Schindler wrote:
>
> I know about this warning and it generally appears on Java 7, but it was *not* printed out in that case (8b78)! The log I posted was the complete printout from javac.
>
> This warning is a Xlint warning - so it's possible that you are compiling the project with a custom set of Xlint warnings that doesn't include this category (called 'options').
>
> Maurizio
>
>


From joe.darcy at oracle.com  Thu Feb 28 16:32:31 2013
From: joe.darcy at oracle.com (Joe Darcy)
Date: Thu, 28 Feb 2013 16:32:31 -0800
Subject: Regression in JDK8 build 78: javac complains about missing
	Class#isAnnotationPresent
In-Reply-To: <013801ce15fa$f5cb1ee0$e1615ca0$@apache.org>
References: <013701ce15f7$94dd9ca0$be98d5e0$@apache.org>
	<512FC939.1030001@oracle.com>
	<013801ce15fa$f5cb1ee0$e1615ca0$@apache.org>
Message-ID: <512FF71F.9080000@oracle.com>

Hello Uwe,

On 2/28/2013 1:31 PM, Uwe Schindler wrote:
> Hi Joe,
>
> I know about this warning and it generally appears on Java 7, but it was *not* printed out in that case (8b78)! The log I posted was the complete printout from javac.

Okay; perhaps the warning should be printed in more circumstances.

>
> In any case, we use other tools to ensure that the code works with JDK 1.6 (e.g. animal-sniffer plugin) and our final release versions of Lucene are compiled and release binaries created using JDK6. But some people may still want to compile the code with recent Java versions, including JDK8.
>
> This is clearly a backwards break and a regression, sorry. With Oracle's current practice to stop supporting older JDKs (like Java 6 from now on),

JDK 6 first shipped in 2006 and JDK 6 had its end of public updates from 
Oracle delayed twice, so JDK 6 is hardly being rushed off the stage!


> how can anybody with a recent JDK compile this open source project (without crazy bootclasspath tricks, just to compile it)?

The "crazy bootclasspath trick" has been the recommend practice in this 
situation and documented in the javac manpage for at least the last 10 
years (see the 1.4.2 man page for javac 
http://docs.oracle.com/javase/1.4.2/docs/tooldocs/solaris/javac.html).

I've personally closed several bugs filed against the JDK along the 
lines of "I compiled with -source OLD -target OLD and it didn't work on 
JDK OLD" because the compiled code referenced methods added since JDK 
OLD. Setting the bootclasspath prevents exactly this problem and is in 
general required for correct cross compile.


>   If this does no longer work at all, you can nuke -source and -target from the possible javac cmd-line options.

Well, we have no plans to get rid of the source and target options, but 
neither are we obliged by the Java SE specification to support them and 
they do add some complication to maintaining the compiler. As a 
historical note, javac did not have a -source option until the JDK 1.4.x 
train:

https://blogs.oracle.com/darcy/entry/source_target_class_file_version

It was important at that point to help manage the addition of the 
"assert" keyword to the language.

-Joe

>
> I will open a new bug report on bugs.sun.com and hope for an "official" response.
>
> Uwe
>
> -----
> Uwe Schindler
> uschindler at apache.org
> Apache Lucene PMC Member / Committer
> Bremen, Germany
> http://lucene.apache.org/
>
>
>> -----Original Message-----
>> From: Joe Darcy [mailto:joe.darcy at oracle.com]
>> Sent: Thursday, February 28, 2013 10:17 PM
>> To: Uwe Schindler
>> Cc: compiler-dev at openjdk.java.net; lambda-dev at openjdk.java.net
>> Subject: Re: Regression in JDK8 build 78: javac complains about missing
>> Class#isAnnotationPresent
>>
>> Hello Uwe,
>>
>> One of the warnings you should have received from javac is JDK 8 is
>> something along the lines of "using -source 6 without setting -
>> bootclasspath."
>>
>>       https://blogs.oracle.com/darcy/entry/bootclasspath_older_source
>>
>> If follow this long-standing recommendation,
>>
>>       https://blogs.oracle.com/darcy/entry/how_to_cross_compile_for
>>
>> then your existing code should compile.
>>
>> Thanks for trying out the JDK 8 builds on Lucene,
>>
>> -Joe
>>
>> On 2/28/2013 1:07 PM, Uwe Schindler wrote:
>>> Hi,
>>>
>>> we tried to build Apache Lucene with JDK8 b78  today (Java(TM) SE
>> Runtime Environment (build 1.8.0-ea-b78)), so we can use the new features
>> of e.g. doclint on javac and javadocs (see related mails on javadoc-
>> dev at openjdk.java.net). Unfortunately those bugs are fixed, but suddenly,
>> the source code of Apache Lucene and Apache Solr no longer compiles,
>> although valid in JDK6, JDK7 and earlier JDK8 builds. We get the following
>> error:
>>>       [javac] Compiling 113 source files to C:\Users\Uwe
>> Schindler\Projects\lucene\trunk-lusolr3\lucene\build\test-
>> framework\classes\java
>>>       [javac] C:\Users\Uwe Schindler\Projects\lucene\trunk-
>> lusolr3\lucene\test-
>> framework\src\java\org\apache\lucene\util\TestRuleSetupAndRestoreClass
>> Env.java:134: error: cannot find symbol
>>>       [javac]     if (targetClass.isAnnotationPresent(SuppressCodecs.class)) {
>>>       [javac]                    ^
>>>       [javac]   symbol:   method isAnnotationPresent(Class<SuppressCodecs>)
>>>       [javac]   location: variable targetClass of type Class<?>
>>>       [javac] Note: Some input files use or override a deprecated API.
>>>       [javac] Note: Recompile with -Xlint:deprecation for details.
>>>       [javac] 1 error
>>>
>>>
>>> This method exists since Java 5, but a recent commit in JDK 8
>> (http://hg.openjdk.java.net/jdk8/awt/jdk/rev/e04467fa13af) seems to
>> cause this. The implementations were removed from the concrete classes,
>> only the new default implementation on the interface should be used.
>> Unfortunately, the compiler (javac) does not understand this and fails to
>> compile. -target and -source is 1.6.
>>> >From the javadocs issues I know that currently the response times on
>> new bugs on bugs.sun.com is > 3 weeks, so I contact you directly.
>>> Please include my eMail address into the responses, as I am not
>>> subscribed to both lists,
>>>
>>> Uwe
>>>
>>> -----
>>> Uwe Schindler
>>> uschindler at apache.org
>>> Apache Lucene PMC Member / Committer
>>> Bremen, Germany
>>> http://lucene.apache.org/
>>>
>>>
>>>
>>>


From joe.darcy at oracle.com  Thu Feb 28 17:25:04 2013
From: joe.darcy at oracle.com (Joe Darcy)
Date: Thu, 28 Feb 2013 17:25:04 -0800
Subject: Regression in JDK8 build 78: javac complains about missing
	Class#isAnnotationPresent
In-Reply-To: <015001ce1604$1def37e0$59cda7a0$@apache.org>
References: <013701ce15f7$94dd9ca0$be98d5e0$@apache.org>
	<512FC939.1030001@oracle.com>
	<013801ce15fa$f5cb1ee0$e1615ca0$@apache.org>
	<512FD6DD.8030403@oracle.com>
	<015001ce1604$1def37e0$59cda7a0$@apache.org>
Message-ID: <51300370.7050809@oracle.com>

On 2/28/2013 2:36 PM, Uwe Schindler wrote:
>
> Thanks Maurizio,
>
> that?s true, somebody added the ?Xlint:-options tot he ANT build file.
>
> This is still no answer to the source of the problem
>

As I'm composing this message, it is less than four hours after your 
initial email was first sent to OpenJDK lists. In that time, your email 
has gotten responses from multiple people working on the JDK. As we are 
over six months before the planned ship date for JDK 8, addressing this 
particular issue does not necessarily need preempt other ongoing work so 
that it can be fully resolved today.

> making again a new Oracle Java version unusable to compile millions of 
> open source projects (Lucene is just an example) ? this status quo 
> seems to repeat on every new major version. Last time it was the 
> serious Hotspot bug corrumpting loops in Java7 GA.
>

Well, it sounds like Lucene is testing with JDK 8 more than a few weeks 
ahead of its ship date, so there should be plenty of time to fix 
correctness bugs that are found and reported ;-)

It is very helpful for external projects to run tests of their code on 
JDK 8 builds along the way to supplement the testing done by the JDK team.

As for the technical details of what is going on, the 
isAnnotationPresent method in the java.lang.reflect.AnnotatedElement 
interface has been turned into a default method:

     http://bugs.sun.com/view_bug.do?bug_id=8007113

This change was introduced in b77 and allows some sharing of code among 
the various classes implementing AnnotatedElement, including 
java.lang.Class, java.lang.reflect.{Method, Constructor}.

For reasons I'll describe shortly, when compiling under a -source 
setting earlier than source 8, code that references isAnnotationPresent 
in the implementing classes (or the declaring interface) will not see 
the method as being present. Code that does not reference this method 
will continue to compile under "-source OLD -target OLD" (with the usual 
caveats) and code that references this method will see the method as 
expected under -source 8.

Now, for the central technical question: (using concrete values) how 
should new-in-Java-8 language constructs in the bootclasspath appear to 
code being compiled under -source 6? This question is outside of the 
Java Language Specification, which assumes only a single source version 
exists at any one time, and has no clear-cut answer. As of today, as a 
matter of policy javac makes default methods invisible to code being 
compiled under source versions earlier than 8. Since most default 
methods added in JDK 8 will be for new methods on interfaces, this will 
usually do what people want when compiling for older releases (but 
setting the bootclasspath is the way to be sure you're getting the 
version of the libraries you should have).

Since AnnoatedElement.isAnnotationPresent is an existing  method that is 
now a default method, is it rendered invisible to code being compiled 
under older source versions (when the recommendation of setting 
bootclasspath has not been followed).

Now javac could be made to special-case isAnnotationPresent or change 
its policy and make all default methods visible under older source 
levels, but we are more likely to partially revert the library change to 
the public implementations of AnnotatedElement by giving them 
implementations that called the method defined in the interface.

Cheers,

-Joe

> Every public Java project has somewhere in their build file ?-target 
> 1.6 -source 1.6? (or another older version), because otherwise you 
> cannot run the generated class files with older Java versions. 
> Compiling with a custom bootclasspath is a good idea to **validate** 
> that your code actually is compliant. But if you need to use the 
> bootclasspath, you need to have the older JDK version installed - in 
> that case you could compile with it, too.
>
> The intention here is to just ?test? the class files with newer JDK 
> versions which is now impossible, without hacking the whole build in 
> an incompatible way. If this is not fixed, we will suggest to users, 
> not to upgrade to JDK8 once it is out ? because we cannot test the 
> class files with JDK 8 (and we have already seen lots of hotspot 
> issues making Apache Lucene crash/fail). The same procedure as every 
> year ? ahm Java version.
>
> Of course to produce Java 6 class file format, one could use only 
> ?-target 1.6? and don?t pass ?-source 1.6? (so let it default to 1.8), 
> but this does not help if you build your project with Apache Ant 
> (maybe doesn?t help with Maven, too):
>
>    [javac] Compiling 113 source files to C:\Users\Uwe 
> Schindler\Projects\lucene\trunk-lusolr3\lucene\build\test-framework\classes\java
>
>     [javac]
>
>     [javac]           WARNING
>
>     [javac]
>
>     [javac] The -source switch defaults to 1.8 in JDK 1.8.
>
>     [javac] If you specify -target 1.6 you now must also specify 
> -source 1.6.
>
>     [javac] Ant will implicitly add -source 1.6 for you.  Please 
> change your build file.
>
> So you no longer have the chance to produce javac 1.6 compliant class 
> files without bootclasspath (using common build tools like Apache 
> ANT). This makes JDK8 unusable.
>
> Sorry for complaining,
>
> But that?s a major regression!
>
> Uwe
>
> -----
>
> Uwe Schindler
>
> uschindler at apache.org
>
> Apache Lucene PMC Member / Committer
>
> Bremen, Germany
>
> http://lucene.apache.org/
>
> *From:*Maurizio Cimadamore [mailto:maurizio.cimadamore at oracle.com]
> *Sent:* Thursday, February 28, 2013 11:15 PM
> *To:* Uwe Schindler
> *Cc:* 'Joe Darcy'; lambda-dev at openjdk.java.net; 
> compiler-dev at openjdk.java.net
> *Subject:* Re: Regression in JDK8 build 78: javac complains about 
> missing Class#isAnnotationPresent
>
> On 28/02/13 21:31, Uwe Schindler wrote:
>
>     I know about this warning and it generally appears on Java 7, but it was****not**  printed out in that case (8b78)! The log I posted was the complete printout from javac.
>
> This warning is a Xlint warning - so it's possible that you are 
> compiling the project with a custom set of Xlint warnings that doesn't 
> include this category (called 'options').
>
> Maurizio
>


From howard.lovatt at gmail.com  Thu Feb 28 17:33:47 2013
From: howard.lovatt at gmail.com (Howard Lovatt)
Date: Fri, 1 Mar 2013 12:33:47 +1100
Subject: Allow default methods to override Object's methods
Message-ID: <CACR_FB7-pX2HKg5DdfUdGc3ewaPa87mg82NwRqfJ_qN0w6cKtw@mail.gmail.com>

Playing round with the lambdas is generally going well for me, good fun.

However a couple of times I have wanted to override Object's methods, i.e.
toString, equals, and hashCode. For example in a toy stream library I am
playing with:

@FunctionalInterface public interface IntStream {
  int next() throws Break, Continue;

  default void forEach(final IntConsumer consumer) {
    try {
      for (;;) {
        try { consumer.accept(next()); }
        catch (final Continue notUsed) {}
      }
    }
    catch (final Break notUsed) {}
  }

  default IntStream map(final IntUnaryOperator unary) { return () ->
unary.applyAsInt(next()); }
}

It would be great to override toString, equals, and hashCode just like a
List does.

I think this has been discussed before I don't remember anyone having any
examples of were it would be useful.

Do you think the above is a genuine example or an outlying case?

  -- Howard.

From howard.lovatt at gmail.com  Thu Feb 28 17:54:30 2013
From: howard.lovatt at gmail.com (Howard Lovatt)
Date: Fri, 1 Mar 2013 12:54:30 +1100
Subject: Allow lambdas to implement abstract classes
Message-ID: <CACR_FB4D55RGP5wbikjwBGj9=v8GbWa3u4NQ8yrdq5c2RQ3bkA@mail.gmail.com>

Playing round with a toy streams library I have come across an inefficiency
doe to lambdas only implementing interfaces, e.g.:

@FunctionalInterface public interface IntStream {
  int next() throws Break, Continue;

  default void forEach(final IntConsumer consumer) {
    try {
      for (;;) {
        try { consumer.accept(next()); }
        catch (final Continue notUsed) {}
      }
    }
    catch (final Break notUsed) {}
  }

  default IntStream map(final IntUnaryOperator unary) { return () ->
unary.applyAsInt(next()); }
}

Where IntUnaryOperator is a functional interface with abstract method
applyAsInt. When the map method is called an instance of IntUnaryOperator
is passed in and then an instance of IntStream is created which calls
IntUnaryOperator's applyAsInt method each time its own next method is
called (i.e. map is lazy but requires two objects an IntUnaryOperator and
an IntStream).

If lambdas could implement abstract classes then only one object is needed,
e.g.:

 // 1. class not interface, 2. it is a IntStream, 3. @FunctionalInterface
becomes @Functional
@Functional public abstract class IntUnaryOperator implements IntStream {
  abstract public int applyAsInt(int in);

  public IntStream previous = null;

  public int next() { return applyAsInt(previous.next()); }
}

Then the map method would become:

  default IntStream map(final IntUnaryOperator unary) {
    unary.previous = this;
    return unary;
  }

This way only one instead of two objects are created, because
IntUnaryOperator is an IntStream.

Would it be useful in other cases if lambdas could implement abstract
methods?

  -- Howard.

From david.lloyd at redhat.com  Thu Feb 28 18:05:40 2013
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Thu, 28 Feb 2013 20:05:40 -0600
Subject: Regression in JDK8 build 78: javac complains about missing
	Class#isAnnotationPresent
In-Reply-To: <51300370.7050809@oracle.com>
References: <013701ce15f7$94dd9ca0$be98d5e0$@apache.org>
	<512FC939.1030001@oracle.com>
	<013801ce15fa$f5cb1ee0$e1615ca0$@apache.org>
	<512FD6DD.8030403@oracle.com>
	<015001ce1604$1def37e0$59cda7a0$@apache.org>
	<51300370.7050809@oracle.com>
Message-ID: <51300CF4.6050308@redhat.com>

On 02/28/2013 07:25 PM, Joe Darcy wrote:
> As for the technical details of what is going on, the
> isAnnotationPresent method in the java.lang.reflect.AnnotatedElement
> interface has been turned into a default method:
>
>       http://bugs.sun.com/view_bug.do?bug_id=8007113
>
> This change was introduced in b77 and allows some sharing of code among
> the various classes implementing AnnotatedElement, including
> java.lang.Class, java.lang.reflect.{Method, Constructor}.
>
> For reasons I'll describe shortly, when compiling under a -source
> setting earlier than source 8, code that references isAnnotationPresent
> in the implementing classes (or the declaring interface) will not see
> the method as being present. Code that does not reference this method
> will continue to compile under "-source OLD -target OLD" (with the usual
> caveats) and code that references this method will see the method as
> expected under -source 8.

Is this something which only occurs at compile time, or will runtime 
code which does invokevirtual on Class#isAnnotationPresent() blow up 
with the same sort of exception?  If so then the method ought to be 
retained on this class, with an upcall to the default implementation.

Do we have any sort of document which covers runtime (binary) 
compatibility considerations for 8 in general, or the new lambda 
functionality in particular?

-- 
- DML

From Robert.Field at oracle.com  Thu Feb 28 18:38:13 2013
From: Robert.Field at oracle.com (Robert Field)
Date: Thu, 28 Feb 2013 18:38:13 -0800
Subject: CFV: New Lambda Project Committer: Akhil Arora
In-Reply-To: <76D178E6-DF94-4F06-81C8-5132FA1248BE@oracle.com>
References: <76D178E6-DF94-4F06-81C8-5132FA1248BE@oracle.com>
Message-ID: <51301495.7050001@oracle.com>

Vote: Yes

On 2/28/13 2:09 PM, Mike Duigou wrote:
> I hereby nominate Akhil Arora for lambda Committer.
>
> Akhil has been working on the core lambdafication efforts and has also made several infrastructure contributions.
>
> http://hg.openjdk.java.net/lambda/lambda/jdk/log?rev=akhil
> http://hg.openjdk.java.net/lambda/lambda/jdk/log?rev=akhil.arora%40oracle.com
>
> Votes are due by March 7, 2013 12:00 UTC. (2013-03-07T1200Z)
>
> Only current Lambda Committers [1] are eligible to vote on this nomination.  Votes must be cast in the open by replying to
> to this mailing list.
>
> For Lazy Consensus voting instructions, see [2].
>
> Mike Duigou
>
>
> [1]http://openjdk.java.net/census#lambda
> [2]http://openjdk.java.net/projects/#committer-vote
>


From jjhstuff at gmail.com  Thu Feb 28 19:58:54 2013
From: jjhstuff at gmail.com (Jim Holmlund)
Date: Thu, 28 Feb 2013 19:58:54 -0800
Subject: CFV: New Lambda Project Committer: Akhil Arora
In-Reply-To: <76D178E6-DF94-4F06-81C8-5132FA1248BE@oracle.com>
References: <76D178E6-DF94-4F06-81C8-5132FA1248BE@oracle.com>
Message-ID: <5130277E.5020305@gmail.com>

Vote: yes

On 2/28/2013 2:09 PM, Mike Duigou wrote:
> I hereby nominate Akhil Arora for lambda Committer.
>
> Akhil has been working on the core lambdafication efforts and has also made several infrastructure contributions.
>
> http://hg.openjdk.java.net/lambda/lambda/jdk/log?rev=akhil
> http://hg.openjdk.java.net/lambda/lambda/jdk/log?rev=akhil.arora%40oracle.com
>
> Votes are due by March 7, 2013 12:00 UTC. (2013-03-07T1200Z)
>
> Only current Lambda Committers [1] are eligible to vote on this nomination.  Votes must be cast in the open by replying to
> to this mailing list.
>
> For Lazy Consensus voting instructions, see [2].
>
> Mike Duigou
>
>
> [1]http://openjdk.java.net/census#lambda
> [2]http://openjdk.java.net/projects/#committer-vote
>
>


From mike.duigou at oracle.com  Thu Feb 28 21:31:26 2013
From: mike.duigou at oracle.com (mike.duigou at oracle.com)
Date: Fri, 01 Mar 2013 05:31:26 +0000
Subject: hg: lambda/lambda: 8008629: webrev.ksh needs to quote bug title it
	gets back from scraping bugs.sun.com
Message-ID: <20130301053126.78D014750A@hg.openjdk.java.net>

Changeset: 1ae17ff49fd1
Author:    mduigou
Date:      2013-02-20 17:56 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/rev/1ae17ff49fd1

8008629: webrev.ksh needs to quote bug title it gets back from scraping bugs.sun.com
Reviewed-by: darcy

! make/scripts/webrev.ksh


From joe.darcy at oracle.com  Thu Feb 28 22:21:41 2013
From: joe.darcy at oracle.com (Joe Darcy)
Date: Thu, 28 Feb 2013 22:21:41 -0800
Subject: Regression in JDK8 build 78: javac complains about missing
	Class#isAnnotationPresent
In-Reply-To: <51300CF4.6050308@redhat.com>
References: <013701ce15f7$94dd9ca0$be98d5e0$@apache.org>
	<512FC939.1030001@oracle.com>
	<013801ce15fa$f5cb1ee0$e1615ca0$@apache.org>
	<512FD6DD.8030403@oracle.com>
	<015001ce1604$1def37e0$59cda7a0$@apache.org>
	<51300370.7050809@oracle.com> <51300CF4.6050308@redhat.com>
Message-ID: <513048F5.6050608@oracle.com>

On 2/28/2013 6:05 PM, David M. Lloyd wrote:
> On 02/28/2013 07:25 PM, Joe Darcy wrote:
>> As for the technical details of what is going on, the
>> isAnnotationPresent method in the java.lang.reflect.AnnotatedElement
>> interface has been turned into a default method:
>>
>>       http://bugs.sun.com/view_bug.do?bug_id=8007113
>>
>> This change was introduced in b77 and allows some sharing of code among
>> the various classes implementing AnnotatedElement, including
>> java.lang.Class, java.lang.reflect.{Method, Constructor}.
>>
>> For reasons I'll describe shortly, when compiling under a -source
>> setting earlier than source 8, code that references isAnnotationPresent
>> in the implementing classes (or the declaring interface) will not see
>> the method as being present. Code that does not reference this method
>> will continue to compile under "-source OLD -target OLD" (with the usual
>> caveats) and code that references this method will see the method as
>> expected under -source 8.
>
> Is this something which only occurs at compile time, or will runtime 
> code which does invokevirtual on Class#isAnnotationPresent() blow up 
> with the same sort of exception?

This situation is only a problem if you compile with a source/target 
that is downrev with respect to the classes on the bootclasspath. If you 
compile with a consistent source / target / bootclasspath you are fine 
and if you run old class files on JDK 8 you are also fine.

>   If so then the method ought to be retained on this class, with an 
> upcall to the default implementation.
>
> Do we have any sort of document which covers runtime (binary) 
> compatibility considerations for 8 in general, or the new lambda 
> functionality in particular?
>

I expect there will be updates to JLS chapter 13 to cover changed binary 
compatibility considerations. Of course default methods are intended to 
allow smoother evolution of interfaces. The hiccup here is where an 
existing interface method was replaced by a default one AND not 
compiling under source 8 where default methods are fully visible to the 
code being compiled.

Cheers,

-Joe


From david.holmes at oracle.com  Thu Feb 28 23:20:21 2013
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 01 Mar 2013 17:20:21 +1000
Subject: CFV: New Lambda Project Committer: Akhil Arora
In-Reply-To: <76D178E6-DF94-4F06-81C8-5132FA1248BE@oracle.com>
References: <76D178E6-DF94-4F06-81C8-5132FA1248BE@oracle.com>
Message-ID: <513056B5.50002@oracle.com>

Vote: yes

David

On 1/03/2013 8:09 AM, Mike Duigou wrote:
> I hereby nominate Akhil Arora for lambda Committer.
>
> Akhil has been working on the core lambdafication efforts and has also made several infrastructure contributions.
>
> http://hg.openjdk.java.net/lambda/lambda/jdk/log?rev=akhil
> http://hg.openjdk.java.net/lambda/lambda/jdk/log?rev=akhil.arora%40oracle.com
>
> Votes are due by March 7, 2013 12:00 UTC. (2013-03-07T1200Z)
>
> Only current Lambda Committers [1] are eligible to vote on this nomination.  Votes must be cast in the open by replying to
> to this mailing list.
>
> For Lazy Consensus voting instructions, see [2].
>
> Mike Duigou
>
>
> [1]http://openjdk.java.net/census#lambda
> [2]http://openjdk.java.net/projects/#committer-vote
>