From neal at gafter.com  Tue Oct 12 08:50:06 2010
From: neal at gafter.com (Neal Gafter)
Date: Tue, 12 Oct 2010 08:50:06 -0700
Subject: JDK7 with lambda's downloadable
In-Reply-To: <7FDA6630E1822F448C97A48D5D73309401F7A532@EXVMSTOR302.intra.rakuten.co.jp>
References: <AANLkTimwXpBUuspdV6UZDTgAtV_CYBAg0x-F0REyiWC7@mail.gmail.com>
	<4C892724.9090907@oracle.com>
	<AANLkTi=oa8NuWB+_Q+47H0E76C-v4T+Fkyh+Da2tN4jh@mail.gmail.com>
	<AANLkTinfWwF_h+S6v7tKxqNbzBuuUm3WNcK_LFcK+ceQ@mail.gmail.com>
	<AANLkTimJcaKFsBsmx9R3+zwqr-TsKSKwVvnq=L6S5Mhm@mail.gmail.com>
	<1284476835.3060.38.camel@springer.wildebeest.org>
	<AANLkTikvaXx_yQveVSNvtvJQQqu5AACd8BoB+S8-gPcq@mail.gmail.com>
	<7FDA6630E1822F448C97A48D5D73309401F7A532@EXVMSTOR302.intra.rakuten.co.jp>
Message-ID: <AANLkTim22QT1iNfikG18q4zYPKFVpBbjSAy8Boa1jUwb@mail.gmail.com>

I don't get it. ?Because HTC is not a good OSS citizen and violates
Google's license under which they get rights to the kernel, it is OK
for Oracle to sue Google?  Is there a reasoning step in there that I'm
missing?

On Tuesday, October 12, 2010, Nathan Bryant <nathan.bryant at linkshare.com> wrote:
> In light of this, I am almost inclined to give Oracle a free pass on
> their lawsuit:
>
> http://www.freedom-to-tinker.com/blog/sjs/htc-willfully-violates-gpl-t-m
> obiles-new-g2-android-phone
>
> It's not like most of the Android distributors are good open source
> citizens; they're not. Those phones all require jailbreaking.
>
> -----Original Message-----
> From: lambda-dev-bounces at openjdk.java.net
> [mailto:lambda-dev-bounces at openjdk.java.net] On Behalf Of Neal Gafter
> Sent: Tuesday, September 14, 2010 6:09 PM
> To: Mark Wielaard
> Cc: lambda-dev at openjdk.java.net
> Subject: Re: JDK7 with lambda's downloadable
>
> On Tue, Sep 14, 2010 at 8:07 AM, Mark Wielaard <mark at klomp.org> wrote:
>
>> On Mon, 2010-09-13 at 17:53 -0700, Neal Gafter wrote:
>> > On Mon, Sep 13, 2010 at 3:48 PM, Dr Andrew John Hughes
>> > <ahughes at redhat.com>wrote:
>> > > On 10 September 2010 06:39, Neal Gafter <neal at gafter.com> wrote:
>> > > > Does Oracle offer a patent grant so that we can *use* the lambda
>> > > prototype,
>> > > > whether from our own builds or prebuilt by Oracle?
>>
>> They explicitly do through their distribution of the code under GPLv2.
>>
>
> I don't see that in GPLv2.
>
>
>> This came up before and then people pointed out that it isn't just the
>> FSF, but that it is also the most likely interpretation when one has
> to
>> actually go to court: "from available case law, it is reasonable to
>> conclude that the implied license defense is available and tenable for
> a
>> defendant in a patent suit involving software released under the
>> GPL" [3].
>>
>
> I don't want a tenable defense. ?I want a license to use.
>
>
>> ?> > http://www.gnu.org/licenses/gpl-2.0.html (7 & 8)
>> > > http://en.swpat.org/wiki/GPLv2_and_patents
>> > >
>> > I'm afraid sections 7 and 8 are not the least bit helpful. ?An
> allegation
>> of
>> > patent infringement for using GPL2'ed code does not contradict any
> of the
>> > conditions of the GPLv2 license.
>>
>> I assume off-by-one and you mean sections 6 and 7. Not providing a
>> patent license would definitely contradict GPLv2. The GPL is pretty
>> explicit that any license granted includes a very broad patent grant:
>> "we have made it clear that any patent must be licensed for everyone's
>> free use".
>
>
> That is the preamble of the license, not the terms of the license. ?As
> it
> turns out, the terms do not make it clear.
>
> So one has to read "license" in sections 6 and 7 to include
>> such a broad patent license (from Oracle and from others that have
>> granted such rights to Oracle itself [for example in the JCP] that are
>> necessary and are now passed through according to clause 6 and 7).
>>
>
> I'd rather not read terms into the license where those terms are absent
> from
> the words of the license.
>
>
>> ?> The GPLv2 license grants freedoms to copy, distribute, and modify
> the
>> > sources. ?But GPLv2 doesn't grant the recipient the right to use
>> (execute)
>> > the code. ?To use the code, you'd need the right to every patent
> that may
>> be
>> > infringed by executing the code.
>>
>> Again the GPL is very explicit about also covering use, it explicitly
>> says all usage rights associated are granted without restrictions:
> "The
>> act of running the Program is not restricted".
>>
>
> You've taken those words out of context. ?Adding back the context:
>
> Activities other than copying, distribution and modification are not
> covered
> by this License; they are outside its scope. The act of running the
> Program
> is not restricted...
>
> In other words, the license does not restrict any rights you may have to
> run
> the program. ?But neither does it grant such rights. ?Patents that the
> user
> does not have rights to may restrict running the program.
>
>
>> ?> Oracle has not granted me, or other non-Oracle openjdk
> contributors, the
>> patent
>> > rights that we need to use the code. ?However, the openjdk
> contributor
>> > agreement requires tha

From nathan.bryant at linkshare.com  Tue Oct 12 08:56:08 2010
From: nathan.bryant at linkshare.com (Nathan Bryant)
Date: Wed, 13 Oct 2010 00:56:08 +0900
Subject: JDK7 with lambda's downloadable
References: <AANLkTimwXpBUuspdV6UZDTgAtV_CYBAg0x-F0REyiWC7@mail.gmail.com><4C892724.9090907@oracle.com><AANLkTi=oa8NuWB+_Q+47H0E76C-v4T+Fkyh+Da2tN4jh@mail.gmail.com><AANLkTinfWwF_h+S6v7tKxqNbzBuuUm3WNcK_LFcK+ceQ@mail.gmail.com><AANLkTimJcaKFsBsmx9R3+zwqr-TsKSKwVvnq=L6S5Mhm@mail.gmail.com><1284476835.3060.38.camel@springer.wildebeest.org><AANLkTikvaXx_yQveVSNvtvJQQqu5AACd8BoB+S8-gPcq@mail.gmail.com><7FDA6630E1822F448C97A48D5D73309401F7A532@EXVMSTOR302.intra.rakuten.co.jp>
	<AANLkTim22QT1iNfikG18q4zYPKFVpBbjSAy8Boa1jUwb@mail.gmail.com>
Message-ID: <7FDA6630E1822F448C97A48D5D73309401F7A60A@EXVMSTOR302.intra.rakuten.co.jp>

Well, stay with me for just a moment before you tune me out: Google wants to work with their distributors. They've stated they don't want to restrict what their distributors do with the kernel.

So they're basically an enabler.

This does not excuse Oracle's behavior; it just turns it into another case of two somewhat shady corporations fighting amongst themselves, rather than one shady corporation and a saintly innocent victim. Make out of that what you will.

-----Original Message-----
From: neal.gafter at gmail.com [mailto:neal.gafter at gmail.com] On Behalf Of Neal Gafter
Sent: Tuesday, October 12, 2010 11:50 AM
To: Nathan Bryant
Cc: Neal Gafter; lambda-dev at openjdk.java.net
Subject: JDK7 with lambda's downloadable

I don't get it. ?Because HTC is not a good OSS citizen and violates
Google's license under which they get rights to the kernel, it is OK
for Oracle to sue Google?  Is there a reasoning step in there that I'm
missing?

On Tuesday, October 12, 2010, Nathan Bryant <nathan.bryant at linkshare.com> wrote:
> In light of this, I am almost inclined to give Oracle a free pass on
> their lawsuit:
>
> http://www.freedom-to-tinker.com/blog/sjs/htc-willfully-violates-gpl-t-m
> obiles-new-g2-android-phone
>
> It's not like most of the Android distributors are good open source
> citizens; they're not. Those phones all require jailbreaking.
>
> -----Original Message-----
> From: lambda-dev-bounces at openjdk.java.net
> [mailto:lambda-dev-bounces at openjdk.java.net] On Behalf Of Neal Gafter
> Sent: Tuesday, September 14, 2010 6:09 PM
> To: Mark Wielaard
> Cc: lambda-dev at openjdk.java.net
> Subject: Re: JDK7 with lambda's downloadable
>
> On Tue, Sep 14, 2010 at 8:07 AM, Mark Wielaard <mark at klomp.org> wrote:
>
>> On Mon, 2010-09-13 at 17:53 -0700, Neal Gafter wrote:
>> > On Mon, Sep 13, 2010 at 3:48 PM, Dr Andrew John Hughes
>> > <ahughes at redhat.com>wrote:
>> > > On 10 September 2010 06:39, Neal Gafter <neal at gafter.com> wrote:
>> > > > Does Oracle offer a patent grant so that we can *use* the lambda
>> > > prototype,
>> > > > whether from our own builds or prebuilt by Oracle?
>>
>> They explicitly do through their distribution of the code under GPLv2.
>>
>
> I don't see that in GPLv2.
>
>
>> This came up before and then people pointed out that it isn't just the
>> FSF, but that it is also the most likely interpretation when one has
> to
>> actually go to court: "from available case law, it is reasonable to
>> conclude that the implied license defense is available and tenable for
> a
>> defendant in a patent suit involving software released under the
>> GPL" [3].
>>
>
> I don't want a tenable defense. ?I want a license to use.
>
>
>> ?> > http://www.gnu.org/licenses/gpl-2.0.html (7 & 8)
>> > > http://en.swpat.org/wiki/GPLv2_and_patents
>> > >
>> > I'm afraid sections 7 and 8 are not the least bit helpful. ?An
> allegation
>> of
>> > patent infringement for using GPL2'ed code does not contradict any
> of the
>> > conditions of the GPLv2 license.
>>
>> I assume off-by-one and you mean sections 6 and 7. Not providing a
>> patent license would definitely contradict GPLv2. The GPL is pretty
>> explicit that any license granted includes a very broad patent grant:
>> "we have made it clear that any patent must be licensed for everyone's
>> free use".
>
>
> That is the preamble of the license, not the terms of the license. ?As
> it
> turns out, the terms do not make it clear.
>
> So one has to read "license" in sections 6 and 7 to include
>> such a broad patent license (from Oracle and from others that have
>> granted such rights to Oracle itself [for example in the JCP] that are
>> necessary and are now passed through according to clause 6 and 7).
>>
>
> I'd rather not read terms into the license where those terms are absent
> from
> the words of the license.
>
>
>> ?> The GPLv2 license grants freedoms to copy, distribute, and modify
> the
>> > sources. ?But GPLv2 doesn't grant the recipient the right to use
>> (execute)
>> > the code. ?To use the code, you'd need the right to every patent
> that may
>> be
>> > infringed by executing the code.
>>
>> Again the GPL is very explicit about also covering use, it explicitly
>> says all usage rights associated are granted without restrictions:
> "The
>> act of running the Program is not restricted".
>>
>
> You've taken those words out of context. ?Adding back the context:
>
> Activities other than copying, distribution and modification are not
> covered
> by this License; they are outside its scope. The act of running the
> Program
> is not restricted...
>
> In other words, the license does not restrict any rights you may have to
> run
> the program. ?But neither does it grant such rights. ?Patents that the
> user
> does not have rights to may restrict running the program.
>
>
>> ?> Oracle has not granted me, or other non-Oracle openjdk
> contributors, the
>> patent
>> > rights that we need to use the code. ?However, the openjdk
> contributor
>> > agreement requires tha

From alex.buckley at oracle.com  Tue Oct 12 12:09:57 2010
From: alex.buckley at oracle.com (Alex Buckley)
Date: Tue, 12 Oct 2010 12:09:57 -0700
Subject: Notice to lambda-dev subscribers
Message-ID: <4CB4B285.1070605@oracle.com>

This list is for technical discussions only.

This list is not for legal or business discussions.

If you feel you cannot hold back from legal or business discussions, you 
should leave this list and seek another forum.

Alex

From brian.goetz at oracle.com  Fri Oct 15 12:55:27 2010
From: brian.goetz at oracle.com (Brian Goetz)
Date: Fri, 15 Oct 2010 15:55:27 -0400
Subject: Updated State of the Lambda
Message-ID: <4CB8B1AF.1090605@oracle.com>

An updated draft (Version 3) of the State of the Lambda has been published at:

   http://cr.openjdk.java.net/~briangoetz/lambda/lambda-state-3.html

Notable differences from the previous draft include:
  - 'this' in lambda expressions is lexically scoped
  - 'yield' keyword dropped in favor of 'return'
  - new syntax

Maurizio will be pushing an implementation conforming to this draft soon.


From luc.duponcheel at gmail.com  Fri Oct 15 13:46:58 2010
From: luc.duponcheel at gmail.com (Luc Duponcheel)
Date: Fri, 15 Oct 2010 22:46:58 +0200
Subject: Updated State of the Lambda
In-Reply-To: <4CB8B1AF.1090605@oracle.com>
References: <4CB8B1AF.1090605@oracle.com>
Message-ID: <AANLkTimONZv_h2WA3R67Reg30GyomnK9rAcVWVHcEHie@mail.gmail.com>

All,

great stuff

the end of the article shows support for simple expressions like

Collections.sortBy(people, #{ p -> p.getLastName() });

what about going one step further and use the (both loved and hated)
underscore syntax of Scala

Collections.sortBy(people, #{ _.getLastName() });

Or would that be one bridge to far?

Luc


On Fri, Oct 15, 2010 at 9:55 PM, Brian Goetz <brian.goetz at oracle.com> wrote:

> An updated draft (Version 3) of the State of the Lambda has been published
> at:
>
>   http://cr.openjdk.java.net/~briangoetz/lambda/lambda-state-3.html<http://cr.openjdk.java.net/%7Ebriangoetz/lambda/lambda-state-3.html>
>
> Notable differences from the previous draft include:
>  - 'this' in lambda expressions is lexically scoped
>  - 'yield' keyword dropped in favor of 'return'
>  - new syntax
>
> Maurizio will be pushing an implementation conforming to this draft soon.
>
>
>


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

reality goes far beyond imagination

From grev at miginfocom.com  Fri Oct 15 13:49:24 2010
From: grev at miginfocom.com (Mikael Grev)
Date: Fri, 15 Oct 2010 22:49:24 +0200
Subject: Updated State of the Lambda
In-Reply-To: <4CB8B1AF.1090605@oracle.com>
References: <4CB8B1AF.1090605@oracle.com>
Message-ID: <6F691F73-9725-45F5-B04C-5D3AA9C0E185@miginfocom.com>

The changes are very good news. Thanks for listening!

Cheers,
Mikael


On Oct 15, 2010, at 21:55 PM, Brian Goetz wrote:

> An updated draft (Version 3) of the State of the Lambda has been published at:
> 
>   http://cr.openjdk.java.net/~briangoetz/lambda/lambda-state-3.html
> 
> Notable differences from the previous draft include:
>  - 'this' in lambda expressions is lexically scoped
>  - 'yield' keyword dropped in favor of 'return'
>  - new syntax
> 
> Maurizio will be pushing an implementation conforming to this draft soon.


From brian.goetz at oracle.com  Fri Oct 15 13:52:06 2010
From: brian.goetz at oracle.com (Brian Goetz)
Date: Fri, 15 Oct 2010 16:52:06 -0400
Subject: Updated State of the Lambda
In-Reply-To: <AANLkTimONZv_h2WA3R67Reg30GyomnK9rAcVWVHcEHie@mail.gmail.com>
References: <4CB8B1AF.1090605@oracle.com>
	<AANLkTimONZv_h2WA3R67Reg30GyomnK9rAcVWVHcEHie@mail.gmail.com>
Message-ID: <4CB8BEF6.2070807@oracle.com>

We do go a few bridges in another direction, as you saw -- but in my opinion 
the _ placeholder is indeed a bridge too far for Java.  (Works fine in Scala 
-- and its OK to not turn Java into Scala.  Different languages, different 
philosophies, so its OK if they draw the line in different places.)

Cheers,
-Brian

On 10/15/2010 4:46 PM, Luc Duponcheel wrote:
> All,
>
> great stuff
>
> the end of the article shows support for simple expressions like
>
> |Collections.sortBy(people, #{ p -> p.getLastName() }); |
>
> what about going one step further and use the (both loved and hated)
> underscore syntax of Scala
>
> |Collections.sortBy(people, #{ _.getLastName() });|
>
> Or would that be one bridge to far?
>
> Luc
>
>
> On Fri, Oct 15, 2010 at 9:55 PM, Brian Goetz <brian.goetz at oracle.com
> <mailto:brian.goetz at oracle.com>> wrote:
>
>     An updated draft (Version 3) of the State of the Lambda has been published at:
>
>     http://cr.openjdk.java.net/~briangoetz/lambda/lambda-state-3.html
>     <http://cr.openjdk.java.net/%7Ebriangoetz/lambda/lambda-state-3.html>
>
>     Notable differences from the previous draft include:
>       - 'this' in lambda expressions is lexically scoped
>       - 'yield' keyword dropped in favor of 'return'
>       - new syntax
>
>     Maurizio will be pushing an implementation conforming to this draft soon.
>
>
>
>
>
> --
>     __~O
>    -\ <,
> (*)/ (*)
>
> reality goes far beyond imagination
>

From pbenedict at apache.org  Fri Oct 15 14:15:57 2010
From: pbenedict at apache.org (Paul Benedict)
Date: Fri, 15 Oct 2010 16:15:57 -0500
Subject: Updated State of the Lambda
In-Reply-To: <4CB8B1AF.1090605@oracle.com>
References: <4CB8B1AF.1090605@oracle.com>
Message-ID: <AANLkTimX0Hz79r_L7b3-hE2cyQoqi3EitM6z4bA0CLot@mail.gmail.com>

Lambda is now part of Part B's Java 8 plan, right?

On Fri, Oct 15, 2010 at 2:55 PM, Brian Goetz <brian.goetz at oracle.com> wrote:
> An updated draft (Version 3) of the State of the Lambda has been published at:
>
> ? http://cr.openjdk.java.net/~briangoetz/lambda/lambda-state-3.html
>
> Notable differences from the previous draft include:
> ?- 'this' in lambda expressions is lexically scoped
> ?- 'yield' keyword dropped in favor of 'return'
> ?- new syntax
>
> Maurizio will be pushing an implementation conforming to this draft soon.
>
>
>

From opinali at gmail.com  Fri Oct 15 13:19:15 2010
From: opinali at gmail.com (Osvaldo Doederlein)
Date: Fri, 15 Oct 2010 17:19:15 -0300
Subject: Updated State of the Lambda
In-Reply-To: <4CB8B1AF.1090605@oracle.com>
References: <4CB8B1AF.1090605@oracle.com>
Message-ID: <AANLkTi=eG3m75vN90SQPY=7S3CofNjtp5yN0xcedP_5p@mail.gmail.com>

Just a small comments:

Runnable r = (Runnable) #{ System.out.println("Blah") };

should be

Object r = (Runnable) #{ System.out.println("Blah") };

(makes the example more useful, and coherent with the later example of
wrong code "Object o = #{ 42 }")

A+
Osvaldo

2010/10/15 Brian Goetz <brian.goetz at oracle.com>:
> An updated draft (Version 3) of the State of the Lambda has been published at:
>
> ? http://cr.openjdk.java.net/~briangoetz/lambda/lambda-state-3.html
>
> Notable differences from the previous draft include:
> ?- 'this' in lambda expressions is lexically scoped
> ?- 'yield' keyword dropped in favor of 'return'
> ?- new syntax
>
> Maurizio will be pushing an implementation conforming to this draft soon.
>
>
>

From brian.goetz at oracle.com  Fri Oct 15 14:24:59 2010
From: brian.goetz at oracle.com (Brian Goetz)
Date: Fri, 15 Oct 2010 17:24:59 -0400
Subject: Updated State of the Lambda
In-Reply-To: <AANLkTimX0Hz79r_L7b3-hE2cyQoqi3EitM6z4bA0CLot@mail.gmail.com>
References: <4CB8B1AF.1090605@oracle.com>
	<AANLkTimX0Hz79r_L7b3-hE2cyQoqi3EitM6z4bA0CLot@mail.gmail.com>
Message-ID: <4CB8C6AB.7000802@oracle.com>

Yes!

On 10/15/2010 5:15 PM, Paul Benedict wrote:
> Lambda is now part of Part B's Java 8 plan, right?
>
> On Fri, Oct 15, 2010 at 2:55 PM, Brian Goetz<brian.goetz at oracle.com>  wrote:
>> An updated draft (Version 3) of the State of the Lambda has been published at:
>>
>>    http://cr.openjdk.java.net/~briangoetz/lambda/lambda-state-3.html
>>
>> Notable differences from the previous draft include:
>>   - 'this' in lambda expressions is lexically scoped
>>   - 'yield' keyword dropped in favor of 'return'
>>   - new syntax
>>
>> Maurizio will be pushing an implementation conforming to this draft soon.
>>
>>
>>

From forax at univ-mlv.fr  Fri Oct 15 15:00:56 2010
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Sat, 16 Oct 2010 00:00:56 +0200
Subject: Updated State of the Lambda
In-Reply-To: <4CB8B1AF.1090605@oracle.com>
References: <4CB8B1AF.1090605@oracle.com>
Message-ID: <4CB8CF18.8080800@univ-mlv.fr>

Le 15/10/2010 21:55, Brian Goetz a ?crit :
> An updated draft (Version 3) of the State of the Lambda has been published at:
>
>     http://cr.openjdk.java.net/~briangoetz/lambda/lambda-state-3.html
>
> Notable differences from the previous draft include:
>    - 'this' in lambda expressions is lexically scoped
>    - 'yield' keyword dropped in favor of 'return'
>    - new syntax
>
> Maurizio will be pushing an implementation conforming to this draft soon.
>
>
>    

I don't understand why # is infix for method reference.
As you said you need to restrict the receiver form
because a simple expression like #a.b.toString() is ambiguous.

Is there a document explaining the translation proposed into bytecode ?

R?mi




From brian.goetz at oracle.com  Fri Oct 15 15:30:21 2010
From: brian.goetz at oracle.com (Brian Goetz)
Date: Fri, 15 Oct 2010 18:30:21 -0400
Subject: Updated State of the Lambda
In-Reply-To: <4CB8CF18.8080800@univ-mlv.fr>
References: <4CB8B1AF.1090605@oracle.com> <4CB8CF18.8080800@univ-mlv.fr>
Message-ID: <4CB8D5FD.2040405@oracle.com>

> I don't understand why # is infix for method reference.
> As you said you need to restrict the receiver form
> because a simple expression like #a.b.toString() is ambiguous.

I think the prefix notation (#ClassName.methodName) is more natural since the 
# is supposed to be the hint of "delayed evaluation of the next thing".  But 
there would definitely be ambiguities if we allowed arbitrary expressions of 
the form #e.methodName.  So our choices are to restrict the form of the 
expression, or to switch to an infix notation like ClassName#methodName, which 
is less problematic in terms of corner cases but personally I find it less 
natural.  IN these simple cases everything is fine, but in cases of chained 
references #a.b.c where there are conflicts between field names and method 
names, there are clear ambiguities that would have to be worked out.

> Is there a document explaining the translation proposed into bytecode ?

Well, the prototype compiler can be considered a document of sorts :)

THere is still the old translation document which is a little out of date. 
We'll be bringing it back into consistency with the compiler soon.  But before 
that I want to finish my work on compatibility guarantees for extension methods.


From grev at miginfocom.com  Fri Oct 15 15:54:18 2010
From: grev at miginfocom.com (Mikael Grev)
Date: Sat, 16 Oct 2010 00:54:18 +0200
Subject: Updated State of the Lambda
In-Reply-To: <4CB8D5FD.2040405@oracle.com>
References: <4CB8B1AF.1090605@oracle.com> <4CB8CF18.8080800@univ-mlv.fr>
	<4CB8D5FD.2040405@oracle.com>
Message-ID: <A5F9F8F4-CA71-45BD-9D9A-6CEBCB030F3F@miginfocom.com>

I like the infix version better. It denotes more clearly that it is the method that's being referenced.

It's also more natural when the class can be taken from the context to go from Class#method to just #method.

Cheers,
Mikael

On Oct 16, 2010, at 0:30 AM, Brian Goetz wrote:

>> I don't understand why # is infix for method reference.
>> As you said you need to restrict the receiver form
>> because a simple expression like #a.b.toString() is ambiguous.
> 
> I think the prefix notation (#ClassName.methodName) is more natural since the 
> # is supposed to be the hint of "delayed evaluation of the next thing".  But 
> there would definitely be ambiguities if we allowed arbitrary expressions of 
> the form #e.methodName.  So our choices are to restrict the form of the 
> expression, or to switch to an infix notation like ClassName#methodName, which 
> is less problematic in terms of corner cases but personally I find it less 
> natural.  IN these simple cases everything is fine, but in cases of chained 
> references #a.b.c where there are conflicts between field names and method 
> names, there are clear ambiguities that would have to be worked out.
> 
>> Is there a document explaining the translation proposed into bytecode ?
> 
> Well, the prototype compiler can be considered a document of sorts :)
> 
> THere is still the old translation document which is a little out of date. 
> We'll be bringing it back into consistency with the compiler soon.  But before 
> that I want to finish my work on compatibility guarantees for extension methods.


From per at bothner.com  Fri Oct 15 16:36:26 2010
From: per at bothner.com (Per Bothner)
Date: Fri, 15 Oct 2010 16:36:26 -0700
Subject: non-static method references [was: Updated State of the Lambda]
In-Reply-To: <4CB8B1AF.1090605@oracle.com>
References: <4CB8B1AF.1090605@oracle.com>
Message-ID: <4CB8E57A.9060902@bothner.com>

Section "11. Putting it together" uses the example:
   Collections.sortBy(people, #Person.getLastName);

But this is not explained in section "8. Method references",
where the syntax #ClassName.methodName is used for references
to static methods, while #Person.getLastName is an instance
expression.

The presumed intent is that in #ClassName.methodName
if methodName is an nullary instance method then it is
syntactic sugar for #{ClassName x -> x.methodName() }.

What about non-nullary instance methods?  My recommendation
is that if methodName has parameter list (T1, ..., Tn} then
#ClassName.methodName would be sugar for
#{ClassName x, T1 t1, ..., Tn tn -> x.methodName(t1, ..., tn)}.
-- 
	--Per Bothner
per at bothner.com   http://per.bothner.com/

From brian.goetz at oracle.com  Fri Oct 15 19:52:31 2010
From: brian.goetz at oracle.com (Brian Goetz)
Date: Fri, 15 Oct 2010 22:52:31 -0400
Subject: non-static method references [was: Updated State of the Lambda]
In-Reply-To: <4CB8E57A.9060902@bothner.com>
References: <4CB8B1AF.1090605@oracle.com> <4CB8E57A.9060902@bothner.com>
Message-ID: <4CB9136F.7020208@oracle.com>

There are three kinds of method references:

  - Static references: #ClassName.someStaticMethod
  - Bound instance methods: #objRef.someInstanceMethod
  - Unbound instance methods: #ClassName.someInstanceMethod

Unbound instance methods are "de-curried" to take the receiver as the first 
argument.  (Which is very convenient given how they are implemented in the VM.)

These were enumerated in other places but not in the SotL draft.

The intended translation is to method handles, which avoids creating the 
intermediate desugared lambdas.

Arity is not a factor; it already works as you describe.

On 10/15/2010 7:36 PM, Per Bothner wrote:
> Section "11. Putting it together" uses the example:
>     Collections.sortBy(people, #Person.getLastName);
>
> But this is not explained in section "8. Method references",
> where the syntax #ClassName.methodName is used for references
> to static methods, while #Person.getLastName is an instance
> expression.
>
> The presumed intent is that in #ClassName.methodName
> if methodName is an nullary instance method then it is
> syntactic sugar for #{ClassName x ->  x.methodName() }.
>
> What about non-nullary instance methods?  My recommendation
> is that if methodName has parameter list (T1, ..., Tn} then
> #ClassName.methodName would be sugar for
> #{ClassName x, T1 t1, ..., Tn tn ->  x.methodName(t1, ..., tn)}.

From ali.ebrahimi1781 at gmail.com  Fri Oct 15 22:36:55 2010
From: ali.ebrahimi1781 at gmail.com (Ali Ebrahimi)
Date: Sat, 16 Oct 2010 09:06:55 +0330
Subject: Updated State of the Lambda
In-Reply-To: <4CB8B1AF.1090605@oracle.com>
References: <4CB8B1AF.1090605@oracle.com>
Message-ID: <AANLkTimbgLMgo9rRPzS8Vzv5PAFuOzeb2-VGgXcLB7n6@mail.gmail.com>

looks fine. another step to real closures.

but one question. if we can not improve the inference scheme to support
following sample code?

public class Test
{
   public static class Customer {
      public String getName() { return "";}
   }
   public abstract static class StringSorter<U> {
      abstract String value(U val);
   }
   public static interface Select<U, V> {
      public V select(U val);
   }
   public static class DBSet<T>  {
      public <U> DBSet<U> select(Select<T,U> x) {return new DBSet<U>();}
      public DBSet<T> sortedByStringAscending(StringSorter<T> x) {return this;}
   }

   public static DBSet<Customer> allCustomer()
   {
      return new DBSet<Customer>();
   }

   public static void main(String[] args)
   {
      DBSet<String> result = allCustomer()   //DBSet<Customer>
         .select(#{c -> c.getName()})      // This line fails in compile time
         .sortedByStringAscending(#{str -> str});

   }
}


On Fri, Oct 15, 2010 at 11:25 PM, Brian Goetz <brian.goetz at oracle.com>wrote:

> An updated draft (Version 3) of the State of the Lambda has been published
> at:
>
>   http://cr.openjdk.java.net/~briangoetz/lambda/lambda-state-3.html
>
> Notable differences from the previous draft include:
>  - 'this' in lambda expressions is lexically scoped
>  - 'yield' keyword dropped in favor of 'return'
>  - new syntax
>
> Maurizio will be pushing an implementation conforming to this draft soon.
>
>
>

From maurizio.cimadamore at oracle.com  Sat Oct 16 03:27:10 2010
From: maurizio.cimadamore at oracle.com (maurizio cimadamore)
Date: Sat, 16 Oct 2010 11:27:10 +0100
Subject: Updated State of the Lambda
In-Reply-To: <AANLkTimbgLMgo9rRPzS8Vzv5PAFuOzeb2-VGgXcLB7n6@mail.gmail.com>
References: <4CB8B1AF.1090605@oracle.com>
	<AANLkTimbgLMgo9rRPzS8Vzv5PAFuOzeb2-VGgXcLB7n6@mail.gmail.com>
Message-ID: <4CB97DFE.8000403@oracle.com>

  On 16/10/2010 06:36, Ali Ebrahimi wrote:
> looks fine. another step to real closures.
>
> but one question. if we can not improve the inference scheme to support
> following sample code?
>
Hi Ali
I think the new semantics of this is very polished and removes many 
complex interactions between the lambda body and the target type which, 
in turn should allow for better inference. That alone, however, won't be 
enough to make this example work. In this specific case I think that the 
inference changes required in order to make things work are deeper than 
it might seem - as I said in a related post, the problem with inference 
in chained method invocations _is_ a problem in the Java language as 
currently specified, regardless of lambda (i.e. you could write examples 
w/o lambda that exhibit the same problem). With lamba things get a lot 
worse since chained calls are very common in certain kinds of libraries, 
and of course we need a better inference story in order to allow that.

Maurizio
> public class Test
> {
>     public static class Customer {
>        public String getName() { return "";}
>     }
>     public abstract static class StringSorter<U>  {
>        abstract String value(U val);
>     }
>     public static interface Select<U, V>  {
>        public V select(U val);
>     }
>     public static class DBSet<T>   {
>        public<U>  DBSet<U>  select(Select<T,U>  x) {return new DBSet<U>();}
>        public DBSet<T>  sortedByStringAscending(StringSorter<T>  x) {return this;}
>     }
>
>     public static DBSet<Customer>  allCustomer()
>     {
>        return new DBSet<Customer>();
>     }
>
>     public static void main(String[] args)
>     {
>        DBSet<String>  result = allCustomer()   //DBSet<Customer>
>           .select(#{c ->  c.getName()})      // This line fails in compile time
>           .sortedByStringAscending(#{str ->  str});
>
>     }
> }
>
>
> On Fri, Oct 15, 2010 at 11:25 PM, Brian Goetz<brian.goetz at oracle.com>wrote:
>
>> An updated draft (Version 3) of the State of the Lambda has been published
>> at:
>>
>>    http://cr.openjdk.java.net/~briangoetz/lambda/lambda-state-3.html
>>
>> Notable differences from the previous draft include:
>>   - 'this' in lambda expressions is lexically scoped
>>   - 'yield' keyword dropped in favor of 'return'
>>   - new syntax
>>
>> Maurizio will be pushing an implementation conforming to this draft soon.
>>
>>
>>


From ali.ebrahimi1781 at gmail.com  Sat Oct 16 05:42:36 2010
From: ali.ebrahimi1781 at gmail.com (Ali Ebrahimi)
Date: Sat, 16 Oct 2010 16:12:36 +0330
Subject: Updated State of the Lambda
In-Reply-To: <4CB97DFE.8000403@oracle.com>
References: <4CB8B1AF.1090605@oracle.com>
	<AANLkTimbgLMgo9rRPzS8Vzv5PAFuOzeb2-VGgXcLB7n6@mail.gmail.com>
	<4CB97DFE.8000403@oracle.com>
Message-ID: <AANLkTi=TjQ6ZMT492Z1vSypMdjSKi=zPotjCxxCtEKra@mail.gmail.com>

I think chained method invocations is very common in java and that is one of
its advantages, thus this limitation is worth fixed very soon.

best regards,
Ali

On Sat, Oct 16, 2010 at 1:57 PM, maurizio cimadamore <
maurizio.cimadamore at oracle.com> wrote:

>  On 16/10/2010 06:36, Ali Ebrahimi wrote:
>
>> looks fine. another step to real closures.
>>
>> but one question. if we can not improve the inference scheme to support
>> following sample code?
>>
>>  Hi Ali
> I think the new semantics of this is very polished and removes many complex
> interactions between the lambda body and the target type which, in turn
> should allow for better inference. That alone, however, won't be enough to
> make this example work. In this specific case I think that the inference
> changes required in order to make things work are deeper than it might seem
> - as I said in a related post, the problem with inference in chained method
> invocations _is_ a problem in the Java language as currently specified,
> regardless of lambda (i.e. you could write examples w/o lambda that exhibit
> the same problem). With lamba things get a lot worse since chained calls are
> very common in certain kinds of libraries, and of course we need a better
> inference story in order to allow that.
>
> Maurizio
>
>> public class Test
>> {
>>    public static class Customer {
>>       public String getName() { return "";}
>>    }
>>    public abstract static class StringSorter<U>  {
>>       abstract String value(U val);
>>    }
>>    public static interface Select<U, V>  {
>>       public V select(U val);
>>    }
>>    public static class DBSet<T>   {
>>       public<U>  DBSet<U>  select(Select<T,U>  x) {return new DBSet<U>();}
>>       public DBSet<T>  sortedByStringAscending(StringSorter<T>  x) {return
>> this;}
>>    }
>>
>>    public static DBSet<Customer>  allCustomer()
>>    {
>>       return new DBSet<Customer>();
>>    }
>>
>>    public static void main(String[] args)
>>    {
>>       DBSet<String>  result = allCustomer()   //DBSet<Customer>
>>          .select(#{c ->  c.getName()})      // This line fails in compile
>> time
>>          .sortedByStringAscending(#{str ->  str});
>>
>>    }
>> }
>>
>>
>> On Fri, Oct 15, 2010 at 11:25 PM, Brian Goetz<brian.goetz at oracle.com
>> >wrote:
>>
>>
>>  An updated draft (Version 3) of the State of the Lambda has been
>>> published
>>> at:
>>>
>>>   http://cr.openjdk.java.net/~briangoetz/lambda/lambda-state-3.html
>>>
>>> Notable differences from the previous draft include:
>>>  - 'this' in lambda expressions is lexically scoped
>>>  - 'yield' keyword dropped in favor of 'return'
>>>  - new syntax
>>>
>>> Maurizio will be pushing an implementation conforming to this draft soon.
>>>
>>>
>>>
>>>
>

From brian.goetz at oracle.com  Sat Oct 16 06:21:23 2010
From: brian.goetz at oracle.com (Brian Goetz)
Date: Sat, 16 Oct 2010 09:21:23 -0400
Subject: Updated State of the Lambda
In-Reply-To: <AANLkTi=m9aBGmJNF9CYedPqWOG_USJ294U8hS07PUeaP@mail.gmail.com>
References: <4CB8B1AF.1090605@oracle.com>
	<AANLkTi=m9aBGmJNF9CYedPqWOG_USJ294U8hS07PUeaP@mail.gmail.com>
Message-ID: <4CB9A6D3.5060702@oracle.com>

No, there's a reason for that.

Consider an assignment, using both tokens:

   Callable c = #{ => 3 };

   Callable c = #{ -> 3 };

When your eyes look at the first line, they see two equal signs, and they are 
perceived "equally" and it is harder for your brain to parse it correctly.

On 10/16/2010 6:27 AM, Llewellyn Falco wrote:
> As i'm sitting in south africa, looking at the table of electric adaptors, I'm
> reminded of the importance of consistency, and I have to ask: why -> instead of =>
>
> ->
> =>
>
> so close, and yet different. is it just to be different?
>
> Llewellyn
>
> On Fri, Oct 15, 2010 at 12:55 PM, Brian Goetz <brian.goetz at oracle.com
> <mailto:brian.goetz at oracle.com>> wrote:
>
>     An updated draft (Version 3) of the State of the Lambda has been published at:
>
>     http://cr.openjdk.java.net/~briangoetz/lambda/lambda-state-3.html
>
>     Notable differences from the previous draft include:
>       - 'this' in lambda expressions is lexically scoped
>       - 'yield' keyword dropped in favor of 'return'
>       - new syntax
>
>     Maurizio will be pushing an implementation conforming to this draft soon.
>
>
>

From john at milsson.nu  Sat Oct 16 14:15:05 2010
From: john at milsson.nu (John Nilsson)
Date: Sat, 16 Oct 2010 23:15:05 +0200
Subject: Updated State of the Lambda
In-Reply-To: <4CB8B1AF.1090605@oracle.com>
References: <4CB8B1AF.1090605@oracle.com>
Message-ID: <AANLkTi=1kVxHDqEN_-06Gfg2+At3OKVFf74mn8sftLu+@mail.gmail.com>

Will method references work with static imports?

import static Person.compareByAge;
...
Arrays.sort(people, #compareByAge);

BR,
John

From brian.goetz at oracle.com  Sat Oct 16 15:56:11 2010
From: brian.goetz at oracle.com (Brian Goetz)
Date: Sat, 16 Oct 2010 16:56:11 -0600
Subject: Updated State of the Lambda
In-Reply-To: <AANLkTi=1kVxHDqEN_-06Gfg2+At3OKVFf74mn8sftLu+@mail.gmail.com>
References: <4CB8B1AF.1090605@oracle.com>
	<AANLkTi=1kVxHDqEN_-06Gfg2+At3OKVFf74mn8sftLu+@mail.gmail.com>
Message-ID: <922A87CA-4E6C-4324-AAF5-7F28B34D084D@oracle.com>

Yes. Once imported, method names are recognized equally whether used  
in a call or a reference capture.

Sent from my iPhone

On Oct 16, 2010, at 3:15 PM, John Nilsson <john at milsson.nu> wrote:

> Will method references work with static imports?
>
> import static Person.compareByAge;
> ...
> Arrays.sort(people, #compareByAge);
>
> BR,
> John

From peter.levart at marand.si  Mon Oct 18 01:04:07 2010
From: peter.levart at marand.si (Peter Levart)
Date: Mon, 18 Oct 2010 10:04:07 +0200
Subject: Updated State of the Lambda
In-Reply-To: <4CB8B1AF.1090605@oracle.com>
References: <4CB8B1AF.1090605@oracle.com>
Message-ID: <201010181004.07597.peter.levart@marand.si>

This is good news. In particular the 1st notable change below. This is a move in the right direction. I wonder if the reason for the cahnge was a result of desire to keep the door open for possible future extension to support "transparent" lambda or just of realization that lexical scoping has a better solution:problem ratio than annonymous inner classes style of scoping? In either case I think we are getting better lambda this way.
I can also understand that the benefit of "yield" was not worth the additional confusion it might cause, although replacing it for "return" it is a step away from transparent lambda.

Regards, Peter
 

On 10/15/10, Brian Goetz wrote:
> An updated draft (Version 3) of the State of the Lambda has been published at:
> 
>    http://cr.openjdk.java.net/~briangoetz/lambda/lambda-state-3.html
> 
> Notable differences from the previous draft include:
>   - 'this' in lambda expressions is lexically scoped
>   - 'yield' keyword dropped in favor of 'return'
>   - new syntax
> 
> Maurizio will be pushing an implementation conforming to this draft soon.
> 
> 
> 

From alex.blewitt at gmail.com  Mon Oct 18 01:37:05 2010
From: alex.blewitt at gmail.com (Alex Blewitt)
Date: Mon, 18 Oct 2010 09:37:05 +0100
Subject: Updated State of the Lambda
In-Reply-To: <201010181004.07597.peter.levart@marand.si>
References: <4CB8B1AF.1090605@oracle.com>
	<201010181004.07597.peter.levart@marand.si>
Message-ID: <99A37C22-540B-4474-9C10-3D5376339506@gmail.com>

I think the change has just flipped the polarity of the changes; whereas before we had abnormal return and normal this, now we have abnormal this and normal return (or vice versa, if such is your preference). We have a crossover of the two concepts here which was present in the first release as well.

As I have said before, I think not binding 'this' to lambdas is a mistake. The DA/DU rules are being stretched, some would say to breaking point, to permit this convolution. Will the weakening of DA/DU cause problems elsewhere? It's certainly a possibility.

The argument of not referring to 'this' as the lambda uses a argument to say that a lambda that doesn't hold onto the enclosing class' instance will be more memory efficient than one that does (c.f. inner classes). However, whether the source code refers to 'this' is an orthogonal concept to whether the runtime representation refers to the instance of the enclosing class. For example, a (non-static) inner class has an implicit reference to the enclosing instance; it doesn't need to refer to 'this' in the body. Conversely, a static inner class may have 'this' injected into it, and thus maintain a reference.

So whilst the conclusion - that lambdas holding an instance to another object are a kind of leak - is valid, it has nothing to do with the type of 'this' captured in the scope of a lambda. A reference to 'this' could point to the current closure (without referring to the original instance in which it was valid) whilst Outer.this could refer to the original instance; unless Outer.this was used, it wouldn't be leaked away in the example described.

Finally: the rules for interpreting 'this' within inner classes are already well known. This is orthogonal to whether the runtime instance actually captures a reference if no 'this' is used, and the argument on this basis is fallacious. Whether there are other reasons for choosing this are not well defined.

Alex

On 18 Oct 2010, at 09:04, Peter Levart wrote:

> This is good news. In particular the 1st notable change below. This is a move in the right direction. I wonder if the reason for the cahnge was a result of desire to keep the door open for possible future extension to support "transparent" lambda or just of realization that lexical scoping has a better solution:problem ratio than annonymous inner classes style of scoping? In either case I think we are getting better lambda this way.
> I can also understand that the benefit of "yield" was not worth the additional confusion it might cause, although replacing it for "return" it is a step away from transparent lambda.
> 
> Regards, Peter
> 
> 
> On 10/15/10, Brian Goetz wrote:
>> An updated draft (Version 3) of the State of the Lambda has been published at:
>> 
>>   http://cr.openjdk.java.net/~briangoetz/lambda/lambda-state-3.html
>> 
>> Notable differences from the previous draft include:
>>  - 'this' in lambda expressions is lexically scoped
>>  - 'yield' keyword dropped in favor of 'return'
>>  - new syntax
>> 
>> Maurizio will be pushing an implementation conforming to this draft soon.
>> 
>> 
>> 
> 


From scolebourne at joda.org  Mon Oct 18 02:38:52 2010
From: scolebourne at joda.org (Stephen Colebourne)
Date: Mon, 18 Oct 2010 10:38:52 +0100
Subject: Updated State of the Lambda
In-Reply-To: <4CB8B1AF.1090605@oracle.com>
References: <4CB8B1AF.1090605@oracle.com>
Message-ID: <AANLkTimHCqmSPb7JnAftj_v5At_K5o=gkafkjqSZvTiL@mail.gmail.com>

I am a strong supporter of the semantics of this latest draft (partly
because its very close to FCM). I especially like the neat DA/DU rule
change.

I still have views on syntax (especially method references), but I
hope that we will have a "syntax month" to allow a timeboxed
discussion of syntax.

Stephen


On 15 October 2010 20:55, Brian Goetz <brian.goetz at oracle.com> wrote:
> An updated draft (Version 3) of the State of the Lambda has been published at:
>
> ? http://cr.openjdk.java.net/~briangoetz/lambda/lambda-state-3.html
>
> Notable differences from the previous draft include:
> ?- 'this' in lambda expressions is lexically scoped
> ?- 'yield' keyword dropped in favor of 'return'
> ?- new syntax
>
> Maurizio will be pushing an implementation conforming to this draft soon.
>
>
>

From peter.levart at marand.si  Mon Oct 18 03:30:32 2010
From: peter.levart at marand.si (Peter Levart)
Date: Mon, 18 Oct 2010 12:30:32 +0200
Subject: Updated State of the Lambda
In-Reply-To: <99A37C22-540B-4474-9C10-3D5376339506@gmail.com>
References: <4CB8B1AF.1090605@oracle.com>
	<201010181004.07597.peter.levart@marand.si>
	<99A37C22-540B-4474-9C10-3D5376339506@gmail.com>
Message-ID: <201010181230.33188.peter.levart@marand.si>

On 10/18/10, Alex Blewitt wrote:
> I think the change has just flipped the polarity of the changes; whereas before we had abnormal return and normal this, now we have abnormal this and normal return (or vice versa, if such is your preference). We have a crossover of the two concepts here which was present in the first release as well.
> 
> As I have said before, I think not binding 'this' to lambdas is a mistake. The DA/DU rules are being stretched, some would say to breaking point, to permit this convolution. Will the weakening of DA/DU cause problems elsewhere? It's certainly a possibility.

You are spreading FUD. Readers of this list are not susceptible to FUD. I don't think DA/DU rules need to be weakened "elsewhere".

> 
> The argument of not referring to 'this' as the lambda uses a argument to say that a lambda that doesn't hold onto the enclosing class' instance will be more memory efficient than one that does (c.f. inner classes). However, whether the source code refers to 'this' is an orthogonal concept to whether the runtime representation refers to the instance of the enclosing class. For example, a (non-static) inner class has an implicit reference to the enclosing instance; it doesn't need to refer to 'this' in the body. Conversely, a static inner class may have 'this' injected into it, and thus maintain a reference.
> 
> So whilst the conclusion - that lambdas holding an instance to another object are a kind of leak - is valid, it has nothing to do with the type of 'this' captured in the scope of a lambda. A reference to 'this' could point to the current closure (without referring to the original instance in which it was valid) whilst Outer.this could refer to the original instance; unless Outer.this was used, it wouldn't be leaked away in the example described.

I too, don't understand this reasoning. From my point of view, the mandatory reference to outer instance in anonymous inner classes (specified in instance methods/initializers/constructors) is actualy a bug of annonymous inner classes and not something that is in any way related to the scoping rules of 'this'.

> 
> Finally: the rules for interpreting 'this' within inner classes are already well known. This is orthogonal to whether the runtime instance actually captures a reference if no 'this' is used, and the argument on this basis is fallacious. Whether there are other reasons for choosing this are not well defined.
> 
> Alex
> 
> On 18 Oct 2010, at 09:04, Peter Levart wrote:
> 
> > This is good news. In particular the 1st notable change below. This is a move in the right direction. I wonder if the reason for the cahnge was a result of desire to keep the door open for possible future extension to support "transparent" lambda or just of realization that lexical scoping has a better solution:problem ratio than annonymous inner classes style of scoping? In either case I think we are getting better lambda this way.
> > I can also understand that the benefit of "yield" was not worth the additional confusion it might cause, although replacing it for "return" it is a step away from transparent lambda.
> > 
> > Regards, Peter
> > 
> > 
> > On 10/15/10, Brian Goetz wrote:
> >> An updated draft (Version 3) of the State of the Lambda has been published at:
> >> 
> >>   http://cr.openjdk.java.net/~briangoetz/lambda/lambda-state-3.html
> >> 
> >> Notable differences from the previous draft include:
> >>  - 'this' in lambda expressions is lexically scoped
> >>  - 'yield' keyword dropped in favor of 'return'
> >>  - new syntax
> >> 
> >> Maurizio will be pushing an implementation conforming to this draft soon.
> >> 
> >> 
> >> 
> > 
> 
> 

From forax at univ-mlv.fr  Mon Oct 18 05:26:50 2010
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Mon, 18 Oct 2010 14:26:50 +0200
Subject: Updated State of the Lambda
In-Reply-To: <99A37C22-540B-4474-9C10-3D5376339506@gmail.com>
References: <4CB8B1AF.1090605@oracle.com>	<201010181004.07597.peter.levart@marand.si>
	<99A37C22-540B-4474-9C10-3D5376339506@gmail.com>
Message-ID: <4CBC3D0A.2080506@univ-mlv.fr>

  Hi Alex,
I really hope that most of the lambdas can be implemented using method 
handles.
There are several advantages to use a method handle instead of a plain 
old inner class
to represent a lambda at runtime.

Method handles are anonymous functions, there aren't bound to an object 
by default,
they are more like static methods.
Trying to provide a 'this' that reference the current lambda is not 
easily doable.
Method handles are immutable by design and the only way to get the 
current method handle
in a method handle is to inject itself as argument, but because the 
injection is a mutation
this will create a new method handle which is different from the one 
injected.

In my opinion, a lambda should be seen as an expression or an 
instruction, not as an object.
The SAM conversion will transform the lambda to an object.
That why 'this' refers to the enclosing object.

R?mi

Le 18/10/2010 10:37, Alex Blewitt a ?crit :
> I think the change has just flipped the polarity of the changes; whereas before we had abnormal return and normal this, now we have abnormal this and normal return (or vice versa, if such is your preference). We have a crossover of the two concepts here which was present in the first release as well.
>
> As I have said before, I think not binding 'this' to lambdas is a mistake. The DA/DU rules are being stretched, some would say to breaking point, to permit this convolution. Will the weakening of DA/DU cause problems elsewhere? It's certainly a possibility.
>
> The argument of not referring to 'this' as the lambda uses a argument to say that a lambda that doesn't hold onto the enclosing class' instance will be more memory efficient than one that does (c.f. inner classes). However, whether the source code refers to 'this' is an orthogonal concept to whether the runtime representation refers to the instance of the enclosing class. For example, a (non-static) inner class has an implicit reference to the enclosing instance; it doesn't need to refer to 'this' in the body. Conversely, a static inner class may have 'this' injected into it, and thus maintain a reference.
>
> So whilst the conclusion - that lambdas holding an instance to another object are a kind of leak - is valid, it has nothing to do with the type of 'this' captured in the scope of a lambda. A reference to 'this' could point to the current closure (without referring to the original instance in which it was valid) whilst Outer.this could refer to the original instance; unless Outer.this was used, it wouldn't be leaked away in the example described.
>
> Finally: the rules for interpreting 'this' within inner classes are already well known. This is orthogonal to whether the runtime instance actually captures a reference if no 'this' is used, and the argument on this basis is fallacious. Whether there are other reasons for choosing this are not well defined.
>
> Alex
>
> On 18 Oct 2010, at 09:04, Peter Levart wrote:
>
>> This is good news. In particular the 1st notable change below. This is a move in the right direction. I wonder if the reason for the cahnge was a result of desire to keep the door open for possible future extension to support "transparent" lambda or just of realization that lexical scoping has a better solution:problem ratio than annonymous inner classes style of scoping? In either case I think we are getting better lambda this way.
>> I can also understand that the benefit of "yield" was not worth the additional confusion it might cause, although replacing it for "return" it is a step away from transparent lambda.
>>
>> Regards, Peter
>>
>>
>> On 10/15/10, Brian Goetz wrote:
>>> An updated draft (Version 3) of the State of the Lambda has been published at:
>>>
>>>    http://cr.openjdk.java.net/~briangoetz/lambda/lambda-state-3.html
>>>
>>> Notable differences from the previous draft include:
>>>   - 'this' in lambda expressions is lexically scoped
>>>   - 'yield' keyword dropped in favor of 'return'
>>>   - new syntax
>>>
>>> Maurizio will be pushing an implementation conforming to this draft soon.
>>>
>>>
>>>
>


From alex.blewitt at gmail.com  Mon Oct 18 06:06:43 2010
From: alex.blewitt at gmail.com (Alex Blewitt)
Date: Mon, 18 Oct 2010 14:06:43 +0100
Subject: Updated State of the Lambda
In-Reply-To: <4CBC3D0A.2080506@univ-mlv.fr>
References: <4CB8B1AF.1090605@oracle.com>
	<201010181004.07597.peter.levart@marand.si>
	<99A37C22-540B-4474-9C10-3D5376339506@gmail.com>
	<4CBC3D0A.2080506@univ-mlv.fr>
Message-ID: <FE4757A8-F99C-432E-918B-695CE9E55646@gmail.com>

On 18 Oct 2010, at 13:26, R??mi Forax <forax at univ-mlv.fr> wrote:

>  Hi Alex,
> I really hope that most of the lambdas can be implemented using method 
> handles.

Yes, I agree. 

> There are several advantages to use a method handle instead of a plain 
> old inner class
> to represent a lambda at runtime.

Yes, I agree. 

> Method handles are anonymous functions, there aren't bound to an object 
> by default,
> they are more like static methods.
> Trying to provide a 'this' that reference the current lambda is not 
> easily doable.

There is no difference between "this" and a recursive reference to the lambda as per the current proposal's example, though. The majority wouldn't be recursive so wouldn't need any capturing - and for when it is needed, could be captured as per the implementation suggested (unlike instance inner classes which capture it all the time). 

> Method handles are immutable by design and the only way to get the 
> current method handle
> in a method handle is to inject itself as argument,

That's an implementation issue, not language design. Why could the compiler not recognise the use of (lambda) this and provide it as an argument as you suggest?

> In my opinion, a lambda should be seen as an expression or an 
> instruction, not as an object.
> The SAM conversion will transform the lambda to an object.

This mechanism implies all recursive functions will be promoted to objects. When tail calls are added to the VM, not having a good way to do recursive calls with method handles without doing implicit SAM conversion will be potentially problematic. 

> That why 'this' refers to the enclosing object.
> 
> R??mi
> 
> Le 18/10/2010 10:37, Alex Blewitt a ??crit :
>> I think the change has just flipped the polarity of the changes; whereas before we had abnormal return and normal this, now we have abnormal this and normal return (or vice versa, if such is your preference). We have a crossover of the two concepts here which was present in the first release as well.
>> 
>> As I have said before, I think not binding 'this' to lambdas is a mistake. The DA/DU rules are being stretched, some would say to breaking point, to permit this convolution. Will the weakening of DA/DU cause problems elsewhere? It's certainly a possibility.
>> 
>> The argument of not referring to 'this' as the lambda uses a argument to say that a lambda that doesn't hold onto the enclosing class' instance will be more memory efficient than one that does (c.f. inner classes). However, whether the source code refers to 'this' is an orthogonal concept to whether the runtime representation refers to the instance of the enclosing class. For example, a (non-static) inner class has an implicit reference to the enclosing instance; it doesn't need to refer to 'this' in the body. Conversely, a static inner class may have 'this' injected into it, and thus maintain a reference.
>> 
>> So whilst the conclusion - that lambdas holding an instance to another object are a kind of leak - is valid, it has nothing to do with the type of 'this' captured in the scope of a lambda. A reference to 'this' could point to the current closure (without referring to the original instance in which it was valid) whilst Outer.this could refer to the original instance; unless Outer.this was used, it wouldn't be leaked away in the example described.
>> 
>> Finally: the rules for interpreting 'this' within inner classes are already well known. This is orthogonal to whether the runtime instance actually captures a reference if no 'this' is used, and the argument on this basis is fallacious. Whether there are other reasons for choosing this are not well defined.
>> 
>> Alex
>> 
>> On 18 Oct 2010, at 09:04, Peter Levart wrote:
>> 
>>> This is good news. In particular the 1st notable change below. This is a move in the right direction. I wonder if the reason for the cahnge was a result of desire to keep the door open for possible future extension to support "transparent" lambda or just of realization that lexical scoping has a better solution:problem ratio than annonymous inner classes style of scoping? In either case I think we are getting better lambda this way.
>>> I can also understand that the benefit of "yield" was not worth the additional confusion it might cause, although replacing it for "return" it is a step away from transparent lambda.
>>> 
>>> Regards, Peter
>>> 
>>> 
>>> On 10/15/10, Brian Goetz wrote:
>>>> An updated draft (Version 3) of the State of the Lambda has been published at:
>>>> 
>>>>   http://cr.openjdk.java.net/~briangoetz/lambda/lambda-state-3.html
>>>> 
>>>> Notable differences from the previous draft include:
>>>>  - 'this' in lambda expressions is lexically scoped
>>>>  - 'yield' keyword dropped in favor of 'return'
>>>>  - new syntax
>>>> 
>>>> Maurizio will be pushing an implementation conforming to this draft soon.
>>>> 
>>>> 
>>>> 
>> 
> 
> 

From forax at univ-mlv.fr  Mon Oct 18 06:37:36 2010
From: forax at univ-mlv.fr (=?GB2312?B?UqimbWkgRm9yYXg=?=)
Date: Mon, 18 Oct 2010 15:37:36 +0200
Subject: Updated State of the Lambda
In-Reply-To: <FE4757A8-F99C-432E-918B-695CE9E55646@gmail.com>
References: <4CB8B1AF.1090605@oracle.com>
	<201010181004.07597.peter.levart@marand.si>
	<99A37C22-540B-4474-9C10-3D5376339506@gmail.com>
	<4CBC3D0A.2080506@univ-mlv.fr>
	<FE4757A8-F99C-432E-918B-695CE9E55646@gmail.com>
Message-ID: <4CBC4DA0.1040501@univ-mlv.fr>

 Le 18/10/2010 15:06, Alex Blewitt a ??crit :
> On 18 Oct 2010, at 13:26, R??mi Forax <forax at univ-mlv.fr> wrote:
>
>> Hi Alex,
>> I really hope that most of the lambdas can be implemented using method
>> handles.
>
> Yes, I agree.
>
>> There are several advantages to use a method handle instead of a plain
>> old inner class
>> to represent a lambda at runtime.
>
> Yes, I agree.
>
>> Method handles are anonymous functions, there aren't bound to an object
>> by default,
>> they are more like static methods.
>> Trying to provide a 'this' that reference the current lambda is not
>> easily doable.
>
> There is no difference between "this" and a recursive reference to the
> lambda as per the current proposal's example, though. The majority
> wouldn't be recursive so wouldn't need any capturing - and for when it
> is needed, could be captured as per the implementation suggested
> (unlike instance inner classes which capture it all the time).

I don't think it's possible to implements lambda that use the DA/DU
trick using method handle.
If this kind of lambda is implemented using an inner class, there is no
problem.

>
>> Method handles are immutable by design and the only way to get the
>> current method handle
>> in a method handle is to inject itself as argument,
>
> That's an implementation issue, not language design.

It's an API design. if method handles are mutable you can't use them to
specify target of
invokedynamic without spurious NPE because you will be able to publish
the target even
if some field containing bound object or adapted method handles are not
yet initialized.

> Why could the compiler not recognise the use of (lambda) this and
> provide it as an argument as you suggest?

Because it's not the same object. If you mutate a method handle, you
create a new one
due to its immutable nature.

MethodHandle mh = #{ MethodHandle anotherMH -> mh == anotherMH };
mh.invokeGeneric(mh) // false

because, it's translated to:

static boolean lambda$1(MethodHandle mh, MethodHandle anotherMH) {
return mh == anotherMH;
}

MethodHandle mh = #lambda$1;
mh = mh.bindTo(mh);

mh.invokeGeneric(mh); // return mh == #lambda$1 => false


>> In my opinion, a lambda should be seen as an expression or an
>> instruction, not as an object.
>> The SAM conversion will transform the lambda to an object.
>
> This mechanism implies all recursive functions will be promoted to
> objects. 

Yes, as suggested by end of section 7, the only way to reference the
current lambda is
by a corresponding SAM object.

> When tail calls are added to the VM, not having a good way to do
> recursive calls with method handles without doing implicit SAM
> conversion will be potentially problematic.

I don't see your point here. You will do taillcall in the inner-class.
Where is the problem ?

>
>> That why 'this' refers to the enclosing object.
>>
>> R??mi

R??mi

From peter.levart at marand.si  Mon Oct 18 07:05:50 2010
From: peter.levart at marand.si (Peter Levart)
Date: Mon, 18 Oct 2010 16:05:50 +0200
Subject: Updated State of the Lambda
In-Reply-To: <4CBC4DA0.1040501@univ-mlv.fr>
References: <4CB8B1AF.1090605@oracle.com>
	<FE4757A8-F99C-432E-918B-695CE9E55646@gmail.com>
	<4CBC4DA0.1040501@univ-mlv.fr>
Message-ID: <201010181605.51153.peter.levart@marand.si>

On 10/18/10, R?mi Forax wrote:
> > Why could the compiler not recognise the use of (lambda) this and
> > provide it as an argument as you suggest?
> 
> Because it's not the same object. If you mutate a method handle, you
> create a new one
> due to its immutable nature.
> 

Ah, now I understand your concern. You would like lambda expressions to be convertible to method handles (java.dyn.MethodHandle) as well as to SAM types. 

> MethodHandle mh = #{ MethodHandle anotherMH -> mh == anotherMH };
> mh.invokeGeneric(mh) // false
> 
> because, it's translated to:
> 
> static boolean lambda$1(MethodHandle mh, MethodHandle anotherMH) {
> return mh == anotherMH;
> }
> 
> MethodHandle mh = #lambda$1;
> mh = mh.bindTo(mh);
> 
> mh.invokeGeneric(mh); // return mh == #lambda$1 => false

Why couldn't compiler translate it to:

static boolean lambda$1(MethodHandle anotherMH) {
  return #lambda$1 == anotherMH;
}
 
MethodHandle mh = #lambda$1;

mh.invokeGeneric(mh); // return #lambda$1 == #lambda$1 => true?


Peter

From maurizio.cimadamore at oracle.com  Mon Oct 18 07:14:26 2010
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Mon, 18 Oct 2010 15:14:26 +0100
Subject: Updated State of the Lambda
In-Reply-To: <201010181605.51153.peter.levart@marand.si>
References: <4CB8B1AF.1090605@oracle.com>	<FE4757A8-F99C-432E-918B-695CE9E55646@gmail.com>	<4CBC4DA0.1040501@univ-mlv.fr>
	<201010181605.51153.peter.levart@marand.si>
Message-ID: <4CBC5642.7040002@oracle.com>

On 18/10/10 15:05, Peter Levart wrote:
> On 10/18/10, R?mi Forax wrote:
>    
>>> Why could the compiler not recognise the use of (lambda) this and
>>> provide it as an argument as you suggest?
>>>        
>> Because it's not the same object. If you mutate a method handle, you
>> create a new one
>> due to its immutable nature.
>>
>>      
> Ah, now I understand your concern. You would like lambda expressions to be convertible to method handles (java.dyn.MethodHandle) as well as to SAM types.
>
>    
>> MethodHandle mh = #{ MethodHandle anotherMH ->  mh == anotherMH };
>> mh.invokeGeneric(mh) // false
>>
>> because, it's translated to:
>>
>> static boolean lambda$1(MethodHandle mh, MethodHandle anotherMH) {
>> return mh == anotherMH;
>> }
>>
>> MethodHandle mh = #lambda$1;
>> mh = mh.bindTo(mh);
>>
>> mh.invokeGeneric(mh); // return mh == #lambda$1 =>  false
>>      
> Why couldn't compiler translate it to:
>
> static boolean lambda$1(MethodHandle anotherMH) {
>    return #lambda$1 == anotherMH;
> }
>
> MethodHandle mh = #lambda$1;
>
> mh.invokeGeneric(mh); // return #lambda$1 == #lambda$1 =>  true?
>    
Hi Peter,
note that the bindTo/insertArgs solution avoids the problem that one or 
more 'synthetic' arguments could not be available anymore when the 
lambda expression is called (i.e. when the Sam type escapes its creation 
context). You really want clients to just specify the arguments required 
by the SAM method, regardless of any other synthetic arg that the 
compiler might have inserted in the translated code.

Maurizio
>
> Peter
>
>    


From peter.levart at marand.si  Mon Oct 18 07:22:49 2010
From: peter.levart at marand.si (Peter Levart)
Date: Mon, 18 Oct 2010 16:22:49 +0200
Subject: Updated State of the Lambda
In-Reply-To: <4CBC5642.7040002@oracle.com>
References: <4CB8B1AF.1090605@oracle.com>
	<201010181605.51153.peter.levart@marand.si>
	<4CBC5642.7040002@oracle.com>
Message-ID: <201010181622.49943.peter.levart@marand.si>

On 10/18/10, Maurizio Cimadamore wrote:
> On 18/10/10 15:05, Peter Levart wrote:
> > On 10/18/10, R?mi Forax wrote:
> >    
> >>> Why could the compiler not recognise the use of (lambda) this and
> >>> provide it as an argument as you suggest?
> >>>        
> >> Because it's not the same object. If you mutate a method handle, you
> >> create a new one
> >> due to its immutable nature.
> >>
> >>      
> > Ah, now I understand your concern. You would like lambda expressions to be convertible to method handles (java.dyn.MethodHandle) as well as to SAM types.
> >
> >    
> >> MethodHandle mh = #{ MethodHandle anotherMH ->  mh == anotherMH };
> >> mh.invokeGeneric(mh) // false
> >>
> >> because, it's translated to:
> >>
> >> static boolean lambda$1(MethodHandle mh, MethodHandle anotherMH) {
> >> return mh == anotherMH;
> >> }
> >>
> >> MethodHandle mh = #lambda$1;
> >> mh = mh.bindTo(mh);
> >>
> >> mh.invokeGeneric(mh); // return mh == #lambda$1 =>  false
> >>      
> > Why couldn't compiler translate it to:
> >
> > static boolean lambda$1(MethodHandle anotherMH) {
> >    return #lambda$1 == anotherMH;
> > }
> >
> > MethodHandle mh = #lambda$1;
> >
> > mh.invokeGeneric(mh); // return #lambda$1 == #lambda$1 =>  true?
> >    
> Hi Peter,
> note that the bindTo/insertArgs solution avoids the problem that one or 
> more 'synthetic' arguments could not be available anymore when the 
> lambda expression is called (i.e. when the Sam type escapes its creation 
> context). You really want clients to just specify the arguments required 
> by the SAM method, regardless of any other synthetic arg that the 
> compiler might have inserted in the translated code.
> 
> Maurizio

I'm not suggesting to stop specifying other synthetic arguments via bindTo/insertArgs. Just the "this" Method handle argument (not called 'this' anymore) which can always be re-constructed inside the lambda method. I don't think it is possible to re-construct the same MethoHandle (by reference), but I think it's possible to reconstruct the equivalent one.

Peter

> >
> > Peter
> >
> >    
> 
> 

From forax at univ-mlv.fr  Mon Oct 18 07:23:09 2010
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Mon, 18 Oct 2010 16:23:09 +0200
Subject: Updated State of the Lambda
In-Reply-To: <4CBC5642.7040002@oracle.com>
References: <4CB8B1AF.1090605@oracle.com>	<FE4757A8-F99C-432E-918B-695CE9E55646@gmail.com>	<4CBC4DA0.1040501@univ-mlv.fr>	<201010181605.51153.peter.levart@marand.si>
	<4CBC5642.7040002@oracle.com>
Message-ID: <4CBC584D.6070807@univ-mlv.fr>

  Le 18/10/2010 16:14, Maurizio Cimadamore a ?crit :
> On 18/10/10 15:05, Peter Levart wrote:
>> On 10/18/10, R?mi Forax wrote:
>>
>>>> Why could the compiler not recognise the use of (lambda) this and
>>>> provide it as an argument as you suggest?
>>>>
>>> Because it's not the same object. If you mutate a method handle, you
>>> create a new one
>>> due to its immutable nature.
>>>
>>>
>> Ah, now I understand your concern. You would like lambda expressions to be convertible to method handles (java.dyn.MethodHandle) as well as to SAM types.
>>
>>
>>> MethodHandle mh = #{ MethodHandle anotherMH ->   mh == anotherMH };
>>> mh.invokeGeneric(mh) // false
>>>
>>> because, it's translated to:
>>>
>>> static boolean lambda$1(MethodHandle mh, MethodHandle anotherMH) {
>>> return mh == anotherMH;
>>> }
>>>
>>> MethodHandle mh = #lambda$1;
>>> mh = mh.bindTo(mh);
>>>
>>> mh.invokeGeneric(mh); // return mh == #lambda$1 =>   false
>>>
>> Why couldn't compiler translate it to:
>>
>> static boolean lambda$1(MethodHandle anotherMH) {
>>     return #lambda$1 == anotherMH;
>> }
>>
>> MethodHandle mh = #lambda$1;
>>
>> mh.invokeGeneric(mh); // return #lambda$1 == #lambda$1 =>   true?
>>
> Hi Peter,
> note that the bindTo/insertArgs solution avoids the problem that one or
> more 'synthetic' arguments could not be available anymore when the
> lambda expression is called (i.e. when the Sam type escapes its creation
> context). You really want clients to just specify the arguments required
> by the SAM method, regardless of any other synthetic arg that the
> compiler might have inserted in the translated code.
>
> Maurizio

As Maurizio said, it doesn't work if the lambda capture variable 
contents from outer scope.

>> Peter

R?mi

From forax at univ-mlv.fr  Mon Oct 18 07:27:50 2010
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Mon, 18 Oct 2010 16:27:50 +0200
Subject: Updated State of the Lambda
In-Reply-To: <201010181622.49943.peter.levart@marand.si>
References: <4CB8B1AF.1090605@oracle.com>	<201010181605.51153.peter.levart@marand.si>	<4CBC5642.7040002@oracle.com>
	<201010181622.49943.peter.levart@marand.si>
Message-ID: <4CBC5966.7070204@univ-mlv.fr>

  Le 18/10/2010 16:22, Peter Levart a ?crit :
> On 10/18/10, Maurizio Cimadamore wrote:
>> On 18/10/10 15:05, Peter Levart wrote:
>>> On 10/18/10, R?mi Forax wrote:
>>>
>>>>> Why could the compiler not recognise the use of (lambda) this and
>>>>> provide it as an argument as you suggest?
>>>>>
>>>> Because it's not the same object. If you mutate a method handle, you
>>>> create a new one
>>>> due to its immutable nature.
>>>>
>>>>
>>> Ah, now I understand your concern. You would like lambda expressions to be convertible to method handles (java.dyn.MethodHandle) as well as to SAM types.
>>>
>>>
>>>> MethodHandle mh = #{ MethodHandle anotherMH ->   mh == anotherMH };
>>>> mh.invokeGeneric(mh) // false
>>>>
>>>> because, it's translated to:
>>>>
>>>> static boolean lambda$1(MethodHandle mh, MethodHandle anotherMH) {
>>>> return mh == anotherMH;
>>>> }
>>>>
>>>> MethodHandle mh = #lambda$1;
>>>> mh = mh.bindTo(mh);
>>>>
>>>> mh.invokeGeneric(mh); // return mh == #lambda$1 =>   false
>>>>
>>> Why couldn't compiler translate it to:
>>>
>>> static boolean lambda$1(MethodHandle anotherMH) {
>>>     return #lambda$1 == anotherMH;
>>> }
>>>
>>> MethodHandle mh = #lambda$1;
>>>
>>> mh.invokeGeneric(mh); // return #lambda$1 == #lambda$1 =>   true?
>>>
>> Hi Peter,
>> note that the bindTo/insertArgs solution avoids the problem that one or
>> more 'synthetic' arguments could not be available anymore when the
>> lambda expression is called (i.e. when the Sam type escapes its creation
>> context). You really want clients to just specify the arguments required
>> by the SAM method, regardless of any other synthetic arg that the
>> compiler might have inserted in the translated code.
>>
>> Maurizio
> I'm not suggesting to stop specifying other synthetic arguments via bindTo/insertArgs. Just the "this" Method handle argument (not called 'this' anymore) which can always be re-constructed inside the lambda method. I don't think it is possible to re-construct the same MethoHandle (by reference), but I think it's possible to reconstruct the equivalent one.
>
> Peter

The reconstructed method handle could have a different identity or not
depending on the implementation of the JSR 292 spec.

>>> Peter
>>>
>>>

R?mi


From peter.levart at marand.si  Mon Oct 18 07:41:59 2010
From: peter.levart at marand.si (Peter Levart)
Date: Mon, 18 Oct 2010 16:41:59 +0200
Subject: Updated State of the Lambda
In-Reply-To: <4CBC5966.7070204@univ-mlv.fr>
References: <4CB8B1AF.1090605@oracle.com>
	<201010181622.49943.peter.levart@marand.si>
	<4CBC5966.7070204@univ-mlv.fr>
Message-ID: <201010181641.59781.peter.levart@marand.si>

On 10/18/10, R?mi Forax wrote:
>   Le 18/10/2010 16:22, Peter Levart a ?crit :
> > On 10/18/10, Maurizio Cimadamore wrote:
> >> On 18/10/10 15:05, Peter Levart wrote:
> >>> On 10/18/10, R?mi Forax wrote:
> >>>
> >>>>> Why could the compiler not recognise the use of (lambda) this and
> >>>>> provide it as an argument as you suggest?
> >>>>>
> >>>> Because it's not the same object. If you mutate a method handle, you
> >>>> create a new one
> >>>> due to its immutable nature.
> >>>>
> >>>>
> >>> Ah, now I understand your concern. You would like lambda expressions to be convertible to method handles (java.dyn.MethodHandle) as well as to SAM types.
> >>>
> >>>
> >>>> MethodHandle mh = #{ MethodHandle anotherMH ->   mh == anotherMH };
> >>>> mh.invokeGeneric(mh) // false
> >>>>
> >>>> because, it's translated to:
> >>>>
> >>>> static boolean lambda$1(MethodHandle mh, MethodHandle anotherMH) {
> >>>> return mh == anotherMH;
> >>>> }
> >>>>
> >>>> MethodHandle mh = #lambda$1;
> >>>> mh = mh.bindTo(mh);
> >>>>
> >>>> mh.invokeGeneric(mh); // return mh == #lambda$1 =>   false
> >>>>
> >>> Why couldn't compiler translate it to:
> >>>
> >>> static boolean lambda$1(MethodHandle anotherMH) {
> >>>     return #lambda$1 == anotherMH;
> >>> }
> >>>
> >>> MethodHandle mh = #lambda$1;
> >>>
> >>> mh.invokeGeneric(mh); // return #lambda$1 == #lambda$1 =>   true?
> >>>
> >> Hi Peter,
> >> note that the bindTo/insertArgs solution avoids the problem that one or
> >> more 'synthetic' arguments could not be available anymore when the
> >> lambda expression is called (i.e. when the Sam type escapes its creation
> >> context). You really want clients to just specify the arguments required
> >> by the SAM method, regardless of any other synthetic arg that the
> >> compiler might have inserted in the translated code.
> >>
> >> Maurizio
> > I'm not suggesting to stop specifying other synthetic arguments via bindTo/insertArgs. Just the "this" Method handle argument (not called 'this' anymore) which can always be re-constructed inside the lambda method. I don't think it is possible to re-construct the same MethoHandle (by reference), but I think it's possible to reconstruct the equivalent one.
> >
> > Peter
> 
> The reconstructed method handle could have a different identity or not
> depending on the implementation of the JSR 292 spec.

That's right. But does it matter? Aren't method handles primarily meant to be invoked? And as far as the invoking is concerned, the two method handles could be indistinguishable. Method handles are immutable, so they don't suffer from problems of SAM classes. It's like having new Integer(1) vs. new Integer(1);

Peter

> 
> >>> Peter
> >>>
> >>>
> 
> R?mi
> 
> 
> 

From peter.levart at marand.si  Mon Oct 18 07:46:00 2010
From: peter.levart at marand.si (Peter Levart)
Date: Mon, 18 Oct 2010 16:46:00 +0200
Subject: Updated State of the Lambda
In-Reply-To: <4CBC584D.6070807@univ-mlv.fr>
References: <4CB8B1AF.1090605@oracle.com> <4CBC5642.7040002@oracle.com>
	<4CBC584D.6070807@univ-mlv.fr>
Message-ID: <201010181646.01156.peter.levart@marand.si>

On 10/18/10, R?mi Forax wrote:
>   Le 18/10/2010 16:14, Maurizio Cimadamore a ?crit :
> > On 18/10/10 15:05, Peter Levart wrote:
> >> On 10/18/10, R?mi Forax wrote:
> >>
> >>>> Why could the compiler not recognise the use of (lambda) this and
> >>>> provide it as an argument as you suggest?
> >>>>
> >>> Because it's not the same object. If you mutate a method handle, you
> >>> create a new one
> >>> due to its immutable nature.
> >>>
> >>>
> >> Ah, now I understand your concern. You would like lambda expressions to be convertible to method handles (java.dyn.MethodHandle) as well as to SAM types.
> >>
> >>
> >>> MethodHandle mh = #{ MethodHandle anotherMH ->   mh == anotherMH };
> >>> mh.invokeGeneric(mh) // false
> >>>
> >>> because, it's translated to:
> >>>
> >>> static boolean lambda$1(MethodHandle mh, MethodHandle anotherMH) {
> >>> return mh == anotherMH;
> >>> }
> >>>
> >>> MethodHandle mh = #lambda$1;
> >>> mh = mh.bindTo(mh);
> >>>
> >>> mh.invokeGeneric(mh); // return mh == #lambda$1 =>   false
> >>>
> >> Why couldn't compiler translate it to:
> >>
> >> static boolean lambda$1(MethodHandle anotherMH) {
> >>     return #lambda$1 == anotherMH;
> >> }
> >>
> >> MethodHandle mh = #lambda$1;
> >>
> >> mh.invokeGeneric(mh); // return #lambda$1 == #lambda$1 =>   true?
> >>
> > Hi Peter,
> > note that the bindTo/insertArgs solution avoids the problem that one or
> > more 'synthetic' arguments could not be available anymore when the
> > lambda expression is called (i.e. when the Sam type escapes its creation
> > context). You really want clients to just specify the arguments required
> > by the SAM method, regardless of any other synthetic arg that the
> > compiler might have inserted in the translated code.
> >
> > Maurizio
> 
> As Maurizio said, it doesn't work if the lambda capture variable 
> contents from outer scope.

Why not. Example:

final String s = "abc";
final MethodHandle mh = #{ String str -> str.startsWith(s) || !str.isEmpty() && mh.invokeGeneric(str.substring(1)) };

Could be translated to:

static boolean lambda$2(String _s, String str) {
  MethodHandle _mh = (#lambda$2).bindTo(_s);
  return str.startsWith(_s) || !str.isEmpty() && _mh.invokeGeneric(str.substring(1));
}
...
final String s = "abc";
final MethodHandle mh = (#lambda$2).bindTo(s);


Peter

> 
> >> Peter
> 
> R?mi
> 
> 

From peter.levart at marand.si  Mon Oct 18 08:04:07 2010
From: peter.levart at marand.si (Peter Levart)
Date: Mon, 18 Oct 2010 17:04:07 +0200
Subject: Updated State of the Lambda
In-Reply-To: <4CBC4DA0.1040501@univ-mlv.fr>
References: <4CB8B1AF.1090605@oracle.com>
	<FE4757A8-F99C-432E-918B-695CE9E55646@gmail.com>
	<4CBC4DA0.1040501@univ-mlv.fr>
Message-ID: <201010181704.07331.peter.levart@marand.si>

On 10/18/10, R?mi Forax wrote:
> > Why could the compiler not recognise the use of (lambda) this and
> > provide it as an argument as you suggest?
> 
> Because it's not the same object. If you mutate a method handle, you
> create a new one
> due to its immutable nature.
> 
> MethodHandle mh = #{ MethodHandle anotherMH -> mh == anotherMH };
> mh.invokeGeneric(mh) // false
> 
> because, it's translated to:
> 
> static boolean lambda$1(MethodHandle mh, MethodHandle anotherMH) {
> return mh == anotherMH;
> }
> 
> MethodHandle mh = #lambda$1;
> mh = mh.bindTo(mh);
> 
> mh.invokeGeneric(mh); // return mh == #lambda$1 => false
> 

If the identity of MethodHandle matters, another trick could be:

static boolean lambda$1(MethodHandle[] mh, MethodHandle anotherMH) {
  return mh[0] == anotherMH;
}

MethodHandle mh = #lambda$1;
MethodHandle[] temp$1 = new MethodHandle[1];
mh = mh.bindTo(temp$1);
temp$1[0] = mh;

mh.invokeGeneric(mh); // return mh == #lambda$1 => true


...for the price of another object on the heap.


Peter


From brian.goetz at oracle.com  Mon Oct 18 08:29:38 2010
From: brian.goetz at oracle.com (Brian Goetz)
Date: Mon, 18 Oct 2010 08:29:38 -0700
Subject: Updated State of the Lambda
In-Reply-To: <201010181004.07597.peter.levart@marand.si>
References: <4CB8B1AF.1090605@oracle.com>
	<201010181004.07597.peter.levart@marand.si>
Message-ID: <ABB4C621-6B1F-4561-AC44-F287B44DEF5D@oracle.com>

More the latter.  Some of the ancillary benefits include: removing identity opens up opportunities for VM optimization; nailing down the type of 'this' greatly simplifies type inference.  And lambdas that need to refer to themselves are, in practice, a corner case.  It is a shame that we created an inconsistency (lambdas behave differently from inner classes) but in the end we felt the new semantics were so far preferable that it was worth doing something different.  

On Oct 18, 2010, at 1:04 AM, Peter Levart wrote:

> This is good news. In particular the 1st notable change below. This is a move in the right direction. I wonder if the reason for the cahnge was a result of desire to keep the door open for possible future extension to support "transparent" lambda or just of realization that lexical scoping has a better solution:problem ratio than annonymous inner classes style of scoping? In either case I think we are getting better lambda this way.
> I can also understand that the benefit of "yield" was not worth the additional confusion it might cause, although replacing it for "return" it is a step away from transparent lambda.
> 
> Regards, Peter
> 
> 
> On 10/15/10, Brian Goetz wrote:
>> An updated draft (Version 3) of the State of the Lambda has been published at:
>> 
>>   http://cr.openjdk.java.net/~briangoetz/lambda/lambda-state-3.html
>> 
>> Notable differences from the previous draft include:
>>  - 'this' in lambda expressions is lexically scoped
>>  - 'yield' keyword dropped in favor of 'return'
>>  - new syntax
>> 
>> Maurizio will be pushing an implementation conforming to this draft soon.
>> 
>> 
>> 


From maurizio.cimadamore at oracle.com  Mon Oct 18 09:34:29 2010
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Mon, 18 Oct 2010 16:34:29 +0000
Subject: hg: lambda/lambda/langtools: Updated prototype in order to reflect
	latest changes in 'State of the Lambda document'
Message-ID: <20101018163435.AB04C4723B@hg.openjdk.java.net>

Changeset: 13e106a36674
Author:    mcimadamore
Date:      2010-10-18 17:21 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/13e106a36674

Updated prototype in order to reflect latest changes in 'State of the Lambda document'

Summary of changes:
*) new syntax ( a lambda is now introduced using #{ comma-separated-args -> body }, as in # { x -> print(x); } )
*)'this' in lambda expressions is lexically scoped
*) updated DA/DU rules to allow lambda expression to recursively refer to itself (via SAM ref)

! src/share/classes/com/sun/source/tree/LambdaExpressionTree.java
! src/share/classes/com/sun/tools/javac/comp/Attr.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/Resolve.java
! src/share/classes/com/sun/tools/javac/comp/Unlambda.java
! src/share/classes/com/sun/tools/javac/parser/JavacParser.java
! src/share/classes/com/sun/tools/javac/parser/Token.java
! src/share/classes/com/sun/tools/javac/tree/JCTree.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
! test/tools/javac/defender/Pos01.java
! test/tools/javac/lambda/BadLambdaPos.java
! test/tools/javac/lambda/BadLambdaPos.out
! test/tools/javac/lambda/BadTargetType.java
! test/tools/javac/lambda/ExceptionTransparency01.java
! test/tools/javac/lambda/ExceptionTransparency03.java
! test/tools/javac/lambda/LambdaCapture01.java
! test/tools/javac/lambda/LambdaCapture02.java
! test/tools/javac/lambda/LambdaCapture03.java
! test/tools/javac/lambda/LambdaCapture04.java
! test/tools/javac/lambda/LambdaCapture05.java
! test/tools/javac/lambda/LambdaConv01.java
! test/tools/javac/lambda/LambdaConv02.java
! test/tools/javac/lambda/LambdaConv03.java
! test/tools/javac/lambda/LambdaConv05.java
! test/tools/javac/lambda/LambdaConv06.java
! test/tools/javac/lambda/LambdaConv07.java
! test/tools/javac/lambda/LambdaConv08.java
! test/tools/javac/lambda/LambdaConv09.java
! test/tools/javac/lambda/LambdaConv10.java
! test/tools/javac/lambda/LambdaConversionTest.java
! test/tools/javac/lambda/LambdaExpr01.java
! test/tools/javac/lambda/LambdaExpr02.java
! test/tools/javac/lambda/LambdaExpr04.java
! test/tools/javac/lambda/LambdaExpr05.java
! test/tools/javac/lambda/LambdaExprNotVoid.java
! test/tools/javac/lambda/LambdaExprNotVoid.out
! test/tools/javac/lambda/LambdaScope01.java
! test/tools/javac/lambda/LambdaScope02.java
! test/tools/javac/lambda/MethodReference07.java
! test/tools/javac/lambda/MethodReference12.java
! test/tools/javac/lambda/NakedThis.java
! test/tools/javac/lambda/TargetType01.java
! test/tools/javac/lambda/TargetType01.out
! test/tools/javac/lambda/TargetType02.java
! test/tools/javac/lambda/TargetType03.java
! test/tools/javac/lambda/TargetType04.java
! test/tools/javac/lambda/TargetType04.out
! test/tools/javac/lambda/TargetType05.java
! test/tools/javac/lambda/TargetType06.java
! test/tools/javac/lambda/TargetType07.java
! test/tools/javac/lambda/TargetType08.java
! test/tools/javac/lambda/TargetType10.java
! test/tools/javac/lambda/TargetType11.java
! test/tools/javac/lambda/TargetType12.java
! test/tools/javac/lambda/TargetType13.java


From reinier at zwitserloot.com  Mon Oct 18 11:46:23 2010
From: reinier at zwitserloot.com (Reinier Zwitserloot)
Date: Mon, 18 Oct 2010 20:46:23 +0200
Subject: Updated State of the Lambda
In-Reply-To: <ABB4C621-6B1F-4561-AC44-F287B44DEF5D@oracle.com>
References: <4CB8B1AF.1090605@oracle.com>
	<201010181004.07597.peter.levart@marand.si>
	<ABB4C621-6B1F-4561-AC44-F287B44DEF5D@oracle.com>
Message-ID: <AANLkTimRhtgH=uVozfJEku=Hfz4oC7XUpyLUOpEEkR8y@mail.gmail.com>

Entirely separate from the discussion around implementation details, having
"this" refer to the outer class is something that makes far more sense (and
has been claimed, repeatedly, as the preferred option for _any_ lambdas,
going all the way back to the inception of this mailing list). I'm sure
opinions are divided on the issue, but from my (possibly biased, as I prefer
this new state) experience, there are more that like outer this vs. inner
this. Popular opinion doesn't have to be right, of course. Still, combine it
with the implementation reasons for going with outer this, and the burden of
proof would appear to be on the inner this camp.

I myself have been asking for 'this = refers to outer' by default because it
makes more sense when writing lambdas: They don't look like classes anymore,
and, I rate the number of times I need Outer.this at about 15 to 50 times
more often than I need Inner.this. I'm expecting the vast majority of SAM
types to be interfaces, and in such a scenario there is absolutely no reason
for an inner this reference except for recursion and recursion-like
practices. I'm speaking specifically of using "this" as an object reference,
and not the "this.x" syntax to clarify which field / method you're referring
to. Those are scoped in reverse (If the SAM type has a field named "foo" and
the outer also does, then an unqualified "foo" reference will refer to the
SAM type's). Therefore, using Outer.this syntax will not be necessary; its
only for clarification: "x" refers to lambda's x, and "this.x" refers to
outer's X. You'd only need it when writing a lambda that is itself in an
inner class.

I don't agree this latest state is inconsistent: This latest state simply
does not attempt to paint a lambda as syntax sugar for anonymous inner class
literals. The previous state also didn't, but that one WAS inconsistent
because 'this' referred to the inner instance. Whether "return" or "yield"
is used is immaterial, other than the idea that using "yield" makes the case
that lambdas aren't syntax sugar for AICs even stronger. It wasn't the only
reason lambdas aren't AICs, though (Re: Alex Blewitt).

NB: I'd like to echo Stephen Colebourne's request for a timeboxed syntax
discussion window, to be held when all issues of structure and
implementation have been sorted out.



 --Reinier Zwitserloot



On Mon, Oct 18, 2010 at 5:29 PM, Brian Goetz <brian.goetz at oracle.com> wrote:

> More the latter.  Some of the ancillary benefits include: removing identity
> opens up opportunities for VM optimization; nailing down the type of 'this'
> greatly simplifies type inference.  And lambdas that need to refer to
> themselves are, in practice, a corner case.  It is a shame that we created
> an inconsistency (lambdas behave differently from inner classes) but in the
> end we felt the new semantics were so far preferable that it was worth doing
> something different.
>
> On Oct 18, 2010, at 1:04 AM, Peter Levart wrote:
>
> > This is good news. In particular the 1st notable change below. This is a
> move in the right direction. I wonder if the reason for the cahnge was a
> result of desire to keep the door open for possible future extension to
> support "transparent" lambda or just of realization that lexical scoping has
> a better solution:problem ratio than annonymous inner classes style of
> scoping? In either case I think we are getting better lambda this way.
> > I can also understand that the benefit of "yield" was not worth the
> additional confusion it might cause, although replacing it for "return" it
> is a step away from transparent lambda.
> >
> > Regards, Peter
> >
> >
> > On 10/15/10, Brian Goetz wrote:
> >> An updated draft (Version 3) of the State of the Lambda has been
> published at:
> >>
> >>   http://cr.openjdk.java.net/~briangoetz/lambda/lambda-state-3.html
> >>
> >> Notable differences from the previous draft include:
> >>  - 'this' in lambda expressions is lexically scoped
> >>  - 'yield' keyword dropped in favor of 'return'
> >>  - new syntax
> >>
> >> Maurizio will be pushing an implementation conforming to this draft
> soon.
> >>
> >>
> >>
>
>
>

From howard.lovatt at gmail.com  Mon Oct 18 19:39:24 2010
From: howard.lovatt at gmail.com (Howard Lovatt)
Date: Tue, 19 Oct 2010 13:39:24 +1100
Subject: Updated State of the Lambda
Message-ID: <AANLkTikuDdqR5fbQcKejKR_dX=oqYFVJvd__Puvpd7sU@mail.gmail.com>

Glad to see the progress on Lambdas and the implementation - I will
try out the latest push when I get chance.

I have some reservations about changing the type of this, particularly
that it will make refactoring from Inner Classes to Lambdas and vice
versa error prone. May I suggest a further couple of changes that
might make refactoring more reliable:

1. SAM types can only be interfaces (you must use an inner class if
you want to inherit from and abstract class or class).
2. The specification defines what all Object's methods do for a
Lambda, in particular getClass, toString, equals, and hashCode, and
how instanceof behaves, is a Lambda an instance of MethodHandle is it
an instance of its SAM type?

Even with the above changes I can see confusion because of the
different meanings of this - therefore I have some reservations.

? -- Howard.

From howard.lovatt at gmail.com  Mon Oct 18 19:39:24 2010
From: howard.lovatt at gmail.com (Howard Lovatt)
Date: Tue, 19 Oct 2010 13:39:24 +1100
Subject: Updated State of the Lambda
Message-ID: <AANLkTikuDdqR5fbQcKejKR_dX=oqYFVJvd__Puvpd7sU@mail.gmail.com>

Glad to see the progress on Lambdas and the implementation - I will
try out the latest push when I get chance.

I have some reservations about changing the type of this, particularly
that it will make refactoring from Inner Classes to Lambdas and vice
versa error prone. May I suggest a further couple of changes that
might make refactoring more reliable:

1. SAM types can only be interfaces (you must use an inner class if
you want to inherit from and abstract class or class).
2. The specification defines what all Object's methods do for a
Lambda, in particular getClass, toString, equals, and hashCode, and
how instanceof behaves, is a Lambda an instance of MethodHandle is it
an instance of its SAM type?

Even with the above changes I can see confusion because of the
different meanings of this - therefore I have some reservations.

? -- Howard.

From t.muenz at xdev-software.de  Mon Oct 18 23:11:58 2010
From: t.muenz at xdev-software.de (=?iso-8859-1?Q?Thomas_M=FCnz=2C_XDEV_Software_Corp=2E?=)
Date: Tue, 19 Oct 2010 06:11:58 +0000
Subject: About the "arrowling" syntax
Message-ID: <DIIE.0000095B0000A6D9@smtp.1und1.de>

---------
Sorry I messed up a little by first posting and then registering to the list. After 24h, I'm not sure if/when the first mail will be approved by an administrator, so I send it again. My apologies if this causes a double post eventually.
---------

Hello!

I'm following this list since the beginning but never wrote so far as I don't have much insight in design of language, compiler, VM, etc. (Compiler lectures only scratched the surface back then...)

Now after seeing the draft syntax changed from #(){} to #{->}, I dare to write and deliver some arguments to the formerly pretty controversially received statement that the "->" syntax does not "feel like Java" (which I second).
I know everyone says "we talk about syntax later" and I gladly catch some reprimand for bringing it up once again now ;), still I think it's good timing to intermediately post some thoughts on the issue (and maybe link to it later) that haven't been brought up before, if I'm not mistaken.


A)
In Java Syntax, the let me call it "optical information flow" always goes from right to left
for example:
int doStuff(int i);
int a = 5;

When reading Java source code, one always implicitely reads it as "some input value starts at the right and the result is passed to the left".

When I first read examples for closures (in 2009 or so) like
#{ int x -> x + 1 }
I had to study the short snippets for minutes (really minutes, not seconds) to figure out what they are supposed to mean.
There are two major problems: one is that all of a sudden, the syntax implies a left to right information flow even though it actually works like calling a method and is supposed to eventually pass the result to the left. The other is that what somehow appears to should have to be something like a parameter is visually INSIDE the code block like a local variable instead of before the block in brackets like parameters are.

This structure-breaking dual-reversal of long time constant Java syntax characteristics is very confusing when reading source code and is not only a matter of "just not being used to it yet".


B)
The "arrow operator" itself creates a misleading intuitive impression. The primary association with "->" is "go to" or "goes to".
here -> there
ball -> goal
man -> moon

A good example from mathematics is limes: lim(x -> 0)
"Limes: for x (goes) to 0 ..."

A nice example in programming where this impression is fitting and actually helps reading source code is:
int i = 10;
while(i --> 0){...}
The impression when reading is: "while i goes to 0, do ..."

Quite intuitive as well is the use as a hashmap association:
"blue" -> new color(0,0,255)
Impression: "key "blue" goes to value color blue".


But for Lambdas?
A simple case like
#{ int x -> x + 1 }
might still be somewhat understandable, "x goes to x plus 1". Problem already here is that this implies that the variable x itself is incremented instead of implying "return x+1".

But what about only a little more complex examples like
#{ c -> System.out.println("pippo") };
?
"c goes to print "pippo"". Immediate thought is: "What the?! Can variable c become a print call execution?"

Or
#{ e -> sum += e.size(); }
"e goes to sum add e's size". Impression: "Huh?! Can e become an addition operation? Really?"


Again, look at the comparable math example: f(x) = x+1
"f of x is x plus 1". A much more intuitive impression than f(x -> x+1) could ever be.



C)
All calls of program code in Java have one inherent, consistent, clarifying signal syntax: the "()". Whenever there are "()" after an identifier, either empty or with values passed in it, you know that some code represented by this identifier is called.
The "->" syntax breaks that as well.
The form "#(...){...}" would perfectly fit into the way Java syntax is structured so far. The "{}" signal (only!) the block, the "()" signal that it's callable code and the parameters used. And as a new feature, everyone can quickly understand that because lambdas are some kind of "anonymous code snippets", there is no identifier but instead the "#" before the "()". (and btw: notice the similarity to the clear and well-known mathematical syntax)
The form "#{... -> ...}", on the other hand, causes massive confusion, implying something like "this is some random uncallable code (or is it a hashmap association?) with no parameters that applies some new operation "->" from one part of the code inside the block to the other". Say what? o_0


I hope this explains what (as I understand it) is meant with "it does not feel like Java" and objectively shows why this syntax is so painful to read for many (ordinary ;)) Java developers (like me).

Personally, I strongly appeal to whoever makes the syntax sugar decision to not choose the structure-breaking and very confusing #{...->...} "arrowling" syntax (sounds only half as funny after translating the german word "Pfeilchen" into english :( ) but to choose the perfectly conforming syntax #(...){...} instead.


Thank you for reading



From reinier at zwitserloot.com  Mon Oct 18 23:34:51 2010
From: reinier at zwitserloot.com (Reinier Zwitserloot)
Date: Tue, 19 Oct 2010 08:34:51 +0200
Subject: About the "arrowling" syntax
In-Reply-To: <DIIE.0000095B0000A6D9@smtp.1und1.de>
References: <DIIE.0000095B0000A6D9@smtp.1und1.de>
Message-ID: <AANLkTi=4q8ZGz6kTv_pOAjKxuswgUr_i_ViiAi6i8NuS@mail.gmail.com>

Discussions about syntactic concerns are preferably held later.

 --Reinier Zwitserloot



On Tue, Oct 19, 2010 at 8:11 AM, Thomas M?nz, XDEV Software Corp. <
t.muenz at xdev-software.de> wrote:

> ---------
> Sorry I messed up a little by first posting and then registering to the
> list. After 24h, I'm not sure if/when the first mail will be approved by an
> administrator, so I send it again. My apologies if this causes a double post
> eventually.
> ---------
>
> Hello!
>
> I'm following this list since the beginning but never wrote so far as I
> don't have much insight in design of language, compiler, VM, etc. (Compiler
> lectures only scratched the surface back then...)
>
> Now after seeing the draft syntax changed from #(){} to #{->}, I dare to
> write and deliver some arguments to the formerly pretty controversially
> received statement that the "->" syntax does not "feel like Java" (which I
> second).
> I know everyone says "we talk about syntax later" and I gladly catch some
> reprimand for bringing it up once again now ;), still I think it's good
> timing to intermediately post some thoughts on the issue (and maybe link to
> it later) that haven't been brought up before, if I'm not mistaken.
>
>
> A)
> In Java Syntax, the let me call it "optical information flow" always goes
> from right to left
> for example:
> int doStuff(int i);
> int a = 5;
>
> When reading Java source code, one always implicitely reads it as "some
> input value starts at the right and the result is passed to the left".
>
> When I first read examples for closures (in 2009 or so) like
> #{ int x -> x + 1 }
> I had to study the short snippets for minutes (really minutes, not seconds)
> to figure out what they are supposed to mean.
> There are two major problems: one is that all of a sudden, the syntax
> implies a left to right information flow even though it actually works like
> calling a method and is supposed to eventually pass the result to the left.
> The other is that what somehow appears to should have to be something like a
> parameter is visually INSIDE the code block like a local variable instead of
> before the block in brackets like parameters are.
>
> This structure-breaking dual-reversal of long time constant Java syntax
> characteristics is very confusing when reading source code and is not only a
> matter of "just not being used to it yet".
>
>
> B)
> The "arrow operator" itself creates a misleading intuitive impression. The
> primary association with "->" is "go to" or "goes to".
> here -> there
> ball -> goal
> man -> moon
>
> A good example from mathematics is limes: lim(x -> 0)
> "Limes: for x (goes) to 0 ..."
>
> A nice example in programming where this impression is fitting and actually
> helps reading source code is:
> int i = 10;
> while(i --> 0){...}
> The impression when reading is: "while i goes to 0, do ..."
>
> Quite intuitive as well is the use as a hashmap association:
> "blue" -> new color(0,0,255)
> Impression: "key "blue" goes to value color blue".
>
>
> But for Lambdas?
> A simple case like
> #{ int x -> x + 1 }
> might still be somewhat understandable, "x goes to x plus 1". Problem
> already here is that this implies that the variable x itself is incremented
> instead of implying "return x+1".
>
> But what about only a little more complex examples like
> #{ c -> System.out.println("pippo") };
> ?
> "c goes to print "pippo"". Immediate thought is: "What the?! Can variable c
> become a print call execution?"
>
> Or
> #{ e -> sum += e.size(); }
> "e goes to sum add e's size". Impression: "Huh?! Can e become an addition
> operation? Really?"
>
>
> Again, look at the comparable math example: f(x) = x+1
> "f of x is x plus 1". A much more intuitive impression than f(x -> x+1)
> could ever be.
>
>
>
> C)
> All calls of program code in Java have one inherent, consistent, clarifying
> signal syntax: the "()". Whenever there are "()" after an identifier, either
> empty or with values passed in it, you know that some code represented by
> this identifier is called.
> The "->" syntax breaks that as well.
> The form "#(...){...}" would perfectly fit into the way Java syntax is
> structured so far. The "{}" signal (only!) the block, the "()" signal that
> it's callable code and the parameters used. And as a new feature, everyone
> can quickly understand that because lambdas are some kind of "anonymous code
> snippets", there is no identifier but instead the "#" before the "()". (and
> btw: notice the similarity to the clear and well-known mathematical syntax)
> The form "#{... -> ...}", on the other hand, causes massive confusion,
> implying something like "this is some random uncallable code (or is it a
> hashmap association?) with no parameters that applies some new operation
> "->" from one part of the code inside the block to the other". Say what? o_0
>
>
> I hope this explains what (as I understand it) is meant with "it does not
> feel like Java" and objectively shows why this syntax is so painful to read
> for many (ordinary ;)) Java developers (like me).
>
> Personally, I strongly appeal to whoever makes the syntax sugar decision to
> not choose the structure-breaking and very confusing #{...->...} "arrowling"
> syntax (sounds only half as funny after translating the german word
> "Pfeilchen" into english :( ) but to choose the perfectly conforming syntax
> #(...){...} instead.
>
>
> Thank you for reading
>
>
>
>

From mcnepp02 at googlemail.com  Tue Oct 19 00:02:12 2010
From: mcnepp02 at googlemail.com (Gernot Neppert)
Date: Tue, 19 Oct 2010 09:02:12 +0200
Subject: Updated State of the Lambda
In-Reply-To: <AANLkTimRhtgH=uVozfJEku=Hfz4oC7XUpyLUOpEEkR8y@mail.gmail.com>
References: <4CB8B1AF.1090605@oracle.com>
	<201010181004.07597.peter.levart@marand.si>
	<ABB4C621-6B1F-4561-AC44-F287B44DEF5D@oracle.com>
	<AANLkTimRhtgH=uVozfJEku=Hfz4oC7XUpyLUOpEEkR8y@mail.gmail.com>
Message-ID: <AANLkTin3y7BF9AHtVipBpywgnaTb-B-vHOt=-fyyX7fy@mail.gmail.com>

2010/10/18 Reinier Zwitserloot <reinier at zwitserloot.com>:
> Entirely separate from the discussion around implementation details, having
> practices. I'm speaking specifically of using "this" as an object reference,
> and not the "this.x" syntax to clarify which field / method you're referring
> to. Those are scoped in reverse (If the SAM type has a field named "foo" and
> the outer also does, then an unqualified "foo" reference will refer to the
> SAM type's). Therefore, using Outer.this syntax will not be necessary; its
> only for clarification: "x" refers to lambda's x, and "this.x" refers to
> outer's X. You'd only need it when writing a lambda that is itself in an
> inner class.
>

Hmm, but here it gets messy, doesn't it?
One argument in favour of 'this referring to the enclosing instance'
is that lambdas should deliberately not resemble inner classes because
they should stand out as a new concept (at least in Java).

Unfortunately, though, lambdas *are* still instances of classes, and
simply trying to hide that fact causes inconsistencies that should be
at least be addressed.

Consider the following TimerTask that will cancel itself conditionally:

class MyClass
{
    private final void Timer timer = new Timer();
    public void cancel()
    {
      timer.cancel();
    }

    public void scheduleHelloWorld()
    {
       timer.scheduler( #{
                                   System.out.println("Hello world");
                                   if(new Random().nextBoolean()) cancel();
                                   } , 1000, 1000 );
    }
}

Merely prefixing 'cancel' with 'this' will now cause the TimerTask to
cancel the entire timer instead:


    public void scheduleHelloWorld()
    {
       timer.scheduler( #{
                                   System.out.println("Hello world");
                                   if(new Random().nextBoolean())
this.cancel();
                                   } , 1000, 1000 );
    }


Basically the meaning of 'prefixing a variable with this' has been
reversed compared to the 'normal case' of inner classes.
Quite counterintuitive, I think!

From maurizio.cimadamore at oracle.com  Tue Oct 19 01:22:15 2010
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Tue, 19 Oct 2010 09:22:15 +0100
Subject: Updated State of the Lambda
In-Reply-To: <AANLkTin3y7BF9AHtVipBpywgnaTb-B-vHOt=-fyyX7fy@mail.gmail.com>
References: <4CB8B1AF.1090605@oracle.com>	<201010181004.07597.peter.levart@marand.si>	<ABB4C621-6B1F-4561-AC44-F287B44DEF5D@oracle.com>	<AANLkTimRhtgH=uVozfJEku=Hfz4oC7XUpyLUOpEEkR8y@mail.gmail.com>
	<AANLkTin3y7BF9AHtVipBpywgnaTb-B-vHOt=-fyyX7fy@mail.gmail.com>
Message-ID: <4CBD5537.9080605@oracle.com>

Hi Gernot,

On 19/10/10 08:02, Gernot Neppert wrote:
> 2010/10/18 Reinier Zwitserloot<reinier at zwitserloot.com>:
>    
>> Entirely separate from the discussion around implementation details, having
>> practices. I'm speaking specifically of using "this" as an object reference,
>> and not the "this.x" syntax to clarify which field / method you're referring
>> to. Those are scoped in reverse (If the SAM type has a field named "foo" and
>> the outer also does, then an unqualified "foo" reference will refer to the
>> SAM type's). Therefore, using Outer.this syntax will not be necessary; its
>> only for clarification: "x" refers to lambda's x, and "this.x" refers to
>> outer's X. You'd only need it when writing a lambda that is itself in an
>> inner class.
>>
>>      
> Hmm, but here it gets messy, doesn't it?
> One argument in favour of 'this referring to the enclosing instance'
> is that lambdas should deliberately not resemble inner classes because
> they should stand out as a new concept (at least in Java).
>
> Unfortunately, though, lambdas *are* still instances of classes, and
> simply trying to hide that fact causes inconsistencies that should be
> at least be addressed.
>
> Consider the following TimerTask that will cancel itself conditionally:
>
> class MyClass
> {
>      private final void Timer timer = new Timer();
>      public void cancel()
>      {
>        timer.cancel();
>      }
>
>      public void scheduleHelloWorld()
>      {
>         timer.scheduler( #{
>                                     System.out.println("Hello world");
>                                     if(new Random().nextBoolean()) cancel();
>                                     } , 1000, 1000 );
>      }
> }
>
> Merely prefixing 'cancel' with 'this' will now cause the TimerTask to
> cancel the entire timer instead:
>    

not quite, this.cancel() and cancel() [unqualified] both refers to 
MyClass.cancel - in the latter case the reference to the 'right' this 
will simply be inferred by the compiler, as already happens with Java. 
But, from the compiler perspective, there's no TimerTask.cancel() 
available inside the lambda body - in order to call that you should use 
the DA/DU trick discussed yesterday:

TimerTask t = #{ ... t.cancel(); ... }

Maurizio
>
>      public void scheduleHelloWorld()
>      {
>         timer.scheduler( #{
>                                     System.out.println("Hello world");
>                                     if(new Random().nextBoolean())
> this.cancel();
>                                     } , 1000, 1000 );
>      }
>
>
> Basically the meaning of 'prefixing a variable with this' has been
> reversed compared to the 'normal case' of inner classes.
> Quite counterintuitive, I think!
>
>    


From mcnepp02 at googlemail.com  Tue Oct 19 04:48:12 2010
From: mcnepp02 at googlemail.com (Gernot Neppert)
Date: Tue, 19 Oct 2010 13:48:12 +0200
Subject: Updated State of the Lambda
In-Reply-To: <4CBD5537.9080605@oracle.com>
References: <4CB8B1AF.1090605@oracle.com>
	<201010181004.07597.peter.levart@marand.si>
	<ABB4C621-6B1F-4561-AC44-F287B44DEF5D@oracle.com>
	<AANLkTimRhtgH=uVozfJEku=Hfz4oC7XUpyLUOpEEkR8y@mail.gmail.com>
	<AANLkTin3y7BF9AHtVipBpywgnaTb-B-vHOt=-fyyX7fy@mail.gmail.com>
	<4CBD5537.9080605@oracle.com>
Message-ID: <AANLkTim_ZBA2XB70aJpcPC-w4E9B2zJ328iCdd-O=fat@mail.gmail.com>

2010/10/19 Maurizio Cimadamore <maurizio.cimadamore at oracle.com>:
> Hi Gernot,
>
>>
>> Merely prefixing 'cancel' with 'this' will now cause the TimerTask to
>> cancel the entire timer instead:
>>
>
> not quite, this.cancel() and cancel() [unqualified] both refers to
> MyClass.cancel - in the latter case the reference to the 'right' this will
> simply be inferred by the compiler, as already happens with Java. But, from
> the compiler perspective, there's no TimerTask.cancel() available inside the
> lambda body - in order to call that you should use the DA/DU trick discussed
> yesterday:
>

I see what you mean, thanks for the clarification!
(which will also interest Reinier Zwitserloot whom I cited in my first post).

However, I see another problem with the approach:
If the only way to access members of the SAM itself from a within
lambda is via the reference that it will get assigned to,
we'll run into trouble with visibility rules!
See the following example. Provided that the rules for final
assignment will have been updated, the following should compile.
The lambda expression wants to make use of the protected
'totallyUsefulHelperMethod()' defined in the abstract base class
'Sam'.
However, it can't, because it does not have access to protected
methods of other instances (even though we know that it's supposed to
be the same instance in this case).
This would mean that we could never make use of protected methods of
abstract base classes in lambdas.

What do we do?


package net.lambdas;

public abstract class Sam implements Runnable
{
    protected final void totallyUsefulHelperMethod()
   {
   }
}

package net.lambdas.test;

public class TestSam
{
   public void testSam()
   {
      final Sam s = #{  s.totallyUsefulHelperMethod(); };
   }
}

From maurizio.cimadamore at oracle.com  Tue Oct 19 05:05:40 2010
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Tue, 19 Oct 2010 13:05:40 +0100
Subject: Updated State of the Lambda
In-Reply-To: <AANLkTim_ZBA2XB70aJpcPC-w4E9B2zJ328iCdd-O=fat@mail.gmail.com>
References: <4CB8B1AF.1090605@oracle.com>	<201010181004.07597.peter.levart@marand.si>	<ABB4C621-6B1F-4561-AC44-F287B44DEF5D@oracle.com>	<AANLkTimRhtgH=uVozfJEku=Hfz4oC7XUpyLUOpEEkR8y@mail.gmail.com>	<AANLkTin3y7BF9AHtVipBpywgnaTb-B-vHOt=-fyyX7fy@mail.gmail.com>	<4CBD5537.9080605@oracle.com>
	<AANLkTim_ZBA2XB70aJpcPC-w4E9B2zJ328iCdd-O=fat@mail.gmail.com>
Message-ID: <4CBD8994.4050801@oracle.com>

On 19/10/10 12:48, Gernot Neppert wrote:
> 2010/10/19 Maurizio Cimadamore<maurizio.cimadamore at oracle.com>:
>    
>> Hi Gernot,
>>
>>      
>>> Merely prefixing 'cancel' with 'this' will now cause the TimerTask to
>>> cancel the entire timer instead:
>>>
>>>        
>> not quite, this.cancel() and cancel() [unqualified] both refers to
>> MyClass.cancel - in the latter case the reference to the 'right' this will
>> simply be inferred by the compiler, as already happens with Java. But, from
>> the compiler perspective, there's no TimerTask.cancel() available inside the
>> lambda body - in order to call that you should use the DA/DU trick discussed
>> yesterday:
>>
>>      
> I see what you mean, thanks for the clarification!
> (which will also interest Reinier Zwitserloot whom I cited in my first post).
>
> However, I see another problem with the approach:
> If the only way to access members of the SAM itself from a within
> lambda is via the reference that it will get assigned to,
> we'll run into trouble with visibility rules!
> See the following example. Provided that the rules for final
> assignment will have been updated, the following should compile.
> The lambda expression wants to make use of the protected
> 'totallyUsefulHelperMethod()' defined in the abstract base class
> 'Sam'.
> However, it can't, because it does not have access to protected
> methods of other instances (even though we know that it's supposed to
> be the same instance in this case).
> This would mean that we could never make use of protected methods of
> abstract base classes in lambdas.
>
> What do we do?
>    
I'm tempted to say that whenever you feel you need to access 'this' then 
you probably need an anonymous inner class, not a lambda - however we 
will look into this and try to assess how frequent this pattern would be.

Thanks
Maurizio
>
> package net.lambdas;
>
> public abstract class Sam implements Runnable
> {
>      protected final void totallyUsefulHelperMethod()
>     {
>     }
> }
>
> package net.lambdas.test;
>
> public class TestSam
> {
>     public void testSam()
>     {
>        final Sam s = #{  s.totallyUsefulHelperMethod(); };
>     }
> }
>    


From alessiostalla at gmail.com  Tue Oct 19 06:11:32 2010
From: alessiostalla at gmail.com (Alessio Stalla)
Date: Tue, 19 Oct 2010 15:11:32 +0200
Subject: Lambdas and serialization
Message-ID: <AANLkTin4ig6HgmoVwSpgRwOcY8ozGdZrz=u8SGBj8-Sj@mail.gmail.com>

Hello,

I just thought about an aspect that I don't recall having been
mentioned on this list: if a lambda's target SAM type is serializable,
will the SAM-converted lambda be guaranteed to be serializable as
well? Or is it an unspecified implementation detail? I see a certain
value in having serialization work for lambdas, but also a host of
potential problems...

Regards,
Alessio

From pbenedict at apache.org  Tue Oct 19 06:30:17 2010
From: pbenedict at apache.org (Paul Benedict)
Date: Tue, 19 Oct 2010 08:30:17 -0500
Subject: Lambdas and serialization
In-Reply-To: <AANLkTin4ig6HgmoVwSpgRwOcY8ozGdZrz=u8SGBj8-Sj@mail.gmail.com>
References: <AANLkTin4ig6HgmoVwSpgRwOcY8ozGdZrz=u8SGBj8-Sj@mail.gmail.com>
Message-ID: <AANLkTinKKTZWF0oH7LKDBXj8vrsd2_tWk7=1ZC1jk7P+@mail.gmail.com>

Will the wrapper be serializable if the SAM interface is? That's a
good question, but I imagine it has to be because it is implementing
the interface.

public interface MySamType extends Serializable {
  void doSomething(int x);
}

On Tue, Oct 19, 2010 at 8:11 AM, Alessio Stalla <alessiostalla at gmail.com> wrote:
> Hello,
>
> I just thought about an aspect that I don't recall having been
> mentioned on this list: if a lambda's target SAM type is serializable,
> will the SAM-converted lambda be guaranteed to be serializable as
> well? Or is it an unspecified implementation detail? I see a certain
> value in having serialization work for lambdas, but also a host of
> potential problems...
>
> Regards,
> Alessio
>
>

From alessiostalla at gmail.com  Tue Oct 19 06:41:04 2010
From: alessiostalla at gmail.com (Alessio Stalla)
Date: Tue, 19 Oct 2010 15:41:04 +0200
Subject: Lambdas and serialization
In-Reply-To: <AANLkTinKKTZWF0oH7LKDBXj8vrsd2_tWk7=1ZC1jk7P+@mail.gmail.com>
References: <AANLkTin4ig6HgmoVwSpgRwOcY8ozGdZrz=u8SGBj8-Sj@mail.gmail.com>
	<AANLkTinKKTZWF0oH7LKDBXj8vrsd2_tWk7=1ZC1jk7P+@mail.gmail.com>
Message-ID: <AANLkTi=r1C4yg+xgedauvDPGgf5AMGWsmcmDPZa-Hh_7@mail.gmail.com>

On Tue, Oct 19, 2010 at 3:30 PM, Paul Benedict <pbenedict at apache.org> wrote:
> Will the wrapper be serializable if the SAM interface is? That's a
> good question, but I imagine it has to be because it is implementing
> the interface.
>
> public interface MySamType extends Serializable {
> ?void doSomething(int x);
> }

Sorry, I was unclear with the expression "be serializable": what I
really meant is not if it will merely implement java.io.Serializable,
rather if it will actually be serialized by an ObjectOutputStream
without any exception in all cases where a "regular" instance of the
SAM would have been serialized without exceptions, and deserialized in
the same conditions as well. That's imho a desirable feature to have,
but it places a possibly non-trivial burden on the implementation.

From maurizio.cimadamore at oracle.com  Tue Oct 19 07:10:47 2010
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Tue, 19 Oct 2010 15:10:47 +0100
Subject: Lambdas and serialization
In-Reply-To: <AANLkTi=r1C4yg+xgedauvDPGgf5AMGWsmcmDPZa-Hh_7@mail.gmail.com>
References: <AANLkTin4ig6HgmoVwSpgRwOcY8ozGdZrz=u8SGBj8-Sj@mail.gmail.com>	<AANLkTinKKTZWF0oH7LKDBXj8vrsd2_tWk7=1ZC1jk7P+@mail.gmail.com>
	<AANLkTi=r1C4yg+xgedauvDPGgf5AMGWsmcmDPZa-Hh_7@mail.gmail.com>
Message-ID: <4CBDA6E7.1050501@oracle.com>

On 19/10/10 14:41, Alessio Stalla wrote:
> On Tue, Oct 19, 2010 at 3:30 PM, Paul Benedict<pbenedict at apache.org>  wrote:
>    
>> Will the wrapper be serializable if the SAM interface is? That's a
>> good question, but I imagine it has to be because it is implementing
>> the interface.
>>
>> public interface MySamType extends Serializable {
>>   void doSomething(int x);
>> }
>>      
> Sorry, I was unclear with the expression "be serializable": what I
> really meant is not if it will merely implement java.io.Serializable,
> rather if it will actually be serialized by an ObjectOutputStream
> without any exception in all cases where a "regular" instance of the
> SAM would have been serialized without exceptions, and deserialized in
> the same conditions as well. That's imho a desirable feature to have,
> but it places a possibly non-trivial burden on the implementation.
>
>    
Good point. The short answer to this question is: it depends on how 
lambda expressions are translated by the compiler. If the compiler uses 
anonymous inner classes to translate away lambda expression, then the 
answer is yes. If lambda expressions are to be translated away by using 
method handles, then I *guess* the answer is no, as it seems like 
MethodHandle are not serializable (Remi or John might know more about 
this though).

Maurizio

From pbenedict at apache.org  Tue Oct 19 07:13:49 2010
From: pbenedict at apache.org (Paul Benedict)
Date: Tue, 19 Oct 2010 09:13:49 -0500
Subject: Lambdas and serialization
In-Reply-To: <4CBDA6E7.1050501@oracle.com>
References: <AANLkTin4ig6HgmoVwSpgRwOcY8ozGdZrz=u8SGBj8-Sj@mail.gmail.com>
	<AANLkTinKKTZWF0oH7LKDBXj8vrsd2_tWk7=1ZC1jk7P+@mail.gmail.com>
	<AANLkTi=r1C4yg+xgedauvDPGgf5AMGWsmcmDPZa-Hh_7@mail.gmail.com>
	<4CBDA6E7.1050501@oracle.com>
Message-ID: <AANLkTi=3HN2UubBYPMfTQiF8xhhP8p90ZuRkfH2JSPBo@mail.gmail.com>

Does the SAM specification say anything about it must implement ALL
the interfaces in the SAM wrapp? Or is that simply not decided on yet?

On Tue, Oct 19, 2010 at 9:10 AM, Maurizio Cimadamore
<maurizio.cimadamore at oracle.com> wrote:
> On 19/10/10 14:41, Alessio Stalla wrote:
>>
>> On Tue, Oct 19, 2010 at 3:30 PM, Paul Benedict<pbenedict at apache.org>
>> ?wrote:
>>
>>>
>>> Will the wrapper be serializable if the SAM interface is? That's a
>>> good question, but I imagine it has to be because it is implementing
>>> the interface.
>>>
>>> public interface MySamType extends Serializable {
>>> ?void doSomething(int x);
>>> }
>>>
>>
>> Sorry, I was unclear with the expression "be serializable": what I
>> really meant is not if it will merely implement java.io.Serializable,
>> rather if it will actually be serialized by an ObjectOutputStream
>> without any exception in all cases where a "regular" instance of the
>> SAM would have been serialized without exceptions, and deserialized in
>> the same conditions as well. That's imho a desirable feature to have,
>> but it places a possibly non-trivial burden on the implementation.
>>
>>
>
> Good point. The short answer to this question is: it depends on how lambda
> expressions are translated by the compiler. If the compiler uses anonymous
> inner classes to translate away lambda expression, then the answer is yes.
> If lambda expressions are to be translated away by using method handles,
> then I *guess* the answer is no, as it seems like MethodHandle are not
> serializable (Remi or John might know more about this though).
>
> Maurizio
>

From maurizio.cimadamore at oracle.com  Tue Oct 19 07:48:29 2010
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Tue, 19 Oct 2010 15:48:29 +0100
Subject: Lambdas and serialization
In-Reply-To: <AANLkTi=3HN2UubBYPMfTQiF8xhhP8p90ZuRkfH2JSPBo@mail.gmail.com>
References: <AANLkTin4ig6HgmoVwSpgRwOcY8ozGdZrz=u8SGBj8-Sj@mail.gmail.com>	<AANLkTinKKTZWF0oH7LKDBXj8vrsd2_tWk7=1ZC1jk7P+@mail.gmail.com>	<AANLkTi=r1C4yg+xgedauvDPGgf5AMGWsmcmDPZa-Hh_7@mail.gmail.com>	<4CBDA6E7.1050501@oracle.com>
	<AANLkTi=3HN2UubBYPMfTQiF8xhhP8p90ZuRkfH2JSPBo@mail.gmail.com>
Message-ID: <4CBDAFBD.20409@oracle.com>

On 19/10/10 15:13, Paul Benedict wrote:
> Does the SAM specification say anything about it must implement ALL
> the interfaces in the SAM wrapp? Or is that simply not decided on yet?
>    
There shouldn't be differences between an instance of a SAM type created 
using 'new' and another instance obtained via lambda conversion. Which 
means, if the SAM type S is serializable, so should be the instance of S 
obtained when SAM-converting a lambda expression to the target type S.

The fact that this might be difficult to achieve should the translation 
strategy exploit method handles is something that can be regarded as an 
implementation problem, not a design one.

Maurizio
> On Tue, Oct 19, 2010 at 9:10 AM, Maurizio Cimadamore
> <maurizio.cimadamore at oracle.com>  wrote:
>    
>> On 19/10/10 14:41, Alessio Stalla wrote:
>>      
>>> On Tue, Oct 19, 2010 at 3:30 PM, Paul Benedict<pbenedict at apache.org>
>>>   wrote:
>>>
>>>        
>>>> Will the wrapper be serializable if the SAM interface is? That's a
>>>> good question, but I imagine it has to be because it is implementing
>>>> the interface.
>>>>
>>>> public interface MySamType extends Serializable {
>>>>   void doSomething(int x);
>>>> }
>>>>
>>>>          
>>> Sorry, I was unclear with the expression "be serializable": what I
>>> really meant is not if it will merely implement java.io.Serializable,
>>> rather if it will actually be serialized by an ObjectOutputStream
>>> without any exception in all cases where a "regular" instance of the
>>> SAM would have been serialized without exceptions, and deserialized in
>>> the same conditions as well. That's imho a desirable feature to have,
>>> but it places a possibly non-trivial burden on the implementation.
>>>
>>>
>>>        
>> Good point. The short answer to this question is: it depends on how lambda
>> expressions are translated by the compiler. If the compiler uses anonymous
>> inner classes to translate away lambda expression, then the answer is yes.
>> If lambda expressions are to be translated away by using method handles,
>> then I *guess* the answer is no, as it seems like MethodHandle are not
>> serializable (Remi or John might know more about this though).
>>
>> Maurizio
>>
>>      


From alessiostalla at gmail.com  Tue Oct 19 08:06:34 2010
From: alessiostalla at gmail.com (Alessio Stalla)
Date: Tue, 19 Oct 2010 17:06:34 +0200
Subject: Lambdas and serialization
In-Reply-To: <4CBDAFBD.20409@oracle.com>
References: <AANLkTin4ig6HgmoVwSpgRwOcY8ozGdZrz=u8SGBj8-Sj@mail.gmail.com>
	<AANLkTinKKTZWF0oH7LKDBXj8vrsd2_tWk7=1ZC1jk7P+@mail.gmail.com>
	<AANLkTi=r1C4yg+xgedauvDPGgf5AMGWsmcmDPZa-Hh_7@mail.gmail.com>
	<4CBDA6E7.1050501@oracle.com>
	<AANLkTi=3HN2UubBYPMfTQiF8xhhP8p90ZuRkfH2JSPBo@mail.gmail.com>
	<4CBDAFBD.20409@oracle.com>
Message-ID: <AANLkTi=K6OGd-M7DJMduuGpXHTHAYQVR0Pv=bz8KLHvY@mail.gmail.com>

On Tue, Oct 19, 2010 at 4:48 PM, Maurizio Cimadamore
<maurizio.cimadamore at oracle.com> wrote:
> On 19/10/10 15:13, Paul Benedict wrote:
>>
>> Does the SAM specification say anything about it must implement ALL
>> the interfaces in the SAM wrapp? Or is that simply not decided on yet?
>>
>
> There shouldn't be differences between an instance of a SAM type created
> using 'new' and another instance obtained via lambda conversion. Which
> means, if the SAM type S is serializable, so should be the instance of S
> obtained when SAM-converting a lambda expression to the target type S.
>
> The fact that this might be difficult to achieve should the translation
> strategy exploit method handles is something that can be regarded as an
> implementation problem, not a design one.

Right, that and your previous reply answer my question. FWIW,
serialization of closures is implementation-dependent, and often
unsupported, in Common Lisp too. In the context of Java I think this
aspect should be documented clearly by the implementation, because
serialization is not rarely used; for example putting lambdas as
callbacks in a HttpSession might not be a good idea...

From maurizio.cimadamore at oracle.com  Tue Oct 19 08:30:27 2010
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Tue, 19 Oct 2010 15:30:27 +0000
Subject: hg: lambda/lambda: 27 new changesets
Message-ID: <20101019153027.9C1B747285@hg.openjdk.java.net>

Changeset: 43096cccf1ce
Author:    cl
Date:      2010-08-13 11:38 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/rev/43096cccf1ce

Added tag jdk7-b105 for changeset 9f96a4269d77

! .hgtags

Changeset: 7d396ad455c3
Author:    cl
Date:      2010-08-19 15:12 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/rev/7d396ad455c3

Added tag jdk7-b106 for changeset 43096cccf1ce

! .hgtags

Changeset: 140fdef4ddf5
Author:    cl
Date:      2010-08-26 16:16 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/rev/140fdef4ddf5

Added tag jdk7-b107 for changeset 7d396ad455c3

! .hgtags

Changeset: 0df9c57eb80d
Author:    cl
Date:      2010-09-03 12:49 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/rev/0df9c57eb80d

Added tag jdk7-b108 for changeset 140fdef4ddf5

! .hgtags

Changeset: d6ea39e0d3eb
Author:    ohair
Date:      2010-09-07 15:13 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/rev/d6ea39e0d3eb

6982946: Change make/jprt.properties to defer to JPRT itself for jdk platform list
Reviewed-by: kamg

! make/jprt.properties

Changeset: 81dfc728d7bb
Author:    cl
Date:      2010-09-08 14:04 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/rev/81dfc728d7bb

Merge


Changeset: f241877c0ac9
Author:    cl
Date:      2010-09-09 15:07 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/rev/f241877c0ac9

Added tag jdk7-b109 for changeset 81dfc728d7bb

! .hgtags

Changeset: 782c0c738f6d
Author:    ohair
Date:      2010-09-08 15:13 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/rev/782c0c738f6d

6974017: Upgrade required Solaris Studio compilers to 5.10 (12 update 1 + patches)
Reviewed-by: jcoomes

! README-builds.html

Changeset: 973560f0387d
Author:    cl
Date:      2010-09-08 17:29 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/rev/973560f0387d

Merge


Changeset: c129c592e9d6
Author:    ohair
Date:      2010-09-09 17:08 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/rev/c129c592e9d6

6982137: Rebranding pass 2 - missed copyright changes
Reviewed-by: mbykov

! make/templates/gpl-cp-header
! make/templates/gpl-header

Changeset: 2a02d4a6955c
Author:    cl
Date:      2010-09-15 13:40 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/rev/2a02d4a6955c

Merge


Changeset: 9702d6fef68e
Author:    cl
Date:      2010-09-16 15:12 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/rev/9702d6fef68e

Added tag jdk7-b110 for changeset 2a02d4a6955c

! .hgtags

Changeset: 989da1ce9287
Author:    cl
Date:      2010-09-23 17:33 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/rev/989da1ce9287

Added tag jdk7-b111 for changeset 9702d6fef68e

! .hgtags

Changeset: 1fbed32d2ddd
Author:    gbenson
Date:      2010-08-24 13:27 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/rev/1fbed32d2ddd

6976186: Integrate Shark
Summary: Shark is a JIT compiler for Zero that uses the LLVM compiler infrastructure.
Reviewed-by: ohair

! make/hotspot-rules.gmk

Changeset: 90357eee5234
Author:    lana
Date:      2010-09-02 22:07 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/rev/90357eee5234

Merge


Changeset: b331aef4bef0
Author:    ohair
Date:      2010-09-07 15:51 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/rev/b331aef4bef0

Merge


Changeset: 87e98a1df774
Author:    lana
Date:      2010-09-16 11:18 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/rev/87e98a1df774

Merge


Changeset: b852103caf73
Author:    lana
Date:      2010-09-24 16:38 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/rev/b852103caf73

Merge


Changeset: c1df968c4527
Author:    cl
Date:      2010-10-01 15:44 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/rev/c1df968c4527

Added tag jdk7-b112 for changeset b852103caf73

! .hgtags

Changeset: aaf7fab2e8e4
Author:    cl
Date:      2010-10-07 15:12 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/rev/aaf7fab2e8e4

Added tag jdk7-b113 for changeset c1df968c4527

! .hgtags

Changeset: ed13debe9a5e
Author:    ohair
Date:      2010-09-24 14:03 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/rev/ed13debe9a5e

6987114: Fix top level "test" Makefile logic, add jdk/make/Makefile test target
Reviewed-by: mchung

! Makefile

Changeset: 27d945094f81
Author:    ohair
Date:      2010-09-24 14:04 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/rev/27d945094f81

6987117: Add jprt test sets
Reviewed-by: mchung

! make/jprt.properties

Changeset: befdbb69155b
Author:    lana
Date:      2010-09-25 10:38 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/rev/befdbb69155b

Merge


Changeset: db9fe730f305
Author:    lana
Date:      2010-10-04 14:38 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/rev/db9fe730f305

Merge


Changeset: 27985a5c6e52
Author:    lana
Date:      2010-10-12 12:47 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/rev/27985a5c6e52

Merge


Changeset: 73c9023ae9b0
Author:    cl
Date:      2010-10-14 19:24 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/rev/73c9023ae9b0

Added tag jdk7-b114 for changeset 27985a5c6e52

! .hgtags

Changeset: af6b5c288a2d
Author:    mcimadamore
Date:      2010-10-19 11:06 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/rev/af6b5c288a2d

merge with jdk7-b114



From maurizio.cimadamore at oracle.com  Tue Oct 19 08:30:36 2010
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Tue, 19 Oct 2010 15:30:36 +0000
Subject: hg: lambda/lambda/corba: 18 new changesets
Message-ID: <20101019153048.3ADA347286@hg.openjdk.java.net>

Changeset: 519daea48888
Author:    cl
Date:      2010-08-13 11:38 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/corba/rev/519daea48888

Added tag jdk7-b105 for changeset 6f21b030092f

! .hgtags

Changeset: 232adb83eae8
Author:    cl
Date:      2010-08-19 15:12 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/corba/rev/232adb83eae8

Added tag jdk7-b106 for changeset 519daea48888

! .hgtags

Changeset: 8d810527b499
Author:    cl
Date:      2010-08-26 16:16 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/corba/rev/8d810527b499

Added tag jdk7-b107 for changeset 232adb83eae8

! .hgtags

Changeset: 74d57b218468
Author:    cl
Date:      2010-09-03 12:49 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/corba/rev/74d57b218468

Added tag jdk7-b108 for changeset 8d810527b499

! .hgtags

Changeset: 3821536d79ab
Author:    ohair
Date:      2010-09-07 15:16 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/corba/rev/3821536d79ab

6982946: Change make/jprt.properties to defer to JPRT itself for jdk platform list
Reviewed-by: kamg

! make/jprt.properties

Changeset: c3dd858e09b2
Author:    cl
Date:      2010-09-08 14:04 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/corba/rev/c3dd858e09b2

Merge


Changeset: 0e1f80fda227
Author:    cl
Date:      2010-09-09 15:07 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/corba/rev/0e1f80fda227

Added tag jdk7-b109 for changeset c3dd858e09b2

! .hgtags

Changeset: 640fa4d4e2ad
Author:    cl
Date:      2010-09-16 15:12 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/corba/rev/640fa4d4e2ad

Added tag jdk7-b110 for changeset 0e1f80fda227

! .hgtags

Changeset: 21c218f9a7be
Author:    cl
Date:      2010-09-23 17:33 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/corba/rev/21c218f9a7be

Added tag jdk7-b111 for changeset 640fa4d4e2ad

! .hgtags

Changeset: 0f60cf26c5b5
Author:    ohair
Date:      2010-08-30 14:39 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/corba/rev/0f60cf26c5b5

6981043: Clean out all native code makefile logic from corba repository
Reviewed-by: jjg

! make/Makefile
! make/common/Defs-linux.gmk
! make/common/Defs-solaris.gmk
! make/common/Defs-windows.gmk
! make/common/Defs.gmk
- make/common/Library.gmk
- make/common/Mapfile-vers.gmk
! make/common/Rules.gmk
- make/common/internal/NativeCompileRules.gmk
- make/common/shared/Compiler-gcc.gmk
- make/common/shared/Compiler-msvc.gmk
- make/common/shared/Compiler-sun.gmk
- make/common/shared/Compiler.gmk
! make/common/shared/Defs-java.gmk
! make/common/shared/Defs-linux.gmk
! make/common/shared/Defs-solaris.gmk
! make/common/shared/Defs-windows.gmk
! make/common/shared/Defs.gmk
! make/common/shared/Platform.gmk
! make/org/omg/idl/Makefile

Changeset: d6297db2b9dd
Author:    lana
Date:      2010-09-02 22:07 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/corba/rev/d6297db2b9dd

Merge


Changeset: 0a91416c1402
Author:    ohair
Date:      2010-09-07 15:50 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/corba/rev/0a91416c1402

Merge

- make/common/Library.gmk
- make/common/Mapfile-vers.gmk
- make/common/internal/NativeCompileRules.gmk
- make/common/shared/Compiler-gcc.gmk
- make/common/shared/Compiler-msvc.gmk
- make/common/shared/Compiler-sun.gmk
- make/common/shared/Compiler.gmk

Changeset: ae60f98d2f42
Author:    lana
Date:      2010-09-16 11:18 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/corba/rev/ae60f98d2f42

Merge

- make/common/Library.gmk
- make/common/Mapfile-vers.gmk
- make/common/internal/NativeCompileRules.gmk
- make/common/shared/Compiler-gcc.gmk
- make/common/shared/Compiler-msvc.gmk
- make/common/shared/Compiler-sun.gmk
- make/common/shared/Compiler.gmk

Changeset: cc67fdc4fee9
Author:    lana
Date:      2010-09-24 16:38 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/corba/rev/cc67fdc4fee9

Merge

- make/common/Library.gmk
- make/common/Mapfile-vers.gmk
- make/common/internal/NativeCompileRules.gmk
- make/common/shared/Compiler-gcc.gmk
- make/common/shared/Compiler-msvc.gmk
- make/common/shared/Compiler-sun.gmk
- make/common/shared/Compiler.gmk

Changeset: a89a6c5be9d1
Author:    cl
Date:      2010-10-01 15:44 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/corba/rev/a89a6c5be9d1

Added tag jdk7-b112 for changeset cc67fdc4fee9

! .hgtags

Changeset: 88fddb73c5c4
Author:    cl
Date:      2010-10-07 15:12 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/corba/rev/88fddb73c5c4

Added tag jdk7-b113 for changeset a89a6c5be9d1

! .hgtags

Changeset: da7561d479e0
Author:    cl
Date:      2010-10-14 19:24 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/corba/rev/da7561d479e0

Added tag jdk7-b114 for changeset 88fddb73c5c4

! .hgtags

Changeset: 38a7da4a7823
Author:    mcimadamore
Date:      2010-10-19 11:07 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/corba/rev/38a7da4a7823

merge with jdk7-b114

- make/common/Library.gmk
- make/common/Mapfile-vers.gmk
- make/common/internal/NativeCompileRules.gmk
- make/common/shared/Compiler-gcc.gmk
- make/common/shared/Compiler-msvc.gmk
- make/common/shared/Compiler-sun.gmk
- make/common/shared/Compiler.gmk


From forax at univ-mlv.fr  Tue Oct 19 08:44:01 2010
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Tue, 19 Oct 2010 17:44:01 +0200
Subject: Lambdas and serialization
In-Reply-To: <4CBDA6E7.1050501@oracle.com>
References: <AANLkTin4ig6HgmoVwSpgRwOcY8ozGdZrz=u8SGBj8-Sj@mail.gmail.com>	<AANLkTinKKTZWF0oH7LKDBXj8vrsd2_tWk7=1ZC1jk7P+@mail.gmail.com>	<AANLkTi=r1C4yg+xgedauvDPGgf5AMGWsmcmDPZa-Hh_7@mail.gmail.com>
	<4CBDA6E7.1050501@oracle.com>
Message-ID: <4CBDBCC1.9020706@univ-mlv.fr>

Le 19/10/2010 16:10, Maurizio Cimadamore a ?crit :
> On 19/10/10 14:41, Alessio Stalla wrote:
>    
>> On Tue, Oct 19, 2010 at 3:30 PM, Paul Benedict<pbenedict at apache.org>   wrote:
>>
>>      
>>> Will the wrapper be serializable if the SAM interface is? That's a
>>> good question, but I imagine it has to be because it is implementing
>>> the interface.
>>>
>>> public interface MySamType extends Serializable {
>>>    void doSomething(int x);
>>> }
>>>
>>>        
>> Sorry, I was unclear with the expression "be serializable": what I
>> really meant is not if it will merely implement java.io.Serializable,
>> rather if it will actually be serialized by an ObjectOutputStream
>> without any exception in all cases where a "regular" instance of the
>> SAM would have been serialized without exceptions, and deserialized in
>> the same conditions as well. That's imho a desirable feature to have,
>> but it places a possibly non-trivial burden on the implementation.
>>
>>
>>      
> Good point. The short answer to this question is: it depends on how
> lambda expressions are translated by the compiler. If the compiler uses
> anonymous inner classes to translate away lambda expression, then the
> answer is yes. If lambda expressions are to be translated away by using
> method handles, then I *guess* the answer is no, as it seems like
> MethodHandle are not serializable (Remi or John might know more about
> this though).
>
> Maurizio
>    

Lambda are not serializable, like java.lang.reflect.Method
because it will create tons of security holes.

BTW, inner classes have some trouble with serialUID.

R?mi

From maurizio.cimadamore at oracle.com  Tue Oct 19 08:31:05 2010
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Tue, 19 Oct 2010 15:31:05 +0000
Subject: hg: lambda/lambda/hotspot: 139 new changesets
Message-ID: <20101019153511.22CDA47287@hg.openjdk.java.net>

Changeset: 3dc64719cf18
Author:    cl
Date:      2010-08-13 11:38 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/3dc64719cf18

Added tag jdk7-b105 for changeset 6709c14587c2

! .hgtags

Changeset: a81afd9c293c
Author:    alanb
Date:      2010-07-16 13:14 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/a81afd9c293c

6649594: Intermittent IOExceptions during dynamic attach on linux and solaris
Reviewed-by: dcubed, dholmes

! src/os/linux/vm/attachListener_linux.cpp
! src/os/solaris/vm/attachListener_solaris.cpp

Changeset: 920aa833fd16
Author:    apangin
Date:      2010-07-17 21:49 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/920aa833fd16

Merge


Changeset: a5c9d63a187d
Author:    apangin
Date:      2010-07-20 08:41 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/a5c9d63a187d

6964170: Verifier crashes
Summary: Check if klassOop != NULL rather than klass_part != NULL
Reviewed-by: kamg, never

! src/share/vm/classfile/verificationType.cpp
! src/share/vm/classfile/verifier.cpp

Changeset: 7f0fdccac34f
Author:    apangin
Date:      2010-07-25 07:31 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/7f0fdccac34f

Merge

! src/share/vm/classfile/verifier.cpp

Changeset: 3d90023429ec
Author:    aph
Date:      2010-07-28 17:38 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/3d90023429ec

6888526: Linux getCurrentThreadCpuTime is drastically slower than Windows
Reviewed-by: dcubed, dholmes

! src/os/linux/vm/globals_linux.hpp
! src/share/vm/runtime/arguments.cpp

Changeset: a64438a2b7e8
Author:    coleenp
Date:      2010-07-28 17:57 -0400
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/a64438a2b7e8

6958465: Sparc aten build24.0: openjdk-7.ea-b96 failed Error: Formal argument ... requires an lvalue
Summary: Fix compilation errors.  Made non-const references const so can be assigned with lvalue.
Reviewed-by: phh, xlu

! src/cpu/sparc/vm/assembler_sparc.cpp
! src/cpu/sparc/vm/assembler_sparc.hpp
! src/cpu/sparc/vm/assembler_sparc.inline.hpp

Changeset: 126ea7725993
Author:    bobv
Date:      2010-08-03 08:13 -0400
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/126ea7725993

6953477: Increase portability and flexibility of building Hotspot
Summary: A collection of portability improvements including shared code support for PPC, ARM platforms, software floating point, cross compilation support and improvements in error crash detail.
Reviewed-by: phh, never, coleenp, dholmes

! agent/src/os/linux/ps_proc.c
! make/Makefile
! make/defs.make
! make/linux/makefiles/build_vm_def.sh
! make/linux/makefiles/buildtree.make
! make/linux/makefiles/defs.make
! make/linux/makefiles/gcc.make
! make/linux/makefiles/product.make
! make/linux/makefiles/sa.make
! make/linux/makefiles/saproc.make
! make/linux/makefiles/vm.make
! make/solaris/makefiles/defs.make
! src/cpu/sparc/vm/bytecodeInterpreter_sparc.inline.hpp
! src/cpu/sparc/vm/c1_LIRGenerator_sparc.cpp
! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp
! src/cpu/sparc/vm/interpreterRT_sparc.cpp
! src/cpu/sparc/vm/javaFrameAnchor_sparc.hpp
! src/cpu/sparc/vm/templateTable_sparc.cpp
! src/cpu/x86/vm/bytecodeInterpreter_x86.inline.hpp
! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp
! src/cpu/x86/vm/c1_Runtime1_x86.cpp
! src/cpu/x86/vm/frame_x86.cpp
! src/cpu/x86/vm/interpreterRT_x86_32.cpp
! src/cpu/x86/vm/javaFrameAnchor_x86.hpp
! src/cpu/x86/vm/templateTable_x86_32.cpp
! src/cpu/x86/vm/templateTable_x86_64.cpp
! src/os/linux/launcher/java_md.c
! src/os/linux/vm/os_linux.cpp
! src/os/solaris/vm/os_solaris.cpp
! src/os/windows/vm/os_windows.cpp
! src/os_cpu/linux_sparc/vm/thread_linux_sparc.cpp
! src/os_cpu/linux_x86/vm/os_linux_x86.cpp
! src/os_cpu/linux_x86/vm/thread_linux_x86.cpp
! src/os_cpu/linux_zero/vm/thread_linux_zero.cpp
! src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp
! src/os_cpu/solaris_sparc/vm/thread_solaris_sparc.cpp
! src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp
! src/os_cpu/solaris_x86/vm/thread_solaris_x86.cpp
! src/os_cpu/windows_x86/vm/os_windows_x86.cpp
! src/os_cpu/windows_x86/vm/thread_windows_x86.cpp
! src/share/vm/asm/codeBuffer.hpp
! src/share/vm/c1/c1_CodeStubs.hpp
! src/share/vm/c1/c1_Compilation.hpp
! src/share/vm/c1/c1_FrameMap.cpp
! src/share/vm/c1/c1_FrameMap.hpp
! src/share/vm/c1/c1_LIR.cpp
! src/share/vm/c1/c1_LIR.hpp
! src/share/vm/c1/c1_LIRGenerator.cpp
! src/share/vm/c1/c1_LIRGenerator.hpp
! src/share/vm/c1/c1_LinearScan.cpp
! src/share/vm/c1/c1_Runtime1.cpp
! src/share/vm/c1/c1_Runtime1.hpp
! src/share/vm/code/codeBlob.cpp
! src/share/vm/code/codeBlob.hpp
! src/share/vm/code/nmethod.hpp
! src/share/vm/code/vtableStubs.cpp
! src/share/vm/code/vtableStubs.hpp
! src/share/vm/compiler/disassembler.cpp
! src/share/vm/includeDB_compiler1
! src/share/vm/includeDB_core
! src/share/vm/interpreter/bytecodeInterpreter.cpp
! src/share/vm/interpreter/bytecodeInterpreter.hpp
! src/share/vm/interpreter/bytecodeInterpreter.inline.hpp
! src/share/vm/interpreter/interpreter.cpp
! src/share/vm/interpreter/interpreter.hpp
! src/share/vm/interpreter/oopMapCache.cpp
! src/share/vm/memory/allocation.cpp
! src/share/vm/memory/allocation.hpp
! src/share/vm/memory/genCollectedHeap.cpp
! src/share/vm/memory/generation.hpp
! src/share/vm/oops/arrayKlass.cpp
! src/share/vm/oops/arrayKlass.hpp
! src/share/vm/oops/arrayKlassKlass.cpp
! src/share/vm/oops/arrayKlassKlass.hpp
! src/share/vm/oops/compiledICHolderKlass.cpp
! src/share/vm/oops/compiledICHolderKlass.hpp
! src/share/vm/oops/constMethodKlass.cpp
! src/share/vm/oops/constMethodKlass.hpp
! src/share/vm/oops/constantPoolKlass.cpp
! src/share/vm/oops/constantPoolKlass.hpp
! src/share/vm/oops/cpCacheKlass.cpp
! src/share/vm/oops/cpCacheKlass.hpp
! src/share/vm/oops/generateOopMap.cpp
! src/share/vm/oops/klass.cpp
! src/share/vm/oops/klass.hpp
! src/share/vm/oops/klassKlass.cpp
! src/share/vm/oops/klassKlass.hpp
! src/share/vm/oops/oop.cpp
! src/share/vm/prims/jni.cpp
! src/share/vm/prims/jvmtiEnvThreadState.hpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/frame.cpp
! src/share/vm/runtime/frame.hpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/java.cpp
! src/share/vm/runtime/javaFrameAnchor.hpp
! src/share/vm/runtime/os.cpp
! src/share/vm/runtime/os.hpp
! src/share/vm/runtime/sharedRuntime.cpp
! src/share/vm/runtime/sharedRuntime.hpp
! src/share/vm/runtime/sharedRuntimeTrans.cpp
! src/share/vm/runtime/signature.hpp
! src/share/vm/runtime/stubCodeGenerator.cpp
! src/share/vm/runtime/stubCodeGenerator.hpp
! src/share/vm/runtime/thread.cpp
! src/share/vm/runtime/thread.hpp
! src/share/vm/runtime/vm_version.cpp
! src/share/vm/runtime/vm_version.hpp
! src/share/vm/utilities/debug.cpp
! src/share/vm/utilities/globalDefinitions_gcc.hpp
! src/share/vm/utilities/macros.hpp
! src/share/vm/utilities/vmError.cpp
! src/share/vm/utilities/vmError.hpp

Changeset: e5dfb3ccb88b
Author:    kvn
Date:      2010-07-23 10:07 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/e5dfb3ccb88b

6969569: assert(is_static() && is_constant()) failed: illegal call to constant_value()
Summary: Add missing is_static guard.
Reviewed-by: twisti

! src/share/vm/ci/ciField.cpp
! src/share/vm/opto/macro.cpp

Changeset: 99ceb0e99c9e
Author:    never
Date:      2010-07-26 15:58 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/99ceb0e99c9e

Merge


Changeset: 66c5dadb4d61
Author:    kvn
Date:      2010-07-30 10:21 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/66c5dadb4d61

6973308: Missing zero length check before repne scas in check_klass_subtype_slow_path()
Summary: set Z = 0 (not equal) before repne_scan() to indicate that class was not found when RCX == 0.
Reviewed-by: never, phh

! src/cpu/x86/vm/assembler_x86.cpp
! src/cpu/x86/vm/assembler_x86.hpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/utilities/exceptions.cpp
! src/share/vm/utilities/exceptions.hpp
! src/share/vm/utilities/vmError.cpp

Changeset: 0e35fa8ebccd
Author:    kvn
Date:      2010-08-03 15:55 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/0e35fa8ebccd

6973963: SEGV in ciBlock::start_bci() with EA
Summary: Added more checks into ResourceObj and growableArray to verify correctness of allocation type.
Reviewed-by: never, coleenp, dholmes

! src/share/vm/asm/codeBuffer.cpp
! src/share/vm/asm/codeBuffer.hpp
! src/share/vm/ci/ciInstanceKlass.cpp
! src/share/vm/ci/ciMethodBlocks.cpp
! src/share/vm/ci/ciTypeFlow.cpp
! src/share/vm/classfile/classFileParser.cpp
! src/share/vm/memory/allocation.cpp
! src/share/vm/memory/allocation.hpp
! src/share/vm/opto/block.cpp
! src/share/vm/opto/block.hpp
! src/share/vm/opto/c2_globals.hpp
! src/share/vm/opto/c2compiler.cpp
! src/share/vm/opto/chaitin.cpp
! src/share/vm/opto/compile.cpp
! src/share/vm/opto/gcm.cpp
! src/share/vm/opto/lcm.cpp
! src/share/vm/utilities/growableArray.hpp

Changeset: 0e09207fc81b
Author:    kvn
Date:      2010-08-04 17:42 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/0e09207fc81b

6974682: CTW: assert(target != NULL) failed: must not be null
Summary: Add address table size to constant section size.
Reviewed-by: never

! src/share/vm/opto/output.cpp

Changeset: fb8abd207dbe
Author:    kvn
Date:      2010-08-06 11:53 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/fb8abd207dbe

6975049: nsk/regression/b4287029 crashes with -Xss64 on solaris-i586
Summary: Tell C++ to not inline so much by using flag -xspace.
Reviewed-by: ysr

! make/solaris/makefiles/sparcWorks.make

Changeset: 2dfd013a7465
Author:    kvn
Date:      2010-08-09 15:17 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/2dfd013a7465

6975078: assert(allocated_on_res_area() || allocated_on_C_heap() || allocated_on_arena()
Summary: Pass the check in ResourceObj() if _allocation value is already set and object is allocated on stack.
Reviewed-by: dholmes, johnc

! src/share/vm/gc_implementation/g1/collectionSetChooser.cpp
! src/share/vm/gc_implementation/g1/heapRegionSeq.cpp
! src/share/vm/memory/allocation.cpp
! src/share/vm/memory/allocation.hpp
! src/share/vm/runtime/thread.cpp
! src/share/vm/runtime/thread.hpp

Changeset: f4f596978298
Author:    never
Date:      2010-08-09 17:51 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/f4f596978298

Merge

! src/share/vm/asm/codeBuffer.hpp
! src/share/vm/memory/allocation.cpp
! src/share/vm/memory/allocation.hpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/thread.cpp
! src/share/vm/runtime/thread.hpp
! src/share/vm/utilities/vmError.cpp

Changeset: 36519c19beeb
Author:    never
Date:      2010-08-10 12:15 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/36519c19beeb

6975027: use of movptr to set length of array
Reviewed-by: kvn, iveresov

! src/cpu/x86/vm/assembler_x86.cpp

Changeset: 4a665be40fd3
Author:    twisti
Date:      2010-08-11 01:17 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/4a665be40fd3

6975855: don't emit deopt MH handler in C1 if not required
Summary: This CR implements the same for C1 as 6926782 for C2.
Reviewed-by: never

! src/share/vm/c1/c1_Compilation.cpp
! src/share/vm/c1/c1_Compilation.hpp
! src/share/vm/c1/c1_LIRAssembler.cpp
! src/share/vm/code/nmethod.cpp

Changeset: d2ede61b7a12
Author:    twisti
Date:      2010-08-11 05:51 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/d2ede61b7a12

6976186: integrate Shark HotSpot changes
Summary: Shark is a JIT compiler for Zero that uses the LLVM compiler infrastructure.
Reviewed-by: kvn, twisti
Contributed-by: Gary Benson <gbenson at redhat.com>

! make/Makefile
! make/linux/Makefile
! make/linux/makefiles/gcc.make
+ make/linux/makefiles/shark.make
! make/linux/makefiles/top.make
! make/linux/makefiles/vm.make
! src/cpu/zero/vm/disassembler_zero.hpp
+ src/cpu/zero/vm/shark_globals_zero.hpp
! src/share/vm/ci/ciMethod.cpp
! src/share/vm/ci/ciMethod.hpp
! src/share/vm/code/nmethod.cpp
! src/share/vm/code/nmethod.hpp
! src/share/vm/compiler/abstractCompiler.hpp
! src/share/vm/compiler/compileBroker.cpp
! src/share/vm/compiler/disassembler.cpp
+ src/share/vm/includeDB_shark
! src/share/vm/memory/cardTableModRefBS.hpp
! src/share/vm/oops/methodOop.cpp
! src/share/vm/runtime/deoptimization.cpp
! src/share/vm/runtime/frame.cpp
! src/share/vm/runtime/globals.cpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/vm_version.cpp
+ src/share/vm/shark/llvmHeaders.hpp
+ src/share/vm/shark/llvmValue.hpp
+ src/share/vm/shark/sharkBlock.cpp
+ src/share/vm/shark/sharkBlock.hpp
+ src/share/vm/shark/sharkBuilder.cpp
+ src/share/vm/shark/sharkBuilder.hpp
+ src/share/vm/shark/sharkCacheDecache.cpp
+ src/share/vm/shark/sharkCacheDecache.hpp
+ src/share/vm/shark/sharkCodeBuffer.hpp
+ src/share/vm/shark/sharkCompiler.cpp
+ src/share/vm/shark/sharkCompiler.hpp
+ src/share/vm/shark/sharkConstant.cpp
+ src/share/vm/shark/sharkConstant.hpp
+ src/share/vm/shark/sharkContext.cpp
+ src/share/vm/shark/sharkContext.hpp
+ src/share/vm/shark/sharkEntry.hpp
+ src/share/vm/shark/sharkFunction.cpp
+ src/share/vm/shark/sharkFunction.hpp
+ src/share/vm/shark/sharkInliner.cpp
+ src/share/vm/shark/sharkInliner.hpp
+ src/share/vm/shark/sharkIntrinsics.cpp
+ src/share/vm/shark/sharkIntrinsics.hpp
+ src/share/vm/shark/sharkInvariants.cpp
+ src/share/vm/shark/sharkInvariants.hpp
+ src/share/vm/shark/sharkMemoryManager.cpp
+ src/share/vm/shark/sharkMemoryManager.hpp
+ src/share/vm/shark/sharkNativeWrapper.cpp
+ src/share/vm/shark/sharkNativeWrapper.hpp
+ src/share/vm/shark/sharkRuntime.cpp
+ src/share/vm/shark/sharkRuntime.hpp
+ src/share/vm/shark/sharkStack.cpp
+ src/share/vm/shark/sharkStack.hpp
+ src/share/vm/shark/sharkState.cpp
+ src/share/vm/shark/sharkState.hpp
+ src/share/vm/shark/sharkStateScanner.cpp
+ src/share/vm/shark/sharkStateScanner.hpp
+ src/share/vm/shark/sharkTopLevelBlock.cpp
+ src/share/vm/shark/sharkTopLevelBlock.hpp
+ src/share/vm/shark/sharkType.hpp
+ src/share/vm/shark/sharkValue.cpp
+ src/share/vm/shark/sharkValue.hpp
+ src/share/vm/shark/shark_globals.cpp
+ src/share/vm/shark/shark_globals.hpp
! src/share/vm/utilities/macros.hpp

Changeset: 6c9cc03d8726
Author:    kvn
Date:      2010-08-11 10:48 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/6c9cc03d8726

6973329: C2 with Zero based COOP produces code with broken anti-dependency on x86
Summary: Recompile without subsuming loads if RA try to clone a node with anti_dependence.
Reviewed-by: never

! src/share/vm/includeDB_compiler2
! src/share/vm/opto/lcm.cpp
! src/share/vm/opto/reg_split.cpp
+ test/compiler/6973329/Test.java

Changeset: ab3fd720516c
Author:    rasbold
Date:      2010-08-10 19:17 -0400
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/ab3fd720516c

6378314: Bad warning message when agent library not found. local directory is not searched.
Summary: Print a more detailed error message for agent library load failure.
Reviewed-by: jcoomes, never, ohair, coleenp
Contributed-by: jeremymanson at google.com

! src/share/vm/runtime/thread.cpp

Changeset: 21e519b91576
Author:    dcubed
Date:      2010-08-13 07:33 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/21e519b91576

Merge

! src/share/vm/runtime/thread.cpp

Changeset: 688a538aa654
Author:    trims
Date:      2010-08-13 10:55 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/688a538aa654

Merge


Changeset: 5f3c8db59d83
Author:    trims
Date:      2010-08-13 10:56 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/5f3c8db59d83

6977051: Bump the HS19 build number to 06
Summary: Update the HS19 build number to 06
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: 1b81ca701fa5
Author:    trims
Date:      2010-08-17 09:43 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/1b81ca701fa5

Merge


Changeset: 30266066c77c
Author:    cl
Date:      2010-08-19 15:13 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/30266066c77c

Added tag jdk7-b106 for changeset 1b81ca701fa5

! .hgtags

Changeset: 295c3ae4ab5b
Author:    trims
Date:      2010-08-19 18:51 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/295c3ae4ab5b

Added tag hs19-b05 for changeset cc3fdfeb54b0

! .hgtags

Changeset: bf496cbe9b74
Author:    trims
Date:      2010-08-19 18:51 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/bf496cbe9b74

Added tag hs19-b06 for changeset 688a538aa654

! .hgtags

Changeset: e44a93947ccb
Author:    cl
Date:      2010-08-26 16:16 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/e44a93947ccb

Added tag jdk7-b107 for changeset bf496cbe9b74

! .hgtags

Changeset: f6f3eef8a521
Author:    kevinw
Date:      2010-07-30 22:43 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/f6f3eef8a521

6581734: CMS Old Gen's collection usage is zero after GC which is incorrect
Summary: Management code enabled for use by a concurrent collector.
Reviewed-by: mchung, ysr

! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp
! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp
! src/share/vm/gc_implementation/includeDB_gc_concurrentMarkSweep
! src/share/vm/services/management.cpp
! src/share/vm/services/memoryManager.cpp
! src/share/vm/services/memoryManager.hpp
! src/share/vm/services/memoryService.cpp
! src/share/vm/services/memoryService.hpp
+ test/gc/6581734/Test6581734.java

Changeset: 63f4675ac87d
Author:    kevinw
Date:      2010-07-31 15:10 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/63f4675ac87d

Merge

- src/os/linux/vm/vtune_linux.cpp
- src/os/solaris/vm/vtune_solaris.cpp
- src/os/windows/vm/vtune_windows.cpp
! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp
- src/share/vm/runtime/vtune.hpp

Changeset: 2d160770d2e5
Author:    johnc
Date:      2010-08-02 12:51 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/2d160770d2e5

6814437: G1: remove the _new_refs array
Summary: The per-worker _new_refs array is used to hold references that point into the collection set. It is populated during RSet updating and subsequently processed. In the event of an evacuation failure it processed again to recreate the RSets of regions in the collection set. Remove the per-worker _new_refs array by processing the references directly. Use a DirtyCardQueue to hold the cards containing the references so that the RSets of regions in the collection set can be recreated when handling an evacuation failure.
Reviewed-by: iveresov, jmasa, tonyp

! src/share/vm/gc_implementation/g1/concurrentG1Refine.cpp
! src/share/vm/gc_implementation/g1/concurrentG1Refine.hpp
! src/share/vm/gc_implementation/g1/dirtyCardQueue.cpp
! src/share/vm/gc_implementation/g1/dirtyCardQueue.hpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp
! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp
! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp
! src/share/vm/gc_implementation/g1/g1OopClosures.inline.hpp
! src/share/vm/gc_implementation/g1/g1RemSet.cpp
! src/share/vm/gc_implementation/g1/g1RemSet.hpp
! src/share/vm/gc_implementation/g1/g1RemSet.inline.hpp
! src/share/vm/gc_implementation/g1/heapRegion.cpp
! src/share/vm/gc_implementation/includeDB_gc_g1

Changeset: 9d7a8ab3736b
Author:    tonyp
Date:      2010-07-22 10:27 -0400
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/9d7a8ab3736b

6962589: remove breadth first scanning code from parallel gc
Summary: Remove the breadth-first copying order from ParallelScavenge and use depth-first by default.
Reviewed-by: jcoomes, ysr, johnc

! src/share/vm/gc_implementation/includeDB_gc_parallelScavenge
! src/share/vm/gc_implementation/parallelScavenge/cardTableExtension.cpp
- src/share/vm/gc_implementation/parallelScavenge/prefetchQueue.hpp
! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.cpp
! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.hpp
! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.inline.hpp
! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp
! src/share/vm/gc_implementation/parallelScavenge/psScavenge.inline.hpp
! src/share/vm/gc_implementation/parallelScavenge/psTasks.cpp
! src/share/vm/oops/arrayKlassKlass.cpp
! src/share/vm/oops/compiledICHolderKlass.cpp
! src/share/vm/oops/constMethodKlass.cpp
! src/share/vm/oops/constantPoolKlass.cpp
! src/share/vm/oops/cpCacheKlass.cpp
! src/share/vm/oops/instanceKlass.cpp
! src/share/vm/oops/instanceKlass.hpp
! src/share/vm/oops/instanceKlassKlass.cpp
! src/share/vm/oops/instanceRefKlass.cpp
! src/share/vm/oops/klassKlass.cpp
! src/share/vm/oops/klassPS.hpp
! src/share/vm/oops/methodDataKlass.cpp
! src/share/vm/oops/methodKlass.cpp
! src/share/vm/oops/objArrayKlass.cpp
! src/share/vm/oops/objArrayKlassKlass.cpp
! src/share/vm/oops/oop.hpp
! src/share/vm/oops/oop.psgc.inline.hpp
! src/share/vm/oops/symbolKlass.cpp
! src/share/vm/oops/typeArrayKlass.cpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/globals.hpp

Changeset: 0ce1569c90e5
Author:    tonyp
Date:      2010-08-04 13:03 -0400
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/0ce1569c90e5

6963209: G1: remove the concept of abandoned pauses
Summary: As part of 6944166 we disabled the concept of abandoned pauses (i.e., if the collection set is empty, we would still try to do a pause even if it is to update the RSets and scan the roots). This changeset removes the code and structures associated with abandoned pauses.
Reviewed-by: iveresov, johnc

! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp
! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp

Changeset: a03ae377b2e8
Author:    johnc
Date:      2010-08-06 10:17 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/a03ae377b2e8

6930581: G1: assert(ParallelGCThreads > 1 || n_yielded() == _hrrs->occupied(),"Should have yielded all the ..
Summary: During RSet updating, when ParallelGCThreads is zero, references that point into the collection set are added directly the referenced region's RSet. This can cause the sparse table in the RSet to expand. RSet scanning and the "occupied" routine will then operate on different instances of the sparse table causing the assert to trip. This may also cause some cards added post expansion to be missed during RSet scanning. When ParallelGCThreads is non-zero such references are recorded on the "references to be scanned" queue and the card containing the reference is recorded in a dirty card queue for use in the event of an evacuation failure. Employ the parallel code in the serial case to avoid expanding the RSets of regions in the collection set.
Reviewed-by: iveresov, ysr, tonyp

! src/share/vm/gc_implementation/g1/g1RemSet.cpp
! src/share/vm/gc_implementation/g1/g1RemSet.hpp
! src/share/vm/gc_implementation/g1/g1RemSet.inline.hpp
! src/share/vm/gc_implementation/g1/sparsePRT.cpp

Changeset: 5f429ee79634
Author:    jcoomes
Date:      2010-08-09 05:41 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/5f429ee79634

6966222: G1: simplify TaskQueue overflow handling
Reviewed-by: tonyp, ysr

! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.inline.hpp
! src/share/vm/utilities/taskqueue.cpp
! src/share/vm/utilities/taskqueue.hpp

Changeset: 94251661de76
Author:    jcoomes
Date:      2010-08-09 18:03 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/94251661de76

6970376: ParNew: shared TaskQueue statistics
Reviewed-by: ysr

! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp
! src/share/vm/gc_implementation/parNew/parNewGeneration.hpp

Changeset: a6bff45449bc
Author:    ysr
Date:      2010-08-10 14:53 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/a6bff45449bc

6973570: OrderAccess::storestore() scales poorly on multi-socket x64 and sparc: cache-line ping-ponging
Summary: volatile store to static variable removed in favour of a volatile store to stack to avoid excessive cache coherency traffic; verified that the volatile store is not elided by any of our current compilers.
Reviewed-by: dholmes, dice, jcoomes, kvn

! src/os_cpu/linux_sparc/vm/orderAccess_linux_sparc.inline.hpp
! src/os_cpu/linux_x86/vm/orderAccess_linux_x86.inline.hpp
! src/os_cpu/solaris_sparc/vm/orderAccess_solaris_sparc.inline.hpp
! src/os_cpu/solaris_x86/vm/orderAccess_solaris_x86.inline.hpp
! src/os_cpu/windows_x86/vm/orderAccess_windows_x86.inline.hpp
! src/share/vm/runtime/orderAccess.cpp
! src/share/vm/runtime/orderAccess.hpp

Changeset: 2d6b74c9a797
Author:    jcoomes
Date:      2010-08-11 13:12 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/2d6b74c9a797

6976378: ParNew:  stats are printed unconditionally in debug builds
Reviewed-by: tonyp

! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp

Changeset: 7fcd5f39bd7a
Author:    johnc
Date:      2010-08-14 00:47 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/7fcd5f39bd7a

Merge

- src/share/vm/gc_implementation/parallelScavenge/prefetchQueue.hpp
! src/share/vm/oops/arrayKlassKlass.cpp
! src/share/vm/oops/compiledICHolderKlass.cpp
! src/share/vm/oops/constMethodKlass.cpp
! src/share/vm/oops/constantPoolKlass.cpp
! src/share/vm/oops/cpCacheKlass.cpp
! src/share/vm/oops/klassKlass.cpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/globals.hpp

Changeset: f121b2772674
Author:    trims
Date:      2010-08-18 16:11 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/f121b2772674

Merge

- src/share/vm/gc_implementation/parallelScavenge/prefetchQueue.hpp

Changeset: 495caa35b1b5
Author:    asaha
Date:      2010-08-17 22:52 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/495caa35b1b5

6977952: Test: Sync missing tests from hs16.3 to hs17.x
Reviewed-by: wrockett

+ test/compiler/6894807/IsInstanceTest.java
+ test/compiler/6894807/Test6894807.sh
+ test/runtime/6626217/IFace.java
+ test/runtime/6626217/Loader2.java
+ test/runtime/6626217/Test6626217.sh
+ test/runtime/6626217/You_Have_Been_P0wned.java
+ test/runtime/6626217/bug_21227.java
+ test/runtime/6626217/from_loader2.java
+ test/runtime/6626217/many_loader1.java.foo
+ test/runtime/6626217/many_loader2.java.foo

Changeset: be3f9c242c9d
Author:    ysr
Date:      2010-08-16 15:58 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/be3f9c242c9d

6948538: CMS: BOT walkers can fall into object allocation and initialization cracks
Summary: GC workers now recognize an intermediate transient state of blocks which are allocated but have not yet completed initialization. blk_start() calls do not attempt to determine the size of a block in the transient state, rather waiting for the block to become initialized so that it is safe to query its size. Audited and ensured the order of initialization of object fields (klass, free bit and size) to respect block state transition protocol. Also included some new assertion checking code enabled in debug mode.
Reviewed-by: chrisphi, johnc, poonam

! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp
! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.hpp
! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp
! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp
! src/share/vm/gc_implementation/concurrentMarkSweep/freeChunk.hpp
! src/share/vm/gc_implementation/concurrentMarkSweep/promotionInfo.cpp
! src/share/vm/gc_implementation/includeDB_gc_concurrentMarkSweep
! src/share/vm/includeDB_core
! src/share/vm/memory/blockOffsetTable.cpp
! src/share/vm/memory/blockOffsetTable.hpp
! src/share/vm/memory/blockOffsetTable.inline.hpp
! src/share/vm/runtime/globals.hpp

Changeset: 688c3755d7af
Author:    tonyp
Date:      2010-08-17 14:40 -0400
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/688c3755d7af

6959014: G1: assert(minimum_desired_capacity <= maximum_desired_capacity) failed: sanity check
Summary: There are a few issues in the code that calculates whether to resize the heap and by how much: a) some calculations can overflow 32-bit size_t's, b) min_desired_capacity is not bounded by the max heap size, and c) the assrt that fires is in the wrong place. The fix also includes some tidying up of the related verbose code.
Reviewed-by: ysr, jmasa

! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp

Changeset: bb847e31b836
Author:    tonyp
Date:      2010-08-17 14:40 -0400
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/bb847e31b836

6974928: G1: sometimes humongous objects are allocated in young regions
Summary: as the title says, sometimes we are allocating humongous objects in young regions and we shouldn't.
Reviewed-by: ysr, johnc

! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.inline.hpp
! src/share/vm/gc_implementation/g1/heapRegion.cpp

Changeset: b63010841f78
Author:    tonyp
Date:      2010-08-17 14:40 -0400
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/b63010841f78

6975964: G1: print out a more descriptive message for evacuation failure when +PrintGCDetails is set
Summary: we're renaming "evacuation failure" to "to-space overflow". I'm also piggy-backing a small additional change which removes the "Mark closure took..." output.
Reviewed-by: ysr, johnc

! src/share/vm/gc_implementation/g1/concurrentMark.cpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp

Changeset: 5ed703250bff
Author:    ysr
Date:      2010-08-18 11:39 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/5ed703250bff

6977970: CMS: concurrentMarkSweepGeneration.cpp:7947 assert(addr <= _limit) failed: sweep invariant
Summary: Allow for the possibility (when the heap is expanding) that the sweep might skip over and past, rather than necessarily step on, the sweep limit determined at the beginning of a concurrent marking cycle.
Reviewed-by: jmasa, tonyp

! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp

Changeset: 413ad0331a0c
Author:    johnc
Date:      2010-08-18 10:59 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/413ad0331a0c

6977924: Changes for 6975078 produce build error with certain gcc versions
Summary: The changes introduced for 6975078 assign badHeapOopVal to the _allocation field in the ResourceObj class. In 32 bit linux builds with certain versions of gcc this assignment will be flagged as an error while compiling allocation.cpp. In 32 bit builds the constant value badHeapOopVal (which is cast to an intptr_t) is negative. The _allocation field is typed as an unsigned intptr_t and gcc catches this as an error.
Reviewed-by: jcoomes, ysr, phh

! src/share/vm/memory/allocation.cpp

Changeset: effb55808a18
Author:    johnc
Date:      2010-08-18 17:44 -0400
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/effb55808a18

Merge


Changeset: 1b0104ab1e5e
Author:    tonyp
Date:      2010-08-19 14:08 -0400
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/1b0104ab1e5e

Merge


Changeset: 0e509ddd9962
Author:    trims
Date:      2010-08-20 03:47 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/0e509ddd9962

6978726: Bump the HS19 build number to 07
Summary: Update the HS19 build number to 07
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: 09cdb1e1c77b
Author:    trims
Date:      2010-08-20 04:08 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/09cdb1e1c77b

Merge

- src/share/vm/gc_implementation/parallelScavenge/prefetchQueue.hpp

Changeset: 71faaa8e3ccc
Author:    never
Date:      2010-08-12 16:38 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/71faaa8e3ccc

6974176: ShouldNotReachHere, instanceKlass.cpp:1426
Reviewed-by: kvn, twisti

! src/share/vm/code/nmethod.cpp
! src/share/vm/code/nmethod.hpp

Changeset: da877bdc9000
Author:    never
Date:      2010-08-12 23:34 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/da877bdc9000

6975006: assert(check.is_deoptimized_frame()) failed: missed deopt
Reviewed-by: kvn, twisti

! src/share/vm/runtime/frame.cpp
! src/share/vm/runtime/frame.hpp
! src/share/vm/runtime/safepoint.cpp
! src/share/vm/runtime/safepoint.hpp
! src/share/vm/runtime/thread.cpp

Changeset: a62d332029cf
Author:    never
Date:      2010-08-13 15:14 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/a62d332029cf

6976372: #  assert(_owner == Thread::current()) failed: invariant
Reviewed-by: kvn, twisti

! src/share/vm/compiler/compileBroker.cpp
! src/share/vm/runtime/sharedRuntime.cpp

Changeset: 13b87063b4d8
Author:    twisti
Date:      2010-08-18 01:22 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/13b87063b4d8

6977640: Zero and Shark fixes
Summary: A number of fixes for Zero and Shark.
Reviewed-by: twisti
Contributed-by: Gary Benson <gbenson at redhat.com>

! src/cpu/zero/vm/bytecodeInterpreter_zero.inline.hpp
! src/cpu/zero/vm/javaFrameAnchor_zero.hpp
! src/os_cpu/linux_zero/vm/os_linux_zero.cpp
! src/os_cpu/linux_zero/vm/thread_linux_zero.cpp
! src/share/vm/interpreter/bytecodeInterpreter.cpp

Changeset: f55c4f82ab9d
Author:    never
Date:      2010-08-19 14:51 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/f55c4f82ab9d

6978249: spill between cpu and fpu registers when those moves are fast
Reviewed-by: kvn

! src/cpu/sparc/vm/vm_version_sparc.cpp
! src/cpu/x86/vm/vm_version_x86.cpp
! src/cpu/x86/vm/x86_32.ad
! src/cpu/x86/vm/x86_64.ad
! src/share/vm/opto/c2_globals.hpp
! src/share/vm/opto/coalesce.cpp
! src/share/vm/opto/matcher.cpp
! src/share/vm/opto/reg_split.cpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/init.cpp

Changeset: ee5cc9e78493
Author:    never
Date:      2010-08-20 09:55 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/ee5cc9e78493

Merge

! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/thread.cpp

Changeset: 52f2bc645da5
Author:    ysr
Date:      2010-08-19 12:02 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/52f2bc645da5

6978533: CMS: Elide BOT  update asserts until 6977974 is fixed correctly
Reviewed-by: jcoomes, jmasa, tonyp

! src/share/vm/memory/blockOffsetTable.hpp

Changeset: 66b9f90a9211
Author:    tonyp
Date:      2010-08-20 13:17 -0400
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/66b9f90a9211

Merge


Changeset: 26faca352942
Author:    tonyp
Date:      2010-08-20 12:01 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/26faca352942

Merge


Changeset: 571f6b35140b
Author:    trims
Date:      2010-08-20 12:57 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/571f6b35140b

6978889: Remove premature change of build number to Hotspot 19 Build 07
Summary: Change the build number back to 06
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: b0b9d64ed9bc
Author:    trims
Date:      2010-08-20 14:24 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/b0b9d64ed9bc

6978915: Remove Mercurial tags for Hotspot 19 Build 06
Summary: Delete the hs19-b06 Hg tag, as it was put on incorrectly
Reviewed-by: jcoomes

! .hgtags

Changeset: 6c43216df135
Author:    trims
Date:      2010-08-31 16:48 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/6c43216df135

Merge

! .hgtags

Changeset: 0803c0f69b51
Author:    trims
Date:      2010-08-31 17:23 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/0803c0f69b51

Added tag hs19-b06 for changeset 6c43216df135

! .hgtags

Changeset: 2fe09e2e70d0
Author:    cl
Date:      2010-09-03 12:49 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/2fe09e2e70d0

Added tag jdk7-b108 for changeset e44a93947ccb

! .hgtags

Changeset: cc4bb3022b31
Author:    cl
Date:      2010-09-09 14:27 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/cc4bb3022b31

Merge

! .hgtags
- src/share/vm/gc_implementation/parallelScavenge/prefetchQueue.hpp

Changeset: 2f25f2b8de27
Author:    cl
Date:      2010-09-09 15:07 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/2f25f2b8de27

Added tag jdk7-b109 for changeset cc4bb3022b31

! .hgtags

Changeset: 07b042e13dde
Author:    cl
Date:      2010-09-16 15:12 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/07b042e13dde

Added tag jdk7-b110 for changeset 2f25f2b8de27

! .hgtags

Changeset: 8d5897b4230f
Author:    cl
Date:      2010-09-23 17:33 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/8d5897b4230f

Added tag jdk7-b111 for changeset 07b042e13dde

! .hgtags

Changeset: f8c5d1bdaad4
Author:    ptisnovs
Date:      2010-08-19 14:23 -0400
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/f8c5d1bdaad4

6885308: The incorrect -XX:StackRedPages, -XX:StackShadowPages, -XX:StackYellowPages could cause VM crash
Summary: Test minimal stack sizes given (also fixed linux compilation error)
Reviewed-by: never, phh, coleenp

! src/share/vm/memory/allocation.cpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/arguments.hpp

Changeset: ebfb7c68865e
Author:    dcubed
Date:      2010-08-23 08:44 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/ebfb7c68865e

Merge

! src/share/vm/memory/allocation.cpp
! src/share/vm/runtime/arguments.cpp

Changeset: 4b29a725c43c
Author:    jrose
Date:      2010-08-20 23:40 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/4b29a725c43c

6912064: type profiles need to be exploited more for dynamic language support
Reviewed-by: kvn

! src/share/vm/includeDB_compiler2
! src/share/vm/opto/graphKit.cpp
! src/share/vm/opto/graphKit.hpp
! src/share/vm/opto/library_call.cpp
! src/share/vm/opto/parse.hpp
! src/share/vm/opto/parse2.cpp
! src/share/vm/opto/parseHelper.cpp
! src/share/vm/runtime/globals.hpp

Changeset: 53dbe853fb3a
Author:    kvn
Date:      2010-08-23 09:09 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/53dbe853fb3a

6896381: CTW fails share/vm/ci/bcEscapeAnalyzer.cpp:99, assert(_stack_height < _max_stack,"stack overflow")
Summary: Check constant Tag type instead of calling get_constant().
Reviewed-by: never

! src/share/vm/ci/bcEscapeAnalyzer.cpp

Changeset: 3e8fbc61cee8
Author:    twisti
Date:      2010-08-25 05:27 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/3e8fbc61cee8

6978355: renaming for 6961697
Summary: This is the renaming part of 6961697 to keep the actual changes small for review.
Reviewed-by: kvn, never

! agent/src/share/classes/sun/jvm/hotspot/CommandProcessor.java
! agent/src/share/classes/sun/jvm/hotspot/c1/Runtime1.java
! agent/src/share/classes/sun/jvm/hotspot/code/CodeBlob.java
! agent/src/share/classes/sun/jvm/hotspot/code/NMethod.java
! agent/src/share/classes/sun/jvm/hotspot/code/PCDesc.java
! agent/src/share/classes/sun/jvm/hotspot/ui/FindInCodeCachePanel.java
! agent/src/share/classes/sun/jvm/hotspot/ui/classbrowser/HTMLGenerator.java
! agent/src/share/classes/sun/jvm/hotspot/utilities/PointerFinder.java
! agent/src/share/classes/sun/jvm/hotspot/utilities/PointerLocation.java
! src/cpu/sparc/vm/assembler_sparc.cpp
! src/cpu/sparc/vm/codeBuffer_sparc.hpp
! src/cpu/sparc/vm/frame_sparc.cpp
! src/cpu/sparc/vm/jniFastGetField_sparc.cpp
! src/cpu/sparc/vm/nativeInst_sparc.cpp
! src/cpu/sparc/vm/sparc.ad
! src/cpu/x86/vm/frame_x86.cpp
! src/cpu/x86/vm/frame_x86.inline.hpp
! src/cpu/x86/vm/jniFastGetField_x86_32.cpp
! src/cpu/x86/vm/jniFastGetField_x86_64.cpp
! src/cpu/x86/vm/vm_version_x86.cpp
! src/cpu/x86/vm/x86_32.ad
! src/cpu/x86/vm/x86_64.ad
! src/os/solaris/dtrace/generateJvmOffsets.cpp
! src/os/solaris/dtrace/libjvm_db.c
! src/os_cpu/windows_x86/vm/os_windows_x86.cpp
! src/os_cpu/windows_x86/vm/windows_x86_32.ad
! src/os_cpu/windows_x86/vm/windows_x86_64.ad
! src/share/vm/adlc/output_c.cpp
! src/share/vm/asm/codeBuffer.cpp
! src/share/vm/asm/codeBuffer.hpp
! src/share/vm/c1/c1_Compilation.cpp
! src/share/vm/c1/c1_Runtime1.cpp
! src/share/vm/c1/c1_Runtime1.hpp
! src/share/vm/ci/ciMethod.cpp
! src/share/vm/code/codeBlob.cpp
! src/share/vm/code/codeBlob.hpp
! src/share/vm/code/codeCache.cpp
! src/share/vm/code/exceptionHandlerTable.cpp
! src/share/vm/code/nmethod.cpp
! src/share/vm/code/nmethod.hpp
! src/share/vm/code/pcDesc.cpp
! src/share/vm/code/relocInfo.cpp
! src/share/vm/code/scopeDesc.cpp
! src/share/vm/code/stubs.cpp
! src/share/vm/code/vtableStubs.cpp
! src/share/vm/compiler/compileBroker.cpp
! src/share/vm/compiler/disassembler.cpp
! src/share/vm/interpreter/interpreter.hpp
! src/share/vm/interpreter/interpreterRuntime.cpp
! src/share/vm/opto/compile.cpp
! src/share/vm/opto/graphKit.cpp
! src/share/vm/opto/lcm.cpp
! src/share/vm/opto/library_call.cpp
! src/share/vm/opto/output.cpp
! src/share/vm/opto/stringopts.cpp
! src/share/vm/prims/jvmtiCodeBlobEvents.cpp
! src/share/vm/prims/jvmtiExport.cpp
! src/share/vm/prims/methodHandles.cpp
! src/share/vm/runtime/compilationPolicy.cpp
! src/share/vm/runtime/frame.cpp
! src/share/vm/runtime/icache.cpp
! src/share/vm/runtime/rframe.cpp
! src/share/vm/runtime/sharedRuntime.cpp
! src/share/vm/runtime/sharedRuntime.hpp
! src/share/vm/runtime/stubRoutines.cpp
! src/share/vm/runtime/vmStructs.cpp

Changeset: b4099f5786da
Author:    never
Date:      2010-08-25 10:31 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/b4099f5786da

Merge

! src/share/vm/runtime/globals.hpp

Changeset: c7004d700b49
Author:    dholmes
Date:      2010-08-25 21:29 -0400
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/c7004d700b49

6978641: Fix for 6929067 introduces additional overhead in thread creation/termination paths
Summary: Disable stack bounds checks in product mode other than for the initial thread
Reviewed-by: coleenp, jcoomes, aph

! src/os/linux/vm/os_linux.cpp

Changeset: 2528b5bd749c
Author:    kamg
Date:      2010-08-27 15:05 -0400
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/2528b5bd749c

6980262: Memory leak when exception is thrown in static initializer
Summary: Use resource memory instead of c-heap for the exception message
Reviewed-by: phh, jmasa

! src/share/vm/oops/instanceKlass.cpp

Changeset: 8397081c7ac1
Author:    dcubed
Date:      2010-08-27 21:31 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/8397081c7ac1

Merge


Changeset: bba76f745fe6
Author:    ysr
Date:      2010-08-23 17:51 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/bba76f745fe6

6910183: CMS: assert(_index < capacity(),"_index out of bounds")
Summary: Weakened a too-strong, off-by-one assert; added code to keep track of and report any overflows at appropriate level of verbosity.
Reviewed-by: jcoomes, tonyp

! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp

Changeset: e967bad2a9ab
Author:    tonyp
Date:      2010-08-25 08:44 -0400
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/e967bad2a9ab

6941275: G1: The MemoryPools are incorrectly supported for G1
Summary: The way we were caluclating the max value meant that it might fluctuate during the run and this broke some assumptions inside the MBeans framework. This change sets the max value of each pool to -1, which means undefined according to the spec.
Reviewed-by: mchung, johnc

! src/share/vm/services/g1MemoryPool.cpp
! src/share/vm/services/g1MemoryPool.hpp

Changeset: 8e5955ddf8e4
Author:    jcoomes
Date:      2010-08-25 14:39 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/8e5955ddf8e4

6978300: G1: debug builds crash if ParallelGCThreads==0
Reviewed-by: tonyp, ysr

! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp

Changeset: 21c29458b334
Author:    kevinw
Date:      2010-08-27 16:57 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/21c29458b334

6980392: TEST_BUG: gc/6581734/Test6581734.java has typo
Summary: simple correction in testcase
Reviewed-by: mchung

! test/gc/6581734/Test6581734.java

Changeset: 1c63587d925b
Author:    tonyp
Date:      2010-08-27 13:34 -0400
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/1c63587d925b

6980206: G1: assert(has_undefined_max_size, "Undefined max size");
Summary: An assert in the management.cpp is too strong and assumes the max size is always defined on memory pools, even when we don't need to use it.
Reviewed-by: mchung, johnc

! src/share/vm/services/management.cpp

Changeset: af586a7893cf
Author:    tonyp
Date:      2010-08-27 10:44 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/af586a7893cf

Merge


Changeset: 75107ee8712f
Author:    tonyp
Date:      2010-08-30 13:00 -0400
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/75107ee8712f

Merge


Changeset: f208bf19192d
Author:    tonyp
Date:      2010-08-30 10:58 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/f208bf19192d

Merge


Changeset: 14b92b91f460
Author:    kvn
Date:      2010-08-26 11:05 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/14b92b91f460

6976400: "Meet Not Symmetric"
Summary: Use NULL as klass for TypeAryPtr::RANGE. Add klass verification into TypeAryPtr ctor.
Reviewed-by: never

! src/share/vm/opto/type.cpp
! src/share/vm/opto/type.hpp

Changeset: 0878d7bae69f
Author:    twisti
Date:      2010-08-27 01:51 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/0878d7bae69f

6961697: move nmethod constants section before instruction section
Summary: This is a preparation for 6961690.
Reviewed-by: kvn, never

! src/share/vm/asm/codeBuffer.cpp
! src/share/vm/asm/codeBuffer.hpp
! src/share/vm/code/codeBlob.cpp
! src/share/vm/code/nmethod.cpp
! src/share/vm/code/nmethod.hpp
! src/share/vm/code/relocInfo.cpp
! src/share/vm/code/relocInfo.hpp

Changeset: d6f45b55c972
Author:    never
Date:      2010-08-27 17:33 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/d6f45b55c972

4809552: Optimize Arrays.fill(...)
Reviewed-by: kvn

! src/cpu/sparc/vm/stubGenerator_sparc.cpp
! src/cpu/x86/vm/assembler_x86.cpp
! src/cpu/x86/vm/assembler_x86.hpp
! src/cpu/x86/vm/stubGenerator_x86_32.cpp
! src/cpu/x86/vm/stubGenerator_x86_64.cpp
! src/share/vm/includeDB_compiler2
! src/share/vm/opto/addnode.cpp
! src/share/vm/opto/c2_globals.hpp
! src/share/vm/opto/loopTransform.cpp
! src/share/vm/opto/loopnode.cpp
! src/share/vm/opto/loopnode.hpp
! src/share/vm/opto/runtime.cpp
! src/share/vm/opto/runtime.hpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/stubRoutines.cpp
! src/share/vm/runtime/stubRoutines.hpp
! src/share/vm/utilities/globalDefinitions.hpp

Changeset: 14197af1010e
Author:    never
Date:      2010-08-27 17:35 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/14197af1010e

Merge

! src/share/vm/includeDB_compiler2
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/stubRoutines.cpp

Changeset: 114e6b93e9e1
Author:    kvn
Date:      2010-08-30 11:02 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/114e6b93e9e1

6980978: assert(mt == t->xmeet(this)) failed: meet not commutative
Summary: Fix code in TypeAryPtr::xmeet() for constant array.
Reviewed-by: never

! src/share/vm/opto/type.cpp

Changeset: 02f0a9b6f654
Author:    never
Date:      2010-08-30 17:27 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/02f0a9b6f654

6969586: OptimizeStringConcat: SIGSEGV in LoadNode::Value()
Reviewed-by: kvn

! src/share/vm/opto/memnode.cpp

Changeset: dee553c74493
Author:    never
Date:      2010-09-01 00:40 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/dee553c74493

Merge


Changeset: 6ee479178066
Author:    ikrylov
Date:      2010-08-31 03:14 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/6ee479178066

6979444: add command line option to print command line flags descriptions
Summary: Implementation of a nonproduct boolean flag XX:PrintFlagsWithComments
Reviewed-by: kamg, dholmes, dsamersoff

! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/globals.cpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/utilities/macros.hpp

Changeset: 1ab9e2cbfa0e
Author:    kamg
Date:      2010-09-03 14:47 -0400
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/1ab9e2cbfa0e

6870851: Bad frame_chop in StackMapTable crashes JVM
Summary: Must check locals for null when processing chop frame
Reviewed-by: dholmes, dcubed

! src/share/vm/classfile/stackMapTable.cpp

Changeset: 40d7b43b6fe0
Author:    kamg
Date:      2010-09-07 11:38 -0400
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/40d7b43b6fe0

Merge

! src/share/vm/runtime/arguments.cpp

Changeset: 07551f490c76
Author:    kamg
Date:      2010-09-07 11:50 -0400
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/07551f490c76

6982851: Add b107 machine classifications to jprt.properties file.
Summary: See synopsis
Reviewed-by: ohair

! make/jprt.properties

Changeset: 40b1534a1dab
Author:    trims
Date:      2010-09-08 18:33 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/40b1534a1dab

Merge


Changeset: 93193e632121
Author:    trims
Date:      2010-09-08 18:33 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/93193e632121

6983320: Fork HS19 to HS20 - renumber Major and build numbers of JVM
Summary: Update the Major and Build numbers for HS20
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: ea175c1b79ce
Author:    dcubed
Date:      2010-09-08 08:34 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/ea175c1b79ce

6561870: 3/3 Long javac compile lines fail due to command line length issues (agent compiles?)
Summary: Use javac's @filename construct to avoid long compile lines
Reviewed-by: ohair, twisti, never
Contributed-by: doko at ubuntu.com

! make/linux/makefiles/sa.make
! make/solaris/makefiles/sa.make

Changeset: 30f67acf635d
Author:    thurka
Date:      2010-09-11 08:18 +0200
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/30f67acf635d

6765718: Indicate which thread throwing OOME when generating the heap dump at OOME
Summary: Emit a fake frame that makes it look like the thread is in the OutOfMemoryError zero-parameter constructor
Reviewed-by: dcubed

! src/share/vm/services/heapDumper.cpp
! src/share/vm/services/heapDumper.hpp
! src/share/vm/utilities/debug.cpp

Changeset: 8a8a7a014a12
Author:    kamg
Date:      2010-09-13 07:38 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/8a8a7a014a12

Merge


Changeset: 179464550c7d
Author:    ysr
Date:      2010-09-10 17:07 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/179464550c7d

6983930: CMS: Various small cleanups ca September 2010
Summary: Fixed comment/documentation typos; converted some guarantee()s to assert()s.
Reviewed-by: jmasa

! src/share/vm/gc_implementation/concurrentMarkSweep/binaryTreeDictionary.cpp
! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp
! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp
! src/share/vm/gc_implementation/concurrentMarkSweep/freeList.cpp
! src/share/vm/gc_implementation/concurrentMarkSweep/promotionInfo.cpp
! src/share/vm/runtime/globals.hpp

Changeset: eeade8e89248
Author:    ysr
Date:      2010-09-11 11:42 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/eeade8e89248

Merge

! src/share/vm/runtime/globals.hpp

Changeset: 6eddcbe17c83
Author:    johnc
Date:      2010-09-13 10:00 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/6eddcbe17c83

6981746: G1: SEGV with -XX:+TraceGen0Time
Summary: Pass correct value for length to NumberSeq constructor. Guard dereferences of "body_summary" pointer with a NULL check.
Reviewed-by: tonyp, ysr

! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp

Changeset: 432d823638f7
Author:    jcoomes
Date:      2010-09-15 10:39 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/432d823638f7

6985022: update make/jprt.properties for new jdk7 tools
Reviewed-by: ohair, kvn

! make/jprt.properties

Changeset: 97fbf5beff7b
Author:    johnc
Date:      2010-09-16 13:45 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/97fbf5beff7b

Merge


Changeset: f353275af40e
Author:    never
Date:      2010-09-02 11:40 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/f353275af40e

6981773: incorrect fill value with OptimizeFill
Reviewed-by: kvn, twisti

! src/cpu/sparc/vm/stubGenerator_sparc.cpp

Changeset: d5d065957597
Author:    iveresov
Date:      2010-09-03 17:51 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/d5d065957597

6953144: Tiered compilation
Summary: Infrastructure for tiered compilation support (interpreter + c1 + c2) for 32 and 64 bit. Simple tiered policy implementation.
Reviewed-by: kvn, never, phh, twisti

! make/linux/Makefile
! make/solaris/Makefile
+ make/solaris/makefiles/reorder_TIERED_sparcv9
! make/windows/build.make
! src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp
! src/cpu/sparc/vm/c1_FrameMap_sparc.cpp
! src/cpu/sparc/vm/c1_FrameMap_sparc.hpp
! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp
! src/cpu/sparc/vm/c1_LIRAssembler_sparc.hpp
! src/cpu/sparc/vm/c1_LIRGenerator_sparc.cpp
! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp
! src/cpu/sparc/vm/c1_globals_sparc.hpp
! src/cpu/sparc/vm/c2_globals_sparc.hpp
! src/cpu/sparc/vm/interp_masm_sparc.cpp
! src/cpu/sparc/vm/interp_masm_sparc.hpp
! src/cpu/sparc/vm/sharedRuntime_sparc.cpp
! src/cpu/sparc/vm/templateInterpreter_sparc.cpp
! src/cpu/sparc/vm/templateTable_sparc.cpp
! src/cpu/x86/vm/c1_CodeStubs_x86.cpp
! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp
! src/cpu/x86/vm/c1_LIRAssembler_x86.hpp
! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp
! src/cpu/x86/vm/c1_Runtime1_x86.cpp
! src/cpu/x86/vm/c1_globals_x86.hpp
! src/cpu/x86/vm/c2_globals_x86.hpp
! src/cpu/x86/vm/interp_masm_x86_32.cpp
! src/cpu/x86/vm/interp_masm_x86_32.hpp
! src/cpu/x86/vm/interp_masm_x86_64.cpp
! src/cpu/x86/vm/interp_masm_x86_64.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/x86/vm/vtableStubs_x86_64.cpp
! src/share/vm/c1/c1_Canonicalizer.cpp
! src/share/vm/c1/c1_Canonicalizer.hpp
! src/share/vm/c1/c1_CodeStubs.hpp
! src/share/vm/c1/c1_Compilation.cpp
! src/share/vm/c1/c1_Compilation.hpp
! src/share/vm/c1/c1_Compiler.hpp
! src/share/vm/c1/c1_GraphBuilder.cpp
! src/share/vm/c1/c1_GraphBuilder.hpp
! src/share/vm/c1/c1_IR.cpp
! src/share/vm/c1/c1_Instruction.cpp
! src/share/vm/c1/c1_Instruction.hpp
! src/share/vm/c1/c1_InstructionPrinter.cpp
! src/share/vm/c1/c1_InstructionPrinter.hpp
! src/share/vm/c1/c1_LIR.cpp
! src/share/vm/c1/c1_LIR.hpp
! src/share/vm/c1/c1_LIRAssembler.cpp
! src/share/vm/c1/c1_LIRAssembler.hpp
! src/share/vm/c1/c1_LIRGenerator.cpp
! src/share/vm/c1/c1_LIRGenerator.hpp
! src/share/vm/c1/c1_Optimizer.cpp
! src/share/vm/c1/c1_Runtime1.cpp
! src/share/vm/c1/c1_Runtime1.hpp
! src/share/vm/c1/c1_ValueMap.hpp
! src/share/vm/c1/c1_globals.hpp
! src/share/vm/ci/ciEnv.cpp
! src/share/vm/ci/ciMethod.cpp
! src/share/vm/ci/ciMethod.hpp
! src/share/vm/ci/ciMethodData.cpp
! src/share/vm/ci/ciMethodData.hpp
! src/share/vm/classfile/classLoader.cpp
! src/share/vm/code/nmethod.cpp
! src/share/vm/code/nmethod.hpp
! src/share/vm/compiler/compileBroker.cpp
! src/share/vm/compiler/compileBroker.hpp
! src/share/vm/includeDB_compiler1
! src/share/vm/includeDB_compiler2
! src/share/vm/includeDB_core
! src/share/vm/interpreter/interpreterRuntime.cpp
! src/share/vm/interpreter/invocationCounter.cpp
! src/share/vm/interpreter/invocationCounter.hpp
! src/share/vm/interpreter/linkResolver.cpp
! src/share/vm/oops/instanceKlass.cpp
! src/share/vm/oops/instanceKlass.hpp
! src/share/vm/oops/methodDataOop.cpp
! src/share/vm/oops/methodDataOop.hpp
! src/share/vm/oops/methodKlass.cpp
! src/share/vm/oops/methodOop.cpp
! src/share/vm/oops/methodOop.hpp
! src/share/vm/opto/bytecodeInfo.cpp
! src/share/vm/opto/compile.cpp
! src/share/vm/prims/methodHandleWalk.cpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/arguments.hpp
! src/share/vm/runtime/compilationPolicy.cpp
! src/share/vm/runtime/compilationPolicy.hpp
! src/share/vm/runtime/deoptimization.cpp
! src/share/vm/runtime/deoptimization.hpp
! src/share/vm/runtime/dtraceJSDT.cpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/java.cpp
! src/share/vm/runtime/javaCalls.cpp
! src/share/vm/runtime/safepoint.cpp
! src/share/vm/runtime/safepoint.hpp
+ src/share/vm/runtime/simpleThresholdPolicy.cpp
+ src/share/vm/runtime/simpleThresholdPolicy.hpp
+ src/share/vm/runtime/simpleThresholdPolicy.inline.hpp
! src/share/vm/runtime/sweeper.cpp
! src/share/vm/utilities/accessFlags.hpp
! src/share/vm/utilities/globalDefinitions.hpp
! src/share/vm/utilities/macros.hpp

Changeset: ac4f710073ed
Author:    iveresov
Date:      2010-09-07 14:16 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/ac4f710073ed

6982921: assert(_entry_bci != InvocationEntryBci) failed: wrong kind of nmethod
Summary: Assertion fails during print compilation because nmethod::print_on() calls osr_entry_bci() without checking that the method is an osr method. The fix adds an appropriate check.
Reviewed-by: never, twisti

! src/share/vm/code/nmethod.cpp

Changeset: 5e4f03302987
Author:    never
Date:      2010-09-07 11:31 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/5e4f03302987

6982533: Crash in  ~StubRoutines::jbyte_fill with AggressiveOpts enabled
Reviewed-by: kvn

! src/share/vm/opto/loopTransform.cpp

Changeset: f9883ee8ce39
Author:    never
Date:      2010-09-08 20:28 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/f9883ee8ce39

6965815: OptimizeStringConcat: assert(!q->is_MergeMem()) failed with specjbb2000
Reviewed-by: kvn

! src/share/vm/opto/graphKit.cpp

Changeset: 84713fd87632
Author:    twisti
Date:      2010-09-08 04:50 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/84713fd87632

6983073: fix compiler error with GCC 4.4 or newer on SPARC
Reviewed-by: twisti
Contributed-by: Matthias Klose <doko at ubuntu.com>

! src/cpu/sparc/vm/frame_sparc.hpp

Changeset: 33a54060190d
Author:    twisti
Date:      2010-09-09 01:43 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/33a54060190d

Merge


Changeset: a83b0246bb77
Author:    twisti
Date:      2010-09-09 05:24 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/a83b0246bb77

6934483: GCC 4.5 errors "suggest parentheses around something..." when compiling with -Werror and -Wall
Summary: These are minor changes fixing compile failure when -Wall -Werror flags are used under gcc 4.5.
Reviewed-by: twisti, kvn, rasbold
Contributed-by: Pavel Tisnovsky <ptisnovs at redhat.com>

! src/cpu/x86/vm/vm_version_x86.hpp
! src/share/vm/memory/referenceProcessor.hpp
! src/share/vm/utilities/globalDefinitions.hpp

Changeset: 7f9553bedfd5
Author:    iveresov
Date:      2010-09-11 15:21 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/7f9553bedfd5

6984056: C1: incorrect code for integer constant addition on x64
Summary: Fix add/sub of constants to ints on x64
Reviewed-by: kvn

! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp

Changeset: 3a294e483abc
Author:    iveresov
Date:      2010-09-13 12:10 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/3a294e483abc

6919069: client compiler needs to capture more profile information for tiered work
Summary: Added profiling of instanceof and aastore.
Reviewed-by: kvn, jrose, never

! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp
! src/cpu/sparc/vm/c1_LIRAssembler_sparc.hpp
! src/cpu/sparc/vm/c1_LIRGenerator_sparc.cpp
! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp
! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp
! src/share/vm/c1/c1_Canonicalizer.cpp
! src/share/vm/c1/c1_GraphBuilder.cpp
! src/share/vm/c1/c1_Instruction.hpp
! src/share/vm/c1/c1_LIR.cpp
! src/share/vm/c1/c1_LIR.hpp
! src/share/vm/c1/c1_LIRAssembler.hpp

Changeset: d20603ee9e10
Author:    kvn
Date:      2010-09-13 16:45 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/d20603ee9e10

6984346: Remove development code in type.hpp
Summary: Remove code which use UseNewCode in type.hpp
Reviewed-by: never

! src/share/vm/opto/type.hpp

Changeset: d257356e35f0
Author:    jrose
Date:      2010-09-13 23:24 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/d257356e35f0

6939224: MethodHandle.invokeGeneric needs to perform the correct set of conversions
Reviewed-by: never

! src/cpu/sparc/vm/stubRoutines_sparc.hpp
! src/cpu/x86/vm/assembler_x86.cpp
! src/cpu/x86/vm/methodHandles_x86.cpp
! src/cpu/x86/vm/stubRoutines_x86_32.hpp
! src/cpu/x86/vm/stubRoutines_x86_64.hpp
! src/share/vm/classfile/javaClasses.cpp
! src/share/vm/classfile/javaClasses.hpp
! src/share/vm/classfile/systemDictionary.cpp
! src/share/vm/classfile/systemDictionary.hpp
! src/share/vm/classfile/vmSymbols.hpp
! src/share/vm/interpreter/interpreterRuntime.cpp
! src/share/vm/oops/constantPoolOop.cpp
! src/share/vm/oops/methodOop.cpp
! src/share/vm/oops/methodOop.hpp
! src/share/vm/prims/methodHandleWalk.cpp
! src/share/vm/prims/methodHandles.hpp
! src/share/vm/runtime/sharedRuntime.cpp

Changeset: 065dd1ca3ab6
Author:    never
Date:      2010-09-14 14:09 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/065dd1ca3ab6

6982370: SIGBUS in jbyte_fill
Reviewed-by: kvn

! src/cpu/sparc/vm/stubGenerator_sparc.cpp
+ test/compiler/6982370/Test6982370.java

Changeset: a8b66e00933b
Author:    kvn
Date:      2010-09-14 17:19 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/a8b66e00933b

6984368: Large default heap size does not allow to use zero based compressed oops
Summary: take into account HeapBaseMinAddress and round down MaxPermSize
Reviewed-by: never

! src/share/vm/memory/collectorPolicy.cpp
! src/share/vm/runtime/arguments.cpp

Changeset: 18c378513575
Author:    kvn
Date:      2010-09-16 16:48 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/18c378513575

Merge

! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/utilities/macros.hpp

Changeset: 883a82d6d41d
Author:    acorn
Date:      2010-09-10 12:36 -0400
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/883a82d6d41d

6942092: Loader-constraint test is failing
Summary: Fix test string compare to match source update
Reviewed-by: dcubed, phh

! test/runtime/6626217/Test6626217.sh

Changeset: 6cde0ed1b568
Author:    acorn
Date:      2010-09-14 10:15 -0400
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/6cde0ed1b568

Merge


Changeset: 4094f07967ca
Author:    kamg
Date:      2010-09-15 16:28 -0400
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/4094f07967ca

6974813: JVM needs to use demand loading for its DTrace probes
Summary: Pass -xlazyload to the 'dtrace -G' invocation
Reviewed-by: phh, ysr

! make/solaris/makefiles/dtrace.make

Changeset: 728a287f6c20
Author:    zgu
Date:      2010-09-17 09:45 -0400
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/728a287f6c20

6981753: Rebrand vm vendor property settings
Summary: Uses JDK_Version to determinate to set vm vendor to "Oracle Corporation" for JDK7 and later.
Reviewed-by: kamg, ohair, coleenp

! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/vm_version.cpp

Changeset: 51640ecd89f8
Author:    zgu
Date:      2010-09-17 09:14 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/51640ecd89f8

Merge


Changeset: 3babdb042f25
Author:    kamg
Date:      2010-09-17 19:45 -0400
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/3babdb042f25

Merge


Changeset: 60f88489896f
Author:    kamg
Date:      2010-09-20 15:38 -0400
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/60f88489896f

6975210: java.lang.VerifyError in some of JCK tests
Summary: Naked oop in verificationType::is_reference_assignable_from()
Reviewed-by: never, kvn, coleenp

! src/share/vm/classfile/verificationType.cpp

Changeset: 2966dab85b3e
Author:    dcubed
Date:      2010-09-21 06:58 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/2966dab85b3e

6985848: 3/4 fix for 6561870 causes sa-jdi.jar to be rebuilt every time
Summary: Refine fix for 6561870 to only rebuild sa-jdi.jar when needed
Reviewed-by: never, ohair, coleenp

! make/linux/makefiles/sa.make
! make/solaris/makefiles/sa.make

Changeset: a25394352030
Author:    kamg
Date:      2010-09-22 12:54 -0400
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/a25394352030

Merge

! src/share/vm/runtime/arguments.cpp

Changeset: 9bdbd693dbaa
Author:    trims
Date:      2010-09-24 00:51 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/9bdbd693dbaa

Merge


Changeset: b2045e0af26e
Author:    trims
Date:      2010-09-24 00:52 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/b2045e0af26e

6987149: Fix incorrect Oracle copyright header in make/templates files
Summary: Minor fix to first line of template copyright files
Reviewed-by: ohair

! make/templates/bsd-header
! make/templates/gpl-cp-header
! make/templates/gpl-header

Changeset: 5511edd5d719
Author:    iveresov
Date:      2010-09-30 16:00 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/5511edd5d719

6988779: c1_LIRAssembler_x86.cpp crashes VS2010 compiler
Summary: The workaround changes the scope of the variable
Reviewed-by: phh, ysr, kvn

! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp

Changeset: beef35b96b81
Author:    cl
Date:      2010-10-01 15:45 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/beef35b96b81

Added tag jdk7-b112 for changeset 5511edd5d719

! .hgtags

Changeset: 68d6141ea19d
Author:    cl
Date:      2010-10-07 15:12 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/68d6141ea19d

Added tag jdk7-b113 for changeset beef35b96b81

! .hgtags

Changeset: 477faa484f91
Author:    cl
Date:      2010-10-14 19:24 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/477faa484f91

Added tag jdk7-b114 for changeset 68d6141ea19d

! .hgtags

Changeset: dc7ac21689ba
Author:    mcimadamore
Date:      2010-10-19 11:07 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/dc7ac21689ba

merge with jdk7-b114

- src/share/vm/gc_implementation/parallelScavenge/prefetchQueue.hpp


From maurizio.cimadamore at oracle.com  Tue Oct 19 08:35:18 2010
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Tue, 19 Oct 2010 15:35:18 +0000
Subject: hg: lambda/lambda/jaxp: 18 new changesets
Message-ID: <20101019153519.0652E47288@hg.openjdk.java.net>

Changeset: 5ba8469212a6
Author:    cl
Date:      2010-08-13 11:38 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxp/rev/5ba8469212a6

Added tag jdk7-b105 for changeset 3233b9a4c12e

! .hgtags

Changeset: 20ee37c1372a
Author:    cl
Date:      2010-08-19 15:13 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxp/rev/20ee37c1372a

Added tag jdk7-b106 for changeset 5ba8469212a6

! .hgtags

Changeset: 7d379f8934ca
Author:    cl
Date:      2010-08-26 16:16 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxp/rev/7d379f8934ca

Added tag jdk7-b107 for changeset 20ee37c1372a

! .hgtags

Changeset: 840d6acde4e8
Author:    cl
Date:      2010-09-03 12:49 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxp/rev/840d6acde4e8

Added tag jdk7-b108 for changeset 7d379f8934ca

! .hgtags

Changeset: cc845b339690
Author:    ohair
Date:      2010-09-07 15:15 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxp/rev/cc845b339690

6982946: Change make/jprt.properties to defer to JPRT itself for jdk platform list
Reviewed-by: kamg

! make/jprt.properties

Changeset: 0f382d6120fc
Author:    cl
Date:      2010-09-08 14:04 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxp/rev/0f382d6120fc

Merge


Changeset: d422dbdd0976
Author:    cl
Date:      2010-09-09 15:07 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxp/rev/d422dbdd0976

Added tag jdk7-b109 for changeset 0f382d6120fc

! .hgtags

Changeset: 8106c747067c
Author:    cl
Date:      2010-09-16 15:13 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxp/rev/8106c747067c

Added tag jdk7-b110 for changeset d422dbdd0976

! .hgtags

Changeset: 028a06f776c0
Author:    cl
Date:      2010-09-23 17:33 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxp/rev/028a06f776c0

Added tag jdk7-b111 for changeset 8106c747067c

! .hgtags

Changeset: a3fe5892cd26
Author:    ohair
Date:      2010-09-01 13:28 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxp/rev/a3fe5892cd26

6981408: Upgrade jaxp to 1.4.4
Reviewed-by: darcy
Contributed-by: Joe Wang <huizhe.wang at oracle.com>

! jaxp.properties

Changeset: 4a249814b147
Author:    lana
Date:      2010-09-02 22:09 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxp/rev/4a249814b147

Merge


Changeset: e58a0bea47f6
Author:    ohair
Date:      2010-09-07 15:50 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxp/rev/e58a0bea47f6

Merge


Changeset: b23fd715a158
Author:    lana
Date:      2010-09-16 11:18 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxp/rev/b23fd715a158

Merge


Changeset: 1b0525424288
Author:    lana
Date:      2010-09-24 16:38 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxp/rev/1b0525424288

Merge


Changeset: bc0c84ce54c3
Author:    cl
Date:      2010-10-01 15:45 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxp/rev/bc0c84ce54c3

Added tag jdk7-b112 for changeset 1b0525424288

! .hgtags

Changeset: d57197d22c2b
Author:    cl
Date:      2010-10-07 15:12 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxp/rev/d57197d22c2b

Added tag jdk7-b113 for changeset bc0c84ce54c3

! .hgtags

Changeset: dc1612e1d3ac
Author:    cl
Date:      2010-10-14 19:25 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxp/rev/dc1612e1d3ac

Added tag jdk7-b114 for changeset d57197d22c2b

! .hgtags

Changeset: bfeed086a9c7
Author:    mcimadamore
Date:      2010-10-19 11:07 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxp/rev/bfeed086a9c7

merge with jdk7-b114



From maurizio.cimadamore at oracle.com  Tue Oct 19 08:35:26 2010
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Tue, 19 Oct 2010 15:35:26 +0000
Subject: hg: lambda/lambda/jaxws: 18 new changesets
Message-ID: <20101019153526.97DAE47289@hg.openjdk.java.net>

Changeset: bc45ccc5bcca
Author:    cl
Date:      2010-08-13 11:38 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxws/rev/bc45ccc5bcca

Added tag jdk7-b105 for changeset 39eb4f3031f4

! .hgtags

Changeset: 017612ea6af4
Author:    cl
Date:      2010-08-19 15:13 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxws/rev/017612ea6af4

Added tag jdk7-b106 for changeset bc45ccc5bcca

! .hgtags

Changeset: b1ca39340238
Author:    cl
Date:      2010-08-26 16:16 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxws/rev/b1ca39340238

Added tag jdk7-b107 for changeset 017612ea6af4

! .hgtags

Changeset: ef7838f988c5
Author:    cl
Date:      2010-09-03 12:49 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxws/rev/ef7838f988c5

Added tag jdk7-b108 for changeset b1ca39340238

! .hgtags

Changeset: 06c51671c84b
Author:    ohair
Date:      2010-09-07 15:16 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxws/rev/06c51671c84b

6982946: Change make/jprt.properties to defer to JPRT itself for jdk platform list
Reviewed-by: kamg

! make/jprt.properties

Changeset: 4f626e0d70bd
Author:    cl
Date:      2010-09-08 14:04 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxws/rev/4f626e0d70bd

Merge


Changeset: 95ecac35fb11
Author:    cl
Date:      2010-09-09 15:07 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxws/rev/95ecac35fb11

Added tag jdk7-b109 for changeset 4f626e0d70bd

! .hgtags

Changeset: 2575ebca96c7
Author:    cl
Date:      2010-09-16 15:13 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxws/rev/2575ebca96c7

Added tag jdk7-b110 for changeset 95ecac35fb11

! .hgtags

Changeset: 3c8627862d07
Author:    cl
Date:      2010-09-23 17:33 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxws/rev/3c8627862d07

Added tag jdk7-b111 for changeset 2575ebca96c7

! .hgtags

Changeset: c6c2f9094bdd
Author:    ohair
Date:      2010-08-30 16:00 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxws/rev/c6c2f9094bdd

6962317: jdk7 jaxws source bundle still needs rebranding
6955300: Missing files in the jaf source bundle
Reviewed-by: ramap

! jaxws.properties

Changeset: 5dd2cc894d0c
Author:    lana
Date:      2010-09-02 22:09 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxws/rev/5dd2cc894d0c

Merge


Changeset: 74737bd256fa
Author:    ohair
Date:      2010-09-07 15:51 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxws/rev/74737bd256fa

Merge


Changeset: 4635da51e3cb
Author:    lana
Date:      2010-09-16 11:18 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxws/rev/4635da51e3cb

Merge


Changeset: 8e0f0054817f
Author:    lana
Date:      2010-09-24 16:38 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxws/rev/8e0f0054817f

Merge


Changeset: d35c94fd2236
Author:    cl
Date:      2010-10-01 15:45 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxws/rev/d35c94fd2236

Added tag jdk7-b112 for changeset 8e0f0054817f

! .hgtags

Changeset: 400f494c81c5
Author:    cl
Date:      2010-10-07 15:12 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxws/rev/400f494c81c5

Added tag jdk7-b113 for changeset d35c94fd2236

! .hgtags

Changeset: 824cc44bd6eb
Author:    cl
Date:      2010-10-14 19:25 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxws/rev/824cc44bd6eb

Added tag jdk7-b114 for changeset 400f494c81c5

! .hgtags

Changeset: 3f61197b38c8
Author:    mcimadamore
Date:      2010-10-19 11:07 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxws/rev/3f61197b38c8

merge with jdk7-b114



From maurizio.cimadamore at Oracle.COM  Tue Oct 19 08:41:07 2010
From: maurizio.cimadamore at Oracle.COM (Maurizio Cimadamore)
Date: Tue, 19 Oct 2010 16:41:07 +0100
Subject: Lambdas and serialization
In-Reply-To: <4CBDBCC1.9020706@univ-mlv.fr>
References: <AANLkTin4ig6HgmoVwSpgRwOcY8ozGdZrz=u8SGBj8-Sj@mail.gmail.com>	<AANLkTinKKTZWF0oH7LKDBXj8vrsd2_tWk7=1ZC1jk7P+@mail.gmail.com>	<AANLkTi=r1C4yg+xgedauvDPGgf5AMGWsmcmDPZa-Hh_7@mail.gmail.com>	<4CBDA6E7.1050501@oracle.com>
	<4CBDBCC1.9020706@univ-mlv.fr>
Message-ID: <4CBDBC13.8060601@oracle.com>

On 19/10/10 16:44, R?mi Forax wrote:
> Le 19/10/2010 16:10, Maurizio Cimadamore a ?crit :
>    
>> On 19/10/10 14:41, Alessio Stalla wrote:
>>
>>      
>>> On Tue, Oct 19, 2010 at 3:30 PM, Paul Benedict<pbenedict at apache.org>    wrote:
>>>
>>>
>>>        
>>>> Will the wrapper be serializable if the SAM interface is? That's a
>>>> good question, but I imagine it has to be because it is implementing
>>>> the interface.
>>>>
>>>> public interface MySamType extends Serializable {
>>>>     void doSomething(int x);
>>>> }
>>>>
>>>>
>>>>          
>>> Sorry, I was unclear with the expression "be serializable": what I
>>> really meant is not if it will merely implement java.io.Serializable,
>>> rather if it will actually be serialized by an ObjectOutputStream
>>> without any exception in all cases where a "regular" instance of the
>>> SAM would have been serialized without exceptions, and deserialized in
>>> the same conditions as well. That's imho a desirable feature to have,
>>> but it places a possibly non-trivial burden on the implementation.
>>>
>>>
>>>
>>>        
>> Good point. The short answer to this question is: it depends on how
>> lambda expressions are translated by the compiler. If the compiler uses
>> anonymous inner classes to translate away lambda expression, then the
>> answer is yes. If lambda expressions are to be translated away by using
>> method handles, then I *guess* the answer is no, as it seems like
>> MethodHandle are not serializable (Remi or John might know more about
>> this though).
>>
>> Maurizio
>>
>>      
> Lambda are not serializable, like java.lang.reflect.Method
> because it will create tons of security holes.
>    
You mean method handles are not serializable? What are the security 
holes deriving from serializable lambda (assuming latest Brian's document) ?

Maurizio
> BTW, inner classes have some trouble with serialUID.
>
> R?mi
>
>    


From alessiostalla at gmail.com  Tue Oct 19 08:45:39 2010
From: alessiostalla at gmail.com (Alessio Stalla)
Date: Tue, 19 Oct 2010 17:45:39 +0200
Subject: Lambdas and serialization
In-Reply-To: <4CBDBCC1.9020706@univ-mlv.fr>
References: <AANLkTin4ig6HgmoVwSpgRwOcY8ozGdZrz=u8SGBj8-Sj@mail.gmail.com>
	<AANLkTinKKTZWF0oH7LKDBXj8vrsd2_tWk7=1ZC1jk7P+@mail.gmail.com>
	<AANLkTi=r1C4yg+xgedauvDPGgf5AMGWsmcmDPZa-Hh_7@mail.gmail.com>
	<4CBDA6E7.1050501@oracle.com> <4CBDBCC1.9020706@univ-mlv.fr>
Message-ID: <AANLkTik6UVNLyTbbYUfwfgUwycM17528cvt1fJOTOeJM@mail.gmail.com>

On Tue, Oct 19, 2010 at 5:44 PM, R?mi Forax <forax at univ-mlv.fr> wrote:
> Le 19/10/2010 16:10, Maurizio Cimadamore a ?crit :
>> On 19/10/10 14:41, Alessio Stalla wrote:
>>
>>> On Tue, Oct 19, 2010 at 3:30 PM, Paul Benedict<pbenedict at apache.org> ? wrote:
>>>
>>>
>>>> Will the wrapper be serializable if the SAM interface is? That's a
>>>> good question, but I imagine it has to be because it is implementing
>>>> the interface.
>>>>
>>>> public interface MySamType extends Serializable {
>>>> ? ?void doSomething(int x);
>>>> }
>>>>
>>>>
>>> Sorry, I was unclear with the expression "be serializable": what I
>>> really meant is not if it will merely implement java.io.Serializable,
>>> rather if it will actually be serialized by an ObjectOutputStream
>>> without any exception in all cases where a "regular" instance of the
>>> SAM would have been serialized without exceptions, and deserialized in
>>> the same conditions as well. That's imho a desirable feature to have,
>>> but it places a possibly non-trivial burden on the implementation.
>>>
>>>
>>>
>> Good point. The short answer to this question is: it depends on how
>> lambda expressions are translated by the compiler. If the compiler uses
>> anonymous inner classes to translate away lambda expression, then the
>> answer is yes. If lambda expressions are to be translated away by using
>> method handles, then I *guess* the answer is no, as it seems like
>> MethodHandle are not serializable (Remi or John might know more about
>> this though).
>>
>> Maurizio
>>
>
> Lambda are not serializable, like java.lang.reflect.Method
> because it will create tons of security holes.

Do you care to elaborate? Are you thinking about malicious code
serializing a Method, changing the serialized bytes in order to alter
some object used for security checks, deserializing the Method, and
calling it? This, I think, could be avoided by customizing the
serialization of Methods to do security checks before serializing, as
if the method had been called, so that no untrusted code will be able
to serialize a method if it has no privilege to call it in the first
place. Maybe not easy, but doable in principle, I think.

> BTW, inner classes have some trouble with serialUID.

Hmm, could you explain that too? Inner classes are normal classes at
the JVM level...

Regards,
Alessio

From maurizio.cimadamore at oracle.com  Tue Oct 19 08:35:57 2010
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Tue, 19 Oct 2010 15:35:57 +0000
Subject: hg: lambda/lambda/jdk: 202 new changesets
Message-ID: <20101019160915.D4F534728B@hg.openjdk.java.net>

Changeset: 9ad95be9deae
Author:    cl
Date:      2010-08-13 11:38 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/9ad95be9deae

Added tag jdk7-b105 for changeset 3b0abcb51280

! .hgtags

Changeset: f8bbf376595c
Author:    yhuang
Date:      2010-08-11 02:22 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/f8bbf376595c

6959252: convert the anonymous arrays to named arrays in Java List Resource files
Reviewed-by: katakai, psun

! src/share/classes/com/sun/tools/example/debug/tty/TTYResources.java
! src/share/classes/sun/applet/resources/MsgAppletViewer.java
! src/share/classes/sun/tools/jconsole/resources/JConsoleResources.java
! src/share/classes/sun/tools/native2ascii/resources/MsgNative2ascii.java

Changeset: 413cede85120
Author:    yhuang
Date:      2010-08-13 01:09 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/413cede85120

Merge

- test/java/net/Socket/AccurateTimeout.java

Changeset: b91ef6b60f4e
Author:    cl
Date:      2010-08-16 14:47 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/b91ef6b60f4e

Merge


Changeset: 882103f334bb
Author:    cl
Date:      2010-08-19 15:13 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/882103f334bb

Added tag jdk7-b106 for changeset b91ef6b60f4e

! .hgtags

Changeset: 17a5d84b7561
Author:    cl
Date:      2010-08-26 16:17 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/17a5d84b7561

Added tag jdk7-b107 for changeset 882103f334bb

! .hgtags

Changeset: d47bd9d94ba4
Author:    dlila
Date:      2010-08-10 13:19 -0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/d47bd9d94ba4

6967436: lines longer than 2^15 can fill window.
6967433: dashed lines broken when using scaling transforms.
Summary: converted pisces to floating point. Also, using better AA algorithm
Reviewed-by: flar

! src/share/classes/sun/java2d/pisces/Dasher.java
! src/share/classes/sun/java2d/pisces/LineSink.java
- src/share/classes/sun/java2d/pisces/PiscesMath.java
! src/share/classes/sun/java2d/pisces/PiscesRenderingEngine.java
! src/share/classes/sun/java2d/pisces/Renderer.java
! src/share/classes/sun/java2d/pisces/Stroker.java
- src/share/classes/sun/java2d/pisces/Transform4.java

Changeset: 4285edea9ddb
Author:    dlila
Date:      2010-08-11 10:05 -0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/4285edea9ddb

6976265: No STROKE_CONTROL
Summary: implemented it in sun.java2d.pisces by adding a PathIterator.
Reviewed-by: flar

! src/share/classes/sun/java2d/pisces/PiscesRenderingEngine.java

Changeset: 0576f6cc0463
Author:    lana
Date:      2010-08-12 19:55 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/0576f6cc0463

Merge

- test/java/net/Socket/AccurateTimeout.java

Changeset: 654145d6560a
Author:    lana
Date:      2010-08-23 19:12 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/654145d6560a

Merge

- src/share/classes/sun/java2d/pisces/PiscesMath.java
- src/share/classes/sun/java2d/pisces/Transform4.java

Changeset: d0e314d59f84
Author:    malenkov
Date:      2010-08-10 19:29 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/d0e314d59f84

6960267: JTable.getRowHeight() returns value different from the specified default (16.0) with GTK L&F
Reviewed-by: peterz

! src/share/classes/javax/swing/JTable.java

Changeset: 58626b4eedcb
Author:    lana
Date:      2010-08-12 11:23 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/58626b4eedcb

Merge

- test/java/net/Socket/AccurateTimeout.java

Changeset: 23f72ec0d8e8
Author:    peytoia
Date:      2010-08-23 14:14 +0900
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/23f72ec0d8e8

6977550: (tz) Support tzdata2010l
Reviewed-by: okutsu

! make/sun/javazic/tzdata/VERSION
! make/sun/javazic/tzdata/africa
! make/sun/javazic/tzdata/asia
! make/sun/javazic/tzdata/australasia
! make/sun/javazic/tzdata/backward
! make/sun/javazic/tzdata/europe
! make/sun/javazic/tzdata/leapseconds
! make/sun/javazic/tzdata/northamerica
! make/sun/javazic/tzdata/zone.tab
! src/share/classes/sun/util/resources/TimeZoneNames.java
! src/share/classes/sun/util/resources/TimeZoneNames_de.java
! src/share/classes/sun/util/resources/TimeZoneNames_es.java
! src/share/classes/sun/util/resources/TimeZoneNames_fr.java
! src/share/classes/sun/util/resources/TimeZoneNames_it.java
! src/share/classes/sun/util/resources/TimeZoneNames_ja.java
! src/share/classes/sun/util/resources/TimeZoneNames_ko.java
! src/share/classes/sun/util/resources/TimeZoneNames_sv.java
! src/share/classes/sun/util/resources/TimeZoneNames_zh_CN.java
! src/share/classes/sun/util/resources/TimeZoneNames_zh_TW.java

Changeset: a18a82d2d506
Author:    lana
Date:      2010-08-23 19:13 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/a18a82d2d506

Merge


Changeset: 367b90ed38b1
Author:    chegar
Date:      2010-08-03 12:03 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/367b90ed38b1

6973030: NTLM proxy authentication fails with https
Reviewed-by: michaelm

! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java
! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/B6226610.java

Changeset: a21c46dac6cf
Author:    mullan
Date:      2010-08-03 09:39 -0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/a21c46dac6cf

6653372: Error in java.security.KeyStore example code
Reviewed-by: weijun

! src/share/classes/java/security/KeyStore.java

Changeset: 2feeefb45a44
Author:    mullan
Date:      2010-08-03 09:55 -0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/2feeefb45a44

Merge


Changeset: 3b63e506b57e
Author:    martin
Date:      2010-08-03 12:22 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/3b63e506b57e

6955504: (str) String[Builder/Buffer].append(char[],int,int) throws OutOfMemoryError in b94
Summary: let arraycopy throw AIOOBE for invalid negative length
Reviewed-by: chegar, forax

! src/share/classes/java/lang/AbstractStringBuilder.java

Changeset: 188f156148ea
Author:    apangin
Date:      2010-08-04 20:25 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/188f156148ea

6945961: SIGSEGV in memcpy() during class loading on linux-i586
Summary: Check the result of strchr() in Bytecode Verifier
Reviewed-by: kamg, acorn

! src/share/native/common/check_code.c

Changeset: d47f5dcda481
Author:    dcubed
Date:      2010-08-06 11:07 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/d47f5dcda481

6962604: 3/3 Testcase sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.sh failure
Summary: Disable MonitorVmStartTerminate.sh until 6543856 is fixed.
Reviewed-by: ohair

! test/sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.sh

Changeset: 3e239fe92832
Author:    lancea
Date:      2010-08-10 10:07 -0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/3e239fe92832

6898593: java.sql.Date.valueOf no exception if date given is not in the JDBC date escape syntax
Reviewed-by: minqi

! src/share/classes/java/sql/Date.java

Changeset: 1f996198877b
Author:    chegar
Date:      2010-08-10 17:30 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/1f996198877b

6882910: Unexplained lack of IP4 network ability when transparent IP6 to IP4 is disabled.
Reviewed-by: alanb

! src/solaris/native/java/net/PlainDatagramSocketImpl.c
! src/solaris/native/java/net/PlainSocketImpl.c
! src/solaris/native/sun/nio/ch/Net.c

Changeset: da5b67ac7755
Author:    sherman
Date:      2010-08-10 13:15 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/da5b67ac7755

6923794: About 40 JCK test case fail with AssertionError if -esa option is specified
Summary: removed the assert
Reviewed-by: alanb

! src/solaris/classes/java/io/UnixFileSystem.java
! src/windows/classes/java/io/Win32FileSystem.java

Changeset: 11ee8b471f9c
Author:    alanb
Date:      2010-08-12 19:53 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/11ee8b471f9c

6971825: (so) improve scatter/gather implementation
Reviewed-by: chegar, sherman

! src/share/classes/sun/nio/ch/DatagramChannelImpl.java
! src/share/classes/sun/nio/ch/FileChannelImpl.java
! src/share/classes/sun/nio/ch/IOUtil.java
! src/share/classes/sun/nio/ch/IOVecWrapper.java
! src/share/classes/sun/nio/ch/SocketChannelImpl.java
! src/share/classes/sun/nio/ch/Util.java

Changeset: 389bc53d0945
Author:    mchung
Date:      2010-08-12 16:36 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/389bc53d0945

6973831: NPE when printing stack trace of OOME
Summary: Initialize suppressedExceptions field to null
Reviewed-by: briangoetz, dholmes, forax

! src/share/classes/java/lang/Throwable.java

Changeset: cdd6d518f47e
Author:    mchung
Date:      2010-08-12 16:47 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/cdd6d518f47e

Merge


Changeset: 041997c49f15
Author:    lana
Date:      2010-08-12 19:58 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/041997c49f15

Merge


Changeset: 0cdd73548292
Author:    gbenson
Date:      2010-08-13 22:26 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/0cdd73548292

6976186: Integrate Shark
Summary: Shark is a JIT compiler for Zero that uses the LLVM compiler infrastructure.
Reviewed-by: ohair

! make/jdk_generic_profile.sh

Changeset: 8329ebeabc10
Author:    mchung
Date:      2010-08-16 15:36 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/8329ebeabc10

6921234: TEST_BUG: java/lang/ClassLoader/deadlock/TestCrossDelegate.sh needs to be modified for Cygwin
Summary: Add check for CYGWIN
Reviewed-by: ohair

! test/java/lang/ClassLoader/deadlock/TestCrossDelegate.sh

Changeset: 42eaa082a4e6
Author:    michaelm
Date:      2010-08-17 14:49 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/42eaa082a4e6

6339649: URI.create should include a detail message when throwing IllegalArgumentException
Summary: create enclosing exception with message of enclosed
Reviewed-by: alanb, chegar

! src/share/classes/java/net/URI.java
! test/java/net/URI/Test.java

Changeset: bfc3855a9341
Author:    sherman
Date:      2010-08-17 16:01 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/bfc3855a9341

6969651: TEST_BUG: tools/jar/JarEntryTime.java failed on JDK7 when run on NFS
Summary: changed to use more appropriate nfs file time
Reviewed-by: martin

! test/tools/jar/JarEntryTime.java

Changeset: 01dec49e95c4
Author:    ohair
Date:      2010-08-18 13:46 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/01dec49e95c4

6974005: Use of cygpath in Makefile logic needs to silence error messages
Reviewed-by: mchung

! make/common/shared/Defs-windows.gmk

Changeset: 42bfa43f2ae1
Author:    ohair
Date:      2010-08-18 13:46 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/42bfa43f2ae1

6932743: Makefiles not parsing version strings with - from uname -r
Reviewed-by: mchung

! make/common/shared/Defs.gmk

Changeset: 4abd65f04638
Author:    weijun
Date:      2010-08-19 11:26 +0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/4abd65f04638

6976536: Solaris JREs do not have the krb5.kdc.bad.policy configured by default.
Reviewed-by: valeriep

! src/share/lib/security/java.security-solaris
! src/share/lib/security/java.security-windows
+ test/sun/security/krb5/BadKdcDefaultValue.java

Changeset: 95bb147c7c33
Author:    weijun
Date:      2010-08-19 12:24 +0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/95bb147c7c33

6921610: 1.6 update 17 and 18 throw java.lang.IndexOutOfBoundsException
Reviewed-by: vinnie, xuelei

! src/share/classes/com/sun/jndi/ldap/Connection.java

Changeset: 1ce9c1690080
Author:    ksrini
Date:      2010-08-19 14:08 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/1ce9c1690080

6888127: java.util.jar.Pack200.Packer Memory Leak
Reviewed-by: jrose

! src/share/classes/com/sun/java/util/jar/pack/Attribute.java
! src/share/classes/com/sun/java/util/jar/pack/ConstantPool.java
! src/share/classes/com/sun/java/util/jar/pack/Driver.java
! src/share/classes/com/sun/java/util/jar/pack/NativeUnpack.java
! src/share/classes/com/sun/java/util/jar/pack/Package.java
! src/share/classes/com/sun/java/util/jar/pack/PackerImpl.java
+ src/share/classes/com/sun/java/util/jar/pack/TLGlobals.java
! src/share/classes/com/sun/java/util/jar/pack/UnpackerImpl.java
! src/share/classes/com/sun/java/util/jar/pack/Utils.java

Changeset: 16e43f336262
Author:    ksrini
Date:      2010-08-20 08:18 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/16e43f336262

6966737: (pack200) the pack200 regression tests need to be more robust.
Reviewed-by: jrose, ohair

+ test/tools/pack200/CommandLineTests.java
- test/tools/pack200/Pack200Simple.sh
! test/tools/pack200/Pack200Test.java
! test/tools/pack200/PackageVersionTest.java
! test/tools/pack200/SegmentLimit.java
+ test/tools/pack200/Utils.java
+ test/tools/pack200/pack200-verifier/data/README
+ test/tools/pack200/pack200-verifier/data/golden.jar
+ test/tools/pack200/pack200-verifier/make/build.xml
+ test/tools/pack200/pack200-verifier/src/sun/tools/pack/verify/ClassCompare.java
+ test/tools/pack200/pack200-verifier/src/sun/tools/pack/verify/Globals.java
+ test/tools/pack200/pack200-verifier/src/sun/tools/pack/verify/JarFileCompare.java
+ test/tools/pack200/pack200-verifier/src/sun/tools/pack/verify/Main.java
+ test/tools/pack200/pack200-verifier/src/sun/tools/pack/verify/VerifyTreeSet.java
+ test/tools/pack200/pack200-verifier/src/xmlkit/ClassReader.java
+ test/tools/pack200/pack200-verifier/src/xmlkit/ClassSyntax.java
+ test/tools/pack200/pack200-verifier/src/xmlkit/ClassWriter.java
+ test/tools/pack200/pack200-verifier/src/xmlkit/CommandLineParser.java
+ test/tools/pack200/pack200-verifier/src/xmlkit/InstructionAssembler.java
+ test/tools/pack200/pack200-verifier/src/xmlkit/InstructionSyntax.java
+ test/tools/pack200/pack200-verifier/src/xmlkit/TokenList.java
+ test/tools/pack200/pack200-verifier/src/xmlkit/XMLKit.java

Changeset: db1b7c10de61
Author:    ksrini
Date:      2010-08-20 08:49 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/db1b7c10de61

Merge


Changeset: fd28003bc1d6
Author:    chegar
Date:      2010-08-23 14:35 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/fd28003bc1d6

6968584: Thread should not be Cloneable
Reviewed-by: dholmes

! src/share/classes/java/lang/Thread.java

Changeset: 03218163f4d5
Author:    chegar
Date:      2010-08-23 16:27 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/03218163f4d5

6965924: java.net.HttpCookie using static SimpleDateFormat which is not thread safe
Reviewed-by: michaelm

! src/share/classes/java/net/HttpCookie.java

Changeset: 47ab0dcec3e8
Author:    alanb
Date:      2010-08-23 17:11 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/47ab0dcec3e8

6978511: (file) Path.toRealPath should fail if not resolving links and file does not exist
Reviewed-by: forax, chegar

! src/solaris/classes/sun/nio/fs/UnixPath.java
! test/java/nio/file/Path/Misc.java

Changeset: f4a2b4e7a831
Author:    alanb
Date:      2010-08-23 17:35 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/f4a2b4e7a831

6431344: (fc) FileChannel.transferTo() doesn't work if address space runs out
Reviewed-by: forax, chegar

! src/share/classes/sun/nio/ch/FileChannelImpl.java

Changeset: 6317f7e2c4fd
Author:    ksrini
Date:      2010-08-23 08:18 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/6317f7e2c4fd

6531345: Memory leak in unpack200
Reviewed-by: jrose

! src/share/classes/com/sun/java/util/jar/pack/NativeUnpack.java
+ test/tools/pack200/UnpackerMemoryTest.java
! test/tools/pack200/Utils.java

Changeset: cb67f0263bd4
Author:    chegar
Date:      2010-08-23 21:59 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/cb67f0263bd4

6977851: NPE from FileURLConnection.connect
Reviewed-by: michaelm

! src/share/classes/sun/net/www/protocol/file/FileURLConnection.java
+ test/sun/net/www/protocol/file/DirPermissionDenied.java
+ test/sun/net/www/protocol/file/DirPermissionDenied.sh

Changeset: 2585368bfc7c
Author:    ksrini
Date:      2010-08-23 10:19 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/2585368bfc7c

6969063: (pack200) The default value of Pack200.Packer.SEGMENT_LIMIT property is empty string instead of -1
Reviewed-by: jrose

! src/share/classes/com/sun/java/util/jar/pack/PropMap.java
+ test/tools/pack200/Pack200Props.java
- test/tools/pack200/SegmentLimit.java

Changeset: 732f59013e78
Author:    ksrini
Date:      2010-08-23 10:47 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/732f59013e78

6966740: (pack200) need to add the timezone regression test
Reviewed-by: jrose

+ test/tools/pack200/TimeStamp.java
! test/tools/pack200/Utils.java

Changeset: 62d37c19c213
Author:    lana
Date:      2010-08-23 19:14 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/62d37c19c213

Merge

- test/tools/pack200/Pack200Simple.sh
- test/tools/pack200/SegmentLimit.java

Changeset: 043d2736d44c
Author:    lana
Date:      2010-08-29 22:41 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/043d2736d44c

Merge

- src/share/classes/sun/java2d/pisces/PiscesMath.java
- src/share/classes/sun/java2d/pisces/Transform4.java
- test/tools/pack200/Pack200Simple.sh
- test/tools/pack200/SegmentLimit.java

Changeset: df049d0b973f
Author:    ohair
Date:      2010-09-07 15:17 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/df049d0b973f

6982946: Change make/jprt.properties to defer to JPRT itself for jdk platform list
Reviewed-by: kamg

! make/jprt.properties

Changeset: 4571856d4628
Author:    cl
Date:      2010-09-03 12:50 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/4571856d4628

Added tag jdk7-b108 for changeset 17a5d84b7561

! .hgtags

Changeset: ab0d3f54a63f
Author:    cl
Date:      2010-09-09 13:48 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/ab0d3f54a63f

Merge


Changeset: 3937dd29f45a
Author:    cl
Date:      2010-09-09 15:07 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/3937dd29f45a

Added tag jdk7-b109 for changeset ab0d3f54a63f

! .hgtags

Changeset: c5f6cd3bd70b
Author:    ohair
Date:      2010-09-08 15:12 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/c5f6cd3bd70b

6974017: Upgrade required Solaris Studio compilers to 5.10 (12 update 1 + patches)
Reviewed-by: jcoomes

! make/common/shared/Compiler-sun.gmk
! make/common/shared/Defs-versions.gmk

Changeset: 8f5a6ea8c9e9
Author:    ohair
Date:      2010-09-09 16:26 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/8f5a6ea8c9e9

6982137: Rebranding pass 2 - missed copyright changes
Reviewed-by: mbykov

! make/templates/gpl-cp-header
! make/templates/gpl-header
! src/share/classes/java/lang/CharacterName.java
! src/share/classes/sun/font/GlyphDisposedListener.java
! src/share/classes/sun/jvmstat/monitor/Units.java
! src/share/classes/sun/jvmstat/monitor/Variability.java
! src/solaris/classes/sun/font/XRGlyphCache.java
! src/solaris/classes/sun/font/XRGlyphCacheEntry.java
! src/solaris/classes/sun/font/XRTextRenderer.java
! src/solaris/classes/sun/java2d/jules/IdleTileCache.java
! src/solaris/classes/sun/java2d/jules/JulesAATileGenerator.java
! src/solaris/classes/sun/java2d/jules/JulesPathBuf.java
! src/solaris/classes/sun/java2d/jules/JulesRenderingEngine.java
! src/solaris/classes/sun/java2d/jules/JulesShapePipe.java
! src/solaris/classes/sun/java2d/jules/JulesTile.java
! src/solaris/classes/sun/java2d/jules/TileWorker.java
! src/solaris/classes/sun/java2d/jules/TrapezoidList.java
! src/solaris/classes/sun/java2d/xr/DirtyRegion.java
! src/solaris/classes/sun/java2d/xr/GrowableByteArray.java
! src/solaris/classes/sun/java2d/xr/GrowableEltArray.java
! src/solaris/classes/sun/java2d/xr/GrowableIntArray.java
! src/solaris/classes/sun/java2d/xr/GrowablePointArray.java
! src/solaris/classes/sun/java2d/xr/GrowableRectArray.java
! src/solaris/classes/sun/java2d/xr/MaskTile.java
! src/solaris/classes/sun/java2d/xr/MaskTileManager.java
! src/solaris/classes/sun/java2d/xr/MutableInteger.java
! src/solaris/classes/sun/java2d/xr/XIDGenerator.java
! src/solaris/classes/sun/java2d/xr/XRBackend.java
! src/solaris/classes/sun/java2d/xr/XRBackendNative.java
! src/solaris/classes/sun/java2d/xr/XRColor.java
! src/solaris/classes/sun/java2d/xr/XRCompositeManager.java
! src/solaris/classes/sun/java2d/xr/XRDrawImage.java
! src/solaris/classes/sun/java2d/xr/XRGraphicsConfig.java
! src/solaris/classes/sun/java2d/xr/XRMaskBlit.java
! src/solaris/classes/sun/java2d/xr/XRMaskFill.java
! src/solaris/classes/sun/java2d/xr/XRMaskImage.java
! src/solaris/classes/sun/java2d/xr/XRPMBlitLoops.java
! src/solaris/classes/sun/java2d/xr/XRPaints.java
! src/solaris/classes/sun/java2d/xr/XRRenderer.java
! src/solaris/classes/sun/java2d/xr/XRSurfaceData.java
! src/solaris/classes/sun/java2d/xr/XRSurfaceDataProxy.java
! src/solaris/classes/sun/java2d/xr/XRUtils.java
! src/solaris/classes/sun/java2d/xr/XRVolatileSurfaceManager.java
! src/solaris/classes/sun/java2d/xr/XcbRequestCounter.java
! src/solaris/native/sun/java2d/x11/XRBackendNative.c
! src/solaris/native/sun/java2d/x11/XRSurfaceData.c
! test/com/sun/java/swing/plaf/gtk/Test6963870.java
! test/java/lang/StringBuffer/Capacity.java
! test/java/security/cert/CertificateFactory/openssl/BadFooter.java
! test/java/util/zip/GZIP/GZIPInputStreamRead.java
! test/javax/swing/JFormattedTextField/Test6462562.java
! test/javax/swing/JTabbedPane/6670274/bug6670274.java
! test/javax/swing/JTable/6768387/bug6768387.java
! test/javax/swing/JTable/6788484/bug6788484.java
! test/javax/swing/JTable/6937798/bug6937798.java
! test/javax/swing/JTableHeader/6884066/bug6884066.java
! test/javax/swing/JTableHeader/6889007/bug6889007.java
! test/javax/swing/JTextArea/6925473/bug6925473.java
! test/javax/swing/JTextArea/6940863/bug6940863.java
! test/javax/swing/JViewport/6953396/bug6953396.java
! test/javax/swing/border/Test6910490.java
! test/javax/swing/plaf/synth/SynthToolBarUI/6739756/bug6739756.java
! test/javax/swing/text/WrappedPlainView/6857057/StubBranchElement.java
! test/javax/swing/text/WrappedPlainView/6857057/StubLeafElement.java
! test/javax/swing/text/WrappedPlainView/6857057/bug6857057.java
! test/sun/security/krb5/MicroTime.java

Changeset: 448387146bb8
Author:    yhuang
Date:      2010-09-09 23:01 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/448387146bb8

6980510: Fix for 6959252 broke JConsole mnemonic keys
Reviewed-by: mfang, yhuang

! src/share/classes/sun/tools/jconsole/resources/JConsoleResources.java

Changeset: 9a1549d682ce
Author:    yhuang
Date:      2010-09-09 23:30 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/9a1549d682ce

Merge


Changeset: 4aaac9fb2293
Author:    yhuang
Date:      2010-09-13 02:54 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/4aaac9fb2293

Merge


Changeset: 176586cd040e
Author:    kamg
Date:      2010-09-13 13:10 -0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/176586cd040e

6983225: libjvm_db.so is not imported into solaris-x86 builds, and libjvm_dtrace.so not imported at all.
Summary: Removed sparc-only libjvm_db code and added rules for libjvm_dtrace
Reviewed-by: ohair

! make/java/redist/Makefile

Changeset: fb63a2688db8
Author:    cl
Date:      2010-09-16 15:13 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/fb63a2688db8

Added tag jdk7-b110 for changeset 176586cd040e

! .hgtags

Changeset: c2cdc8c94b65
Author:    cl
Date:      2010-09-23 17:33 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/c2cdc8c94b65

Added tag jdk7-b111 for changeset fb63a2688db8

! .hgtags

Changeset: d4012b86a6e9
Author:    bae
Date:      2010-09-07 16:54 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/d4012b86a6e9

6972495: javax/imageio/CachePremissionsTest/CachePermissionsTest.java failed
Reviewed-by: prr

! test/javax/imageio/CachePremissionsTest/CachePermissionsTest.java

Changeset: fd7eb86ac690
Author:    bae
Date:      2010-09-09 16:20 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/fd7eb86ac690

6523398: OSS CMM: Need to implement writing ICC profile tags in new lcms library
Reviewed-by: igor, prr

! make/sun/cmm/lcms/FILES_c_unix.gmk
! make/sun/cmm/lcms/FILES_c_windows.gmk
! make/sun/cmm/lcms/Makefile
! src/share/classes/sun/java2d/cmm/CMSManager.java
! src/share/classes/sun/java2d/cmm/lcms/LCMS.java
! src/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java
! src/share/native/sun/java2d/cmm/lcms/LCMS.c
! src/share/native/sun/java2d/cmm/lcms/cmscam02.c
- src/share/native/sun/java2d/cmm/lcms/cmscam97.c
! src/share/native/sun/java2d/cmm/lcms/cmscgats.c
! src/share/native/sun/java2d/cmm/lcms/cmscnvrt.c
! src/share/native/sun/java2d/cmm/lcms/cmserr.c
! src/share/native/sun/java2d/cmm/lcms/cmsgamma.c
! src/share/native/sun/java2d/cmm/lcms/cmsgmt.c
! src/share/native/sun/java2d/cmm/lcms/cmsintrp.c
! src/share/native/sun/java2d/cmm/lcms/cmsio0.c
! src/share/native/sun/java2d/cmm/lcms/cmsio1.c
! src/share/native/sun/java2d/cmm/lcms/cmslut.c
- src/share/native/sun/java2d/cmm/lcms/cmsmatsh.c
+ src/share/native/sun/java2d/cmm/lcms/cmsmd5.c
! src/share/native/sun/java2d/cmm/lcms/cmsmtrx.c
! src/share/native/sun/java2d/cmm/lcms/cmsnamed.c
+ src/share/native/sun/java2d/cmm/lcms/cmsopt.c
! src/share/native/sun/java2d/cmm/lcms/cmspack.c
! src/share/native/sun/java2d/cmm/lcms/cmspcs.c
+ src/share/native/sun/java2d/cmm/lcms/cmsplugin.c
! src/share/native/sun/java2d/cmm/lcms/cmsps2.c
! src/share/native/sun/java2d/cmm/lcms/cmssamp.c
+ src/share/native/sun/java2d/cmm/lcms/cmssm.c
+ src/share/native/sun/java2d/cmm/lcms/cmstypes.c
! src/share/native/sun/java2d/cmm/lcms/cmsvirt.c
! src/share/native/sun/java2d/cmm/lcms/cmswtpnt.c
! src/share/native/sun/java2d/cmm/lcms/cmsxform.c
- src/share/native/sun/java2d/cmm/lcms/icc34.h
- src/share/native/sun/java2d/cmm/lcms/lcms.h
+ src/share/native/sun/java2d/cmm/lcms/lcms2.h
+ src/share/native/sun/java2d/cmm/lcms/lcms2_internal.h
+ src/share/native/sun/java2d/cmm/lcms/lcms2_plugin.h

Changeset: abe6a61835cb
Author:    lana
Date:      2010-09-16 11:15 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/abe6a61835cb

Merge

- src/share/native/sun/java2d/cmm/lcms/cmscam97.c
- src/share/native/sun/java2d/cmm/lcms/cmsmatsh.c
- src/share/native/sun/java2d/cmm/lcms/icc34.h
- src/share/native/sun/java2d/cmm/lcms/lcms.h

Changeset: 7e26538596be
Author:    art
Date:      2010-08-24 12:54 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/7e26538596be

6949936: Provide API for running nested events loops, similar to what modal dialogs do
Reviewed-by: ant, anthony

! src/share/classes/java/awt/Dialog.java
! src/share/classes/java/awt/EventDispatchThread.java
! src/share/classes/java/awt/EventQueue.java
+ src/share/classes/java/awt/SecondaryLoop.java
+ src/share/classes/java/awt/WaitDispatchSupport.java
+ test/java/awt/EventQueue/SecondaryLoopTest/SecondaryLoopTest.java

Changeset: d3fdf9e7e9c2
Author:    dav
Date:      2010-08-31 15:05 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/d3fdf9e7e9c2

6480547: REG: bug 4118621 which got Integrated in 1.1.8 fails in mustang from b25 onwards.
6808185: test/closed/java/awt/Menu/NullMenuLabelTest crashes
Reviewed-by: dcherepanov

! src/windows/native/sun/windows/awt_MenuItem.cpp
! src/windows/native/sun/windows/awt_TextComponent.h
! src/windows/native/sun/windows/awt_TextField.cpp
! src/windows/native/sun/windows/awt_TextField.h
+ test/java/awt/Menu/NullMenuLabelTest/NullMenuLabelTest.java
! test/java/awt/TextField/ScrollSelectionTest/ScrollSelectionTest.java
! test/java/awt/event/MouseEvent/SpuriousExitEnter/SpuriousExitEnter_3.java

Changeset: 7f8a9157544a
Author:    lana
Date:      2010-09-02 12:17 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/7f8a9157544a

Merge

- src/share/classes/sun/java2d/pisces/PiscesMath.java
- src/share/classes/sun/java2d/pisces/Transform4.java
- test/tools/pack200/Pack200Simple.sh
- test/tools/pack200/SegmentLimit.java

Changeset: c12a03da538b
Author:    ant
Date:      2010-09-03 11:08 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/c12a03da538b

6867293: switching TAB in a browser doesn't deactivate EmbeddedFrame
Reviewed-by: dcherepanov, art

! src/windows/native/sun/windows/awt_Window.h

Changeset: 252af007f819
Author:    lana
Date:      2010-09-16 11:16 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/252af007f819

Merge


Changeset: 48070a2633a1
Author:    naoto
Date:      2010-08-31 11:27 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/48070a2633a1

4700857: RFE: separating user locale and user interface locale
Reviewed-by: okutsu

! src/share/classes/java/text/DateFormat.java
! src/share/classes/java/text/DateFormatSymbols.java
! src/share/classes/java/text/DecimalFormat.java
! src/share/classes/java/text/DecimalFormatSymbols.java
! src/share/classes/java/text/MessageFormat.java
! src/share/classes/java/text/NumberFormat.java
! src/share/classes/java/text/SimpleDateFormat.java
! src/share/classes/java/util/Calendar.java
! src/share/classes/java/util/Currency.java
! src/share/classes/java/util/Formatter.java
! src/share/classes/java/util/GregorianCalendar.java
! src/share/classes/java/util/Locale.java
! src/share/classes/java/util/Scanner.java
! src/share/classes/java/util/TimeZone.java
! src/share/native/java/lang/System.c
! src/share/native/java/lang/java_props.h
! src/solaris/native/java/lang/java_props_md.c
! src/windows/native/java/lang/java_props_md.c
! src/windows/native/sun/windows/awt_DataTransferer.cpp
! src/windows/native/sun/windows/awt_InputMethod.cpp
! test/java/util/Formatter/Constructors.java
+ test/java/util/Locale/LocaleCategory.sh
! test/java/util/Locale/PrintDefaultLocale.java
! test/java/util/Locale/data/deflocale.c
+ test/java/util/Locale/data/deflocale.input
- test/java/util/Locale/data/deflocale.jds3
- test/java/util/Locale/data/deflocale.rhel4
+ test/java/util/Locale/data/deflocale.rhel5
+ test/java/util/Locale/data/deflocale.rhel5.fmtasdefault
! test/java/util/Locale/data/deflocale.sh
! test/java/util/Locale/data/deflocale.sol10
+ test/java/util/Locale/data/deflocale.sol10.fmtasdefault
+ test/java/util/Locale/data/deflocale.win7
+ test/java/util/Locale/data/deflocale.win7.fmtasdefault
- test/java/util/Locale/data/deflocale.winvista
- test/java/util/Locale/data/deflocale.winxp

Changeset: 3b64274e3cda
Author:    naoto
Date:      2010-08-31 23:56 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/3b64274e3cda

6981466: Adding missing test LocaleCategory.java
Reviewed-by: okutsu

+ test/java/util/Locale/LocaleCategory.java

Changeset: de0f18fe09e7
Author:    okutsu
Date:      2010-09-01 15:19 +0900
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/de0f18fe09e7

4267450: (cal) API: Need public API to calculate, format and parse "year of week"
6549953: (cal) WEEK_OF_YEAR and DAY_OF_YEAR calculation problems around Gregorian cutover
Reviewed-by: peytoia

! make/java/text/base/FILES_java.gmk
+ src/share/classes/java/text/CalendarBuilder.java
! src/share/classes/java/text/DateFormatSymbols.java
! src/share/classes/java/text/SimpleDateFormat.java
! src/share/classes/java/util/Calendar.java
! src/share/classes/java/util/GregorianCalendar.java
+ test/java/text/Format/DateFormat/WeekDateTest.java
+ test/java/util/Calendar/WeekDateTest.java

Changeset: 513a9ae0bbdd
Author:    okutsu
Date:      2010-09-02 10:52 +0900
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/513a9ae0bbdd

Merge


Changeset: 8af4eca2e2be
Author:    lana
Date:      2010-09-01 16:15 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/8af4eca2e2be

Merge

- src/share/classes/sun/java2d/pisces/PiscesMath.java
- src/share/classes/sun/java2d/pisces/Transform4.java
- test/tools/pack200/Pack200Simple.sh
- test/tools/pack200/SegmentLimit.java

Changeset: 7b92a8ecece2
Author:    lana
Date:      2010-09-02 00:02 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/7b92a8ecece2

Merge


Changeset: b83701dcae1e
Author:    naoto
Date:      2010-09-02 11:09 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/b83701dcae1e

6981759: copyright header fix for test/java/util/Locale/LocaleCategory.java
Reviewed-by: okutsu

! test/java/util/Locale/LocaleCategory.java

Changeset: 93d13ea00faf
Author:    naoto
Date:      2010-09-02 11:13 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/93d13ea00faf

6930062: Need to remove or build as part of the test file jdk/test/java/util/Locale/data/deflocale.exe
Reviewed-by: okutsu

- test/java/util/Locale/data/deflocale.exe

Changeset: c47eb064d6ba
Author:    okutsu
Date:      2010-09-09 15:37 +0900
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/c47eb064d6ba

4919632: RFE: SimpleDateFormat should fully support ISO8601 standard for timezone
Reviewed-by: peytoia

! src/share/classes/java/text/DateFormatSymbols.java
! src/share/classes/java/text/SimpleDateFormat.java
+ test/java/text/Format/DateFormat/ISO8601ZoneTest.java

Changeset: 4f1eacca4e6b
Author:    peytoia
Date:      2010-09-10 17:22 +0900
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/4f1eacca4e6b

6983724: redundant @exception description for Character.Subset(String name)
Reviewed-by: okutsu

! src/share/classes/java/lang/Character.java

Changeset: afae9229e4a7
Author:    okutsu
Date:      2010-09-10 17:51 +0900
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/afae9229e4a7

6912560: Timezone is not set correctly on Win Vista when Security manager is present.
6941137: DST broken in 6u18 when jre/lib/zi is moved elsewhere and replaced with symlink.
Reviewed-by: peytoia

! src/share/classes/sun/util/calendar/ZoneInfoFile.java
+ test/java/util/TimeZone/Bug6912560.java

Changeset: 4fea9ea1661d
Author:    malenkov
Date:      2010-09-10 20:48 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/4fea9ea1661d

6915566: Closed swing tests failing with assert errors when run with -ea -esa
Reviewed-by: art, peterz

! src/share/classes/com/sun/java/swing/SwingUtilities3.java
! src/share/classes/com/sun/java/swing/plaf/gtk/GTKPainter.java
! src/share/classes/javax/swing/plaf/synth/SynthTabbedPaneUI.java

Changeset: ee4d92fb6df3
Author:    naoto
Date:      2010-09-10 15:29 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/ee4d92fb6df3

6875847: Java Locale Enhancement
Reviewed-by: srl
Contributed-by: Yoshito Umaoka <y.umaoka at gmail.com>, Doug Felt <dougfelt at google.com>, Mark Davis <markdavis at google.com>

! make/java/java/FILES_java.gmk
! src/share/classes/java/text/DecimalFormatSymbols.java
! src/share/classes/java/util/Calendar.java
+ src/share/classes/java/util/IllformedLocaleException.java
! src/share/classes/java/util/Locale.java
! src/share/classes/java/util/ResourceBundle.java
! src/share/classes/java/util/spi/LocaleNameProvider.java
! src/share/classes/java/util/spi/LocaleServiceProvider.java
! src/share/classes/sun/util/LocaleServiceProviderPool.java
+ src/share/classes/sun/util/locale/AsciiUtil.java
+ src/share/classes/sun/util/locale/BaseLocale.java
+ src/share/classes/sun/util/locale/Extension.java
+ src/share/classes/sun/util/locale/InternalLocaleBuilder.java
+ src/share/classes/sun/util/locale/LanguageTag.java
+ src/share/classes/sun/util/locale/LocaleExtensions.java
+ src/share/classes/sun/util/locale/LocaleObjectCache.java
+ src/share/classes/sun/util/locale/LocaleSyntaxException.java
+ src/share/classes/sun/util/locale/ParseStatus.java
+ src/share/classes/sun/util/locale/StringTokenIterator.java
+ src/share/classes/sun/util/locale/UnicodeLocaleExtension.java
! src/share/classes/sun/util/resources/LocaleData.java
! src/share/classes/sun/util/resources/LocaleNames.properties
! src/share/classes/sun/util/resources/LocaleNames_zh.properties
! src/share/classes/sun/util/resources/LocaleNames_zh_TW.properties
+ test/java/util/Locale/LocaleEnhanceTest.java
! test/java/util/Locale/LocaleTestFmwk.java
+ test/java/util/Locale/icuLocales.txt
+ test/java/util/Locale/serialized/java6locale_ROOT
+ test/java/util/Locale/serialized/java6locale__US
+ test/java/util/Locale/serialized/java6locale___Java
+ test/java/util/Locale/serialized/java6locale_en
+ test/java/util/Locale/serialized/java6locale_en_US
+ test/java/util/Locale/serialized/java6locale_en_US_Java
+ test/java/util/Locale/serialized/java6locale_iw_IL
+ test/java/util/Locale/serialized/java6locale_ja_JP_JP
+ test/java/util/Locale/serialized/java6locale_no_NO_NY
+ test/java/util/Locale/serialized/java6locale_th_TH_TH

Changeset: 903f44341e34
Author:    kalli
Date:      2010-09-13 15:12 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/903f44341e34

6941027: Gervill update, April 2010
Reviewed-by: amenkov

! src/share/classes/com/sun/media/sound/AudioFloatFormatConverter.java
! src/share/classes/com/sun/media/sound/AudioSynthesizerPropertyInfo.java
! src/share/classes/com/sun/media/sound/ModelByteBufferWavetable.java
! src/share/classes/com/sun/media/sound/ModelInstrument.java
+ src/share/classes/com/sun/media/sound/ModelStandardIndexedDirector.java
! src/share/classes/com/sun/media/sound/SoftChannel.java
! src/share/classes/com/sun/media/sound/SoftSynthesizer.java
! src/share/classes/com/sun/media/sound/SoftVoice.java
+ test/javax/sound/midi/Gervill/AudioFloatFormatConverter/SkipTest.java
+ test/javax/sound/midi/Gervill/ModelByteBufferWavetable/OpenStream.java
+ test/javax/sound/midi/Gervill/SoftSynthesizer/GetAvailableInstruments2.java
+ test/javax/sound/midi/Gervill/SoftSynthesizer/GetLoadedInstruments2.java
+ test/javax/sound/midi/Gervill/SoftSynthesizer/GetPropertyInfo.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/LoadAllInstruments.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/LoadInstrument.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/LoadInstruments.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/RemapInstrument.java
+ test/javax/sound/midi/Gervill/SoftSynthesizer/TestDisableLoadDefaultSoundbank.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/UnloadAllInstruments.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/UnloadInstrument.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/UnloadInstruments.java
+ test/javax/sound/midi/Gervill/SoftTuning/RealTimeTuning.java

Changeset: 3fa6114faa54
Author:    kalli
Date:      2010-09-13 15:34 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/3fa6114faa54

6943053: Gervill: failures on invalid ranges and 14-bit banks
Summary: ModelStandardIndexedDirector fails on invalid ranges. Program changes with 14-bit banks where handled incorectly as 7-bit banks.
Reviewed-by: amenkov

! src/share/classes/com/sun/media/sound/ModelStandardIndexedDirector.java
! src/share/classes/com/sun/media/sound/SoftChannel.java
+ test/javax/sound/midi/Gervill/ModelStandardIndexedDirector/ModelStandardIndexedDirectorTest.java
+ test/javax/sound/midi/Gervill/SoftChannel/ProgramAndBankChange.java

Changeset: c610f475558d
Author:    okutsu
Date:      2010-09-14 16:47 +0900
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/c610f475558d

6984418: (cal) GregorianCalendar.setWeekDate doesn't check parameter consistency in non-lenient
Reviewed-by: peytoia

! src/share/classes/java/util/GregorianCalendar.java
! test/java/util/Calendar/WeekDateTest.java

Changeset: 7fe3d0fd99b8
Author:    amenkov
Date:      2010-09-14 12:38 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/7fe3d0fd99b8

6944033: RFE: add PCM_FLOAT support
Reviewed-by: dav

! src/share/classes/com/sun/media/sound/AudioFloatConverter.java
! src/share/classes/com/sun/media/sound/AudioFloatFormatConverter.java
! src/share/classes/com/sun/media/sound/DLSSoundbank.java
! src/share/classes/com/sun/media/sound/SoftMixingMixer.java
! src/share/classes/com/sun/media/sound/WaveExtensibleFileReader.java
! src/share/classes/com/sun/media/sound/WaveFloatFileReader.java
! src/share/classes/com/sun/media/sound/WaveFloatFileWriter.java
! src/share/classes/javax/sound/sampled/AudioFormat.java
+ test/javax/sound/sampled/AudioFormat/PCM_FLOAT_support.java

Changeset: c3c28ce45273
Author:    amenkov
Date:      2010-09-14 14:07 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/c3c28ce45273

4937708: AudioFormat.matches should allow NOT_SPECIFY in all fields
Reviewed-by: denis

! src/share/classes/javax/sound/sampled/AudioFormat.java
+ test/javax/sound/sampled/AudioFormat/Matches_NOT_SPECIFIED.java

Changeset: 167a6a4634f5
Author:    amenkov
Date:      2010-09-14 14:09 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/167a6a4634f5

Merge

! src/share/classes/javax/sound/sampled/AudioFormat.java

Changeset: 82e98a8dccec
Author:    amenkov
Date:      2010-09-14 14:14 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/82e98a8dccec

4933700: RFE: Add way to get device from Receiver and Transmitter
Reviewed-by: art

! src/share/classes/com/sun/media/sound/AbstractMidiDevice.java
- src/share/classes/com/sun/media/sound/MidiDeviceReceiver.java
+ src/share/classes/com/sun/media/sound/MidiDeviceReceiverEnvelope.java
+ src/share/classes/com/sun/media/sound/MidiDeviceTransmitterEnvelope.java
! src/share/classes/com/sun/media/sound/SoftReceiver.java
! src/share/classes/javax/sound/midi/MidiDevice.java
+ src/share/classes/javax/sound/midi/MidiDeviceReceiver.java
+ src/share/classes/javax/sound/midi/MidiDeviceTransmitter.java
! src/share/classes/javax/sound/midi/MidiSystem.java
+ test/javax/sound/midi/MidiDeviceConnectors/TestAllDevices.java

Changeset: bb733c150f94
Author:    omajid
Date:      2010-09-14 10:45 -0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/bb733c150f94

6979979: Rounding error in font sizes selected by the GTK Look and Feel
Summary: Use floating point font sizes
Reviewed-by: prr

! src/share/classes/com/sun/java/swing/plaf/gtk/PangoFonts.java
! src/share/classes/sun/font/FontUtilities.java

Changeset: 7fc59f27318c
Author:    malenkov
Date:      2010-09-14 19:12 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/7fc59f27318c

6978482: MetalBorders.ToolBarBorder should specify that its getBorderInsets impl accepts only JToolBar inst
Reviewed-by: alexp

! src/share/classes/com/sun/java/swing/plaf/motif/MotifBorders.java
! src/share/classes/com/sun/java/swing/plaf/windows/WindowsBorders.java
! src/share/classes/javax/swing/plaf/basic/BasicBorders.java
! src/share/classes/javax/swing/plaf/metal/MetalBorders.java
! src/share/classes/sun/swing/plaf/synth/SynthFileChooserUI.java
+ test/javax/swing/border/Test6978482.java

Changeset: 2ffd71748740
Author:    malenkov
Date:      2010-09-14 21:22 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/2ffd71748740

6635395: javax.swing.JDialog constructors should specify IAE throwing if invalid owners passed
Reviewed-by: alexp

! src/share/classes/javax/swing/JDialog.java

Changeset: 49650448c3c7
Author:    malenkov
Date:      2010-09-14 22:05 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/49650448c3c7

6977726: JColorChooser.getPreviewPanel() returnes null starting from jdk7 b105.
Reviewed-by: alexp

! src/share/classes/javax/swing/JColorChooser.java
! src/share/classes/javax/swing/plaf/basic/BasicColorChooserUI.java
+ test/javax/swing/JColorChooser/Test6977726.html
+ test/javax/swing/JColorChooser/Test6977726.java

Changeset: bf89c7fc48fd
Author:    malenkov
Date:      2010-09-16 09:07 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/bf89c7fc48fd

6741392: libmawt.so crash at Java_com_sun_java_swing_plaf_gtk_GTKEngine_nativeFinishPainting+0x4f
Reviewed-by: peterz

! src/solaris/native/sun/awt/gtk2_interface.c
! src/solaris/native/sun/awt/gtk2_interface.h
! src/solaris/native/sun/awt/swing_GTKEngine.c

Changeset: 21562f873588
Author:    lana
Date:      2010-09-16 11:17 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/21562f873588

Merge

- src/share/classes/com/sun/media/sound/MidiDeviceReceiver.java
- test/java/util/Locale/data/deflocale.exe
- test/java/util/Locale/data/deflocale.jds3
- test/java/util/Locale/data/deflocale.rhel4
- test/java/util/Locale/data/deflocale.winvista
- test/java/util/Locale/data/deflocale.winxp

Changeset: 93c49f01a4c2
Author:    darcy
Date:      2010-08-25 15:35 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/93c49f01a4c2

6980019: Finish rename of ARM -> try-with-resources in jdk repository
Reviewed-by: jjg

! src/share/classes/java/lang/AutoCloseable.java
! src/share/classes/java/lang/Throwable.java

Changeset: 1470dffe6551
Author:    martin
Date:      2010-08-28 12:15 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/1470dffe6551

6980747: Runtime.exec can fail due to SecurityException (lnx)
Summary: Add missing doPrivileged to UNIXProcess.java.linux
Reviewed-by: alanb

! src/solaris/classes/java/lang/UNIXProcess.java.linux
+ test/java/lang/ProcessBuilder/SecurityManagerClinit.java

Changeset: 9be643e70f42
Author:    weijun
Date:      2010-08-30 14:37 +0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/9be643e70f42

6911951: NTLM should be a supported Java SASL mechanism
Reviewed-by: vinnie, michaelm

+ src/share/classes/com/sun/security/ntlm/Client.java
+ src/share/classes/com/sun/security/ntlm/NTLM.java
+ src/share/classes/com/sun/security/ntlm/NTLMException.java
+ src/share/classes/com/sun/security/ntlm/Server.java
+ src/share/classes/com/sun/security/ntlm/Version.java
! src/share/classes/com/sun/security/sasl/Provider.java
+ src/share/classes/com/sun/security/sasl/ntlm/FactoryImpl.java
+ src/share/classes/com/sun/security/sasl/ntlm/NTLMClient.java
+ src/share/classes/com/sun/security/sasl/ntlm/NTLMServer.java
! src/solaris/classes/sun/net/www/protocol/http/ntlm/NTLMAuthentication.java
+ test/com/sun/security/sasl/ntlm/NTLMTest.java

Changeset: 6586ab5b79f4
Author:    mchung
Date:      2010-08-31 09:15 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/6586ab5b79f4

6981005: TEST BUG: java/lang/ClassLoader/TestCrossDelegate.sh timeout on windows
Summary: Increase timeout value
Reviewed-by: alanb

! test/ProblemList.txt
! test/java/lang/ClassLoader/deadlock/TestCrossDelegate.sh

Changeset: def50d3ad78e
Author:    mchung
Date:      2010-08-31 09:17 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/def50d3ad78e

6977548: Broken link in ClassLoader.defineClass javadoc
Reviewed-by: valeriep

! src/share/classes/java/lang/ClassLoader.java

Changeset: bb8f48e1e042
Author:    martin
Date:      2010-09-01 09:45 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/bb8f48e1e042

6981145: (se) Eliminate JNI*Critical when creating pipes and other cleanups
Summary: Avoid *Critical; fix compile warnings; improve readability
Reviewed-by: alanb

! make/java/nio/mapfile-linux
! make/java/nio/mapfile-solaris
! src/share/classes/sun/nio/ch/IOUtil.java
! src/solaris/classes/sun/nio/ch/DevPollSelectorImpl.java
! src/solaris/classes/sun/nio/ch/EPollSelectorImpl.java
! src/solaris/classes/sun/nio/ch/PipeImpl.java
! src/solaris/classes/sun/nio/ch/PollSelectorImpl.java
! src/solaris/native/sun/nio/ch/IOUtil.c

Changeset: b200263f1b68
Author:    mchung
Date:      2010-09-01 17:37 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/b200263f1b68

6977887: (doc) Java 6 API missing info about encoding parameter in storeToXML method
Reviewed-by: sherman

! src/share/classes/java/util/Properties.java

Changeset: b790c1ecee19
Author:    ksrini
Date:      2010-09-03 07:59 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/b790c1ecee19

6981001: (launcher) EnsureJREInstallation is not being called in order
Reviewed-by: darcy

! src/windows/bin/java_md.c
+ test/tools/launcher/MiscTests.java
- test/tools/launcher/VerifyExceptions.java

Changeset: 80a8742483bf
Author:    lana
Date:      2010-09-02 22:11 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/80a8742483bf

Merge

- src/share/classes/sun/java2d/pisces/PiscesMath.java
- src/share/classes/sun/java2d/pisces/Transform4.java

Changeset: 10728041e814
Author:    lana
Date:      2010-09-03 12:00 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/10728041e814

Merge

- test/tools/launcher/VerifyExceptions.java

Changeset: 174916d435c9
Author:    alanb
Date:      2010-09-03 13:11 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/174916d435c9

6965072: Need API to create SDP sockets
Reviewed-by: michaelm

! make/com/Makefile
+ make/com/oracle/Makefile
+ make/com/oracle/net/Makefile
! make/docs/NON_CORE_PKGS.gmk
! make/java/net/FILES_c.gmk
! make/java/net/Makefile
! make/java/net/mapfile-vers
! make/java/nio/FILES_java.gmk
! make/sun/net/FILES_java.gmk
+ src/share/classes/com/oracle/net/Sdp.java
+ src/share/classes/java/net/SdpSocketImpl.java
! src/share/classes/java/net/ServerSocket.java
+ src/share/classes/sun/net/sdp/SdpSupport.java
+ src/share/classes/sun/nio/ch/Secrets.java
! src/share/classes/sun/nio/ch/ServerSocketChannelImpl.java
! src/share/classes/sun/nio/ch/SocketChannelImpl.java
! src/solaris/classes/sun/net/NetHooks.java
+ src/solaris/classes/sun/net/sdp/SdpProvider.java
- src/solaris/classes/sun/net/spi/SdpProvider.java
! src/solaris/classes/sun/nio/ch/InheritedChannel.java
+ src/solaris/native/sun/net/sdp/SdpSupport.c
- src/solaris/native/sun/net/spi/SdpProvider.c
+ test/com/oracle/net/Sanity.java
+ test/com/oracle/net/sanity.sh
! test/sun/net/sdp/ProbeIB.java
! test/sun/net/sdp/sanity.sh

Changeset: e17654f00d93
Author:    alanb
Date:      2010-09-03 21:03 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/e17654f00d93

Merge

- src/share/classes/sun/java2d/pisces/PiscesMath.java
- src/share/classes/sun/java2d/pisces/Transform4.java
- test/tools/launcher/VerifyExceptions.java

Changeset: a6c142240837
Author:    darcy
Date:      2010-09-03 15:00 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/a6c142240837

4881419: The type of X[].clone() should be X[]
Reviewed-by: martin

! src/share/classes/java/lang/Object.java

Changeset: 1f99ad63eb9e
Author:    lancea
Date:      2010-09-04 12:21 -0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/1f99ad63eb9e

6861385: Updated SQLException subclasses to clarify that they may be thrown for vendor specific conditions
Reviewed-by: alanb

! src/share/classes/java/sql/SQLDataException.java
! src/share/classes/java/sql/SQLIntegrityConstraintViolationException.java
! src/share/classes/java/sql/SQLInvalidAuthorizationSpecException.java
! src/share/classes/java/sql/SQLNonTransientConnectionException.java
! src/share/classes/java/sql/SQLSyntaxErrorException.java
! src/share/classes/java/sql/SQLTransactionRollbackException.java
! src/share/classes/java/sql/SQLTransientConnectionException.java

Changeset: d44696691445
Author:    lancea
Date:      2010-09-04 13:56 -0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/d44696691445

6843995: RowSet 1.1 updates
Reviewed-by: darcy, valeriep

+ src/share/classes/com/sun/rowset/RowSetFactoryImpl.java
! src/share/classes/javax/sql/rowset/CachedRowSet.java
+ src/share/classes/javax/sql/rowset/RowSetFactory.java
+ src/share/classes/javax/sql/rowset/RowSetProvider.java
! src/share/classes/javax/sql/rowset/package.html
! src/share/classes/javax/sql/rowset/spi/SyncFactory.java
! src/share/classes/javax/sql/rowset/spi/SyncProvider.java

Changeset: c4defe31c94a
Author:    lancea
Date:      2010-09-04 15:30 -0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/c4defe31c94a

6680198: UnmarshalException caused by incompatible serialVersionUID
Reviewed-by: sherman

! src/share/classes/com/sun/rowset/CachedRowSetImpl.java
! src/share/classes/com/sun/rowset/FilteredRowSetImpl.java
! src/share/classes/com/sun/rowset/JdbcRowSetImpl.java
! src/share/classes/com/sun/rowset/JdbcRowSetResourceBundle.java
! src/share/classes/com/sun/rowset/JoinRowSetImpl.java
! src/share/classes/com/sun/rowset/WebRowSetImpl.java
! src/share/classes/com/sun/rowset/internal/CachedRowSetReader.java
! src/share/classes/com/sun/rowset/internal/CachedRowSetWriter.java
! src/share/classes/com/sun/rowset/internal/InsertRow.java
! src/share/classes/com/sun/rowset/internal/SyncResolverImpl.java
! src/share/classes/com/sun/rowset/internal/WebRowSetXmlReader.java
! src/share/classes/com/sun/rowset/internal/WebRowSetXmlWriter.java
! src/share/classes/com/sun/rowset/providers/RIOptimisticProvider.java

Changeset: 5cf79568f0b9
Author:    lancea
Date:      2010-09-04 15:37 -0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/5cf79568f0b9

6982510: Updated SQLException subclasses  from the outback for 6861385 so that the copyrights only have 2 years
Reviewed-by: alanb

! src/share/classes/java/sql/SQLDataException.java
! src/share/classes/java/sql/SQLIntegrityConstraintViolationException.java
! src/share/classes/java/sql/SQLInvalidAuthorizationSpecException.java
! src/share/classes/java/sql/SQLNonTransientConnectionException.java
! src/share/classes/java/sql/SQLSyntaxErrorException.java
! src/share/classes/java/sql/SQLTransactionRollbackException.java
! src/share/classes/java/sql/SQLTransientConnectionException.java

Changeset: cecc431cd78a
Author:    alanb
Date:      2010-09-07 08:36 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/cecc431cd78a

6971706: sun/nio/cs/ext/* classes are duplicated between rt.jar, charsets.jar, and localedata.jar
Reviewed-by: ohair

! make/common/Release.gmk

Changeset: 299955417217
Author:    ohair
Date:      2010-09-07 15:53 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/299955417217

Merge

- src/solaris/classes/sun/net/spi/SdpProvider.java
- src/solaris/native/sun/net/spi/SdpProvider.c
- test/tools/launcher/VerifyExceptions.java

Changeset: fa00d112bb00
Author:    darcy
Date:      2010-09-08 17:10 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/fa00d112bb00

6294399: (reflect) Constructor.getName() returns fully qualified name of declaring class
Reviewed-by: alanb

! src/share/classes/java/lang/reflect/Constructor.java

Changeset: da7835e74005
Author:    ksrini
Date:      2010-09-09 11:50 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/da7835e74005

6390477: (launcher) replace unsafe usages of sprintf with snprintf
Reviewed-by: darcy, mchung

! src/share/bin/java.c
! src/solaris/bin/java_md.c
! src/windows/bin/java_md.c

Changeset: 6960b4f07bf9
Author:    chegar
Date:      2010-09-10 15:57 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/6960b4f07bf9

6980517: TEST_BUG sun\net\www\http\ChunkedInputStream\ChunkedEncodingTest.java NullPointerException
Reviewed-by: michaelm

! test/sun/net/www/http/ChunkedInputStream/ChunkedEncodingTest.java

Changeset: 55eb9f25bf7a
Author:    alanb
Date:      2010-09-10 16:36 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/55eb9f25bf7a

6881498: (file) Re-examine DirectoryStream exception handling
Reviewed-by: forax

! make/java/nio/FILES_java.gmk
+ src/share/classes/java/nio/file/DirectoryIteratorException.java
! src/share/classes/java/nio/file/DirectoryStream.java
! src/share/classes/java/nio/file/Path.java
! src/share/classes/java/nio/file/SecureDirectoryStream.java
! src/share/classes/java/util/ConcurrentModificationException.java
! src/solaris/classes/sun/nio/fs/UnixDirectoryStream.java
! src/solaris/classes/sun/nio/fs/UnixSecureDirectoryStream.java
! src/windows/classes/sun/nio/fs/WindowsDirectoryStream.java
! test/java/nio/file/DirectoryStream/Basic.java
! test/java/nio/file/DirectoryStream/SecureDS.java
+ test/java/nio/file/etc/Exceptions.java

Changeset: b1f49e54be97
Author:    alanb
Date:      2010-09-10 18:48 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/b1f49e54be97

6983794: TEST_BUG: test/java/nio/channels/Selector/ConnectWrite.java failing
Reviewed-by: chegar

! test/java/nio/channels/Selector/ConnectWrite.java

Changeset: 186d0259f5d6
Author:    alanb
Date:      2010-09-10 18:50 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/186d0259f5d6

Merge


Changeset: c786a9c927fd
Author:    lancea
Date:      2010-09-10 15:26 -0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/c786a9c927fd

6589685: JDBC 4.1 updates
Reviewed-by: darcy

! src/share/classes/com/sun/rowset/CachedRowSetImpl.java
! src/share/classes/com/sun/rowset/JdbcRowSetImpl.java
! src/share/classes/java/sql/CallableStatement.java
! src/share/classes/java/sql/Connection.java
! src/share/classes/java/sql/DatabaseMetaData.java
! src/share/classes/java/sql/Date.java
! src/share/classes/java/sql/Driver.java
! src/share/classes/java/sql/PreparedStatement.java
+ src/share/classes/java/sql/PseudoColumnUsage.java
! src/share/classes/java/sql/ResultSet.java
! src/share/classes/java/sql/SQLPermission.java
! src/share/classes/java/sql/Statement.java
! src/share/classes/java/sql/Timestamp.java
! src/share/classes/javax/sql/CommonDataSource.java

Changeset: 73872b992aab
Author:    lancea
Date:      2010-09-10 18:51 -0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/73872b992aab

6983984: Fixed typo in DatabaseMetaData.getPseudoColumns() javadocs
Reviewed-by: darcy

! src/share/classes/java/sql/DatabaseMetaData.java

Changeset: f7915efcba1b
Author:    weijun
Date:      2010-09-13 09:32 +0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/f7915efcba1b

6845220: Need to update Policytool for Rowset 1.1 and JDBC 4.1 MR added permissions
Reviewed-by: lancea

! src/share/classes/sun/security/tools/policytool/PolicyTool.java

Changeset: be1ca1f90114
Author:    dl
Date:      2010-09-13 09:55 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/be1ca1f90114

6978087: jsr166y Updates
Summary: Simplify the ForkJoinPool API, reworking some of the internals
Reviewed-by: martin, dholmes, chegar

! src/share/classes/java/util/concurrent/ForkJoinPool.java
! src/share/classes/java/util/concurrent/ForkJoinTask.java
! src/share/classes/java/util/concurrent/ForkJoinWorkerThread.java
! src/share/classes/java/util/concurrent/LinkedTransferQueue.java
! src/share/classes/java/util/concurrent/Phaser.java
! test/java/util/concurrent/forkjoin/Integrate.java

Changeset: 5c3bad1d7f8a
Author:    weijun
Date:      2010-09-14 10:18 +0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/5c3bad1d7f8a

6982840: sun/security/tools/jarsigner/emptymanifest.sh fails
Reviewed-by: dholmes

! test/sun/security/tools/jarsigner/emptymanifest.sh

Changeset: a248eb631aa2
Author:    alanb
Date:      2010-09-15 15:13 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/a248eb631aa2

6984545: (fc) transferFrom does not throw NonReadableChannelException when target is size 0 and non-readable
Reviewed-by: forax

! src/share/classes/sun/nio/ch/FileChannelImpl.java
! test/java/nio/channels/FileChannel/Transfer.java

Changeset: 441e86ab3233
Author:    ptisnovs
Date:      2010-09-16 13:25 +0200
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/441e86ab3233

6984543: Test sun/java2d/DirectX/OnScreenRenderingResizeTest fails on GNOME
Summary: Testcase correction.
Reviewed-by: art

! test/sun/java2d/DirectX/OnScreenRenderingResizeTest/OnScreenRenderingResizeTest.java

Changeset: 61f1bbd49a5e
Author:    lana
Date:      2010-09-16 11:19 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/61f1bbd49a5e

Merge

- src/solaris/classes/sun/net/spi/SdpProvider.java
- src/solaris/native/sun/net/spi/SdpProvider.c
- test/tools/launcher/VerifyExceptions.java

Changeset: b53f226b1d91
Author:    lana
Date:      2010-09-24 16:41 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/b53f226b1d91

Merge

- src/share/classes/com/sun/media/sound/MidiDeviceReceiver.java
- src/share/native/sun/java2d/cmm/lcms/cmscam97.c
- src/share/native/sun/java2d/cmm/lcms/cmsmatsh.c
- src/share/native/sun/java2d/cmm/lcms/icc34.h
- src/share/native/sun/java2d/cmm/lcms/lcms.h
- src/solaris/classes/sun/net/spi/SdpProvider.java
- src/solaris/native/sun/net/spi/SdpProvider.c
- test/java/util/Locale/data/deflocale.exe
- test/java/util/Locale/data/deflocale.jds3
- test/java/util/Locale/data/deflocale.rhel4
- test/java/util/Locale/data/deflocale.winvista
- test/java/util/Locale/data/deflocale.winxp
- test/tools/launcher/VerifyExceptions.java

Changeset: 61d3b9fbb26b
Author:    cl
Date:      2010-10-01 15:45 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/61d3b9fbb26b

Added tag jdk7-b112 for changeset b53f226b1d91

! .hgtags

Changeset: 621be994f8d9
Author:    cl
Date:      2010-10-07 15:12 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/621be994f8d9

Added tag jdk7-b113 for changeset 61d3b9fbb26b

! .hgtags

Changeset: ad17cf689258
Author:    bae
Date:      2010-09-29 10:44 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/ad17cf689258

6735275: java.awt.image.SampleModel.getSamples() methods not allways throw ArrayIndexOutOfBoundsException
Reviewed-by: igor, prr

! src/share/classes/java/awt/image/SampleModel.java
+ test/java/awt/image/GetSamplesTest.java

Changeset: 160f7ffc3d14
Author:    bae
Date:      2010-10-02 12:41 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/160f7ffc3d14

6988213: lcms build failure on windows-amd64
Reviewed-by: igor, prr

! make/sun/cmm/lcms/Makefile

Changeset: d0cfe52db29e
Author:    lana
Date:      2010-10-04 14:34 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/d0cfe52db29e

Merge


Changeset: d32203d5a47c
Author:    ant
Date:      2010-09-27 16:11 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/d32203d5a47c

6505819: Provide traverseIn method for sun.awt.EmbeddedFrame
Reviewed-by: dcherepanov, art

! src/share/classes/java/awt/KeyboardFocusManager.java
! src/share/classes/sun/awt/AWTAccessor.java
! src/share/classes/sun/awt/EmbeddedFrame.java
! src/solaris/classes/sun/awt/X11/XEmbeddedFrame.java
! src/solaris/classes/sun/awt/X11/XEmbeddedFramePeer.java
! src/windows/classes/sun/awt/windows/WEmbeddedFrame.java

Changeset: d21c9804c512
Author:    ant
Date:      2010-09-27 17:38 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/d21c9804c512

6886678: Clicking on parent JFrame's client area does not switch focus from JWindow to JFrame on Windows
Reviewed-by: dcherepanov, art

! src/windows/native/sun/windows/awt_Component.cpp
+ test/java/awt/Focus/FocusOwnerFrameOnClick/FocusOwnerFrameOnClick.java

Changeset: 40fa33254fc6
Author:    art
Date:      2010-09-28 14:57 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/40fa33254fc6

6987896: Modal dialogs resumes the calling thread before it's hidden
Reviewed-by: anthony

! src/share/classes/java/awt/Dialog.java

Changeset: 6994facc6a8b
Author:    omajid
Date:      2010-09-28 10:16 -0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/6994facc6a8b

6987945: XDecoratedPeer shouldn't allow to resize a frame to zero size
Reviewed-by: anthony

! src/solaris/classes/sun/awt/X11/XBaseWindow.java
! src/solaris/classes/sun/awt/X11/XDecoratedPeer.java

Changeset: a601a6711ef8
Author:    lana
Date:      2010-09-28 00:20 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/a601a6711ef8

Merge

- src/share/classes/com/sun/media/sound/MidiDeviceReceiver.java
- src/share/native/sun/java2d/cmm/lcms/cmscam97.c
- src/share/native/sun/java2d/cmm/lcms/cmsmatsh.c
- src/share/native/sun/java2d/cmm/lcms/icc34.h
- src/share/native/sun/java2d/cmm/lcms/lcms.h
- src/solaris/classes/sun/net/spi/SdpProvider.java
- src/solaris/native/sun/net/spi/SdpProvider.c
- test/java/util/Locale/data/deflocale.exe
- test/java/util/Locale/data/deflocale.jds3
- test/java/util/Locale/data/deflocale.rhel4
- test/java/util/Locale/data/deflocale.winvista
- test/java/util/Locale/data/deflocale.winxp
- test/tools/launcher/VerifyExceptions.java

Changeset: 8936ad6b154e
Author:    lana
Date:      2010-09-28 11:43 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/8936ad6b154e

Merge


Changeset: 3caf15616f46
Author:    dav
Date:      2010-09-30 14:50 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/3caf15616f46

6694729: obsolete link in ActionEvent javadoc
Reviewed-by: art

! src/share/classes/java/awt/event/ActionEvent.java

Changeset: 8afd49c55619
Author:    art
Date:      2010-09-30 21:06 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/8afd49c55619

6860270: JVM crash is occuring when verifying whether Browse action is supported on WinVista 64 bit
Reviewed-by: anthony, uta

! src/windows/native/sun/windows/awt_Desktop.cpp

Changeset: b0d1ef182650
Author:    dav
Date:      2010-10-01 15:10 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/b0d1ef182650

6829267: Regression test java/awt/Toolkit/ToolkitPropertyTest/ToolkitPropertyTest_Enable.java fails in RHEL5
Reviewed-by: art, anthony

! src/solaris/classes/sun/awt/X11/XToolkit.java
! src/windows/native/sun/windows/awt_DesktopProperties.cpp
! src/windows/native/sun/windows/awt_Toolkit.cpp
! src/windows/native/sun/windows/awt_Toolkit.h
! test/java/awt/Toolkit/ToolkitPropertyTest/ToolkitPropertyTest_Enable.java

Changeset: 70a73fc061d9
Author:    dav
Date:      2010-10-04 11:40 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/70a73fc061d9

6847155: test/java/awt/Mouse/MouseModifiersUnitTest/MouseModifiersUnitTest_Extra.java fails
Reviewed-by: denis

! test/java/awt/Mouse/MouseModifiersUnitTest/MouseModifiersUnitTest_Extra.java

Changeset: a014255d826c
Author:    anthony
Date:      2010-10-04 16:12 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/a014255d826c

6987233: FileDialog.getDirectory() should add a trainling slash when GTK FileDialog is used
Summary: Add the trailing slash if it's absent
Reviewed-by: art, dcherepanov

! src/solaris/classes/sun/awt/X11/GtkFileDialogPeer.java

Changeset: d147113a36fd
Author:    anthony
Date:      2010-10-04 16:21 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/d147113a36fd

6982279: java/awt/FullScreen/TranslucentWindow/TranslucentWindow.java failed due to NPE
Summary: Rely on the WWindowPeer.getTranslucentGraphics()'s return value
Reviewed-by: art, dcherepanov

! src/windows/classes/sun/awt/windows/WComponentPeer.java
! src/windows/classes/sun/awt/windows/WWindowPeer.java

Changeset: 63b6059eebd0
Author:    lana
Date:      2010-10-04 14:36 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/63b6059eebd0

Merge


Changeset: e2050786c3ce
Author:    alexp
Date:      2010-09-17 22:50 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/e2050786c3ce

6982661: Complete JLayer component
Reviewed-by: malenkov

! src/share/classes/javax/swing/JComponent.java
! src/share/classes/javax/swing/JLayer.java
! src/share/classes/javax/swing/plaf/LayerUI.java

Changeset: a463040967f2
Author:    alexp
Date:      2010-09-17 23:00 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/a463040967f2

6606019: NPE and IAE are interchanged in specification for GroupLayout.Group class
Reviewed-by: rupashka

! src/share/classes/javax/swing/GroupLayout.java

Changeset: cdd64925de04
Author:    alexp
Date:      2010-09-17 23:09 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/cdd64925de04

6632953: MetalComboBoxUI.getBaseline(JComponent, int, int) throws IAE for valid width/height
Reviewed-by: rupashka

! src/share/classes/javax/swing/plaf/metal/MetalComboBoxUI.java
+ test/javax/swing/JComboBox/6632953/bug6632953.java

Changeset: a8ec7a461254
Author:    alexp
Date:      2010-09-17 23:16 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/a8ec7a461254

6576054: NullPointerException when closing tooltip by pressing esc
Reviewed-by: rupashka

! src/share/classes/javax/swing/ToolTipManager.java

Changeset: e753db9c4416
Author:    alexp
Date:      2010-09-17 23:21 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/e753db9c4416

4330950: Lost newly entered data in the cell when resizing column width
Reviewed-by: peterz

! src/share/classes/javax/swing/JTable.java

Changeset: 76b39a4964fa
Author:    alexp
Date:      2010-09-17 23:34 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/76b39a4964fa

6542335: different behavior on knob of scroll bar between 1.4.2 and 5.0
Reviewed-by: peterz

! src/share/classes/javax/swing/plaf/basic/BasicScrollBarUI.java
+ test/javax/swing/JScrollBar/6542335/bug6542335.java

Changeset: 002495e6aecb
Author:    peterz
Date:      2010-09-21 10:03 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/002495e6aecb

6960126: With GTK L&F JDesktopPane substitutes set desktop manager
Reviewed-by: malenkov

! src/share/classes/javax/swing/JDesktopPane.java

Changeset: c650dd9e6be2
Author:    peterz
Date:      2010-09-21 10:04 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/c650dd9e6be2

6978052: No appropriate CCC request for listed JDK 7 changes in javax.swing.plaf.synth package (b84)
Reviewed-by: malenkov

! src/share/classes/javax/swing/plaf/synth/SynthTabbedPaneUI.java

Changeset: 39351e11b8f9
Author:    naoto
Date:      2010-09-23 20:05 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/39351e11b8f9

6986612: pit jdk7 b112: java.util.Locale getDisplayVariant() sqe test getDisplayVariantTests.java fails
Reviewed-by: dougfelt
Contributed-by: Yoshito Umaoka <y.umaoka at gmail.com>

! src/share/classes/java/util/Locale.java
! src/share/classes/sun/util/locale/BaseLocale.java

Changeset: b57ca6031a35
Author:    lana
Date:      2010-09-26 14:14 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/b57ca6031a35

Merge

- src/share/native/sun/java2d/cmm/lcms/cmscam97.c
- src/share/native/sun/java2d/cmm/lcms/cmsmatsh.c
- src/share/native/sun/java2d/cmm/lcms/icc34.h
- src/share/native/sun/java2d/cmm/lcms/lcms.h
- src/solaris/classes/sun/net/spi/SdpProvider.java
- src/solaris/native/sun/net/spi/SdpProvider.c
- test/tools/launcher/VerifyExceptions.java

Changeset: 278c8daa3075
Author:    malenkov
Date:      2010-09-27 13:38 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/278c8daa3075

6976577: JCK7 api/java_beans/EventSetDescriptor/descriptions.html#Ctor1 fails since jdk7 b102
Reviewed-by: peterz

! src/share/classes/java/beans/EventSetDescriptor.java
! src/share/classes/java/beans/IndexedPropertyDescriptor.java
! src/share/classes/java/beans/Introspector.java
! src/share/classes/java/beans/MethodDescriptor.java
! src/share/classes/java/beans/PropertyDescriptor.java
+ test/java/beans/Introspector/6976577/Test6976577.java
+ test/java/beans/Introspector/6976577/test/Accessor.java

Changeset: bbadb9484f53
Author:    omajid
Date:      2010-09-27 11:30 -0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/bbadb9484f53

6986968: Crash on XIM server restart
Summary: Free XIM data structures on DestroyXIMCallback
Reviewed-by: naoto

! src/solaris/native/sun/awt/awt_InputMethod.c

Changeset: 0ca4ae74cf44
Author:    malenkov
Date:      2010-09-27 21:07 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/0ca4ae74cf44

6986450: javax/swing/JTable/Test6888156.java test is failing against jdk7 just on windows
Reviewed-by: alexp

! test/javax/swing/JTable/Test6888156.java

Changeset: 75a0f7b47024
Author:    naoto
Date:      2010-09-28 10:57 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/75a0f7b47024

6915621: (rb) ResourceBundle.getBundle() deadlock when called inside a synchronized thread
Reviewed-by: okutsu

! src/share/classes/java/util/ResourceBundle.java

Changeset: 990bbd005f28
Author:    malenkov
Date:      2010-09-30 20:21 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/990bbd005f28

6982753: javax/swing/JTextArea/6940863/bug6940863.java should be modified
Reviewed-by: alexp

! test/javax/swing/JTextArea/6940863/bug6940863.java

Changeset: 76edcef04379
Author:    okutsu
Date:      2010-10-04 13:05 +0900
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/76edcef04379

6955776: (tz) Windows-only: tzmappings needs update for KB981793
6929185: (tz) Windows-only: tzmappings needs update for KB979306
Reviewed-by: peytoia

! src/windows/lib/tzmappings

Changeset: b210ae2a8e74
Author:    lana
Date:      2010-10-04 14:38 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/b210ae2a8e74

Merge


Changeset: 7794d718ffe2
Author:    lancea
Date:      2010-09-17 13:23 -0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/7794d718ffe2

6983452: SyncProvider issue for JoinRowSet implementation
Reviewed-by: darcy, ohair

! src/share/classes/com/sun/rowset/CachedRowSetImpl.java

Changeset: 1cb444a3d5cd
Author:    lancea
Date:      2010-09-17 13:26 -0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/1cb444a3d5cd

6984864: Exception when running acceptChanges with custom SyncProvider
Reviewed-by: darcy, ohair

! src/share/classes/com/sun/rowset/JoinRowSetImpl.java

Changeset: 095a5e5a025a
Author:    lancea
Date:      2010-09-17 13:30 -0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/095a5e5a025a

6985400: DatabaseMetaData.generatedKeyAlwaysReturned, "indexe(s)" should be "index(es)"
Reviewed-by: darcy, ohair

! src/share/classes/java/sql/DatabaseMetaData.java

Changeset: 291a5c52f9d0
Author:    lancea
Date:      2010-09-17 13:33 -0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/291a5c52f9d0

6985725: RowSetProvider has typo for the property javax.sql.rowset.RowSetFactory in the javadoc
Reviewed-by: darcy, ohair

! src/share/classes/javax/sql/rowset/RowSetProvider.java

Changeset: 605b327f4830
Author:    mchung
Date:      2010-09-17 14:16 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/605b327f4830

6888546: restore System.initializeSystemClasses
Summary: restore System.initializeSystemClasses prior to fix for 6797688
Reviewed-by: alanb

! src/share/classes/java/lang/System.java

Changeset: 48d7f8c4cd60
Author:    martin
Date:      2010-09-17 14:35 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/48d7f8c4cd60

6981138: (process) Process.waitFor() may hang if subprocess has live descendants (lnx)
Summary: Do exit status handling before trying to close streams
Reviewed-by: alanb, dholmes

! src/solaris/classes/java/lang/UNIXProcess.java.linux
! test/java/lang/ProcessBuilder/Basic.java

Changeset: b5d37597c815
Author:    martin
Date:      2010-09-17 14:40 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/b5d37597c815

6981157: Improve UnknownHostException with EAI error details and other cleanups
Summary: generify; remove compiler warnings, typos, casts; return status information via gai_strerror when getaddrinfo fails; show full stack of native failures
Reviewed-by: michaelm, alanb

! src/share/classes/java/net/InetAddress.java
! src/solaris/native/java/net/Inet6AddressImpl.c
! src/solaris/native/java/net/net_util_md.c
! src/solaris/native/java/net/net_util_md.h

Changeset: 0d78b3eedecc
Author:    lancea
Date:      2010-09-18 06:09 -0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/0d78b3eedecc

6984044: RowSet source needs to rebrand vendor references
Reviewed-by: darcy, ohair

! src/share/classes/com/sun/rowset/internal/WebRowSetXmlWriter.java
! src/share/classes/com/sun/rowset/providers/RIOptimisticProvider.java
! src/share/classes/com/sun/rowset/providers/RIXMLProvider.java
! src/share/classes/javax/sql/rowset/CachedRowSet.java
! src/share/classes/javax/sql/rowset/WebRowSet.java
! src/share/classes/javax/sql/rowset/rowset.properties
! src/share/classes/javax/sql/rowset/spi/SyncFactory.java
! src/share/classes/javax/sql/rowset/spi/SyncProvider.java
! src/share/classes/javax/sql/rowset/spi/package.html

Changeset: 902486a8e414
Author:    dl
Date:      2010-09-20 18:05 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/902486a8e414

6981113: Add ConcurrentLinkedDeque
Summary: Extend techniques developed for ConcurrentLinkedQueue and LinkedTransferQueue to implement a non-blocking concurrent Deque with interior removes.
Reviewed-by: martin, dholmes, chegar

! make/java/java/FILES_java.gmk
+ src/share/classes/java/util/concurrent/ConcurrentLinkedDeque.java
! src/share/classes/java/util/concurrent/ConcurrentLinkedQueue.java
! test/java/util/Collection/BiggernYours.java
! test/java/util/Collection/IteratorAtEnd.java
! test/java/util/Collection/MOAT.java
! test/java/util/Collections/RacingCollections.java
! test/java/util/Deque/ChorusLine.java
! test/java/util/concurrent/ConcurrentQueues/ConcurrentQueueLoops.java
! test/java/util/concurrent/ConcurrentQueues/GCRetention.java
! test/java/util/concurrent/ConcurrentQueues/IteratorWeakConsistency.java
! test/java/util/concurrent/ConcurrentQueues/OfferRemoveLoops.java
! test/java/util/concurrent/ConcurrentQueues/RemovePollRace.java

Changeset: cd4aad589b3f
Author:    chegar
Date:      2010-09-21 15:58 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/cd4aad589b3f

6672144: HttpURLConnection.getInputStream sends POST request after failed chunked
Reviewed-by: michaelm

! src/share/classes/sun/net/www/http/HttpClient.java
! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java
+ test/sun/net/www/http/HttpClient/StreamingRetry.java

Changeset: f5d25402ed53
Author:    dl
Date:      2010-09-21 16:06 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/f5d25402ed53

6986050: Small clarifications and fixes for ForkJoin
Summary: Clarify FJ.get on throw InterruptedException, propagate ThreadFactory, shutdown transition
Reviewed-by: chegar

! src/share/classes/java/util/concurrent/ForkJoinPool.java
! src/share/classes/java/util/concurrent/ForkJoinTask.java
! src/share/classes/java/util/concurrent/ForkJoinWorkerThread.java
! src/share/classes/java/util/concurrent/RecursiveAction.java

Changeset: 4927d1319b2f
Author:    dcubed
Date:      2010-09-22 07:46 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/4927d1319b2f

6949710: 3/3 the GC'able nature of Logging objects needs to be made brutally clear
Summary: Add words in more places to make it clear that Logger objects are GC'able unless there is a strong reference.
Reviewed-by: dholmes, andrew

! src/share/classes/java/util/logging/LogManager.java
! src/share/classes/java/util/logging/Logger.java

Changeset: 4db5c4867a78
Author:    ohair
Date:      2010-09-22 11:06 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/4db5c4867a78

6946527: rebranding system properties per Oracle Requirements (vendor)
Summary: Changes from "Sun Microsystems, Inc." to "Oracle Corporation" in the java.vendor, java.specification.vendor and java.vendor.url Java system properties. Also change of Windows COMPANY file property from "Oracle" to "Oracle Corporation".
Reviewed-by: lancea, flar

! make/common/shared/Defs.gmk
! src/share/native/java/lang/System.c

Changeset: 378ea143ff5f
Author:    ohair
Date:      2010-09-22 12:53 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/378ea143ff5f

Merge


Changeset: ca630e91d473
Author:    weijun
Date:      2010-09-23 10:46 +0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/ca630e91d473

6982971: TEST failure: com/sun/security/sasl/ntlm/NTLMTest.java
Reviewed-by: wetmore

! test/com/sun/security/sasl/ntlm/NTLMTest.java

Changeset: 60cff062f66d
Author:    mchung
Date:      2010-09-22 21:44 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/60cff062f66d

6984036: servicetag vendor rebranding issues
Summary: Update product_vendor field to use java.vendor system property
Reviewed-by: ohair

! src/share/classes/com/sun/servicetag/Installer.java
! src/share/classes/com/sun/servicetag/RegistrationData.java
! src/share/classes/com/sun/servicetag/Registry.java
! src/share/classes/com/sun/servicetag/SolarisSystemEnvironment.java
! test/com/sun/servicetag/JavaServiceTagTest.java
! test/com/sun/servicetag/JavaServiceTagTest1.java
! test/com/sun/servicetag/Util.java
! test/com/sun/servicetag/environ.properties
! test/com/sun/servicetag/missing-environ-field.xml
! test/com/sun/servicetag/newer-registry-version.xml
! test/com/sun/servicetag/registration.xml
! test/com/sun/servicetag/servicetag1.properties
! test/com/sun/servicetag/servicetag2.properties
! test/com/sun/servicetag/servicetag3.properties
! test/com/sun/servicetag/servicetag4.properties
! test/com/sun/servicetag/servicetag5.properties

Changeset: 9a837f410672
Author:    ohair
Date:      2010-09-24 14:06 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/9a837f410672

6987117: Add jprt test sets
Reviewed-by: mchung

! make/jprt.properties

Changeset: 8503c7f3a354
Author:    ohair
Date:      2010-09-24 14:22 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/8503c7f3a354

6987114: Fix top level "test" Makefile logic, add jdk/make/Makefile test target
6987113: Remove SCCS logic from makefiles
Reviewed-by: mchung

! make/Makefile
! make/common/Cscope.gmk
! make/common/Defs.gmk
- make/common/Rules-SCCS.gmk
! make/common/shared/Defs-utils.gmk
! test/ProblemList.txt

Changeset: 9eb9485ec45b
Author:    weijun
Date:      2010-09-25 10:21 +0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/9eb9485ec45b

6986868: TEST failure: sun/security/tools/jarsigner/crl.sh
Reviewed-by: ohair

! test/sun/security/tools/jarsigner/crl.sh

Changeset: 4b0fdb9f7cfe
Author:    lana
Date:      2010-09-25 12:00 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/4b0fdb9f7cfe

Merge

! make/java/java/FILES_java.gmk
- src/share/classes/com/sun/media/sound/MidiDeviceReceiver.java
! src/share/native/java/lang/System.c
- src/share/native/sun/java2d/cmm/lcms/cmscam97.c
- src/share/native/sun/java2d/cmm/lcms/cmsmatsh.c
- src/share/native/sun/java2d/cmm/lcms/icc34.h
- src/share/native/sun/java2d/cmm/lcms/lcms.h
- test/java/util/Locale/data/deflocale.exe
- test/java/util/Locale/data/deflocale.jds3
- test/java/util/Locale/data/deflocale.rhel4
- test/java/util/Locale/data/deflocale.winvista
- test/java/util/Locale/data/deflocale.winxp

Changeset: 7b2b0131fa61
Author:    lancea
Date:      2010-09-27 18:05 -0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/7b2b0131fa61

6987638: javadoc update to RowSetProvider and Statement
Reviewed-by: darcy, alanb

! src/share/classes/java/sql/Statement.java
! src/share/classes/javax/sql/rowset/RowSetProvider.java

Changeset: b3a4add96d45
Author:    michaelm
Date:      2010-09-28 11:59 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/b3a4add96d45

6550798: Using InputStream.skip with ResponseCache will cause partial data to be cached
Reviewed-by: chegar

! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java
+ test/sun/net/www/protocol/http/6550798/TestCache.java
+ test/sun/net/www/protocol/http/6550798/test.java

Changeset: 4b637d890b6c
Author:    michaelm
Date:      2010-09-28 12:04 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/4b637d890b6c

Merge


Changeset: a43232b264cb
Author:    michaelm
Date:      2010-09-28 14:36 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/a43232b264cb

6987927: can't use -Dfile.encoding=Cp037 in net test
Reviewed-by: chegar

- test/sun/net/www/http/ChunkedInputStream/ChunkedCharEncoding.sh

Changeset: 26c6ee936f63
Author:    weijun
Date:      2010-09-29 15:26 +0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/26c6ee936f63

6988163: sun.security.util.Resources dup and a keytool doc typo
Reviewed-by: xuelei

! src/share/classes/sun/security/tools/KeyTool.java
! src/share/classes/sun/security/util/Resources.java

Changeset: 570f825ad872
Author:    chegar
Date:      2010-09-29 17:33 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/570f825ad872

6987461: Handle leak when enabling java.net.useSystemProxies
Summary: Release the registry key handle if ProxyEnable is 0
Reviewed-by: michaelm

! src/windows/native/sun/net/spi/DefaultProxySelector.c

Changeset: 04d9b09dbef9
Author:    alanb
Date:      2010-09-30 14:48 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/04d9b09dbef9

6988037: fileClose prints debug message is close fails
Reviewed-by: kevinw, forax

! src/solaris/native/java/io/io_util_md.c
! src/windows/native/java/io/io_util_md.c

Changeset: 1fe397df4aaa
Author:    alanb
Date:      2010-09-30 14:49 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/1fe397df4aaa

Merge

- test/sun/net/www/http/ChunkedInputStream/ChunkedCharEncoding.sh

Changeset: 9a8022905f6a
Author:    lancea
Date:      2010-10-01 14:36 -0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/9a8022905f6a

6988993: Address Findbugs warnings for the use of String Constructor
Reviewed-by: ohair

! src/share/classes/com/sun/rowset/CachedRowSetImpl.java
! src/share/classes/com/sun/rowset/FilteredRowSetImpl.java
! src/share/classes/com/sun/rowset/JoinRowSetImpl.java
! src/share/classes/com/sun/rowset/internal/CachedRowSetWriter.java
! src/share/classes/com/sun/rowset/internal/WebRowSetXmlWriter.java
! src/share/classes/com/sun/rowset/internal/XmlReaderContentHandler.java
! src/share/classes/javax/sql/rowset/BaseRowSet.java
! src/share/classes/javax/sql/rowset/RowSetMetaDataImpl.java
! src/share/classes/javax/sql/rowset/serial/SerialRef.java
! src/share/classes/javax/sql/rowset/serial/SerialStruct.java

Changeset: f439d8b1e84a
Author:    alanb
Date:      2010-10-02 12:59 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/f439d8b1e84a

6979526: (file) java/nio/file/FileStore/Basic.java fails if the same file system is mounted more than once
Reviewed-by: kevinw, forax

! src/solaris/classes/sun/nio/fs/LinuxFileStore.java
! src/solaris/classes/sun/nio/fs/SolarisFileStore.java
! src/solaris/classes/sun/nio/fs/UnixFileStore.java
! test/java/nio/file/FileStore/Basic.java

Changeset: a6591c8b046d
Author:    alanb
Date:      2010-10-02 12:59 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/a6591c8b046d

Merge


Changeset: 81b0c1e3d5a7
Author:    alanb
Date:      2010-10-03 19:39 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/81b0c1e3d5a7

6907737: (file) FileVisitor and Files.walkFileTree issues
Reviewed-by: sherman

+ src/share/classes/java/nio/file/FileSystemLoopException.java
! src/share/classes/java/nio/file/FileTreeWalker.java
! src/share/classes/java/nio/file/FileVisitOption.java
! src/share/classes/java/nio/file/FileVisitor.java
! src/share/classes/java/nio/file/Files.java
! src/share/classes/java/nio/file/SimpleFileVisitor.java
! src/share/sample/nio/file/Chmod.java
! src/share/sample/nio/file/Copy.java
! src/share/sample/nio/file/WatchDir.java
+ test/java/nio/file/Files/MaxDepth.java
! test/java/nio/file/Files/Misc.java
! test/java/nio/file/Files/PrintFileTree.java
! test/java/nio/file/Files/SkipSiblings.java
! test/java/nio/file/Files/TerminateWalk.java
! test/java/nio/file/Files/WalkWithSecurity.java
! test/java/nio/file/Files/walk_file_tree.sh
! test/java/nio/file/TestUtil.java

Changeset: b8af3bab5dbf
Author:    alanb
Date:      2010-10-04 14:17 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/b8af3bab5dbf

6989190: SO_SNDBUF/SO_RCVBUF limits should only be checked when setsockopt fails (sol)
Reviewed-by: chegar, michaelm

! src/solaris/native/java/net/net_util_md.c
! test/java/nio/channels/AsynchronousServerSocketChannel/Basic.java
! test/java/nio/channels/AsynchronousSocketChannel/Basic.java
! test/java/nio/channels/DatagramChannel/SocketOptionTests.java
! test/java/nio/channels/ServerSocketChannel/SocketOptionTests.java
! test/java/nio/channels/SocketChannel/SocketOptionTests.java

Changeset: ffaf6a35b895
Author:    lancea
Date:      2010-10-04 13:04 -0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/ffaf6a35b895

6989139: Address JDBC Findbugs where Number type Constructor are used
Reviewed-by: ohair

! src/share/classes/com/sun/rowset/CachedRowSetImpl.java
! src/share/classes/com/sun/rowset/FilteredRowSetImpl.java
! src/share/classes/com/sun/rowset/JdbcRowSetImpl.java
! src/share/classes/com/sun/rowset/JoinRowSetImpl.java
! src/share/classes/com/sun/rowset/internal/CachedRowSetWriter.java
! src/share/classes/com/sun/rowset/internal/WebRowSetXmlWriter.java
! src/share/classes/com/sun/rowset/internal/XmlReaderContentHandler.java
! src/share/classes/javax/sql/rowset/BaseRowSet.java
! src/share/classes/javax/sql/rowset/serial/SQLOutputImpl.java
! src/share/classes/javax/sql/rowset/serial/SerialRef.java

Changeset: d5fc514976fa
Author:    lana
Date:      2010-10-04 14:39 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/d5fc514976fa

Merge

- make/common/Rules-SCCS.gmk
- test/sun/net/www/http/ChunkedInputStream/ChunkedCharEncoding.sh

Changeset: 4a513df0df12
Author:    sherman
Date:      2010-10-08 21:33 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/4a513df0df12

6990846: Demo: NIO.2 filesystem provider for zip/jar archives
Summary: The first drop of the zip filesystem provider, as a separate demo
Reviewed-by: alanb

! make/mkdemo/Makefile
+ make/mkdemo/nio/Makefile
+ make/mkdemo/nio/zipfs/Makefile
+ src/share/demo/nio/zipfs/Demo.java
+ src/share/demo/nio/zipfs/META-INF/services/java.nio.file.spi.FileSystemProvider
+ src/share/demo/nio/zipfs/README.txt
+ src/share/demo/nio/zipfs/com/sun/nio/zipfs/JarFileSystemProvider.java
+ src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipCoder.java
+ src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipConstants.java
+ src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipDirectoryStream.java
+ src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileAttributeView.java
+ src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileAttributes.java
+ src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileStore.java
+ src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileSystem.java
+ src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileSystemProvider.java
+ src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipInfo.java
+ src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipPath.java
+ src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipUtils.java
+ test/demo/zipfs/Basic.java
+ test/demo/zipfs/PathOps.java
+ test/demo/zipfs/ZipFSTester.java
+ test/demo/zipfs/basic.sh

Changeset: e250cef36ea0
Author:    lana
Date:      2010-10-12 12:51 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/e250cef36ea0

Merge

- make/common/Rules-SCCS.gmk
- test/sun/net/www/http/ChunkedInputStream/ChunkedCharEncoding.sh

Changeset: 0613978371d8
Author:    cl
Date:      2010-10-14 19:25 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/0613978371d8

Added tag jdk7-b114 for changeset e250cef36ea0

! .hgtags

Changeset: 4a97cf36956b
Author:    mcimadamore
Date:      2010-10-19 11:09 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/4a97cf36956b

merge with jdk7-b114

- make/common/Rules-SCCS.gmk
! make/docs/NON_CORE_PKGS.gmk
! src/share/bin/java.c
- src/share/classes/com/sun/media/sound/MidiDeviceReceiver.java
- src/share/classes/sun/java2d/pisces/PiscesMath.java
- src/share/classes/sun/java2d/pisces/Transform4.java
- src/share/native/sun/java2d/cmm/lcms/cmscam97.c
- src/share/native/sun/java2d/cmm/lcms/cmsmatsh.c
- src/share/native/sun/java2d/cmm/lcms/icc34.h
- src/share/native/sun/java2d/cmm/lcms/lcms.h
- src/solaris/classes/sun/net/spi/SdpProvider.java
- src/solaris/native/sun/net/spi/SdpProvider.c
- test/java/util/Locale/data/deflocale.exe
- test/java/util/Locale/data/deflocale.jds3
- test/java/util/Locale/data/deflocale.rhel4
- test/java/util/Locale/data/deflocale.winvista
- test/java/util/Locale/data/deflocale.winxp
- test/sun/net/www/http/ChunkedInputStream/ChunkedCharEncoding.sh
- test/tools/launcher/VerifyExceptions.java
- test/tools/pack200/Pack200Simple.sh
- test/tools/pack200/SegmentLimit.java


From maurizio.cimadamore at oracle.com  Tue Oct 19 09:09:29 2010
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Tue, 19 Oct 2010 16:09:29 +0000
Subject: hg: lambda/lambda/langtools: 80 new changesets
Message-ID: <20101019161200.A51604728C@hg.openjdk.java.net>

Changeset: 112fcc00659d
Author:    cl
Date:      2010-08-13 11:38 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/112fcc00659d

Added tag jdk7-b105 for changeset aaecac256d39

! .hgtags

Changeset: 2c1c657f69a4
Author:    cl
Date:      2010-08-19 15:13 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/2c1c657f69a4

Added tag jdk7-b106 for changeset 112fcc00659d

! .hgtags

Changeset: a408ebb8b3d4
Author:    cl
Date:      2010-08-26 16:17 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/a408ebb8b3d4

Added tag jdk7-b107 for changeset 2c1c657f69a4

! .hgtags

Changeset: 0fe472f4a332
Author:    mcimadamore
Date:      2010-08-05 09:44 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/0fe472f4a332

6881115: javac permits nested anno w/o mandatory attrs => IncompleteAnnotationException
Summary: default annotation value is not attributed
Reviewed-by: jjg, darcy

! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/Check.java
+ test/tools/javac/annotations/6881115/T6881115.java
+ test/tools/javac/annotations/6881115/T6881115.out

Changeset: 237f3bd52242
Author:    mcimadamore
Date:      2010-08-05 09:45 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/237f3bd52242

6857948: Calling a constructor with a doubly bogus argument causes an internal error
Summary: problem when constructor resolution returns an erroneous symbol
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/Attr.java
+ test/tools/javac/6857948/T6857948.java
+ test/tools/javac/6857948/T6857948.out

Changeset: a2d8c7071f24
Author:    mcimadamore
Date:      2010-08-10 14:52 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/a2d8c7071f24

6975275: diamond implementation needs some cleanup
Summary: resolution issues during diamond inference should be reported through Resolve.logResolveError()
Reviewed-by: jjg

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

Changeset: ea1930f4b789
Author:    mcimadamore
Date:      2010-08-10 14:53 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/ea1930f4b789

6975231: Regression test for 6881115 is failing with compiler output not matching expected output
Summary: missing symbols are collected in an HashSet which doesn't preserve ordering
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/Check.java
! src/share/classes/com/sun/tools/javac/resources/compiler.properties
! test/tools/javac/annotations/6881115/T6881115.out
+ test/tools/javac/diags/examples/AnnotationMissingValues1.java

Changeset: c04ae2714f52
Author:    lana
Date:      2010-08-12 19:59 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/c04ae2714f52

Merge


Changeset: 27bae58329d5
Author:    mcimadamore
Date:      2010-08-16 14:56 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/27bae58329d5

6976649: javac does not enforce required annotation elements in arrays
Summary: type annotation should take advantage of recursive annotation checking
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/Check.java
! test/tools/javac/annotations/6881115/T6881115.java
! test/tools/javac/annotations/6881115/T6881115.out
! test/tools/javac/annotations/pos/TrailingComma.java

Changeset: dc550520ed6f
Author:    mcimadamore
Date:      2010-08-16 14:58 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/dc550520ed6f

6369605: Unconstrained type variables fails to include bounds
Summary: unconstrained type-variables with recursive bounds are not inferred properly
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Type.java
! src/share/classes/com/sun/tools/javac/comp/Infer.java
! test/tools/javac/Diagnostics/6862608/T6862608a.out
! test/tools/javac/diags/examples.not-yet.txt
! test/tools/javac/diags/examples/InvalidInferredTypes.java
+ test/tools/javac/generics/inference/6369605/T6369605a.java
+ test/tools/javac/generics/inference/6369605/T6369605b.java
! test/tools/javac/generics/inference/6638712/T6638712a.out

Changeset: a31c511db424
Author:    jjg
Date:      2010-08-16 14:59 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/a31c511db424

6976833: options included twice in Example SimpleCompiler
Reviewed-by: darcy

! test/tools/javac/diags/Example.java

Changeset: c655e0280bdc
Author:    mcimadamore
Date:      2010-08-19 11:50 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/c655e0280bdc

6886247: regression: javac crashes with an assertion error in Attr.java
Summary: capture conversion does not work on nested types
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Types.java
+ test/tools/javac/generics/wildcards/6886247/T6886247_1.java
+ test/tools/javac/generics/wildcards/6886247/T6886247_2.java
+ test/tools/javac/generics/wildcards/6886247/T6886247_2.out

Changeset: d6fe0ea070aa
Author:    mcimadamore
Date:      2010-08-19 11:52 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/d6fe0ea070aa

6885255: Improve usability of raw warnings
Summary: raw warnings should be disabled in (i) instanceof expressions and (ii) when java.lang.Class is not parameterized
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/Check.java
! test/tools/javac/warnings/6747671/T6747671.java
! test/tools/javac/warnings/6747671/T6747671.out
+ test/tools/javac/warnings/6885255/T6885255.java
+ test/tools/javac/warnings/6885255/T6885255.out

Changeset: a75770c0d7f6
Author:    mcimadamore
Date:      2010-08-19 11:54 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/a75770c0d7f6

6977800: Regression: invalid resolution of supertype for local class
Summary: resolution of superclass/superinterfaces in extends/implements clause skips local classes
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/Check.java
! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java
+ test/tools/javac/T6977800.java
! test/tools/javac/generics/typevars/5060485/Compatibility.java
+ test/tools/javac/generics/typevars/5060485/Compatibility.out
+ test/tools/javac/generics/typevars/5060485/Compatibility02.java
+ test/tools/javac/generics/typevars/5060485/Compatibility02.out

Changeset: 995bcdb9a41d
Author:    mcimadamore
Date:      2010-08-23 16:59 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/995bcdb9a41d

6932571: Compiling Generics causing Inconvertible types
Summary: Types.rewriteQuantifiers() does not work well with recursive type-variable bounds
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Type.java
! src/share/classes/com/sun/tools/javac/code/Types.java
+ test/tools/javac/cast/6270087/T6270087.java
+ test/tools/javac/cast/6270087/T6270087neg.java
+ test/tools/javac/cast/6270087/T6270087neg.out
+ test/tools/javac/cast/6507317/T6507317.java
+ test/tools/javac/cast/6569057/T6569057.java
+ test/tools/javac/cast/6932571/T6932571a.java
+ test/tools/javac/cast/6932571/T6932571b.java
+ test/tools/javac/cast/6932571/T6932571neg.java
+ test/tools/javac/cast/6932571/T6932571neg.out

Changeset: 594b3c2ef585
Author:    mcimadamore
Date:      2010-08-23 17:00 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/594b3c2ef585

6978574: return statement in try block with multi-catch causes ClassFormatError
Summary: Wrong nested loops in Gen.java causes javac to generate bad bytecode
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/jvm/Gen.java
+ test/tools/javac/multicatch/T6978574.java

Changeset: 6b95dd682538
Author:    jjg
Date:      2010-08-23 11:56 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/6b95dd682538

6975005: improve JavacProcessingEnvironment.Round abstraction
Reviewed-by: darcy

! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java
! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java
! test/tools/javac/T6358024.java
! test/tools/javac/T6403466.out
! test/tools/javac/processing/filer/TestLastRound.out

Changeset: a626d8c1de6e
Author:    jjg
Date:      2010-08-23 15:13 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/a626d8c1de6e

6976747: JCDiagnostic: replace "boolean mandatory" with new "Set<JCDiagnostic.Flag>"
Reviewed-by: mcimadamore

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

Changeset: 0c81bff15ced
Author:    lana
Date:      2010-08-23 19:14 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/0c81bff15ced

Merge


Changeset: ba774f919ad0
Author:    lana
Date:      2010-08-29 22:42 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/ba774f919ad0

Merge


Changeset: 47e7ff871196
Author:    ohair
Date:      2010-09-07 15:14 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/47e7ff871196

6982946: Change make/jprt.properties to defer to JPRT itself for jdk platform list
Reviewed-by: kamg

! make/jprt.properties

Changeset: f4d91b4f7153
Author:    cl
Date:      2010-09-03 12:50 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/f4d91b4f7153

Added tag jdk7-b108 for changeset a408ebb8b3d4

! .hgtags

Changeset: 4826378eaade
Author:    cl
Date:      2010-09-09 13:49 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/4826378eaade

Merge


Changeset: 1c13c5ea73b5
Author:    cl
Date:      2010-09-09 15:08 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/1c13c5ea73b5

Added tag jdk7-b109 for changeset 4826378eaade

! .hgtags

Changeset: b599cc9a9c22
Author:    ohair
Date:      2010-09-09 16:29 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/b599cc9a9c22

6982137: Rebranding pass 2 - missed copyright changes
Reviewed-by: mbykov

! test/tools/javac/generics/inference/6938454/T6938454a.java
! test/tools/javac/generics/inference/6938454/T6938454b.java

Changeset: 32da0f38d2fe
Author:    cl
Date:      2010-09-15 13:41 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/32da0f38d2fe

Merge


Changeset: 8bec624274ef
Author:    cl
Date:      2010-09-16 15:13 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/8bec624274ef

Added tag jdk7-b110 for changeset 32da0f38d2fe

! .hgtags

Changeset: 7ad86852c38a
Author:    cl
Date:      2010-09-23 17:33 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/7ad86852c38a

Added tag jdk7-b111 for changeset 8bec624274ef

! .hgtags

Changeset: e9d09e97d669
Author:    jjg
Date:      2010-08-24 11:31 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/e9d09e97d669

6935638: -implicit:none prevents compilation with annotation processing
Reviewed-by: darcy

! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java
+ test/tools/javac/processing/options/TestImplicitNone.java

Changeset: f3323b1c65ee
Author:    jjg
Date:      2010-08-24 15:09 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/f3323b1c65ee

6929404: Filer.getResource(SOURCE_PATH, ...) does not work when -sourcepath contains >1 entry
Reviewed-by: darcy

! src/share/classes/com/sun/tools/javac/processing/JavacFiler.java
+ test/tools/javac/processing/filer/TestGetResource2.java

Changeset: 6ef801fa38b7
Author:    jjg
Date:      2010-08-25 11:24 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/6ef801fa38b7

6979564: ":" for path separator in dist/bin/javac does not work on Windows
Reviewed-by: jjh

! make/build.xml
! src/share/bin/launcher.sh-template

Changeset: 70ebdef189c9
Author:    jjg
Date:      2010-08-25 11:40 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/70ebdef189c9

6960424: new option -Xpkginfo for better control of when package-info.class is generated
Reviewed-by: mcimadamore

! src/share/classes/com/sun/tools/javac/code/Attribute.java
! src/share/classes/com/sun/tools/javac/code/Types.java
! src/share/classes/com/sun/tools/javac/comp/Enter.java
! src/share/classes/com/sun/tools/javac/comp/Lower.java
! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java
! src/share/classes/com/sun/tools/javac/main/OptionName.java
! src/share/classes/com/sun/tools/javac/main/RecognizedOptions.java
! src/share/classes/com/sun/tools/javac/resources/javac.properties
+ test/tools/javac/TestPkgInfo.java

Changeset: ecff24121064
Author:    naoto
Date:      2010-08-25 15:31 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/ecff24121064

6875847: Java Locale Enhancement
Summary: Fix for javac to allow "sun.util.locale" package accessible.
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/resources/legacy.properties

Changeset: cfd047f3cf60
Author:    jjg
Date:      2010-08-26 15:17 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/cfd047f3cf60

6604599: ToolProvider should be less compiler-specific
Reviewed-by: darcy

! src/share/classes/javax/tools/ToolProvider.java
+ test/tools/javac/api/ToolProvider/HelloWorldTest.java
+ test/tools/javac/api/ToolProvider/ToolProviderTest1.java
+ test/tools/javac/api/ToolProvider/ToolProviderTest2.java

Changeset: ae3acbf63943
Author:    jjg
Date:      2010-08-26 16:13 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/ae3acbf63943

6980017: javap -XDdetail:source behaves badly if source not available.
Reviewed-by: ksrini

! src/share/classes/com/sun/tools/javap/CodeWriter.java
! src/share/classes/com/sun/tools/javap/SourceWriter.java
+ test/tools/javap/T6980017.java

Changeset: 3a9f319be48a
Author:    jjg
Date:      2010-08-27 17:14 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/3a9f319be48a

6980724: test/tools/javac/InterfaceAssert.java sometimes fails
Reviewed-by: darcy

! test/tools/javac/InterfaceAssert.java

Changeset: b4e7a57af8df
Author:    jjg
Date:      2010-08-27 17:21 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/b4e7a57af8df

6570730: com.sun.source.tree.ModifiersTree.getFlags() should return class type
Reviewed-by: mcimadamore

! src/share/classes/com/sun/source/tree/Tree.java
! src/share/classes/com/sun/tools/javac/tree/JCTree.java
- test/tools/javac/T6341023.java
+ test/tools/javac/tree/ClassTreeTest.java
+ test/tools/javac/tree/TreeKindTest.java

Changeset: eb7c263aab73
Author:    jjg
Date:      2010-08-27 17:59 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/eb7c263aab73

6980707: Reduce use of IOException in JavaCompiler
Reviewed-by: darcy

! 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/processing/JavacProcessingEnvironment.java
! src/share/classes/com/sun/tools/javac/resources/compiler.properties
! src/share/classes/com/sun/tools/javac/util/FatalError.java
! test/tools/javac/diags/examples.not-yet.txt

Changeset: 4124840b35fe
Author:    jjg
Date:      2010-08-30 18:03 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/4124840b35fe

6403465: javac should defer diagnostics until it can be determined they are persistent
Reviewed-by: mcimadamore, darcy

! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java
! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java
! src/share/classes/com/sun/tools/javac/util/Log.java
! test/tools/javac/processing/6430209/b6341534.java
+ test/tools/javac/processing/errors/TestSuppression.java

Changeset: d3ead6731a91
Author:    jrose
Date:      2010-09-01 03:19 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/d3ead6731a91

6979683: inconsistent interaction of reference cast with box/unbox conversions leaves out a useful case
Summary: Allow casts which narrow and then unbox.
Reviewed-by: mcimadamore

! src/share/classes/com/sun/tools/javac/code/Types.java
! src/share/classes/com/sun/tools/javac/comp/Lower.java
+ test/tools/javac/6979683/TestCast6979683_BAD34.java
+ test/tools/javac/6979683/TestCast6979683_BAD34.java.errlog
+ test/tools/javac/6979683/TestCast6979683_BAD35.java
+ test/tools/javac/6979683/TestCast6979683_BAD35.java.errlog
+ test/tools/javac/6979683/TestCast6979683_BAD36.java
+ test/tools/javac/6979683/TestCast6979683_BAD36.java.errlog
+ test/tools/javac/6979683/TestCast6979683_BAD37.java
+ test/tools/javac/6979683/TestCast6979683_BAD37.java.errlog
+ test/tools/javac/6979683/TestCast6979683_BAD38.java
+ test/tools/javac/6979683/TestCast6979683_BAD38.java.errlog
+ test/tools/javac/6979683/TestCast6979683_BAD39.java
+ test/tools/javac/6979683/TestCast6979683_BAD39.java.errlog
+ test/tools/javac/6979683/TestCast6979683_GOOD.java

Changeset: f37253c9e082
Author:    sundar
Date:      2010-09-02 23:10 +0530
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/f37253c9e082

6458749: TypeParameterElement.getEnclosedElements throws NPE within javac.
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Symbol.java
+ test/tools/javac/T6458749.java

Changeset: 3ff3f20471b4
Author:    jjg
Date:      2010-09-02 18:26 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/3ff3f20471b4

6921495: spurious semicolons in class def cause empty NOPOS blocks
Reviewed-by: mcimadamore

! src/share/classes/com/sun/tools/javac/parser/JavacParser.java
+ test/tools/javac/parser/ExtraSemiTest.java

Changeset: 25dd23fa2511
Author:    sundar
Date:      2010-09-03 11:25 +0530
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/25dd23fa2511

6458823: Messager messages on TypeParamterElements to not include position information.
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java
+ test/tools/javac/T6458823/MyProcessor.java
+ test/tools/javac/T6458823/T6458823.java
+ test/tools/javac/T6458823/TestClass.java

Changeset: d54300fb3554
Author:    sundar
Date:      2010-09-03 12:36 +0530
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/d54300fb3554

6956462: AssertionError exception thrown in the Compiler Tree API in JDK 7.
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/Attr.java
+ test/tools/javac/T6956462/T6956462.java
+ test/tools/javac/T6956462/TestClass.java

Changeset: 3fba23db9619
Author:    lana
Date:      2010-09-02 22:11 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/3fba23db9619

Merge


Changeset: 68e765b1e9ed
Author:    lana
Date:      2010-09-03 12:00 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/68e765b1e9ed

Merge


Changeset: ea54372637a5
Author:    jjg
Date:      2010-09-06 12:55 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/ea54372637a5

6930507: Symbols for anonymous and local classes made too late for use by java tree API
Reviewed-by: mcimadamore

! src/share/classes/com/sun/tools/javac/api/JavacTrees.java
! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java
+ test/tools/javac/api/TestGetElement.java
! test/tools/javac/processing/model/element/TestAnonClassNames.java
! test/tools/javac/processing/model/element/TestAnonSourceNames.java

Changeset: 7ae4016c5938
Author:    mcimadamore
Date:      2010-09-07 17:31 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/7ae4016c5938

6337171: javac should create bridge methods when type variable bounds restricted
Summary: javac should add synthetic overrides for inherited abstract methods in order to preserve binary compatibility
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Flags.java
! src/share/classes/com/sun/tools/javac/code/Scope.java
! src/share/classes/com/sun/tools/javac/code/Symbol.java
! src/share/classes/com/sun/tools/javac/code/Types.java
! src/share/classes/com/sun/tools/javac/comp/TransTypes.java
+ src/share/classes/com/sun/tools/javac/util/Filter.java
+ test/tools/javac/generics/OverrideBridge.java

Changeset: 584365f256a7
Author:    mcimadamore
Date:      2010-09-07 17:32 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/584365f256a7

6979327: method handle invocation should use casts instead of type parameters to specify return type
Summary: infer return type for polymorphic signature calls according to updated JSR 292 draft
Reviewed-by: jjg
Contributed-by: john.r.rose at oracle.com

! 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/Infer.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/Target.java
! src/share/classes/com/sun/tools/javac/main/Main.java
! src/share/classes/com/sun/tools/javac/parser/Scanner.java
! src/share/classes/com/sun/tools/javac/resources/compiler.properties
! src/share/classes/com/sun/tools/javac/util/Names.java
! test/tools/javac/diags/examples.not-yet.txt
+ test/tools/javac/diags/examples/TypeParameterOnPolymorphicSignature.java
+ test/tools/javac/diags/examples/UnsupportedExoticID.java
! test/tools/javac/meth/InvokeDyn.java
+ test/tools/javac/meth/InvokeDynTrans.java
+ test/tools/javac/meth/InvokeDynTrans.out
! test/tools/javac/meth/InvokeMH.java
+ test/tools/javac/meth/InvokeMHTrans.java
+ test/tools/javac/meth/InvokeMHTrans.out
- test/tools/javac/meth/MakeNegTests.sh
- test/tools/javac/quid/MakeNegTests.sh
! test/tools/javac/quid/QuotedIdent.java
! test/tools/javac/quid/QuotedIdent2.java

Changeset: 12d8f7e417fd
Author:    mcimadamore
Date:      2010-09-07 17:32 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/12d8f7e417fd

6981185: com.sun.tools.model.JavacTypes.contains() calls Type.contains instead of Types.containsType
Summary: wrong implementation is causing trivial containment tests to fail unexpectedly (when such tests are executed using compiler API)
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/model/JavacTypes.java
+ test/tools/javac/api/TestContainTypes.java

Changeset: bfdfc13fe641
Author:    mcimadamore
Date:      2010-09-07 17:33 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/bfdfc13fe641

6970584: Flow.java should be more error-friendly
Summary: Added a post-attribution visitor that fixup uninitialized types/symbol in AST after erroneous attribution
Reviewed-by: jjg

! 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/Flow.java
! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java
+ test/tools/javac/failover/CheckAttributedTree.java
+ test/tools/javac/failover/FailOver01.java
+ test/tools/javac/failover/FailOver01.out
+ test/tools/javac/failover/FailOver02.java
+ test/tools/javac/failover/FailOver02.out
+ test/tools/javac/failover/FailOver03.java
+ test/tools/javac/failover/FailOver03.out
+ test/tools/javac/failover/FailOver04.java
+ test/tools/javac/failover/FailOver04.out
+ test/tools/javac/failover/FailOver05.java
+ test/tools/javac/failover/FailOver05.out
+ test/tools/javac/failover/FailOver06.java
+ test/tools/javac/failover/FailOver06.out
+ test/tools/javac/failover/FailOver07.java
+ test/tools/javac/failover/FailOver07.out
+ test/tools/javac/failover/FailOver08.java
+ test/tools/javac/failover/FailOver08.out
+ test/tools/javac/failover/FailOver09.java
+ test/tools/javac/failover/FailOver09.out
+ test/tools/javac/failover/FailOver10.java
+ test/tools/javac/failover/FailOver10.out
+ test/tools/javac/failover/FailOver11.java
+ test/tools/javac/failover/FailOver11.out
+ test/tools/javac/failover/FailOver12.java
+ test/tools/javac/failover/FailOver12.out
+ test/tools/javac/failover/FailOver13.java
+ test/tools/javac/failover/FailOver13.out
+ test/tools/javac/failover/FailOver14.java
+ test/tools/javac/failover/FailOver14.out

Changeset: c388fa8c6a43
Author:    ohair
Date:      2010-09-07 15:49 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/c388fa8c6a43

Merge

- test/tools/javac/T6341023.java
- test/tools/javac/meth/MakeNegTests.sh
- test/tools/javac/quid/MakeNegTests.sh

Changeset: 014cf6234586
Author:    sundar
Date:      2010-09-09 09:42 +0530
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/014cf6234586

6900149: IllegalStateException when compiling same files and DiagnosticListener is set.
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java
+ test/tools/javac/T6900149.java

Changeset: fc73f83cd563
Author:    jjg
Date:      2010-09-09 13:31 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/fc73f83cd563

6983239: TreeScanner does not scan default value for method
Reviewed-by: mcimadamore

! src/share/classes/com/sun/source/util/TreeScanner.java
! test/tools/javac/api/T6392782.java
+ test/tools/javac/tree/AbstractTreeScannerTest.java
+ test/tools/javac/tree/JavacTreeScannerTest.java
+ test/tools/javac/tree/SourceTreeScannerTest.java
- test/tools/javac/tree/TreeScannerTest.java

Changeset: 80505c2026e7
Author:    jjg
Date:      2010-09-13 11:35 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/80505c2026e7

6965264: langtools build should use ${ant.core.lib} instead of ${ant.home}/lib/ant.jar
Reviewed-by: mcimadamore
Contributed-by: jesse.glick at oracle.com

! make/build.xml

Changeset: e92ae290fb47
Author:    jjg
Date:      2010-09-13 11:40 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/e92ae290fb47

6978974: [langtools] <findbugs> task should use ${target.java.home}
Reviewed-by: mcimadamore

! make/build.xml

Changeset: 6e2ccba61117
Author:    jjg
Date:      2010-09-16 09:56 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/6e2ccba61117

6985181: Annotations lost from classfile
Reviewed-by: mcimadamore

! src/share/classes/com/sun/tools/javac/api/JavacTrees.java
! src/share/classes/com/sun/tools/javac/code/TypeAnnotations.java
+ test/tools/javac/T6985181.java

Changeset: bbc9765d9ec6
Author:    jjg
Date:      2010-09-16 09:57 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/bbc9765d9ec6

6985115: tests create too much output
Reviewed-by: mcimadamore

! test/tools/javac/T6855236.java
! test/tools/javac/failover/CheckAttributedTree.java
! test/tools/javac/tree/AbstractTreeScannerTest.java
! test/tools/javac/tree/JavacTreeScannerTest.java
! test/tools/javac/tree/SourceTreeScannerTest.java
! test/tools/javap/T6868539.java
! test/tools/javap/T6980017.java

Changeset: c5df455918c4
Author:    lana
Date:      2010-09-16 11:20 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/c5df455918c4

Merge

- test/tools/javac/T6341023.java
- test/tools/javac/meth/MakeNegTests.sh
- test/tools/javac/quid/MakeNegTests.sh
- test/tools/javac/tree/TreeScannerTest.java

Changeset: fd2579b80b83
Author:    lana
Date:      2010-09-24 16:43 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/fd2579b80b83

Merge

- test/tools/javac/T6341023.java
- test/tools/javac/meth/MakeNegTests.sh
- test/tools/javac/quid/MakeNegTests.sh
- test/tools/javac/tree/TreeScannerTest.java

Changeset: 6dbd2d869b05
Author:    cl
Date:      2010-10-01 15:45 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/6dbd2d869b05

Added tag jdk7-b112 for changeset fd2579b80b83

! .hgtags

Changeset: cd3235a96b6c
Author:    cl
Date:      2010-10-07 15:12 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/cd3235a96b6c

Added tag jdk7-b113 for changeset 6dbd2d869b05

! .hgtags

Changeset: 50f9ac2f4730
Author:    mcimadamore
Date:      2010-09-18 09:54 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/50f9ac2f4730

6980862: too aggressive compiler optimization causes stale results of Types.implementation()
Summary: use a scope counter in order to determine when/if the implementation cache entries are stale
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Scope.java
! 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/Enter.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/ClassReader.java

Changeset: 77cc34d5e548
Author:    mcimadamore
Date:      2010-09-18 09:56 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/77cc34d5e548

5088624: cannot find symbol message should be more intelligent
Summary: Resolve.java should keep track of all candidates found during a method resolution sweep to generate more meaningful diagnostics
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/Attr.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/resources/compiler.properties
! src/share/classes/com/sun/tools/javac/util/BasicDiagnosticFormatter.java
! test/tools/javac/6758789/T6758789a.out
! test/tools/javac/6840059/T6840059.out
! test/tools/javac/6857948/T6857948.out
! test/tools/javac/Diagnostics/6722234/T6722234a_1.out
! test/tools/javac/Diagnostics/6722234/T6722234a_2.out
! test/tools/javac/Diagnostics/6722234/T6722234b_1.out
! test/tools/javac/Diagnostics/6722234/T6722234b_2.out
! test/tools/javac/Diagnostics/6722234/T6722234c.out
! test/tools/javac/Diagnostics/6799605/T6799605.out
! test/tools/javac/Diagnostics/6862608/T6862608a.out
! test/tools/javac/Diagnostics/6862608/T6862608b.out
! test/tools/javac/T6326754.out
! test/tools/javac/diags/Example.java
! test/tools/javac/diags/examples.not-yet.txt
+ test/tools/javac/diags/examples/ExplicitParamsDoNotConformToBounds.java
+ test/tools/javac/diags/examples/InapplicableSymbols.java
! test/tools/javac/diags/examples/IncompatibleTypes1.java
+ test/tools/javac/diags/examples/InferArgsLengthMismatch.java
! test/tools/javac/diags/examples/KindnameConstructor.java
! test/tools/javac/diags/examples/NoArgs.java
+ test/tools/javac/diags/examples/VarargsArgumentMismatch.java
! test/tools/javac/diags/examples/WhereCaptured.java
! test/tools/javac/diags/examples/WhereCaptured1.java
! test/tools/javac/diags/examples/WhereTypeVar.java
! test/tools/javac/generics/diamond/neg/Neg06.out
! test/tools/javac/generics/inference/6315770/T6315770.out
! test/tools/javac/generics/inference/6611449/T6611449.out
! test/tools/javac/generics/inference/6638712/T6638712a.out
! test/tools/javac/generics/inference/6638712/T6638712b.out
! test/tools/javac/generics/inference/6638712/T6638712c.out
! test/tools/javac/generics/inference/6638712/T6638712d.out
! test/tools/javac/generics/inference/6638712/T6638712e.out

Changeset: 0c1ef2af7a8e
Author:    mcimadamore
Date:      2010-09-18 14:24 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/0c1ef2af7a8e

6863465: javac doesn't detect circular subclass dependencies via qualified names
Summary: class inheritance circularity check should look at trees, not just symbols
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/Check.java
! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java
+ test/tools/javac/6863465/T6863465a.java
+ test/tools/javac/6863465/T6863465a.out
+ test/tools/javac/6863465/T6863465b.java
+ test/tools/javac/6863465/T6863465b.out
+ test/tools/javac/6863465/T6863465c.java
+ test/tools/javac/6863465/T6863465c.out
+ test/tools/javac/6863465/T6863465d.java
+ test/tools/javac/6863465/T6863465d.out
+ test/tools/javac/6863465/TestCircularClassfile.java
! test/tools/javac/CyclicInheritance.out
! test/tools/javac/NameCollision.out

Changeset: da7ca56d092c
Author:    sundar
Date:      2010-09-22 20:53 +0530
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/da7ca56d092c

6587674: NoClassdefFound when anonymously extending a class.
Reviewed-by: jjg, mcimadamore

! src/share/classes/com/sun/tools/javac/comp/Lower.java
+ test/tools/javac/T6587674.java

Changeset: 3eea38ce151c
Author:    jjg
Date:      2010-09-22 12:53 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/3eea38ce151c

6986772: langtools netbeans build should use ${ant.core.lib} instead of ${ant.home}/lib/ant.jar
Reviewed-by: ohair

! make/netbeans/langtools/build.xml

Changeset: 827d87221959
Author:    lana
Date:      2010-09-25 12:02 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/827d87221959

Merge


Changeset: f6fe12839a8a
Author:    jjg
Date:      2010-09-27 14:05 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/f6fe12839a8a

6890226: javah -version is broken
Reviewed-by: darcy

! src/share/classes/com/sun/tools/javah/JavahTask.java
! src/share/classes/com/sun/tools/javah/resources/l10n.properties
+ src/share/classes/com/sun/tools/javah/resources/version.properties-template
+ test/tools/javah/VersionTest.java

Changeset: 3c9b64e55c5d
Author:    jjg
Date:      2010-09-27 14:20 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/3c9b64e55c5d

6877202: Elements.getDocComment() is not getting JavaDocComments
6861094: javac -Xprint <file> does not print comments
6985205: access to tree positions and doc comments may be lost across annotation processing rounds
Reviewed-by: darcy

! src/share/classes/com/sun/tools/apt/main/JavaCompiler.java
! src/share/classes/com/sun/tools/javac/api/JavacTaskImpl.java
! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java
! src/share/classes/com/sun/tools/javac/parser/DocCommentScanner.java
! src/share/classes/com/sun/tools/javac/parser/JavacParser.java
! src/share/classes/com/sun/tools/javac/parser/ParserFactory.java
! src/share/classes/com/sun/tools/javac/parser/Scanner.java
+ src/share/classes/com/sun/tools/javac/parser/ScannerFactory.java
! src/share/classes/com/sun/tools/javadoc/JavadocTool.java
! test/tools/javac/6302184/T6302184.out
! test/tools/javac/6304921/TestLog.java
! test/tools/javac/api/TestJavacTaskScanner.java
- test/tools/javac/processing/Xprint.java
+ test/tools/javac/processing/model/util/elements/doccomments/TestDocComments.java
+ test/tools/javac/processing/model/util/elements/doccomments/a/First.java
+ test/tools/javac/processing/model/util/elements/doccomments/z/Last.java
+ test/tools/javac/processing/options/Xprint.java
+ test/tools/javac/processing/options/XprintDocComments.java
+ test/tools/javac/processing/options/XprintDocComments.out
+ test/tools/javac/tree/TreePosRoundsTest.java

Changeset: d4df3b6ee729
Author:    jjg
Date:      2010-09-27 17:28 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/d4df3b6ee729

6986246: Trees object is round-specific
Reviewed-by: darcy

! src/share/classes/com/sun/tools/javac/api/JavacTrees.java
! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java
! test/tools/javac/processing/model/util/elements/doccomments/TestDocComments.java
! test/tools/javac/tree/TreePosRoundsTest.java

Changeset: 28b021bb889f
Author:    sundar
Date:      2010-09-28 22:46 +0530
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/28b021bb889f

6967842: Element not returned from tree API for ARM resource variables.
Reviewed-by: jjg, darcy

! src/share/classes/com/sun/tools/javac/code/Symbol.java
+ test/tools/javac/processing/model/element/TestResourceElement.java
! test/tools/javac/processing/model/element/TestResourceVariable.java

Changeset: f94af0667151
Author:    jjg
Date:      2010-09-29 14:01 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/f94af0667151

6502392: Invalid relative names for Filer.createResource and Filer.getResource
Reviewed-by: darcy

! src/share/classes/com/sun/tools/javac/file/JavacFileManager.java
+ test/tools/javac/processing/filer/TestInvalidRelativeNames.java

Changeset: d2aaaec153e8
Author:    darcy
Date:      2010-09-29 23:27 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/d2aaaec153e8

6983738: Use a JavacTestingAbstractProcessor
Reviewed-by: jjg

+ test/tools/javac/lib/JavacTestingAbstractProcessor.java
! test/tools/javac/processing/6348499/A.java
! test/tools/javac/processing/6348499/T6348499.java
! test/tools/javac/processing/6359313/T6359313.java
! test/tools/javac/processing/6365040/ProcBar.java
! test/tools/javac/processing/6365040/ProcFoo.java
! test/tools/javac/processing/6365040/T6365040.java
! test/tools/javac/processing/6413690/T6413690.java
! test/tools/javac/processing/6414633/A.java
! test/tools/javac/processing/6414633/T6414633.java
! test/tools/javac/processing/6430209/T6430209.java
! test/tools/javac/processing/6430209/b6341534.java
! test/tools/javac/processing/6499119/ClassProcessor.java
! test/tools/javac/processing/6511613/DummyProcessor.java
! test/tools/javac/processing/6511613/clss41701.java
! test/tools/javac/processing/6512707/T6512707.java
! test/tools/javac/processing/6634138/T6634138.java
! test/tools/javac/processing/T6439826.java
! test/tools/javac/processing/T6920317.java
! test/tools/javac/processing/environment/TestSourceVersion.java
! test/tools/javac/processing/environment/round/TestElementsAnnotatedWith.java
! test/tools/javac/processing/errors/TestFatalityOfParseErrors.java
! test/tools/javac/processing/errors/TestOptionSyntaxErrors.java
! test/tools/javac/processing/errors/TestReturnCode.java
! test/tools/javac/processing/filer/TestFilerConstraints.java
! test/tools/javac/processing/filer/TestGetResource.java
! test/tools/javac/processing/filer/TestGetResource2.java
! test/tools/javac/processing/filer/TestInvalidRelativeNames.java
! test/tools/javac/processing/filer/TestLastRound.java
! test/tools/javac/processing/filer/TestPackageInfo.java
! test/tools/javac/processing/messager/6362067/T6362067.java
! test/tools/javac/processing/messager/MessagerBasics.java
! test/tools/javac/processing/model/6194785/T6194785.java
! test/tools/javac/processing/model/6341534/T6341534.java
! test/tools/javac/processing/model/element/TestAnonClassNames.java
! test/tools/javac/processing/model/element/TestAnonSourceNames.java
! test/tools/javac/processing/model/element/TestElement.java
! test/tools/javac/processing/model/element/TestNames.java
! test/tools/javac/processing/model/element/TestPackageElement.java
! test/tools/javac/processing/model/element/TestResourceElement.java
! test/tools/javac/processing/model/element/TestResourceVariable.java
! test/tools/javac/processing/model/element/TypeParamBounds.java
! test/tools/javac/processing/model/type/MirroredTypeEx/OverEager.java
! test/tools/javac/processing/model/type/MirroredTypeEx/Plurality.java
! test/tools/javac/processing/model/type/NoTypes.java
! test/tools/javac/processing/model/util/BinaryName.java
! test/tools/javac/processing/model/util/GetTypeElemBadArg.java
! test/tools/javac/processing/model/util/NoSupers.java
! test/tools/javac/processing/model/util/OverridesSpecEx.java
! test/tools/javac/processing/model/util/TypesBadArg.java
! test/tools/javac/processing/model/util/deprecation/TestDeprecation.java
! test/tools/javac/processing/model/util/directSupersOfErr/DirectSupersOfErr.java
! test/tools/javac/processing/model/util/elements/TestGetConstantExpression.java
! test/tools/javac/processing/model/util/elements/TestGetPackageOf.java
! test/tools/javac/processing/model/util/filter/TestIterables.java
! test/tools/javac/processing/warnings/TestSourceVersionWarnings.java
! test/tools/javac/processing/werror/WError1.java
! test/tools/javac/processing/werror/WErrorGen.java
! test/tools/javac/processing/werror/WErrorLast.java

Changeset: 7b413ac1a720
Author:    jjg
Date:      2010-09-30 10:47 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/7b413ac1a720

6988436: Cleanup javac option handling
Reviewed-by: darcy

! 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/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/file/JavacFileManager.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/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/processing/JavacFiler.java
! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.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/Options.java

Changeset: 232919708730
Author:    alanb
Date:      2010-10-03 19:40 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/232919708730

6907737: (file) FileVisitor and Files.walkFileTree issues
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/nio/JavacPathFileManager.java

Changeset: 2c321dcb1edc
Author:    lana
Date:      2010-10-04 14:40 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/2c321dcb1edc

Merge

- test/tools/javac/processing/Xprint.java

Changeset: e4e7408cdc5b
Author:    lana
Date:      2010-10-12 12:52 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/e4e7408cdc5b

Merge

- test/tools/javac/processing/Xprint.java

Changeset: 01e8ac5fbefd
Author:    cl
Date:      2010-10-14 19:25 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/01e8ac5fbefd

Added tag jdk7-b114 for changeset e4e7408cdc5b

! .hgtags

Changeset: caadb412a4a6
Author:    mcimadamore
Date:      2010-10-19 16:26 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/caadb412a4a6

merge with jdk7-b114

! make/build.xml
! src/share/bin/launcher.sh-template
! src/share/classes/com/sun/source/tree/Tree.java
! src/share/classes/com/sun/source/util/TreeScanner.java
! src/share/classes/com/sun/tools/javac/code/Flags.java
! src/share/classes/com/sun/tools/javac/code/Scope.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/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/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/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/Gen.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/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/ScannerFactory.java
! src/share/classes/com/sun/tools/javac/resources/compiler.properties
! src/share/classes/com/sun/tools/javac/tree/JCTree.java
! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java
! src/share/classes/com/sun/tools/javac/util/Log.java
! src/share/classes/com/sun/tools/javac/util/Names.java
- test/tools/javac/T6341023.java
! test/tools/javac/diags/examples.not-yet.txt
+ test/tools/javac/generics/typevars/5060485/Compatibility.out
+ test/tools/javac/generics/typevars/5060485/Compatibility02.out
! test/tools/javac/lambda/BadTargetType.out
! test/tools/javac/lambda/LambdaConv02.out
- test/tools/javac/meth/MakeNegTests.sh
- test/tools/javac/processing/Xprint.java
- test/tools/javac/quid/MakeNegTests.sh
- test/tools/javac/tree/TreeScannerTest.java


From brian.goetz at oracle.com  Tue Oct 19 09:24:47 2010
From: brian.goetz at oracle.com (Brian Goetz)
Date: Tue, 19 Oct 2010 09:24:47 -0700
Subject: Updated State of the Lambda
In-Reply-To: <99A37C22-540B-4474-9C10-3D5376339506@gmail.com>
References: <4CB8B1AF.1090605@oracle.com>
	<201010181004.07597.peter.levart@marand.si>
	<99A37C22-540B-4474-9C10-3D5376339506@gmail.com>
Message-ID: <807505D1-C08F-4421-8141-B04BB8E89BAC@oracle.com>

> The argument of not referring to 'this' as the lambda uses a argument to say that a lambda that doesn't hold onto the enclosing class' instance will be more memory efficient than one that does (c.f. inner classes).

No, it does not.  This is not part of the argument for or against, this is simply an observation about a desirable characteristic.  The decision was made before making this particular observation.  Inner classes could potentially also acquire this characteristic, as you point out, though compatibility becomes more of an issue with that (and it is not currently under consideration.) 



From brian.goetz at oracle.com  Tue Oct 19 09:38:57 2010
From: brian.goetz at oracle.com (Brian Goetz)
Date: Tue, 19 Oct 2010 09:38:57 -0700
Subject: Updated State of the Lambda
In-Reply-To: <AANLkTikuDdqR5fbQcKejKR_dX=oqYFVJvd__Puvpd7sU@mail.gmail.com>
References: <AANLkTikuDdqR5fbQcKejKR_dX=oqYFVJvd__Puvpd7sU@mail.gmail.com>
Message-ID: <8E00E9C9-8897-4CF2-8ECD-51855C43869F@oracle.com>

> I have some reservations about changing the type of this, particularly
> that it will make refactoring from Inner Classes to Lambdas and vice
> versa error prone.

That's a risk, but (a) most of the time the compiler will catch simply cut and paste bugs and (b) we expect IDEs to provide "refactor lambda to named inner class" refactorings, which can adapt / warn on code that uses 'this'.  

> May I suggest a further couple of changes that
> might make refactoring more reliable:
> 
> 1. SAM types can only be interfaces (you must use an inner class if
> you want to inherit from and abstract class or class).

We explored this early on and concluded this was unsatisfactory.  It is quite common in the evolution of a project that interface-based SAM types evolve to be abstract classes when the need for "optional", rarely-used methods is encountered.  This conclusion was made on the basis of looking at specific code bases.  However, moving the cutoff just past "abstract classes with no-arg constructors" captures many more of the desirable cases and excludes relatively few.  

> 2. The specification defines what all Object's methods do for a
> Lambda, in particular getClass, toString, equals, and hashCode, and
> how instanceof behaves, is a Lambda an instance of MethodHandle is it
> an instance of its SAM type?

Neither.  Lambdas expressions can be *converted to* references to SAM types.  It is not specified what they are; they cannot exist in any context other than one in which they will be converted.  So you cannot assume they are objects, or SAM types, or anything.  

This turns out to be far less of a restriction than you might think.  (Think: what is the type of a method body?  Does it bother you that in all your years of Java coding, you've never had the need to ask this question?)  


From brian.goetz at oracle.com  Tue Oct 19 09:46:23 2010
From: brian.goetz at oracle.com (Brian Goetz)
Date: Tue, 19 Oct 2010 09:46:23 -0700
Subject: Updated State of the Lambda
In-Reply-To: <AANLkTin3y7BF9AHtVipBpywgnaTb-B-vHOt=-fyyX7fy@mail.gmail.com>
References: <4CB8B1AF.1090605@oracle.com>
	<201010181004.07597.peter.levart@marand.si>
	<ABB4C621-6B1F-4561-AC44-F287B44DEF5D@oracle.com>
	<AANLkTimRhtgH=uVozfJEku=Hfz4oC7XUpyLUOpEEkR8y@mail.gmail.com>
	<AANLkTin3y7BF9AHtVipBpywgnaTb-B-vHOt=-fyyX7fy@mail.gmail.com>
Message-ID: <741CA25B-F4DF-436D-8261-D8E17BD648CC@oracle.com>


On Oct 19, 2010, at 12:02 AM, Gernot Neppert wrote:

> 2010/10/18 Reinier Zwitserloot <reinier at zwitserloot.com>:
>> Entirely separate from the discussion around implementation details, having
>> practices. I'm speaking specifically of using "this" as an object reference,
>> and not the "this.x" syntax to clarify which field / method you're referring
>> to. Those are scoped in reverse (If the SAM type has a field named "foo" and
>> the outer also does, then an unqualified "foo" reference will refer to the
>> SAM type's). Therefore, using Outer.this syntax will not be necessary; its
>> only for clarification: "x" refers to lambda's x, and "this.x" refers to
>> outer's X. You'd only need it when writing a lambda that is itself in an
>> inner class.
>> 
> 
> Hmm, but here it gets messy, doesn't it?
> One argument in favour of 'this referring to the enclosing instance'
> is that lambdas should deliberately not resemble inner classes because
> they should stand out as a new concept (at least in Java).
> 
> Unfortunately, though, lambdas *are* still instances of classes, and
> simply trying to hide that fact causes inconsistencies that should be
> at least be addressed.

No.  Lambdas are not instances of classes.  Lambdas are *converted to* SAM types.  The SAM types are instances of classes, but are really just "boxes" for the method handle (not unlike the primitive wrapper classes.)  

(In the method reference #doSomething, where #doSomething is assigned to a Runnable, does that mean that the method doSomething() is an instance of Runnable?  Surely not.)  

> Consider the following TimerTask that will cancel itself conditionally:
> 
> class MyClass
> {
>    private final void Timer timer = new Timer();
>    public void cancel()
>    {
>      timer.cancel();
>    }
> 
>    public void scheduleHelloWorld()
>    {
>       timer.scheduler( #{
>                                   System.out.println("Hello world");
>                                   if(new Random().nextBoolean()) cancel();
>                                   } , 1000, 1000 );
>    }
> }
> 
> Merely prefixing 'cancel' with 'this' will now cause the TimerTask to
> cancel the entire timer instead:
> 
> 
>    public void scheduleHelloWorld()
>    {
>       timer.scheduler( #{
>                                   System.out.println("Hello world");
>                                   if(new Random().nextBoolean())
> this.cancel();
>                                   } , 1000, 1000 );
>    }
> 
> 
> Basically the meaning of 'prefixing a variable with this' has been
> reversed compared to the 'normal case' of inner classes.
> Quite counterintuitive, I think!
> 


OK, but you really had to jump through some hoops to construct this example.  Yes, people can and will make mistakes.  (People very frequently make mistakes calling toString() or hashCode() inside of inner classes and are surprised to find what happens!)  We believe people will (a) make fewer mistakes with the lexical scoping of this, and (b) lexical scoping enables other advantages in the compiler and VM, including better type inference and performance.  



From brian.goetz at oracle.com  Tue Oct 19 09:48:16 2010
From: brian.goetz at oracle.com (Brian Goetz)
Date: Tue, 19 Oct 2010 09:48:16 -0700
Subject: Updated State of the Lambda
In-Reply-To: <AANLkTim_ZBA2XB70aJpcPC-w4E9B2zJ328iCdd-O=fat@mail.gmail.com>
References: <4CB8B1AF.1090605@oracle.com>
	<201010181004.07597.peter.levart@marand.si>
	<ABB4C621-6B1F-4561-AC44-F287B44DEF5D@oracle.com>
	<AANLkTimRhtgH=uVozfJEku=Hfz4oC7XUpyLUOpEEkR8y@mail.gmail.com>
	<AANLkTin3y7BF9AHtVipBpywgnaTb-B-vHOt=-fyyX7fy@mail.gmail.com>
	<4CBD5537.9080605@oracle.com>
	<AANLkTim_ZBA2XB70aJpcPC-w4E9B2zJ328iCdd-O=fat@mail.gmail.com>
Message-ID: <1B459450-105B-4525-AE26-011895A4BFF7@oracle.com>


On Oct 19, 2010, at 4:48 AM, Gernot Neppert wrote:

> 2010/10/19 Maurizio Cimadamore <maurizio.cimadamore at oracle.com>:
>> Hi Gernot,
>> 
>>> 
>>> Merely prefixing 'cancel' with 'this' will now cause the TimerTask to
>>> cancel the entire timer instead:
>>> 
>> 
>> not quite, this.cancel() and cancel() [unqualified] both refers to
>> MyClass.cancel - in the latter case the reference to the 'right' this will
>> simply be inferred by the compiler, as already happens with Java. But, from
>> the compiler perspective, there's no TimerTask.cancel() available inside the
>> lambda body - in order to call that you should use the DA/DU trick discussed
>> yesterday:
>> 
> 
> I see what you mean, thanks for the clarification!
> (which will also interest Reinier Zwitserloot whom I cited in my first post).
> 
> However, I see another problem with the approach:
> If the only way to access members of the SAM itself from a within
> lambda is via the reference that it will get assigned to,
> we'll run into trouble with visibility rules!
> See the following example. Provided that the rules for final
> assignment will have been updated, the following should compile.
> The lambda expression wants to make use of the protected
> 'totallyUsefulHelperMethod()' defined in the abstract base class
> 'Sam'.
> However, it can't, because it does not have access to protected
> methods of other instances (even though we know that it's supposed to
> be the same instance in this case).
> This would mean that we could never make use of protected methods of
> abstract base classes in lambdas.
> 
> What do we do?

Use inner classes when you hit the limit of what lambdas can do.  This is a corner case of a corner case; it seems silly to distort the semantics of lambda to accomodate given that there's already a way to do that.  

> 
> 
> package net.lambdas;
> 
> public abstract class Sam implements Runnable
> {
>    protected final void totallyUsefulHelperMethod()
>   {
>   }
> }
> 
> package net.lambdas.test;
> 
> public class TestSam
> {
>   public void testSam()
>   {
>      final Sam s = #{  s.totallyUsefulHelperMethod(); };
>   }
> }
> 


From brian.goetz at oracle.com  Tue Oct 19 09:49:51 2010
From: brian.goetz at oracle.com (Brian Goetz)
Date: Tue, 19 Oct 2010 09:49:51 -0700
Subject: Lambdas and serialization
In-Reply-To: <AANLkTin4ig6HgmoVwSpgRwOcY8ozGdZrz=u8SGBj8-Sj@mail.gmail.com>
References: <AANLkTin4ig6HgmoVwSpgRwOcY8ozGdZrz=u8SGBj8-Sj@mail.gmail.com>
Message-ID: <A8B58C3B-3A99-4285-92D3-4E68F2036004@oracle.com>

Yes, yes, and yes.  

It will be very bad to assign a lambda to a Serializable SAM type and have it not be serialiazable.  

This is as much a question for the JSR-292 expert group (Remi?) as for us.  We don't have an answer yet but this is an important requirement.

On Oct 19, 2010, at 6:11 AM, Alessio Stalla wrote:

> Hello,
> 
> I just thought about an aspect that I don't recall having been
> mentioned on this list: if a lambda's target SAM type is serializable,
> will the SAM-converted lambda be guaranteed to be serializable as
> well? Or is it an unspecified implementation detail? I see a certain
> value in having serialization work for lambdas, but also a host of
> potential problems...
> 
> Regards,
> Alessio
> 


From nathan.bryant at linkshare.com  Tue Oct 19 09:58:17 2010
From: nathan.bryant at linkshare.com (Nathan Bryant)
Date: Wed, 20 Oct 2010 01:58:17 +0900
Subject: Lambdas and serialization
References: <AANLkTin4ig6HgmoVwSpgRwOcY8ozGdZrz=u8SGBj8-Sj@mail.gmail.com>	<AANLkTinKKTZWF0oH7LKDBXj8vrsd2_tWk7=1ZC1jk7P+@mail.gmail.com>	<AANLkTi=r1C4yg+xgedauvDPGgf5AMGWsmcmDPZa-Hh_7@mail.gmail.com><4CBDA6E7.1050501@oracle.com>
	<4CBDBCC1.9020706@univ-mlv.fr>
Message-ID: <7FDA6630E1822F448C97A48D5D7330940206B558@EXVMSTOR302.intra.rakuten.co.jp>

Hi R?mi,

If lambdas are to be SAM converted then users will find it a surprising limitation that the resulting SAM instance does not have the same capabilities as a regular SAM; it leads to an irregularity in the language. Any implementation choice that precludes serialization should be considered an implementation bug.

-----Original Message-----
From: lambda-dev-bounces at openjdk.java.net [mailto:lambda-dev-bounces at openjdk.java.net] On Behalf Of R?mi Forax
Sent: Tuesday, October 19, 2010 11:44 AM
To: lambda-dev at openjdk.java.net
Subject: Re: Lambdas and serialization

Le 19/10/2010 16:10, Maurizio Cimadamore a ?crit :
> On 19/10/10 14:41, Alessio Stalla wrote:
>    
>> On Tue, Oct 19, 2010 at 3:30 PM, Paul Benedict<pbenedict at apache.org>   wrote:
>>
>>      
>>> Will the wrapper be serializable if the SAM interface is? That's a
>>> good question, but I imagine it has to be because it is implementing
>>> the interface.
>>>
>>> public interface MySamType extends Serializable {
>>>    void doSomething(int x);
>>> }
>>>
>>>        
>> Sorry, I was unclear with the expression "be serializable": what I
>> really meant is not if it will merely implement java.io.Serializable,
>> rather if it will actually be serialized by an ObjectOutputStream
>> without any exception in all cases where a "regular" instance of the
>> SAM would have been serialized without exceptions, and deserialized in
>> the same conditions as well. That's imho a desirable feature to have,
>> but it places a possibly non-trivial burden on the implementation.
>>
>>
>>      
> Good point. The short answer to this question is: it depends on how
> lambda expressions are translated by the compiler. If the compiler uses
> anonymous inner classes to translate away lambda expression, then the
> answer is yes. If lambda expressions are to be translated away by using
> method handles, then I *guess* the answer is no, as it seems like
> MethodHandle are not serializable (Remi or John might know more about
> this though).
>
> Maurizio
>    

Lambda are not serializable, like java.lang.reflect.Method
because it will create tons of security holes.

BTW, inner classes have some trouble with serialUID.

R?mi


From maurizio.cimadamore at oracle.com  Tue Oct 19 10:03:36 2010
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Tue, 19 Oct 2010 18:03:36 +0100
Subject: lambda syntax tutorial - cont'd
In-Reply-To: <4C59999E.8050609@oracle.com>
References: <4C59999E.8050609@oracle.com>
Message-ID: <4CBDCF68.6070204@oracle.com>

Hi,
here's an update of the rough syntax tutorial I put together few months 
ago. It reflects latest syntax changes as implemented in the compiler.

Maurizio

On 04/08/10 17:47, Maurizio Cimadamore wrote:
> Hi,
> since most of the features are available in the compiler, I took the 
> time to write a pretty basic syntax document/tutorial that shows the 
> syntax supported by the current lambda prototype. As usual, the 
> document does *not* imply that the currently implemented syntax is 
> also the final one - the aim of this document is to simply help 
> developers working with the lambda prototype.
>
> Thanks
> Maurizio
>
>
>
>    

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: lambda-syntax-v2.txt
Url: http://mail.openjdk.java.net/pipermail/lambda-dev/attachments/20101019/ef738c7f/attachment-0001.txt 

From crazybob at crazybob.org  Tue Oct 19 10:18:09 2010
From: crazybob at crazybob.org (Bob Lee)
Date: Tue, 19 Oct 2010 10:18:09 -0700
Subject: Lambdas and serialization
In-Reply-To: <A8B58C3B-3A99-4285-92D3-4E68F2036004@oracle.com>
References: <AANLkTin4ig6HgmoVwSpgRwOcY8ozGdZrz=u8SGBj8-Sj@mail.gmail.com>
	<A8B58C3B-3A99-4285-92D3-4E68F2036004@oracle.com>
Message-ID: <AANLkTim_Q_9X6+OWM+vSrej5oGjOSbm5+ZDWJOHLe9iW@mail.gmail.com>

FWIW, anonymous inner classes can technically be serializable (insofar as
they can implement Serializable), but it's typically not safe to do so
because their internal state is unspecified. In other words, the
serializable form of an anonymous inner class from one compiler may not be
compatible with another.

I've personally always wanted anonymous classes to be safely serializable so
I could use them in HTTP sessions, RPCs, etc.

Bob

From nathan.bryant at linkshare.com  Tue Oct 19 10:48:52 2010
From: nathan.bryant at linkshare.com (Nathan Bryant)
Date: Wed, 20 Oct 2010 02:48:52 +0900
Subject: Lambdas and serialization
References: <AANLkTin4ig6HgmoVwSpgRwOcY8ozGdZrz=u8SGBj8-Sj@mail.gmail.com><A8B58C3B-3A99-4285-92D3-4E68F2036004@oracle.com>
	<AANLkTim_Q_9X6+OWM+vSrej5oGjOSbm5+ZDWJOHLe9iW@mail.gmail.com>
Message-ID: <7FDA6630E1822F448C97A48D5D7330940206B5EA@EXVMSTOR302.intra.rakuten.co.jp>

It does seem like there is a more general issue: simply that they're
anonymous. How do you safely serialize something that has no
reliably-defined name, or a name that's just a byproduct of whatever the
compiler decided to call it?

For example, if you pass one over RMI, I think the peer will try to
resolve that name locally, and might resolve it the wrong way. Only if
it can't find the name will it attempt to download the bytecode from the
other end.

-----Original Message-----
From: lambda-dev-bounces at openjdk.java.net
[mailto:lambda-dev-bounces at openjdk.java.net] On Behalf Of Bob Lee
Sent: Tuesday, October 19, 2010 1:18 PM
To: Brian Goetz
Cc: lambda-dev
Subject: Re: Lambdas and serialization

FWIW, anonymous inner classes can technically be serializable (insofar
as
they can implement Serializable), but it's typically not safe to do so
because their internal state is unspecified. In other words, the
serializable form of an anonymous inner class from one compiler may not
be
compatible with another.

I've personally always wanted anonymous classes to be safely
serializable so
I could use them in HTTP sessions, RPCs, etc.

Bob


From forax at univ-mlv.fr  Tue Oct 19 11:19:04 2010
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Tue, 19 Oct 2010 20:19:04 +0200
Subject: Lambdas and serialization
In-Reply-To: <4CBDBC13.8060601@oracle.com>
References: <AANLkTin4ig6HgmoVwSpgRwOcY8ozGdZrz=u8SGBj8-Sj@mail.gmail.com>	<AANLkTinKKTZWF0oH7LKDBXj8vrsd2_tWk7=1ZC1jk7P+@mail.gmail.com>	<AANLkTi=r1C4yg+xgedauvDPGgf5AMGWsmcmDPZa-Hh_7@mail.gmail.com>	<4CBDA6E7.1050501@oracle.com>
	<4CBDBCC1.9020706@univ-mlv.fr> <4CBDBC13.8060601@oracle.com>
Message-ID: <4CBDE118.4030103@univ-mlv.fr>

Le 19/10/2010 17:41, Maurizio Cimadamore a ?crit :

[...]

>> Lambda are not serializable, like java.lang.reflect.Method
>> because it will create tons of security holes.
> You mean method handles are not serializable? What are the security 
> holes deriving from serializable lambda (assuming latest Brian's 
> document) ?

If you can serialize a lambda, you are able to forge a binary blob which 
once decoded by the serialization
is a reference any private method.

>
> Maurizio

R?mi


From tom.hawtin at oracle.com  Tue Oct 19 12:50:47 2010
From: tom.hawtin at oracle.com (tom.hawtin at oracle.com)
Date: Tue, 19 Oct 2010 20:50:47 +0100
Subject: Lambdas and serialization
In-Reply-To: <4CBDBCC1.9020706@univ-mlv.fr>
References: <AANLkTin4ig6HgmoVwSpgRwOcY8ozGdZrz=u8SGBj8-Sj@mail.gmail.com>	<AANLkTinKKTZWF0oH7LKDBXj8vrsd2_tWk7=1ZC1jk7P+@mail.gmail.com>	<AANLkTi=r1C4yg+xgedauvDPGgf5AMGWsmcmDPZa-Hh_7@mail.gmail.com>	<4CBDA6E7.1050501@oracle.com>
	<4CBDBCC1.9020706@univ-mlv.fr>
Message-ID: <4CBDF697.2010201@oracle.com>

On 19/10/2010 16:44, R?mi Forax wrote:

> Lambda are not serializable, like java.lang.reflect.Method
> because it will create tons of security holes.

Having lambdas serialisable by default would rather put them out of 
bounds for code that deals with other less trusted code. However, as 
anonymous inner classes, it is not a security issue that they can be 
serialisable if the creator explicitly wants them to be.

> BTW, inner classes have some trouble with serialUID.

Depends on the purpose. If you go right back serialisation was part of 
making both data and code mobile. In a way that may be thought of as 
object oriented (probably a dangerous thought). If the data and code is 
in step, then the default serialVersionUID calculation is ideal. 
Unfortunately provided mechnanisms for keeping data and code in step a 
tad "lightweight" and this isn't really how serialisation appears to be 
used these days.

Perhaps it would be useful to extend the SAM syntax to enums (SAMEs?), 
for stateless lambdas. Or perhaps Java has deeper issues with objects 
capturing state (compare against Simula).

Tom Hawtin

From alessiostalla at gmail.com  Tue Oct 19 15:33:33 2010
From: alessiostalla at gmail.com (Alessio Stalla)
Date: Wed, 20 Oct 2010 00:33:33 +0200
Subject: Lambdas and serialization
In-Reply-To: <AANLkTim_Q_9X6+OWM+vSrej5oGjOSbm5+ZDWJOHLe9iW@mail.gmail.com>
References: <AANLkTin4ig6HgmoVwSpgRwOcY8ozGdZrz=u8SGBj8-Sj@mail.gmail.com>
	<A8B58C3B-3A99-4285-92D3-4E68F2036004@oracle.com>
	<AANLkTim_Q_9X6+OWM+vSrej5oGjOSbm5+ZDWJOHLe9iW@mail.gmail.com>
Message-ID: <AANLkTi=1fqMP1ASeYkDG_2bHOeoBdoVyPLgte-j_7sC=@mail.gmail.com>

On Tue, Oct 19, 2010 at 7:18 PM, Bob Lee <crazybob at crazybob.org> wrote:
> FWIW, anonymous inner classes can technically be serializable (insofar as
> they can implement Serializable), but it's typically not safe to do so
> because their internal state is unspecified. In other words, the
> serializable form of an anonymous inner class from one compiler may not be
> compatible with another.

Well, but then the serializable form of any java.* class is not
necessarily compatible between different JVMs, again because the
internal details might be different. Default serialization is not
meant as a standard storage format, rather as a means to store a graph
of objects into a sequence of bytes and restore it later *using the
same JVM*.

> I've personally always wanted anonymous classes to be safely serializable so
> I could use them in HTTP sessions, RPCs, etc.

If you want, you can; serialization is flexible enough to allow it.
Provided of course that both sides of the communication have loaded
the same class with the same name.

From crazybob at crazybob.org  Tue Oct 19 15:40:26 2010
From: crazybob at crazybob.org (Bob Lee)
Date: Tue, 19 Oct 2010 15:40:26 -0700
Subject: Lambdas and serialization
In-Reply-To: <AANLkTi=1fqMP1ASeYkDG_2bHOeoBdoVyPLgte-j_7sC=@mail.gmail.com>
References: <AANLkTin4ig6HgmoVwSpgRwOcY8ozGdZrz=u8SGBj8-Sj@mail.gmail.com>
	<A8B58C3B-3A99-4285-92D3-4E68F2036004@oracle.com>
	<AANLkTim_Q_9X6+OWM+vSrej5oGjOSbm5+ZDWJOHLe9iW@mail.gmail.com>
	<AANLkTi=1fqMP1ASeYkDG_2bHOeoBdoVyPLgte-j_7sC=@mail.gmail.com>
Message-ID: <AANLkTin-FkLWyvd=sPDJ8kTH_ZOP-pFbbvzubz_4BMZG@mail.gmail.com>

On Tue, Oct 19, 2010 at 3:33 PM, Alessio Stalla <alessiostalla at gmail.com>wrote:

> Well, but then the serializable form of any java.* class is not
> necessarily compatible between different JVMs, again because the
> internal details might be different. Default serialization is not
> meant as a standard storage format, rather as a means to store a graph
> of objects into a sequence of bytes and restore it later *using the
> same JVM*.


That's actually not true. If a class is serializable, its serialized form is
part of the published API, and you are guaranteed compatibility across VMs
and VM versions.

Bob

From nathan.bryant at linkshare.com  Tue Oct 19 16:13:33 2010
From: nathan.bryant at linkshare.com (Nathan Bryant)
Date: Wed, 20 Oct 2010 08:13:33 +0900
Subject: Lambdas and serialization
References: <AANLkTin4ig6HgmoVwSpgRwOcY8ozGdZrz=u8SGBj8-Sj@mail.gmail.com><A8B58C3B-3A99-4285-92D3-4E68F2036004@oracle.com><AANLkTim_Q_9X6+OWM+vSrej5oGjOSbm5+ZDWJOHLe9iW@mail.gmail.com>
	<AANLkTi=1fqMP1ASeYkDG_2bHOeoBdoVyPLgte-j_7sC=@mail.gmail.com>
Message-ID: <7FDA6630E1822F448C97A48D5D7330940206B900@EXVMSTOR302.intra.rakuten.co.jp>

Take the example of an RMI client/server, where the client wants to pass
a lambda to the server for remote execution.

Although there's the general problem with anonymity of inner classes,
and non-durability of the automatically generated version ID, it's quite
sufficient (and easy) for this use case to simply ensure that the server
does not have the same class by the same name. Then it can load it via
the java.rmi.server.RMIClassLoader.

-----Original Message-----
...

If you want, you can; serialization is flexible enough to allow it.
Provided of course that both sides of the communication have loaded
the same class with the same name.


From mthornton at optrak.co.uk  Wed Oct 20 00:49:41 2010
From: mthornton at optrak.co.uk (Mark Thornton)
Date: Wed, 20 Oct 2010 08:49:41 +0100
Subject: Lambdas and serialization
In-Reply-To: <AANLkTin-FkLWyvd=sPDJ8kTH_ZOP-pFbbvzubz_4BMZG@mail.gmail.com>
References: <AANLkTin4ig6HgmoVwSpgRwOcY8ozGdZrz=u8SGBj8-Sj@mail.gmail.com>	<A8B58C3B-3A99-4285-92D3-4E68F2036004@oracle.com>	<AANLkTim_Q_9X6+OWM+vSrej5oGjOSbm5+ZDWJOHLe9iW@mail.gmail.com>	<AANLkTi=1fqMP1ASeYkDG_2bHOeoBdoVyPLgte-j_7sC=@mail.gmail.com>
	<AANLkTin-FkLWyvd=sPDJ8kTH_ZOP-pFbbvzubz_4BMZG@mail.gmail.com>
Message-ID: <4CBE9F15.3000009@optrak.co.uk>

  On 19/10/2010 23:40, Bob Lee wrote:
>
> That's actually not true. If a class is serializable, its serialized form is
> part of the published API, and you are guaranteed compatibility across VMs
> and VM versions.
>
Only true if you explicitly specify the serialVersionUID. The default 
calculation includes methods which are implementation artifacts of a 
particular compiler.

Mark



From alessiostalla at gmail.com  Wed Oct 20 00:54:13 2010
From: alessiostalla at gmail.com (Alessio Stalla)
Date: Wed, 20 Oct 2010 09:54:13 +0200
Subject: Lambdas and serialization
In-Reply-To: <4CBE9F15.3000009@optrak.co.uk>
References: <AANLkTin4ig6HgmoVwSpgRwOcY8ozGdZrz=u8SGBj8-Sj@mail.gmail.com>
	<A8B58C3B-3A99-4285-92D3-4E68F2036004@oracle.com>
	<AANLkTim_Q_9X6+OWM+vSrej5oGjOSbm5+ZDWJOHLe9iW@mail.gmail.com>
	<AANLkTi=1fqMP1ASeYkDG_2bHOeoBdoVyPLgte-j_7sC=@mail.gmail.com>
	<AANLkTin-FkLWyvd=sPDJ8kTH_ZOP-pFbbvzubz_4BMZG@mail.gmail.com>
	<4CBE9F15.3000009@optrak.co.uk>
Message-ID: <AANLkTik1a81t3oAqbzE1MaKXPwKG6PeDouwQM-C1NFiK@mail.gmail.com>

On Wed, Oct 20, 2010 at 9:49 AM, Mark Thornton <mthornton at optrak.co.uk> wrote:
> ?On 19/10/2010 23:40, Bob Lee wrote:
>>
>> That's actually not true. If a class is serializable, its serialized form is
>> part of the published API, and you are guaranteed compatibility across VMs
>> and VM versions.
>>
> Only true if you explicitly specify the serialVersionUID. The default
> calculation includes methods which are implementation artifacts of a
> particular compiler.

True, for user-defined classes. But for implementation-defined
classes, you don't have any guarantee. In fact if you look at the
documentation for Swing components, which are serializable, you'll
find a big disclaimer along the lines of "only use serialization for
short-term storage".

From mark at klomp.org  Wed Oct 20 00:55:05 2010
From: mark at klomp.org (Mark Wielaard)
Date: Wed, 20 Oct 2010 09:55:05 +0200
Subject: Lambdas and serialization
In-Reply-To: <AANLkTin-FkLWyvd=sPDJ8kTH_ZOP-pFbbvzubz_4BMZG@mail.gmail.com>
References: <AANLkTin4ig6HgmoVwSpgRwOcY8ozGdZrz=u8SGBj8-Sj@mail.gmail.com>
	<A8B58C3B-3A99-4285-92D3-4E68F2036004@oracle.com>
	<AANLkTim_Q_9X6+OWM+vSrej5oGjOSbm5+ZDWJOHLe9iW@mail.gmail.com>
	<AANLkTi=1fqMP1ASeYkDG_2bHOeoBdoVyPLgte-j_7sC=@mail.gmail.com>
	<AANLkTin-FkLWyvd=sPDJ8kTH_ZOP-pFbbvzubz_4BMZG@mail.gmail.com>
Message-ID: <1287561305.2686.31.camel@springer.wildebeest.org>

On Tue, 2010-10-19 at 15:40 -0700, Bob Lee wrote:
> On Tue, Oct 19, 2010 at 3:33 PM, Alessio Stalla <alessiostalla at gmail.com>wrote:
> 
> > Well, but then the serializable form of any java.* class is not
> > necessarily compatible between different JVMs, again because the
> > internal details might be different. Default serialization is not
> > meant as a standard storage format, rather as a means to store a graph
> > of objects into a sequence of bytes and restore it later *using the
> > same JVM*.

> That's actually not true. If a class is serializable, its serialized form is
> part of the published API, and you are guaranteed compatibility across VMs
> and VM versions.

But not all serialized forms are published. For example it is not
specified how precisely an inner class is transformed to byte code
(compiler generated methods/fields can have different names) so using
different java source to byte code compilers might result in different
serialized forms. And sometimes constructs use (undocumented) internal
implementation classes for serialization like Annotations (which uses
sun.reflect.annotation which isn't guaranteed to be compatible across
independent implementations).

Cheers,

Mark


From howard.lovatt at gmail.com  Wed Oct 20 01:04:10 2010
From: howard.lovatt at gmail.com (Howard Lovatt)
Date: Wed, 20 Oct 2010 19:04:10 +1100
Subject: Updated State of the Lambda
In-Reply-To: <8E00E9C9-8897-4CF2-8ECD-51855C43869F@oracle.com>
References: <AANLkTikuDdqR5fbQcKejKR_dX=oqYFVJvd__Puvpd7sU@mail.gmail.com>
	<8E00E9C9-8897-4CF2-8ECD-51855C43869F@oracle.com>
Message-ID: <AANLkTi=AguNNfeogyMg9fyGwHK5ynmsSBK8skvV6MZdy@mail.gmail.com>

Hi Brian,

Taking each of your points in turn:

1. Yes an IDE can help with the refactoring of inner classes to
lambdas and the changing of this, however not everyone uses an IDE (I
personally do but know many people who use a text editor or if they do
use an IDE they use it like a text editor).

2. I agree that abstract classes as SAM types are desirable, but the construct:

   AbstractClass ac = #{ ac.sam() };

will be confusing because people are used to qualifying with a class
name, not an field/variable name. Also rather defeats the point of an
inline definition since it must be on a separate line.

3. Not defining what instanceof, getClass, etc. do is undesirable, consider:

  Runnable r = #{ ... };
  List<Runnable> l = new ArrayList<>();
  List<Runnable> cl = Collections.checkedList( l, Runnable.class );
  cl.add( r ); // Oops - fails because r isn't a Runnable (its only
treated as one by the type system - not by the JVM)

You get similar issues to the checkedList issue above with
Serializable/Cloneable; you need, at times, to be able to check if an
object is Serializable/Cloneable.

Cheers,

 -- Howard.

On 20 October 2010 03:38, Brian Goetz <brian.goetz at oracle.com> wrote:
>> I have some reservations about changing the type of this, particularly
>> that it will make refactoring from Inner Classes to Lambdas and vice
>> versa error prone.
>
> That's a risk, but (a) most of the time the compiler will catch simply cut and paste bugs and (b) we expect IDEs to provide "refactor lambda to named inner class" refactorings, which can adapt / warn on code that uses 'this'.
>
>> May I suggest a further couple of changes that
>> might make refactoring more reliable:
>>
>> 1. SAM types can only be interfaces (you must use an inner class if
>> you want to inherit from and abstract class or class).
>
> We explored this early on and concluded this was unsatisfactory. ?It is quite common in the evolution of a project that interface-based SAM types evolve to be abstract classes when the need for "optional", rarely-used methods is encountered. ?This conclusion was made on the basis of looking at specific code bases. ?However, moving the cutoff just past "abstract classes with no-arg constructors" captures many more of the desirable cases and excludes relatively few.
>
>> 2. The specification defines what all Object's methods do for a
>> Lambda, in particular getClass, toString, equals, and hashCode, and
>> how instanceof behaves, is a Lambda an instance of MethodHandle is it
>> an instance of its SAM type?
>
> Neither. ?Lambdas expressions can be *converted to* references to SAM types. ?It is not specified what they are; they cannot exist in any context other than one in which they will be converted. ?So you cannot assume they are objects, or SAM types, or anything.
>
> This turns out to be far less of a restriction than you might think. ?(Think: what is the type of a method body? ?Does it bother you that in all your years of Java coding, you've never had the need to ask this question?)
>
>



-- 
? -- Howard.

From alessiostalla at gmail.com  Wed Oct 20 02:32:12 2010
From: alessiostalla at gmail.com (Alessio Stalla)
Date: Wed, 20 Oct 2010 11:32:12 +0200
Subject: Updated State of the Lambda
In-Reply-To: <AANLkTi=AguNNfeogyMg9fyGwHK5ynmsSBK8skvV6MZdy@mail.gmail.com>
References: <AANLkTikuDdqR5fbQcKejKR_dX=oqYFVJvd__Puvpd7sU@mail.gmail.com>
	<8E00E9C9-8897-4CF2-8ECD-51855C43869F@oracle.com>
	<AANLkTi=AguNNfeogyMg9fyGwHK5ynmsSBK8skvV6MZdy@mail.gmail.com>
Message-ID: <AANLkTi=iUzrdGrmzNqfo7Neq=_pknc70LbaW5MFWFNrS@mail.gmail.com>

On Wed, Oct 20, 2010 at 10:04 AM, Howard Lovatt <howard.lovatt at gmail.com> wrote:
> Hi Brian,
>
> Taking each of your points in turn:
>
> 1. Yes an IDE can help with the refactoring of inner classes to
> lambdas and the changing of this, however not everyone uses an IDE (I
> personally do but know many people who use a text editor or if they do
> use an IDE they use it like a text editor).

You could ease the transition by adding a compiler flag to warn about
the use of this inside lambdas.

> 2. I agree that abstract classes as SAM types are desirable, but the construct:
>
> ? AbstractClass ac = #{ ac.sam() };
>
> will be confusing because people are used to qualifying with a class
> name, not an field/variable name. Also rather defeats the point of an
> inline definition since it must be on a separate line.

Lambdas are a new concept, people will have to adapt (or not use
them). I appreciate the distinction between lambdas and inner classes,
as the former are not merely syntax sugar for the latter. This leaves
the door open for future extensions. So, I favor a certain decoupling
between the lambda and the target SAM, and the proposed treatment of
this imho goes into the right direction in that regard.

> 3. Not defining what instanceof, getClass, etc. do is undesirable, consider:
>
> ?Runnable r = #{ ... };
> ?List<Runnable> l = new ArrayList<>();
> ?List<Runnable> cl = Collections.checkedList( l, Runnable.class );
> ?cl.add( r ); // Oops - fails because r isn't a Runnable (its only
> treated as one by the type system - not by the JVM)

No, it *is* a Runnable, that's the whole point of SAM conversion. It
can be freely passed around and invoked by code that knows nothing
about lambdas.

> You get similar issues to the checkedList issue above with
> Serializable/Cloneable; you need, at times, to be able to check if an
> object is Serializable/Cloneable.

You can check it, the problem is how it will behave at runtime when
you attempt to serialize/clone it. But AFAIK you have the same problem
with proxies.

Alessio

From tom.hawtin at oracle.com  Wed Oct 20 05:49:02 2010
From: tom.hawtin at oracle.com (tom.hawtin at oracle.com)
Date: Wed, 20 Oct 2010 13:49:02 +0100
Subject: Lambdas and serialization
In-Reply-To: <AANLkTik1a81t3oAqbzE1MaKXPwKG6PeDouwQM-C1NFiK@mail.gmail.com>
References: <AANLkTin4ig6HgmoVwSpgRwOcY8ozGdZrz=u8SGBj8-Sj@mail.gmail.com>	<A8B58C3B-3A99-4285-92D3-4E68F2036004@oracle.com>	<AANLkTim_Q_9X6+OWM+vSrej5oGjOSbm5+ZDWJOHLe9iW@mail.gmail.com>	<AANLkTi=1fqMP1ASeYkDG_2bHOeoBdoVyPLgte-j_7sC=@mail.gmail.com>	<AANLkTin-FkLWyvd=sPDJ8kTH_ZOP-pFbbvzubz_4BMZG@mail.gmail.com>	<4CBE9F15.3000009@optrak.co.uk>
	<AANLkTik1a81t3oAqbzE1MaKXPwKG6PeDouwQM-C1NFiK@mail.gmail.com>
Message-ID: <4CBEE53E.1060405@oracle.com>

On 20/10/2010 08:54, Alessio Stalla wrote:

> True, for user-defined classes. But for implementation-defined
> classes, you don't have any guarantee. In fact if you look at the
> documentation for Swing components, which are serializable, you'll
> find a big disclaimer along the lines of "only use serialization for
> short-term storage".

Swing is a special case. Hence that documentation, and the absence of 
Swing from the Serialized Form documentation (not that the Serialized 
Form documentation is that precise).

http://download.oracle.com/javase/6/docs/api/serialized-form.html

Tom

From forax at univ-mlv.fr  Wed Oct 20 06:37:02 2010
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Wed, 20 Oct 2010 15:37:02 +0200
Subject: Lambdas and serialization
In-Reply-To: <4CBDF697.2010201@oracle.com>
References: <AANLkTin4ig6HgmoVwSpgRwOcY8ozGdZrz=u8SGBj8-Sj@mail.gmail.com>	<AANLkTinKKTZWF0oH7LKDBXj8vrsd2_tWk7=1ZC1jk7P+@mail.gmail.com>	<AANLkTi=r1C4yg+xgedauvDPGgf5AMGWsmcmDPZa-Hh_7@mail.gmail.com>	<4CBDA6E7.1050501@oracle.com>
	<4CBDBCC1.9020706@univ-mlv.fr> <4CBDF697.2010201@oracle.com>
Message-ID: <4CBEF07E.3040704@univ-mlv.fr>

Hi tom,

Le 19/10/2010 21:50, tom.hawtin at oracle.com a ?crit :
> On 19/10/2010 16:44, R?mi Forax wrote:
>
>> Lambda are not serializable, like java.lang.reflect.Method
>> because it will create tons of security holes.

sorry, I mean method handle are not serializable.
Lambda can be serializable if the spec change :)

>
> Having lambdas serialisable by default would rather put them out of 
> bounds for code that deals with other less trusted code. However, as 
> anonymous inner classes, it is not a security issue that they can be 
> serialisable if the creator explicitly wants them to be.

Yes, perhaps the lambda spec should be modified to add a way for the 
user to request serialization.
In that case, the compiler need to provide a dedicated support for that 
by storing more information
that just a method handle.

>
>> BTW, inner classes have some trouble with serialUID.
>
> Depends on the purpose. If you go right back serialisation was part of 
> making both data and code mobile. In a way that may be thought of as 
> object oriented (probably a dangerous thought). If the data and code 
> is in step, then the default serialVersionUID calculation is ideal. 
> Unfortunately provided mechnanisms for keeping data and code in step a 
> tad "lightweight" and this isn't really how serialisation appears to 
> be used these days.

There is another problem if you want migrate the code, where to stop, 
you can easily construct example
where the whole application code need to be transferred.

>
> Perhaps it would be useful to extend the SAM syntax to enums (SAMEs?), 
> for stateless lambdas. Or perhaps Java has deeper issues with objects 
> capturing state (compare against Simula).

Yes, something like enum, a lambda can be encoded as a class and a 
method name/method descriptor +
some bound arguments.
I don't see any issue with bound object if there are serializable.
Method handle bind objects using theirs values (like inner-classes) with 
a semantics which is at least
as strong as reading the values in final fields.

>
> Tom Hawtin

R?mi

From reinier at zwitserloot.com  Wed Oct 20 06:37:40 2010
From: reinier at zwitserloot.com (Reinier Zwitserloot)
Date: Wed, 20 Oct 2010 15:37:40 +0200
Subject: Updated State of the Lambda
In-Reply-To: <AANLkTi=AguNNfeogyMg9fyGwHK5ynmsSBK8skvV6MZdy@mail.gmail.com>
References: <AANLkTikuDdqR5fbQcKejKR_dX=oqYFVJvd__Puvpd7sU@mail.gmail.com>
	<8E00E9C9-8897-4CF2-8ECD-51855C43869F@oracle.com>
	<AANLkTi=AguNNfeogyMg9fyGwHK5ynmsSBK8skvV6MZdy@mail.gmail.com>
Message-ID: <AANLkTi=Hn8sD+42OVXyR3L4essirK2uzFB6hnW5ND6ru@mail.gmail.com>

On Wed, Oct 20, 2010 at 10:04 AM, Howard Lovatt <howard.lovatt at gmail.com>wrote:

> 2. I agree that abstract classes as SAM types are desirable, but the
> construct:
>
>   AbstractClass ac = #{ ac.sam() };
>
> will be confusing because people are used to qualifying with a class
> name, not an field/variable name. Also rather defeats the point of an
> inline definition since it must be on a separate line.
>


I don't have solid numbers for this, but think of the practical use case:
You'd almost NEVER need to call your own SAM types' methods. For all
interface SAMs (which I'm guessing are going to be the (vast) majority of
SAM types), there's absolutely no point. How often do you need .clone(),
.equals(), .hashCode(), or wait/notify stuff on self, and how often do you
need to recurse? Virtually never. On the other hand, calling the container's
.toString() sounds like something I might do rather a lot.

For AbstractClass SAMs there's more utility in calling self. Some sort of
DSL-ish approach where a bunch of utility methods are defined in a class
SAM. This particular use case is hurt quite a bit by the DA/DU trick, but
there are alternatives: static imports, and using an anonymous inner class.

A solution where either kind of call is trivial would be nice, but one of
the two (calling members of outer, or calling members of inner), is going to
require some sort of somewhat annoying hoop to jump through. It should be
calls to inner self that require this awkardness and not calls to outer,
because calls to outer will be far more common (again, gut instinct, but
probably not that hard to verify with a few large codebases and the right
analyser).

From peter.levart at marand.si  Wed Oct 20 08:04:24 2010
From: peter.levart at marand.si (Peter Levart)
Date: Wed, 20 Oct 2010 17:04:24 +0200
Subject: Lambdas and serialization
In-Reply-To: <4CBDE118.4030103@univ-mlv.fr>
References: <AANLkTin4ig6HgmoVwSpgRwOcY8ozGdZrz=u8SGBj8-Sj@mail.gmail.com>
	<4CBDBC13.8060601@oracle.com> <4CBDE118.4030103@univ-mlv.fr>
Message-ID: <201010201704.24519.peter.levart@marand.si>

On 10/19/10, R?mi Forax wrote:
> Le 19/10/2010 17:41, Maurizio Cimadamore a ?crit :
> 
> [...]
> 
> >> Lambda are not serializable, like java.lang.reflect.Method
> >> because it will create tons of security holes.
> > You mean method handles are not serializable? What are the security 
> > holes deriving from serializable lambda (assuming latest Brian's 
> > document) ?
> 
> If you can serialize a lambda, you are able to forge a binary blob which 
> once decoded by the serialization
> is a reference any private method.

Hasn't JSR 292 promissed to provide a two way conversion API between java.dyn.MethodHandle <-> (java.lang.reflect.Method,Constructor)? This API could be used by compiler (JVM) generated SAM subclass (a single generic sub-class per SAM type) to enable serialization of MethoHandle in the following way:

Serialization:

java.dyn.MethodHandle --> java.lang.reflect.Method --> bytestream

De-serialization:

bytestream --> java.lang.reflect.Method --(access check)--> java.dyn.MethodHandle


Regards, Peter

> 
> >
> > Maurizio
> 
> R?mi
> 
> 
> 

From mcnepp02 at googlemail.com  Wed Oct 20 08:12:58 2010
From: mcnepp02 at googlemail.com (Gernot Neppert)
Date: Wed, 20 Oct 2010 17:12:58 +0200
Subject: Changing definite assignement rules: How?
Message-ID: <AANLkTi=19xJtrkzcUk5rkNDWqWr0aMpHNz6QQGX8yojH@mail.gmail.com>

The document "State of the lambda" brought up the idea to change the
rules for definite assignment in order to allow self-referential
lambdas.

This would make the following code valid:

final Runnable r = #{ if(arbitraryCondition()) r.run(); };

Well, changing the grammar is one thing. But could somebody please
shed some light on how this could ever be implemented?

How can you copy the value of the reference 'r' into the lambda before
it has been assigned?

A first suggestion would be to let the compiler generate code equivalent to:

final AutoRunnable[] $ref = {null};
final AutoRunnable r  = #{  if(arbitraryCondition()) $ref[0].run(); }
$ref[0] = r;


But that wouldn't work with:

abstract class AutoRunnable implements Runnable
{
   AutoRunnable()
   {
       run();
   }

}

final AutoRunnable r = #{ if(arbitraryCondition()) r.run(); };

Or, even worse:

abstract class AutoRunnable implements Runnable
{
   AutoRunnable()
   {
       new Thread(this).start();
   }

}

final AutoRunnable r = #{ if(arbitraryCondition()) r.run(); };

What am I overlooking here?

From peter.levart at marand.si  Wed Oct 20 08:17:34 2010
From: peter.levart at marand.si (Peter Levart)
Date: Wed, 20 Oct 2010 17:17:34 +0200
Subject: Lambdas and serialization
In-Reply-To: <201010201704.24519.peter.levart@marand.si>
References: <AANLkTin4ig6HgmoVwSpgRwOcY8ozGdZrz=u8SGBj8-Sj@mail.gmail.com>
	<4CBDE118.4030103@univ-mlv.fr>
	<201010201704.24519.peter.levart@marand.si>
Message-ID: <201010201717.34573.peter.levart@marand.si>

On 10/20/10, Peter Levart wrote:
> On 10/19/10, R?mi Forax wrote:
> > Le 19/10/2010 17:41, Maurizio Cimadamore a ?crit :
> > 
> > [...]
> > 
> > >> Lambda are not serializable, like java.lang.reflect.Method
> > >> because it will create tons of security holes.
> > > You mean method handles are not serializable? What are the security 
> > > holes deriving from serializable lambda (assuming latest Brian's 
> > > document) ?
> > 
> > If you can serialize a lambda, you are able to forge a binary blob which 
> > once decoded by the serialization
> > is a reference any private method.
> 
> Hasn't JSR 292 promissed to provide a two way conversion API between java.dyn.MethodHandle <-> (java.lang.reflect.Method,Constructor)? This API could be used by compiler (JVM) generated SAM subclass (a single generic sub-class per SAM type) to enable serialization of MethoHandle in the following way:
> 
> Serialization:
> 
> java.dyn.MethodHandle --> java.lang.reflect.Method --> bytestream
> 
> De-serialization:
> 
> bytestream --> java.lang.reflect.Method --(access check)--> java.dyn.MethodHandle
> 

Oh, I see the catch. The methods that lambda's MethodHandles refer to would probably want to be private and generated in the class that contains the lambda expression...

Tricky.

Peter

> 
> Regards, Peter
> 
> > 
> > >
> > > Maurizio
> > 
> > R?mi
> > 
> > 
> > 
> 
> 

From brian.goetz at oracle.com  Wed Oct 20 08:20:02 2010
From: brian.goetz at oracle.com (Brian Goetz)
Date: Wed, 20 Oct 2010 08:20:02 -0700
Subject: Updated State of the Lambda
In-Reply-To: <AANLkTi=AguNNfeogyMg9fyGwHK5ynmsSBK8skvV6MZdy@mail.gmail.com>
References: <AANLkTikuDdqR5fbQcKejKR_dX=oqYFVJvd__Puvpd7sU@mail.gmail.com>
	<8E00E9C9-8897-4CF2-8ECD-51855C43869F@oracle.com>
	<AANLkTi=AguNNfeogyMg9fyGwHK5ynmsSBK8skvV6MZdy@mail.gmail.com>
Message-ID: <66F61C2D-94F6-4B32-9E3F-C696E33F6A00@oracle.com>

I agree that restricting SAM conversion to interfaces would be simpler and cleaner.  However, it fails the "real world usefulness" test.  So unless there are serious show-stopping problems (other than just "something could go wrong"), I am taking this as a requirement.  

Your point (1) amounts to "there are risks!"  Yes, there are risks.  Life is risky.  There are also techniques to mitigate the risks.  This comes down to a risk/benefit call, and I don't see any reason why the risks win here.  

Your point (2) is focusing on a corner case of a corner case; self-referential lambdas occur infrequently.  Let's not let that tail wag the dog.  

Your point (3) is simply mistaken.  In 

>  Runnable r = #{ ... };

the variable r *is* a Runnable.  It is the lambda expression #{...} that is not.  Once you SAM-convert, the conversion target IS an instance of that SAM type.  

On Oct 20, 2010, at 1:04 AM, Howard Lovatt wrote:

> Hi Brian,
> 
> Taking each of your points in turn:
> 
> 1. Yes an IDE can help with the refactoring of inner classes to
> lambdas and the changing of this, however not everyone uses an IDE (I
> personally do but know many people who use a text editor or if they do
> use an IDE they use it like a text editor).
> 
> 2. I agree that abstract classes as SAM types are desirable, but the construct:
> 
>   AbstractClass ac = #{ ac.sam() };
> 
> will be confusing because people are used to qualifying with a class
> name, not an field/variable name. Also rather defeats the point of an
> inline definition since it must be on a separate line.
> 
> 3. Not defining what instanceof, getClass, etc. do is undesirable, consider:
> 
>  Runnable r = #{ ... };
>  List<Runnable> l = new ArrayList<>();
>  List<Runnable> cl = Collections.checkedList( l, Runnable.class );
>  cl.add( r ); // Oops - fails because r isn't a Runnable (its only
> treated as one by the type system - not by the JVM)
> 
> You get similar issues to the checkedList issue above with
> Serializable/Cloneable; you need, at times, to be able to check if an
> object is Serializable/Cloneable.
> 
> Cheers,
> 
> -- Howard.
> 
> On 20 October 2010 03:38, Brian Goetz <brian.goetz at oracle.com> wrote:
>>> I have some reservations about changing the type of this, particularly
>>> that it will make refactoring from Inner Classes to Lambdas and vice
>>> versa error prone.
>> 
>> That's a risk, but (a) most of the time the compiler will catch simply cut and paste bugs and (b) we expect IDEs to provide "refactor lambda to named inner class" refactorings, which can adapt / warn on code that uses 'this'.
>> 
>>> May I suggest a further couple of changes that
>>> might make refactoring more reliable:
>>> 
>>> 1. SAM types can only be interfaces (you must use an inner class if
>>> you want to inherit from and abstract class or class).
>> 
>> We explored this early on and concluded this was unsatisfactory.  It is quite common in the evolution of a project that interface-based SAM types evolve to be abstract classes when the need for "optional", rarely-used methods is encountered.  This conclusion was made on the basis of looking at specific code bases.  However, moving the cutoff just past "abstract classes with no-arg constructors" captures many more of the desirable cases and excludes relatively few.
>> 
>>> 2. The specification defines what all Object's methods do for a
>>> Lambda, in particular getClass, toString, equals, and hashCode, and
>>> how instanceof behaves, is a Lambda an instance of MethodHandle is it
>>> an instance of its SAM type?
>> 
>> Neither.  Lambdas expressions can be *converted to* references to SAM types.  It is not specified what they are; they cannot exist in any context other than one in which they will be converted.  So you cannot assume they are objects, or SAM types, or anything.
>> 
>> This turns out to be far less of a restriction than you might think.  (Think: what is the type of a method body?  Does it bother you that in all your years of Java coding, you've never had the need to ask this question?)
>> 
>> 
> 
> 
> 
> -- 
>   -- Howard.


From crazybob at crazybob.org  Wed Oct 20 08:32:53 2010
From: crazybob at crazybob.org (Bob Lee)
Date: Wed, 20 Oct 2010 08:32:53 -0700
Subject: Lambdas and serialization
In-Reply-To: <4CBDE118.4030103@univ-mlv.fr>
References: <AANLkTin4ig6HgmoVwSpgRwOcY8ozGdZrz=u8SGBj8-Sj@mail.gmail.com>
	<AANLkTinKKTZWF0oH7LKDBXj8vrsd2_tWk7=1ZC1jk7P+@mail.gmail.com>
	<AANLkTi=r1C4yg+xgedauvDPGgf5AMGWsmcmDPZa-Hh_7@mail.gmail.com>
	<4CBDA6E7.1050501@oracle.com> <4CBDBCC1.9020706@univ-mlv.fr>
	<4CBDBC13.8060601@oracle.com> <4CBDE118.4030103@univ-mlv.fr>
Message-ID: <AANLkTi=yPLOP=PtoeWMeZ7N1BqKeEehdB6wNCcPndf+P@mail.gmail.com>

On Tue, Oct 19, 2010 at 11:19 AM, R?mi Forax <forax at univ-mlv.fr> wrote:

> If you can serialize a lambda, you are able to forge a binary blob which
> once decoded by the serialization
> is a reference any private method.
>

FWIW, normal Java Method instances aren't serializable simply because they
may not exist from VM to VM. You're typically able to look up private
methods, even if you can't invoke them. The security checks happen when you
try to invoke them.

That's not to say lambdas will work this way.

Bob

From joe.darcy at oracle.com  Wed Oct 20 08:37:09 2010
From: joe.darcy at oracle.com (Joe Darcy)
Date: Wed, 20 Oct 2010 08:37:09 -0700
Subject: Lambdas and serialization
In-Reply-To: <1287561305.2686.31.camel@springer.wildebeest.org>
References: <AANLkTin4ig6HgmoVwSpgRwOcY8ozGdZrz=u8SGBj8-Sj@mail.gmail.com>	<A8B58C3B-3A99-4285-92D3-4E68F2036004@oracle.com>	<AANLkTim_Q_9X6+OWM+vSrej5oGjOSbm5+ZDWJOHLe9iW@mail.gmail.com>	<AANLkTi=1fqMP1ASeYkDG_2bHOeoBdoVyPLgte-j_7sC=@mail.gmail.com>	<AANLkTin-FkLWyvd=sPDJ8kTH_ZOP-pFbbvzubz_4BMZG@mail.gmail.com>
	<1287561305.2686.31.camel@springer.wildebeest.org>
Message-ID: <4CBF0CA5.2000108@oracle.com>

Mark Wielaard wrote:
> On Tue, 2010-10-19 at 15:40 -0700, Bob Lee wrote:
>   
>> On Tue, Oct 19, 2010 at 3:33 PM, Alessio Stalla <alessiostalla at gmail.com>wrote:
>>
>>     
>>> Well, but then the serializable form of any java.* class is not
>>> necessarily compatible between different JVMs, again because the
>>> internal details might be different. Default serialization is not
>>> meant as a standard storage format, rather as a means to store a graph
>>> of objects into a sequence of bytes and restore it later *using the
>>> same JVM*.
>>>       
>
>   
>> That's actually not true. If a class is serializable, its serialized form is
>> part of the published API, and you are guaranteed compatibility across VMs
>> and VM versions.
>>     
>
> But not all serialized forms are published. For example it is not
> specified how precisely an inner class is transformed to byte code
> (compiler generated methods/fields can have different names) so using
> different java source to byte code compilers might result in different
> serialized forms. 

Or even different versions of the same compiler or the same compiler 
with seemingly independent modifications to the source file (anonymous 
classes are numbered).  How an anonymous class is compiled is a 
compiler-internal contract.

> And sometimes constructs use (undocumented) internal
> implementation classes for serialization like Annotations (which uses
> sun.reflect.annotation which isn't guaranteed to be compatible across
> independent implementations).
>   

It was a bug that annotations used a sun.* class in their serialized form.

-Joe

From forax at univ-mlv.fr  Wed Oct 20 09:15:54 2010
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Wed, 20 Oct 2010 18:15:54 +0200
Subject: Lambdas and serialization
In-Reply-To: <AANLkTi=yPLOP=PtoeWMeZ7N1BqKeEehdB6wNCcPndf+P@mail.gmail.com>
References: <AANLkTin4ig6HgmoVwSpgRwOcY8ozGdZrz=u8SGBj8-Sj@mail.gmail.com>	<AANLkTinKKTZWF0oH7LKDBXj8vrsd2_tWk7=1ZC1jk7P+@mail.gmail.com>	<AANLkTi=r1C4yg+xgedauvDPGgf5AMGWsmcmDPZa-Hh_7@mail.gmail.com>	<4CBDA6E7.1050501@oracle.com>	<4CBDBCC1.9020706@univ-mlv.fr>	<4CBDBC13.8060601@oracle.com>	<4CBDE118.4030103@univ-mlv.fr>
	<AANLkTi=yPLOP=PtoeWMeZ7N1BqKeEehdB6wNCcPndf+P@mail.gmail.com>
Message-ID: <4CBF15BA.4020703@univ-mlv.fr>

Le 20/10/2010 17:32, Bob Lee a ?crit :
> On Tue, Oct 19, 2010 at 11:19 AM, R?mi Forax <forax at univ-mlv.fr 
> <mailto:forax at univ-mlv.fr>> wrote:
>
>     If you can serialize a lambda, you are able to forge a binary blob
>     which
>     once decoded by the serialization
>     is a reference any private method.
>
>
> FWIW, normal Java Method instances aren't serializable simply because 
> they may not exist from VM to VM. You're typically able to look up 
> private methods, even if you can't invoke them. The security checks 
> happen when you try to invoke them.

I don't follow you, some objects are serializable even if their classes 
may not exist in another VM.

>
> That's not to say lambdas will work this way.

To complete the picture, method handles are slightly different.
The security check is done once when you create it.

You first create a Lookup object (MethodHandles.Lookup) that holds the 
information of the class
that has created the Lookup object (the caller class). Then you create a 
method handle by using a method find*
of the lookup object. Here a check is done between the method that you 
want to handle
and the class that has created the lookup class.

Method handle can not be easily serializable because they don't hold 
information like the declaring class,
the method name. They are typically represented by a pointer or a base 
pointer and a vtable slot.
They are more close to the VM and less close to the language.

>
> Bob

R?mi

From forax at univ-mlv.fr  Wed Oct 20 09:19:50 2010
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Wed, 20 Oct 2010 18:19:50 +0200
Subject: Changing definite assignement rules: How?
In-Reply-To: <AANLkTi=19xJtrkzcUk5rkNDWqWr0aMpHNz6QQGX8yojH@mail.gmail.com>
References: <AANLkTi=19xJtrkzcUk5rkNDWqWr0aMpHNz6QQGX8yojH@mail.gmail.com>
Message-ID: <4CBF16A6.50100@univ-mlv.fr>

Le 20/10/2010 17:12, Gernot Neppert a ?crit :
> The document "State of the lambda" brought up the idea to change the
> rules for definite assignment in order to allow self-referential
> lambdas.
>
> This would make the following code valid:
>
> final Runnable r = #{ if(arbitraryCondition()) r.run(); };
>
> Well, changing the grammar is one thing. But could somebody please
> shed some light on how this could ever be implemented?
>
> How can you copy the value of the reference 'r' into the lambda before
> it has been assigned?
>
> A first suggestion would be to let the compiler generate code equivalent to:
>
> final AutoRunnable[] $ref = {null};
> final AutoRunnable r  = #{  if(arbitraryCondition()) $ref[0].run(); }
> $ref[0] = r;
>
>
> But that wouldn't work with:
>
> abstract class AutoRunnable implements Runnable
> {
>     AutoRunnable()
>     {
>         run();
>     }
>
> }
>
> final AutoRunnable r = #{ if(arbitraryCondition()) r.run(); };
>
> Or, even worse:
>
> abstract class AutoRunnable implements Runnable
> {
>     AutoRunnable()
>     {
>         new Thread(this).start();
>     }
>
> }
>
> final AutoRunnable r = #{ if(arbitraryCondition()) r.run(); };
>
> What am I overlooking here?
>    

The lambda is generated as an inner class and
the reference 'r' is simply replaced by 'this'.

R?mi



From brian.goetz at oracle.com  Wed Oct 20 09:12:48 2010
From: brian.goetz at oracle.com (Brian Goetz)
Date: Wed, 20 Oct 2010 09:12:48 -0700
Subject: Lambdas and serialization
In-Reply-To: <AANLkTin-FkLWyvd=sPDJ8kTH_ZOP-pFbbvzubz_4BMZG@mail.gmail.com>
References: <AANLkTin4ig6HgmoVwSpgRwOcY8ozGdZrz=u8SGBj8-Sj@mail.gmail.com>
	<A8B58C3B-3A99-4285-92D3-4E68F2036004@oracle.com>
	<AANLkTim_Q_9X6+OWM+vSrej5oGjOSbm5+ZDWJOHLe9iW@mail.gmail.com>
	<AANLkTi=1fqMP1ASeYkDG_2bHOeoBdoVyPLgte-j_7sC=@mail.gmail.com>
	<AANLkTin-FkLWyvd=sPDJ8kTH_ZOP-pFbbvzubz_4BMZG@mail.gmail.com>
Message-ID: <E9C12CC7-257F-444F-A567-24505D12CFA8@oracle.com>

All this is true, but I don't think this slams the door on lambdas being serializable.  Inner classes are serializable now, and while their serialized form is compiler-specific, people do get useful work done with them (such as, by ensuring you have the same version of all classes on both sides of an RMI connection.)  As far as I can see, the proposed serializability requirement of lambdas would put them in the same boat as inner classes, which, while not perfect, is not any worse than things are right now.  

On Oct 19, 2010, at 3:40 PM, Bob Lee wrote:

> On Tue, Oct 19, 2010 at 3:33 PM, Alessio Stalla <alessiostalla at gmail.com> wrote:
> Well, but then the serializable form of any java.* class is not
> necessarily compatible between different JVMs, again because the
> internal details might be different. Default serialization is not
> meant as a standard storage format, rather as a means to store a graph
> of objects into a sequence of bytes and restore it later *using the
> same JVM*.
> 
> That's actually not true. If a class is serializable, its serialized form is part of the published API, and you are guaranteed compatibility across VMs and VM versions.
> 
> Bob


From oehrstroem at gmail.com  Wed Oct 20 10:21:00 2010
From: oehrstroem at gmail.com (=?ISO-8859-1?Q?Fredrik_=D6hrstr=F6m?=)
Date: Wed, 20 Oct 2010 19:21:00 +0200
Subject: Lambdas and serialization
In-Reply-To: <4CBF15BA.4020703@univ-mlv.fr>
References: <AANLkTin4ig6HgmoVwSpgRwOcY8ozGdZrz=u8SGBj8-Sj@mail.gmail.com>
	<AANLkTinKKTZWF0oH7LKDBXj8vrsd2_tWk7=1ZC1jk7P+@mail.gmail.com>
	<AANLkTi=r1C4yg+xgedauvDPGgf5AMGWsmcmDPZa-Hh_7@mail.gmail.com>
	<4CBDA6E7.1050501@oracle.com> <4CBDBCC1.9020706@univ-mlv.fr>
	<4CBDBC13.8060601@oracle.com> <4CBDE118.4030103@univ-mlv.fr>
	<AANLkTi=yPLOP=PtoeWMeZ7N1BqKeEehdB6wNCcPndf+P@mail.gmail.com>
	<4CBF15BA.4020703@univ-mlv.fr>
Message-ID: <AANLkTik-DRttFCVEizUKKVnYCn4EvO7v-G=bTheRwpQF@mail.gmail.com>

2010/10/20w R?mi Forax <forax at univ-mlv.fr>

> Method handle can not be easily serializable because they don't hold
> information like the declaring class,
> the method name. They are typically represented by a pointer or a base
> pointer and a vtable slot.
> They are more close to the VM and less close to the language.
>

Hmm, it must be possible to deduce that a certain methodhandle keeps
a certain target class alive. If not, bad things can happen after GC.

For example, the target class that owns an immediate target address
can be found using the meta data; a virtual method handle has the
target class as the first argument in the MethodType; a bound method
handle  has a pointer to an instance of the target class.

//Fredrik

From forax at univ-mlv.fr  Wed Oct 20 11:36:35 2010
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Wed, 20 Oct 2010 20:36:35 +0200
Subject: Lambdas and serialization
In-Reply-To: <AANLkTik-DRttFCVEizUKKVnYCn4EvO7v-G=bTheRwpQF@mail.gmail.com>
References: <AANLkTin4ig6HgmoVwSpgRwOcY8ozGdZrz=u8SGBj8-Sj@mail.gmail.com>	<AANLkTinKKTZWF0oH7LKDBXj8vrsd2_tWk7=1ZC1jk7P+@mail.gmail.com>	<AANLkTi=r1C4yg+xgedauvDPGgf5AMGWsmcmDPZa-Hh_7@mail.gmail.com>	<4CBDA6E7.1050501@oracle.com>	<4CBDBCC1.9020706@univ-mlv.fr>	<4CBDBC13.8060601@oracle.com>	<4CBDE118.4030103@univ-mlv.fr>	<AANLkTi=yPLOP=PtoeWMeZ7N1BqKeEehdB6wNCcPndf+P@mail.gmail.com>	<4CBF15BA.4020703@univ-mlv.fr>
	<AANLkTik-DRttFCVEizUKKVnYCn4EvO7v-G=bTheRwpQF@mail.gmail.com>
Message-ID: <4CBF36B3.8020203@univ-mlv.fr>

Le 20/10/2010 19:21, Fredrik ?hrstr?m a ?crit :
> 2010/10/20w R?mi Forax <forax at univ-mlv.fr <mailto:forax at univ-mlv.fr>>
>
>     Method handle can not be easily serializable because they don't hold
>     information like the declaring class,
>     the method name. They are typically represented by a pointer or a base
>     pointer and a vtable slot.
>     They are more close to the VM and less close to the language.
>
>
> Hmm, it must be possible to deduce that a certain methodhandle keeps
> a certain target class alive. If not, bad things can happen after GC.
>
> For example, the target class that owns an immediate target address
> can be found using the meta data; a virtual method handle has the
> target class as the first argument in the MethodType; a bound method
> handle  has a pointer to an instance of the target class.

You're right, getting the declaring class seems possible for 'nice' method
handles (as Brian called them). And you can perform a reverse lookup
using the list of all methods of a class (the VM must have that list if it
implement reflection) to find the method name, but it will be slow.

>
> //Fredrik

R?mi

From maurizio.cimadamore at oracle.com  Wed Oct 20 11:18:30 2010
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Wed, 20 Oct 2010 18:18:30 +0000
Subject: hg: lambda/lambda/langtools: Bug fix:
Message-ID: <20101020181832.34025472D8@hg.openjdk.java.net>

Changeset: f813d93e510c
Author:    mcimadamore
Date:      2010-10-20 18:19 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/f813d93e510c

Bug fix:
*) Small adjustments to DA/DU rules and corresponding translation technique.
*) Better error reporting (hide partially specified lambda types)

! src/share/classes/com/sun/tools/javac/comp/Flow.java
! src/share/classes/com/sun/tools/javac/comp/Unlambda.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


From maurizio.cimadamore at oracle.com  Thu Oct 21 07:06:47 2010
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Thu, 21 Oct 2010 14:06:47 +0000
Subject: hg: lambda/lambda/langtools: Futher improvements to compiler
	diagnostics.
Message-ID: <20101021140652.E3E1947312@hg.openjdk.java.net>

Changeset: e23ed3e167e8
Author:    mcimadamore
Date:      2010-10-21 15:06 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/e23ed3e167e8

Futher improvements to compiler diagnostics.
The compiler now emits detailed information about SAM conversion failures occurring in argument position.

! 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/Infer.java
! src/share/classes/com/sun/tools/javac/comp/Lower.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/resources/compiler.properties
! test/tools/javac/6840059/T6840059.out
! test/tools/javac/Diagnostics/6722234/T6722234a_1.out
! test/tools/javac/Diagnostics/6722234/T6722234a_2.out
! test/tools/javac/Diagnostics/6722234/T6722234b_1.out
! test/tools/javac/Diagnostics/6722234/T6722234b_2.out
! test/tools/javac/Diagnostics/6722234/T6722234c.out
! test/tools/javac/Diagnostics/6799605/T6799605.out
! test/tools/javac/Diagnostics/6862608/T6862608b.out
! test/tools/javac/diags/examples.not-yet.txt
! test/tools/javac/lambda/BadTargetType.out
! test/tools/javac/lambda/LambdaConv02.out


From maurizio.cimadamore at oracle.com  Thu Oct 21 09:28:03 2010
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Thu, 21 Oct 2010 17:28:03 +0100
Subject: new changeset
Message-ID: <4CC06A13.9010300@oracle.com>

Hi,
I noticed that no notification has been generated for the following 
changeset:

changeset:   744:e23ed3e167e8
tag:         tip
user:        mcimadamore
date:        Thu Oct 21 15:06:09 2010 +0100
files:       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/Infer.java 
src/share/classes/com/sun/tools/javac/comp/Lower.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/resources/compiler.properties 
test/tools/javac/6840059/T6840059.out 
test/tools/javac/Diagnostics/6722234/T6722234a_1.out 
test/tools/javac/Diagnostics/6722234/T6722234a_2.out 
test/tools/javac/Diagnostics/6722234/T6722234b_1.out 
test/tools/javac/Diagnostics/6722234/T6722234b_2.out 
test/tools/javac/Diagnostics/6722234/T6722234c.out 
test/tools/javac/Diagnostics/6799605/T6799605.out 
test/tools/javac/Diagnostics/6862608/T6862608b.out 
test/tools/javac/diags/examples.not-yet.txt 
test/tools/javac/lambda/BadTargetType.out 
test/tools/javac/lambda/LambdaConv02.out
description:

Futher improvements to compiler diagnostics.
The compiler now emits detailed information about SAM conversion 
failures occurring in argument position.

Maurizio


From forax at univ-mlv.fr  Thu Oct 21 09:46:51 2010
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Thu, 21 Oct 2010 18:46:51 +0200
Subject: new changeset
In-Reply-To: <4CC06A13.9010300@oracle.com>
References: <4CC06A13.9010300@oracle.com>
Message-ID: <4CC06E7B.1020102@univ-mlv.fr>

We've got it but under another changeset id ?
http://hg.openjdk.java.net/lambda/lambda/langtools/rev/e23ed3e167e8

Changeset: e23ed3e167e8
Author:    mcimadamore
Date:      2010-10-21 15:06 +0100
URL:http://hg.openjdk.java.net/lambda/lambda/langtools/rev/e23ed3e167e8

Futher improvements to compiler diagnostics.
The compiler now emits detailed information about SAM conversion failures occurring in argument position.

! 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/Infer.java
! src/share/classes/com/sun/tools/javac/comp/Lower.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/resources/compiler.properties
! test/tools/javac/6840059/T6840059.out
! test/tools/javac/Diagnostics/6722234/T6722234a_1.out
! test/tools/javac/Diagnostics/6722234/T6722234a_2.out
! test/tools/javac/Diagnostics/6722234/T6722234b_1.out
! test/tools/javac/Diagnostics/6722234/T6722234b_2.out
! test/tools/javac/Diagnostics/6722234/T6722234c.out
! test/tools/javac/Diagnostics/6799605/T6799605.out
! test/tools/javac/Diagnostics/6862608/T6862608b.out
! test/tools/javac/diags/examples.not-yet.txt
! test/tools/javac/lambda/BadTargetType.out
! test/tools/javac/lambda/LambdaConv02.ou


R?mi

Le 21/10/2010 18:28, Maurizio Cimadamore a ?crit :
> Hi,
> I noticed that no notification has been generated for the following
> changeset:
>
> changeset:   744:e23ed3e167e8
> tag:         tip
> user:        mcimadamore
> date:        Thu Oct 21 15:06:09 2010 +0100
> files:       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/Infer.java
> src/share/classes/com/sun/tools/javac/comp/Lower.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/resources/compiler.properties
> test/tools/javac/6840059/T6840059.out
> test/tools/javac/Diagnostics/6722234/T6722234a_1.out
> test/tools/javac/Diagnostics/6722234/T6722234a_2.out
> test/tools/javac/Diagnostics/6722234/T6722234b_1.out
> test/tools/javac/Diagnostics/6722234/T6722234b_2.out
> test/tools/javac/Diagnostics/6722234/T6722234c.out
> test/tools/javac/Diagnostics/6799605/T6799605.out
> test/tools/javac/Diagnostics/6862608/T6862608b.out
> test/tools/javac/diags/examples.not-yet.txt
> test/tools/javac/lambda/BadTargetType.out
> test/tools/javac/lambda/LambdaConv02.out
> description:
>
> Futher improvements to compiler diagnostics.
> The compiler now emits detailed information about SAM conversion
> failures occurring in argument position.
>
> Maurizio
>
>    




From maurizio.cimadamore at oracle.com  Thu Oct 21 09:39:16 2010
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Thu, 21 Oct 2010 17:39:16 +0100
Subject: new changeset
In-Reply-To: <4CC06E7B.1020102@univ-mlv.fr>
References: <4CC06A13.9010300@oracle.com> <4CC06E7B.1020102@univ-mlv.fr>
Message-ID: <4CC06CB4.4060905@oracle.com>

Sorry about the duplication - my email client get stuck  ;-)
The ids look the same to me...

Maurizio

On 21/10/10 17:46, R?mi Forax wrote:
> We've got it but under another changeset id ?
> http://hg.openjdk.java.net/lambda/lambda/langtools/rev/e23ed3e167e8
>
> Changeset: e23ed3e167e8
> Author:    mcimadamore
> Date:      2010-10-21 15:06 +0100
> URL:http://hg.openjdk.java.net/lambda/lambda/langtools/rev/e23ed3e167e8
>
> Futher improvements to compiler diagnostics.
> The compiler now emits detailed information about SAM conversion failures occurring in argument position.
>
> ! 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/Infer.java
> ! src/share/classes/com/sun/tools/javac/comp/Lower.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/resources/compiler.properties
> ! test/tools/javac/6840059/T6840059.out
> ! test/tools/javac/Diagnostics/6722234/T6722234a_1.out
> ! test/tools/javac/Diagnostics/6722234/T6722234a_2.out
> ! test/tools/javac/Diagnostics/6722234/T6722234b_1.out
> ! test/tools/javac/Diagnostics/6722234/T6722234b_2.out
> ! test/tools/javac/Diagnostics/6722234/T6722234c.out
> ! test/tools/javac/Diagnostics/6799605/T6799605.out
> ! test/tools/javac/Diagnostics/6862608/T6862608b.out
> ! test/tools/javac/diags/examples.not-yet.txt
> ! test/tools/javac/lambda/BadTargetType.out
> ! test/tools/javac/lambda/LambdaConv02.ou
>
>
> R?mi
>
> Le 21/10/2010 18:28, Maurizio Cimadamore a ?crit :
>    
>> Hi,
>> I noticed that no notification has been generated for the following
>> changeset:
>>
>> changeset:   744:e23ed3e167e8
>> tag:         tip
>> user:        mcimadamore
>> date:        Thu Oct 21 15:06:09 2010 +0100
>> files:       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/Infer.java
>> src/share/classes/com/sun/tools/javac/comp/Lower.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/resources/compiler.properties
>> test/tools/javac/6840059/T6840059.out
>> test/tools/javac/Diagnostics/6722234/T6722234a_1.out
>> test/tools/javac/Diagnostics/6722234/T6722234a_2.out
>> test/tools/javac/Diagnostics/6722234/T6722234b_1.out
>> test/tools/javac/Diagnostics/6722234/T6722234b_2.out
>> test/tools/javac/Diagnostics/6722234/T6722234c.out
>> test/tools/javac/Diagnostics/6799605/T6799605.out
>> test/tools/javac/Diagnostics/6862608/T6862608b.out
>> test/tools/javac/diags/examples.not-yet.txt
>> test/tools/javac/lambda/BadTargetType.out
>> test/tools/javac/lambda/LambdaConv02.out
>> description:
>>
>> Futher improvements to compiler diagnostics.
>> The compiler now emits detailed information about SAM conversion
>> failures occurring in argument position.
>>
>> Maurizio
>>
>>
>>      
>
>
>
>    


From john.r.rose at oracle.com  Sat Oct 23 01:14:42 2010
From: john.r.rose at oracle.com (John Rose)
Date: Sat, 23 Oct 2010 01:14:42 -0700
Subject: Updated State of the Lambda
In-Reply-To: <4CB8B1AF.1090605@oracle.com>
References: <4CB8B1AF.1090605@oracle.com>
Message-ID: <217F036E-29B2-4889-A233-662C7D6777E2@oracle.com>

I just read http://cr.openjdk.java.net/~briangoetz/lambda/lambda-state-3.html .

Congratulations.  It's looking good.  The half-dozen little abbreviation rules feel comfy.

Thanks for keeping 'this' at arm's length.  (I'll learn to live with 'return' co-opted, though I admire how beautifully Python dodged that bullet.)

-- John

P.S.  Regarding DA rules, I wonder if this:

  final SAM1 x = #{ ...x... };

could generalize without much straining to this:

  final SAM1 x;
  x = #{ ...x... };

and then, most usefully, to this:

  final SAM1 x;
  final SAM2 y;
  x = #{ ...x...y... };
  y = #{ ...y...x...y... };

If so, there is a simple notation for local multi-variable recursion.  (And with an invisible 'letrec' keyword.)


From mingyeeiu+lambda at gmail.com  Sat Oct 23 08:08:49 2010
From: mingyeeiu+lambda at gmail.com (Ming-Yee Iu)
Date: Sat, 23 Oct 2010 17:08:49 +0200
Subject: Lambdas and Annotations
Message-ID: <AANLkTi=uS2d4v6681rQkZrhFXDVyObJjkh7D-bQjvD8g@mail.gmail.com>

If there are no guarantees that lambdas will be translated into
classes, then it might be useful to have proper annotation support
instead.

Can you cram them in after the #?

   # @annotation {x -> x + 1}

-Ming

From ali.ebrahimi1781 at gmail.com  Sat Oct 23 21:55:11 2010
From: ali.ebrahimi1781 at gmail.com (Ali Ebrahimi)
Date: Sun, 24 Oct 2010 08:25:11 +0330
Subject: Bugs in new push
Message-ID: <AANLkTikzzuY2mWsLUsZkK4WNxOsjSNMt5kx5EJqQVkpm@mail.gmail.com>

*Hi **Maurizio,*
*
*
*After new push the following test that already passed successfully, now
have a few compile error.*
*1)*
*
        final Runnable r1 =#
        {
            System.out.println("Start")
        };
        r1.run();

    Error:Error:line (67)variable r1 might already have been assigned

2)

        final Runnable r2 =#
        {
            int sum = 0;
            for (int i = 1; i <= 4; i++) {
                sum += i;
            }
            out.println("Sum 4 = " + sum);
        }
        ;
        r2.run();
    Error:Error:line (76)local variable i cannot be referenced
    Error:Error:line (77)local variable sum cannot be referenced

3)

        final IntList11 il = new IntList11();
        out.println(il);


        il.forEach( #
        { i ->   return i+0;
        });
    Error:Error:line (181)unreported exception Exception; must be caught or
declared to be thrown

I compiled the test with my build after getting latest changes.
I attached full test to my mail.


Best Regards
Ali Ebrahimi
*

From maurizio.cimadamore at oracle.com  Sun Oct 24 03:17:48 2010
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Sun, 24 Oct 2010 11:17:48 +0100
Subject: Bugs in new push
In-Reply-To: <AANLkTikzzuY2mWsLUsZkK4WNxOsjSNMt5kx5EJqQVkpm@mail.gmail.com>
References: <AANLkTikzzuY2mWsLUsZkK4WNxOsjSNMt5kx5EJqQVkpm@mail.gmail.com>
Message-ID: <4CC407CC.4090706@oracle.com>

Thanks for the report, I will look into that.

Maurizio

On 24/10/10 05:55, Ali Ebrahimi wrote:
> *Hi **Maurizio,*
> *
> *
> *After new push the following test that already passed successfully, now
> have a few compile error.*
> *1)*
> *
>          final Runnable r1 =#
>          {
>              System.out.println("Start")
>          };
>          r1.run();
>
>      Error:Error:line (67)variable r1 might already have been assigned
>
> 2)
>
>          final Runnable r2 =#
>          {
>              int sum = 0;
>              for (int i = 1; i<= 4; i++) {
>                  sum += i;
>              }
>              out.println("Sum 4 = " + sum);
>          }
>          ;
>          r2.run();
>      Error:Error:line (76)local variable i cannot be referenced
>      Error:Error:line (77)local variable sum cannot be referenced
>
> 3)
>
>          final IntList11 il = new IntList11();
>          out.println(il);
>
>
>          il.forEach( #
>          { i ->    return i+0;
>          });
>      Error:Error:line (181)unreported exception Exception; must be caught or
> declared to be thrown
>
> I compiled the test with my build after getting latest changes.
> I attached full test to my mail.
>
>
> Best Regards
> Ali Ebrahimi
> *
>    
>
>
>
>    


From maurizio.cimadamore at oracle.com  Sun Oct 24 03:39:11 2010
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Sun, 24 Oct 2010 11:39:11 +0100
Subject: Bugs in new push
In-Reply-To: <4CC407CC.4090706@oracle.com>
References: <AANLkTikzzuY2mWsLUsZkK4WNxOsjSNMt5kx5EJqQVkpm@mail.gmail.com>
	<4CC407CC.4090706@oracle.com>
Message-ID: <4CC40CCF.4040001@oracle.com>

See comments below:

On 24/10/10 11:17, Maurizio Cimadamore wrote:
> Thanks for the report, I will look into that.
>
> Maurizio
>
> On 24/10/10 05:55, Ali Ebrahimi wrote:
>    
>> *Hi **Maurizio,*
>> *
>> *
>> *After new push the following test that already passed successfully, now
>> have a few compile error.*
>> *1)*
>> *
>>           final Runnable r1 =#
>>           {
>>               System.out.println("Start")
>>           };
>>           r1.run();
>>
>>       Error:Error:line (67)variable r1 might already have been assigned
>>      

This works now - I fixed this in the latest push
>> 2)
>>
>>           final Runnable r2 =#
>>           {
>>               int sum = 0;
>>               for (int i = 1; i<= 4; i++) {
>>                   sum += i;
>>               }
>>               out.println("Sum 4 = " + sum);
>>           }
>>           ;
>>           r2.run();
>>       Error:Error:line (76)local variable i cannot be referenced
>>       Error:Error:line (77)local variable sum cannot be referenced
>>      
I need to fix this - I cleaned up some code in the effectively final 
analysis, and I probably ended up messing up something, as the compiler 
now complains also for local variables declared *inside* the closure, 
which is obviously not intended.
>> 3)
>>
>>           final IntList11 il = new IntList11();
>>           out.println(il);
>>
>>
>>           il.forEach( #
>>           { i ->     return i+0;
>>           });
>>       Error:Error:line (181)unreported exception Exception; must be caught or
>> declared to be thrown
>>      

This doesn't seem a regression from the latest set of changes - I 
reverted the compiler back and tried to compile this:

interface Function<R,A,throws X> {
R f(A a) throws X;
}

class List<E> {
<throws X> E forEach(Function<E,E,X> a) throws X { return null; }
}

class Test {
{
         final List<Integer> il = new List<>();
         System.out.println(il);

         il.forEach( #(i)
         {   return i+0;
         });
}
}

Which fails in the same way. The current inference scheme goes nuts when 
it sees 'i + 0', causing exception types not to be inferred from the 
lambda body (see related warning).

Maurizio

>> I compiled the test with my build after getting latest changes.
>> I attached full test to my mail.
>>
>>
>> Best Regards
>> Ali Ebrahimi
>> *
>>
>>
>>
>>
>>
>>      
>
>    


From ali.ebrahimi1781 at gmail.com  Sun Oct 24 21:51:15 2010
From: ali.ebrahimi1781 at gmail.com (Ali Ebrahimi)
Date: Mon, 25 Oct 2010 08:21:15 +0330
Subject: Bugs in new push
In-Reply-To: <4CC40CCF.4040001@oracle.com>
References: <AANLkTikzzuY2mWsLUsZkK4WNxOsjSNMt5kx5EJqQVkpm@mail.gmail.com>
	<4CC407CC.4090706@oracle.com> <4CC40CCF.4040001@oracle.com>
Message-ID: <AANLkTinNQsW5co3+w-FphOF-+PzF8f_28m=vYYFoJvoC@mail.gmail.com>

Hi Maurizio,
I got latest bug fixes and merges and now case 1 and 3 works fine.
Comments  inlined.
On Sun, Oct 24, 2010 at 2:09 PM, Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

> See comments below:
>
>
> On 24/10/10 11:17, Maurizio Cimadamore wrote:
>
>> Thanks for the report, I will look into that.
>>
>> Maurizio
>>
>> On 24/10/10 05:55, Ali Ebrahimi wrote:
>>
>>
>>> *Hi **Maurizio,*
>>> *
>>> *
>>> *After new push the following test that already passed successfully, now
>>> have a few compile error.*
>>> *1)*
>>> *
>>>          final Runnable r1 =#
>>>          {
>>>              System.out.println("Start")
>>>          };
>>>          r1.run();
>>>
>>>      Error:Error:line (67)variable r1 might already have been assigned
>>>
>>>
>>
> This works now - I fixed this in the latest push

yes, this works.

>
>  2)
>>>
>>>          final Runnable r2 =#
>>>          {
>>>              int sum = 0;
>>>              for (int i = 1; i<= 4; i++) {
>>>                  sum += i;
>>>              }
>>>              out.println("Sum 4 = " + sum);
>>>          }
>>>          ;
>>>          r2.run();
>>>      Error:Error:line (76)local variable i cannot be referenced
>>>      Error:Error:line (77)local variable sum cannot be referenced
>>>
>>>
>> I need to fix this - I cleaned up some code in the effectively final
> analysis, and I probably ended up messing up something, as the compiler now
> complains also for local variables declared *inside* the closure, which is
> obviously not intended.
>
>  3)
>>>
>>>          final IntList11 il = new IntList11();
>>>          out.println(il);
>>>
>>>
>>>          il.forEach( #
>>>          { i ->     return i+0;
>>>          });
>>>      Error:Error:line (181)unreported exception Exception; must be caught
>>> or
>>> declared to be thrown
>>>
>>>
>>
> This doesn't seem a regression from the latest set of changes - I reverted
> the compiler back and tried to compile this:
>
> interface Function<R,A,throws X> {
> R f(A a) throws X;
> }
>
> class List<E> {
> <throws X> E forEach(Function<E,E,X> a) throws X { return null; }
> }
>
> class Test {
> {
>        final List<Integer> il = new List<>();
>        System.out.println(il);
>
>
>        il.forEach( #(i)
>        {   return i+0;
>        });
> }
> }
>
> Which fails in the same way. The current inference scheme goes nuts when it
> sees 'i + 0', causing exception types not to be inferred from the lambda
> body (see related warning).
>
Oh, My bad. my test case was this:
       il.forEach( #{Integer i ->
         return i+0;
       });
And with latest changes works as expected.

>
> Maurizio
>
>
>  I compiled the test with my build after getting latest changes.
>>> I attached full test to my mail.
>>>
>>>
>>> Best Regards
>>> Ali Ebrahimi
>>> *
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>
>
Best Regards
Ali Ebrahimi

From maurizio.cimadamore at oracle.com  Tue Oct 26 09:51:40 2010
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Tue, 26 Oct 2010 16:51:40 +0000
Subject: hg: lambda/lambda/langtools: Misc bug fixes:
Message-ID: <20101026165143.6F5F547443@hg.openjdk.java.net>

Changeset: 4506d2ab97a0
Author:    mcimadamore
Date:      2010-10-26 17:50 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/4506d2ab97a0

Misc bug fixes:
*) Fixed regression in flow analysis involving effectively-final variables
*) Improved inference of lambda return type in case of cyclic type-inference

! 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/Flow.java
! test/tools/javac/lambda/BadAccess02.java
! test/tools/javac/lambda/BadAccess02.out
+ test/tools/javac/lambda/DefiniteAssignment01.java
! test/tools/javac/lambda/TargetType01.out
+ test/tools/javac/lambda/TargetType14.java
+ test/tools/javac/lambda/TargetType14.out


From isidore at setgame.com  Wed Oct 27 03:48:02 2010
From: isidore at setgame.com (Llewellyn Falco)
Date: Wed, 27 Oct 2010 03:48:02 -0700
Subject: Lambdas and serialization
In-Reply-To: <4CBF36B3.8020203@univ-mlv.fr>
References: <AANLkTin4ig6HgmoVwSpgRwOcY8ozGdZrz=u8SGBj8-Sj@mail.gmail.com>
	<AANLkTinKKTZWF0oH7LKDBXj8vrsd2_tWk7=1ZC1jk7P+@mail.gmail.com>
	<AANLkTi=r1C4yg+xgedauvDPGgf5AMGWsmcmDPZa-Hh_7@mail.gmail.com>
	<4CBDA6E7.1050501@oracle.com> <4CBDBCC1.9020706@univ-mlv.fr>
	<4CBDBC13.8060601@oracle.com> <4CBDE118.4030103@univ-mlv.fr>
	<AANLkTi=yPLOP=PtoeWMeZ7N1BqKeEehdB6wNCcPndf+P@mail.gmail.com>
	<4CBF15BA.4020703@univ-mlv.fr>
	<AANLkTik-DRttFCVEizUKKVnYCn4EvO7v-G=bTheRwpQF@mail.gmail.com>
	<4CBF36B3.8020203@univ-mlv.fr>
Message-ID: <AANLkTik=kH2hLuPR6YUkn6Min0TitEFk2gANxVYZUbq2@mail.gmail.com>

Everybody seems to be thinking of lambdas from the "I want to create a
lambda" side of the fence.
allow me to comment from the "I want to consume a lambda" side of the fence.

As I understand it the method

<T> T max(List<T> from, Comparable<T> c)

should be invokable via a lambda?

if this is correct, then by the time the lambda reaches this consuming
method, the fact it was created by lambda should *no longer be relevant*.

By this logic, if the rules for a consuming method signature would allow for
the parameter to be serialized, then the lambda should conform to those
rules.

Llewellyn

btw: what happens with comparator? it's not a SAM (2 methods - compare,
equals), but seems to be a very wanted case for lambdas?

From maurizio.cimadamore at oracle.com  Wed Oct 27 04:00:04 2010
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Wed, 27 Oct 2010 12:00:04 +0100
Subject: Lambdas and serialization
In-Reply-To: <AANLkTik=kH2hLuPR6YUkn6Min0TitEFk2gANxVYZUbq2@mail.gmail.com>
References: <AANLkTin4ig6HgmoVwSpgRwOcY8ozGdZrz=u8SGBj8-Sj@mail.gmail.com>	<AANLkTinKKTZWF0oH7LKDBXj8vrsd2_tWk7=1ZC1jk7P+@mail.gmail.com>	<AANLkTi=r1C4yg+xgedauvDPGgf5AMGWsmcmDPZa-Hh_7@mail.gmail.com>	<4CBDA6E7.1050501@oracle.com>
	<4CBDBCC1.9020706@univ-mlv.fr>	<4CBDBC13.8060601@oracle.com>
	<4CBDE118.4030103@univ-mlv.fr>	<AANLkTi=yPLOP=PtoeWMeZ7N1BqKeEehdB6wNCcPndf+P@mail.gmail.com>	<4CBF15BA.4020703@univ-mlv.fr>	<AANLkTik-DRttFCVEizUKKVnYCn4EvO7v-G=bTheRwpQF@mail.gmail.com>	<4CBF36B3.8020203@univ-mlv.fr>
	<AANLkTik=kH2hLuPR6YUkn6Min0TitEFk2gANxVYZUbq2@mail.gmail.com>
Message-ID: <4CC80634.5000908@oracle.com>


> btw: what happens with comparator? it's not a SAM (2 methods - compare,
> equals), but seems to be a very wanted case for lambdas?
>
>    
The definition of SAM does not take into account methods inherithed from 
java.lang.Object. Which means that Comparator<T> really has just one 
relevant target method and therefore can be used as the target of a SAM 
conversion.

Maurizio

From alessiostalla at gmail.com  Wed Oct 27 04:57:41 2010
From: alessiostalla at gmail.com (Alessio Stalla)
Date: Wed, 27 Oct 2010 13:57:41 +0200
Subject: Lambdas and serialization
In-Reply-To: <AANLkTik=kH2hLuPR6YUkn6Min0TitEFk2gANxVYZUbq2@mail.gmail.com>
References: <AANLkTin4ig6HgmoVwSpgRwOcY8ozGdZrz=u8SGBj8-Sj@mail.gmail.com>
	<AANLkTinKKTZWF0oH7LKDBXj8vrsd2_tWk7=1ZC1jk7P+@mail.gmail.com>
	<AANLkTi=r1C4yg+xgedauvDPGgf5AMGWsmcmDPZa-Hh_7@mail.gmail.com>
	<4CBDA6E7.1050501@oracle.com> <4CBDBCC1.9020706@univ-mlv.fr>
	<4CBDBC13.8060601@oracle.com> <4CBDE118.4030103@univ-mlv.fr>
	<AANLkTi=yPLOP=PtoeWMeZ7N1BqKeEehdB6wNCcPndf+P@mail.gmail.com>
	<4CBF15BA.4020703@univ-mlv.fr>
	<AANLkTik-DRttFCVEizUKKVnYCn4EvO7v-G=bTheRwpQF@mail.gmail.com>
	<4CBF36B3.8020203@univ-mlv.fr>
	<AANLkTik=kH2hLuPR6YUkn6Min0TitEFk2gANxVYZUbq2@mail.gmail.com>
Message-ID: <AANLkTin41YLpCE-19QwUbKmroTtPsZ5MPMm7ksN0EiTW@mail.gmail.com>

On Wed, Oct 27, 2010 at 12:48 PM, Llewellyn Falco <isidore at setgame.com> wrote:
> Everybody seems to be thinking of lambdas from the "I want to create a
> lambda" side of the fence.
> allow me to comment from the "I want to consume a lambda" side of the fence.
>
> As I understand it the method
>
> <T> T max(List<T> from, Comparable<T> c)
>
> should be invokable via a lambda?
>
> if this is correct, then by the time the lambda reaches this consuming
> method, the fact it was created by lambda should *no longer be relevant*.
>
> By this logic, if the rules for a consuming method signature would allow for
> the parameter to be serialized, then the lambda should conform to those
> rules.

In general I agree, but Serializable is a special case. It is a marker
interface and, strictly speaking, it does not specify an interface
(i.e. an API); the implementing object might be or might be not
serializable. An example: collections generally implement
Serializable, however, if you try to serialize a collection containing
non-serializable items, it'll fail.
SAM-conversion only ensures that lambdas respect the target type's
API; it doesn't limit the runtime behavior in any way, so it's allowed
for a lambda to not be serializable even if the target is. Of course,
it would be better if lambdas were always serializable, but that's a
tradeoff between functionality and implementers' freedom to optimize.

From thomas.andreas.jung at googlemail.com  Wed Oct 27 12:37:21 2010
From: thomas.andreas.jung at googlemail.com (Thomas Jung)
Date: Wed, 27 Oct 2010 21:37:21 +0200
Subject: valid SAM type not accepted
Message-ID: <AANLkTinHRP9GgVN2gNT2uuYYQ62oik-yUXd1jmQaRQ9+@mail.gmail.com>

Hi,

I tried to convert my lambda examples to the new syntax and got the
following error with the latest changes:

class X<T>{
   private Ordering<T> x = new Ordering<T>(){ public int compare(T
left, T right) { return 0; }};  //as documentation
   private Ordering<T> y = #{l, r -> 0 };
}

X.java:8: invalid target type Ordering<T> for lambda conversion
   private Ordering<T> y = #{l, r -> 0 };                            ^
 reason: the target type of a lambda conversion has multiple
non-overriding abstract methods
 where T is a type-variable:
    T extends Object declared in class X

I hope it?s not a dump error.

Thomas

From maurizio.cimadamore at oracle.com  Wed Oct 27 13:01:07 2010
From: maurizio.cimadamore at oracle.com (maurizio cimadamore)
Date: Wed, 27 Oct 2010 21:01:07 +0100
Subject: valid SAM type not accepted
In-Reply-To: <AANLkTinHRP9GgVN2gNT2uuYYQ62oik-yUXd1jmQaRQ9+@mail.gmail.com>
References: <AANLkTinHRP9GgVN2gNT2uuYYQ62oik-yUXd1jmQaRQ9+@mail.gmail.com>
Message-ID: <4CC88503.4060908@oracle.com>

Could you point me to the definition of the Ordering class?

Is it this?

http://guava-libraries.googlecode.com/svn/trunk/javadoc/com/google/common/collect/Ordering.html

Maurizio


On 27/10/2010 20:37, Thomas Jung wrote:
> Hi,
>
> I tried to convert my lambda examples to the new syntax and got the
> following error with the latest changes:
>
> class X<T>{
>     private Ordering<T>  x = new Ordering<T>(){ public int compare(T
> left, T right) { return 0; }};  //as documentation
>     private Ordering<T>  y = #{l, r ->  0 };
> }
>
> X.java:8: invalid target type Ordering<T>  for lambda conversion
>     private Ordering<T>  y = #{l, r ->  0 };                            ^
>   reason: the target type of a lambda conversion has multiple
> non-overriding abstract methods
>   where T is a type-variable:
>      T extends Object declared in class X
>
> I hope it?s not a dump error.
>
> Thomas
>


From thomas.andreas.jung at googlemail.com  Wed Oct 27 13:12:21 2010
From: thomas.andreas.jung at googlemail.com (Thomas Jung)
Date: Wed, 27 Oct 2010 22:12:21 +0200
Subject: valid SAM type not accepted
In-Reply-To: <4CC88503.4060908@oracle.com>
References: <AANLkTinHRP9GgVN2gNT2uuYYQ62oik-yUXd1jmQaRQ9+@mail.gmail.com>
	<4CC88503.4060908@oracle.com>
Message-ID: <AANLkTimL3Azm=ge+trcSK+mJAHk39ySdw4WBi4bshVBo@mail.gmail.com>

Oh sorry Maurizio. I removed this line: import com.google.common.collect.*;

Yes, it is from

<dependency>
  <groupId>com.google.guava</groupId>
  <artifactId>guava</artifactId>
  <version>r06</version>
</dependency>

Thomas


On 27 October 2010 22:01, maurizio cimadamore
<maurizio.cimadamore at oracle.com> wrote:
> Could you point me to the definition of the Ordering class?
>
> Is it this?
>
> http://guava-libraries.googlecode.com/svn/trunk/javadoc/com/google/common/collect/Ordering.html
>
> Maurizio
>
>
> On 27/10/2010 20:37, Thomas Jung wrote:
>>
>> Hi,
>>
>> I tried to convert my lambda examples to the new syntax and got the
>> following error with the latest changes:
>>
>> class X<T>{
>> ? ?private Ordering<T> ?x = new Ordering<T>(){ public int compare(T
>> left, T right) { return 0; }}; ?//as documentation
>> ? ?private Ordering<T> ?y = #{l, r -> ?0 };
>> }
>>
>> X.java:8: invalid target type Ordering<T> ?for lambda conversion
>> ? ?private Ordering<T> ?y = #{l, r -> ?0 }; ? ? ? ? ? ? ? ? ? ? ? ? ? ?^
>> ?reason: the target type of a lambda conversion has multiple
>> non-overriding abstract methods
>> ?where T is a type-variable:
>> ? ? T extends Object declared in class X
>>
>> I hope it?s not a dump error.
>>
>> Thomas
>>
>
>

From brian.goetz at oracle.com  Wed Oct 27 14:43:42 2010
From: brian.goetz at oracle.com (Brian Goetz)
Date: Wed, 27 Oct 2010 17:43:42 -0400
Subject: javac bug: defender method processing
Message-ID: <4CC89D0E.7020303@oracle.com>

I created this file:

src/Impl.java (no package)

class Impl {
     public static int one() { return 1 };
}

and this test file:

src/junit/SimpleDefenderTest.java:

package junit;

import junit.framework.TestCase;

public class SimpleDefenderTest extends TestCase {
     private static interface A {
         public extension int get() default Impl.one;
     }

     private static class C implements A {
     }

     public void testSimpleWeave() {
         C c = new C();
         assertEquals(1, c.get());
     }
}


It failed to compile, with this error:

     [javac] src/junit/SimpleDefenderTest.java:7: cannot find symbol
     [javac]         public extension int get() default Impl.one;
     [javac]                              ^
     [javac]   symbol:   variable Impl
     [javac]   location: interface A
     [javac] 1 error


The problem seems to be either that Impl was in the empty package, or maybe 
that it was just in another package.  I moved it to the same package and it 
worked.




From brian.goetz at oracle.com  Wed Oct 27 15:02:34 2010
From: brian.goetz at oracle.com (Brian Goetz)
Date: Wed, 27 Oct 2010 18:02:34 -0400
Subject: javac bug: inheritance of defenders
Message-ID: <4CC8A17A.9020301@oracle.com>

The following class fails to compile:

public class SimpleDefenderTest extends TestCase {
     private static interface A {
         public extension int get() default Implementations.one;
     }

     private static interface B extends A { }

     private static class C implements A { }

     private static class D extends C { }

     private static class E implements B { }

     public void testSimpleWeave() {
         C c = new C();
         assertEquals(1, c.get());
     }

     public void testExtendWovenClass() {
         D d = new D();
         assertEquals(1, d.get());
     }

     public void testAnonymousWeave() {
         assertEquals(1, new A() { }.get());
     }

     public void testImplementSubclassOfExtended() {
         E e = new E();
         assertEquals(1, e.get());
     }
}


test-compile:
     [javac] Compiling 1 source file to 
/home/brian/work/mangler/trunk/defender/build/test-classes
     [javac] 
/home/brian/work/mangler/trunk/defender/test/src/junit/SimpleDefenderTest.java:34: 
cannot find symbol
     [javac]         assertEquals(1, e.get());
     [javac]                          ^
     [javac]   symbol:   method get()
     [javac]   location: class E
     [javac] 1 error

The implementation of the one() method is straightforward:

public class Implementations {
     public static int one(Object receiver) {
         return 1;
     }

     public static int two(Object receiver) {
         return 2;
     }
}

It would appear that E is not believed to have member get(), which is 
inherited from B, which is inherited from A.


From schlosna at gmail.com  Wed Oct 27 18:45:16 2010
From: schlosna at gmail.com (David Schlosnagle)
Date: Wed, 27 Oct 2010 21:45:16 -0400
Subject: javac bug: defender method processing
In-Reply-To: <4CC89D0E.7020303@oracle.com>
References: <4CC89D0E.7020303@oracle.com>
Message-ID: <AANLkTik6qHGtfNJFNF0pTkF6Akp1i1uFN6_X5SwKFEoi@mail.gmail.com>

Brian,

I don't believe this problem is specific to lambda, it is purely a
combination of the interactions between the default visibility of the
Impl type JLS 6.6.1 [1] and unnamed packages JLS 7.4.2 [2]. If you
were to make the Impl class public, I would think you should be able
to reference it using the fully qualified name 'Impl' per JLS 6.7 [3]:
    The fully qualified name of a top level class or top level
interface that is declared in an unnamed package is the simple name of
the class or interface.

Unfortunately, a quick test shows that javac doesn't seem to fully
implement JLS 6.7 in regards to unnamed packages, all the more reason
to not use unnamed packages!

$ javac -fullversion
javac full version "1.7.0-internal-david_2010_07_23_16_08-b00"

$ cat Impl.java
public class Impl {}

$ cat test/TestUnnamedPackageVisibility.java
package test;
public class TestUnnamedPackageVisibility {
    public static void main(String... args) {
        System.out.println(Impl.class);
    }
}

$ find . -name "*.java"
./Impl.java
./test/TestUnnamedPackageVisibility.java

$ javac -d ../bin/ Impl.java test/TestUnnamedPackageVisibility.java
test/TestUnnamedPackageVisibility.java:4: cannot find symbol
        System.out.println(Impl.class);
                           ^
  symbol:   class Impl
  location: class TestUnnamedPackageVisibility
1 error


Also, Java 1.4 removed the ability to explicitly import a type from an
unnamed package (per section 8 of the Java 1.4 compatibility [4]):
    The compiler now rejects import statements that import a type from the
    unnamed namespace. Previous versions of the compiler would accept such
    import declarations, even though they were arguably not allowed by the
    language (because the type name appearing in the import clause is not in
    scope). The specification is being clarified to state clearly that you
    cannot have a simple name in an import statement, nor can you import from
    the unnamed namespace.


References:
[1]: http://java.sun.com/docs/books/jls/third_edition/html/names.html#6.6.1
[2]:?http://java.sun.com/docs/books/jls/third_edition/html/packages.html#7.4.2
[3]: http://java.sun.com/docs/books/jls/third_edition/html/names.html#6.7
[4]:?http://java.sun.com/javase/compatibility_j2se1.4.html

- Dave


On Wed, Oct 27, 2010 at 5:43 PM, Brian Goetz <brian.goetz at oracle.com> wrote:
>
> I created this file:
>
> src/Impl.java (no package)
>
> class Impl {
> ? ? public static int one() { return 1 };
> }
>
> and this test file:
>
> src/junit/SimpleDefenderTest.java:
>
> package junit;
>
> import junit.framework.TestCase;
>
> public class SimpleDefenderTest extends TestCase {
> ? ? private static interface A {
> ? ? ? ? public extension int get() default Impl.one;
> ? ? }
>
> ? ? private static class C implements A {
> ? ? }
>
> ? ? public void testSimpleWeave() {
> ? ? ? ? C c = new C();
> ? ? ? ? assertEquals(1, c.get());
> ? ? }
> }
>
>
> It failed to compile, with this error:
>
> ? ? [javac] src/junit/SimpleDefenderTest.java:7: cannot find symbol
> ? ? [javac] ? ? ? ? public extension int get() default Impl.one;
> ? ? [javac] ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?^
> ? ? [javac] ? symbol: ? variable Impl
> ? ? [javac] ? location: interface A
> ? ? [javac] 1 error
>
>
> The problem seems to be either that Impl was in the empty package, or maybe
> that it was just in another package. ?I moved it to the same package and it
> worked.
>
>
>
>

From brian.goetz at oracle.com  Wed Oct 27 20:04:11 2010
From: brian.goetz at oracle.com (Brian Goetz)
Date: Wed, 27 Oct 2010 23:04:11 -0400
Subject: javac bug: dispatch to multiply inherited defenders
Message-ID: <4CC8E82B.4050907@oracle.com>

This test case fails to compile:

public class MultipleInheritanceTest extends DefenderTestCase {
     private interface A {
         public extension int get() default Implementations.one;
     }

     private interface B {
         public extension int get() default Implementations.one;
     }

     private static class X implements A, B { }

     public void testValidMI() {
         assertDefender(X.class, "get", new Class[] { }, 
Implementations.class, "one");
         X x = new X();
         assertEquals(1, x.get());        // @@@
         assertEquals(1, ((A) x).get());
         assertEquals(1, ((B) x).get());
     }
}

We get the error at the line marked // @@@

test-compile:
     [javac] Compiling 3 source files to 
/home/brian/work/mangler/trunk/defender/build/test-classes
     [javac] 
/home/brian/work/mangler/trunk/defender/test/src/junit/MultipleInheritanceTest.java:20: 
reference to get is ambiguous, both method get() in B and method get() in A match
     [javac]         assertEquals(1, x.get());
     [javac]                          ^


The static type of 'x' is 'X', which is a class that has a get() method.  That 
method happens to be inherited from both A and B, but their signatures and 
defaults are the same so they should be compatible methods.

The testValidMI() method should generate an invokevirtual and two 
invokeinterface invocations.


From jonathan.gibbons at oracle.com  Wed Oct 27 21:53:27 2010
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Wed, 27 Oct 2010 21:53:27 -0700
Subject: javac bug: defender method processing
In-Reply-To: <AANLkTik6qHGtfNJFNF0pTkF6Akp1i1uFN6_X5SwKFEoi@mail.gmail.com>
References: <4CC89D0E.7020303@oracle.com>
	<AANLkTik6qHGtfNJFNF0pTkF6Akp1i1uFN6_X5SwKFEoi@mail.gmail.com>
Message-ID: <4CC901C7.2020801@oracle.com>

David,
> Unfortunately, a quick test shows that javac doesn't seem to fully
> implement JLS 6.7 in regards to unnamed packages
6.7 simply defines Fully Qualified Names and Canonical Names. It says 
nothing about the meaning of names. For that you need to read 6.5, and 
6.5.5.1 in particular:

http://java.sun.com/docs/books/jls/third_edition/html/names.html#6.5.5.1

If a type name consists of a single /Identifier/, then the identifier 
must occur in the scope of exactly one visible declaration of a type 
with this name, or a compile-time error occurs. The meaning of the type 
name is that type.

-- Jon




On 10/27/2010 06:45 PM, David Schlosnagle wrote:
> Brian,
>
> I don't believe this problem is specific to lambda, it is purely a
> combination of the interactions between the default visibility of the
> Impl type JLS 6.6.1 [1] and unnamed packages JLS 7.4.2 [2]. If you
> were to make the Impl class public, I would think you should be able
> to reference it using the fully qualified name 'Impl' per JLS 6.7 [3]:
>      The fully qualified name of a top level class or top level
> interface that is declared in an unnamed package is the simple name of
> the class or interface.
>
> Unfortunately, a quick test shows that javac doesn't seem to fully
> implement JLS 6.7 in regards to unnamed packages, all the more reason
> to not use unnamed packages!
>
> $ javac -fullversion
> javac full version "1.7.0-internal-david_2010_07_23_16_08-b00"
>
> $ cat Impl.java
> public class Impl {}
>
> $ cat test/TestUnnamedPackageVisibility.java
> package test;
> public class TestUnnamedPackageVisibility {
>      public static void main(String... args) {
>          System.out.println(Impl.class);
>      }
> }
>
> $ find . -name "*.java"
> ./Impl.java
> ./test/TestUnnamedPackageVisibility.java
>
> $ javac -d ../bin/ Impl.java test/TestUnnamedPackageVisibility.java
> test/TestUnnamedPackageVisibility.java:4: cannot find symbol
>          System.out.println(Impl.class);
>                             ^
>    symbol:   class Impl
>    location: class TestUnnamedPackageVisibility
> 1 error
>
>
> Also, Java 1.4 removed the ability to explicitly import a type from an
> unnamed package (per section 8 of the Java 1.4 compatibility [4]):
>      The compiler now rejects import statements that import a type from the
>      unnamed namespace. Previous versions of the compiler would accept such
>      import declarations, even though they were arguably not allowed by the
>      language (because the type name appearing in the import clause is not in
>      scope). The specification is being clarified to state clearly that you
>      cannot have a simple name in an import statement, nor can you import from
>      the unnamed namespace.
>
>
> References:
> [1]: http://java.sun.com/docs/books/jls/third_edition/html/names.html#6.6.1
> [2]: http://java.sun.com/docs/books/jls/third_edition/html/packages.html#7.4.2
> [3]: http://java.sun.com/docs/books/jls/third_edition/html/names.html#6.7
> [4]: http://java.sun.com/javase/compatibility_j2se1.4.html
>
> - Dave
>
>
> On Wed, Oct 27, 2010 at 5:43 PM, Brian Goetz<brian.goetz at oracle.com>  wrote:
>> I created this file:
>>
>> src/Impl.java (no package)
>>
>> class Impl {
>>      public static int one() { return 1 };
>> }
>>
>> and this test file:
>>
>> src/junit/SimpleDefenderTest.java:
>>
>> package junit;
>>
>> import junit.framework.TestCase;
>>
>> public class SimpleDefenderTest extends TestCase {
>>      private static interface A {
>>          public extension int get() default Impl.one;
>>      }
>>
>>      private static class C implements A {
>>      }
>>
>>      public void testSimpleWeave() {
>>          C c = new C();
>>          assertEquals(1, c.get());
>>      }
>> }
>>
>>
>> It failed to compile, with this error:
>>
>>      [javac] src/junit/SimpleDefenderTest.java:7: cannot find symbol
>>      [javac]         public extension int get() default Impl.one;
>>      [javac]                              ^
>>      [javac]   symbol:   variable Impl
>>      [javac]   location: interface A
>>      [javac] 1 error
>>
>>
>> The problem seems to be either that Impl was in the empty package, or maybe
>> that it was just in another package.  I moved it to the same package and it
>> worked.
>>
>>
>>
>>


From David.Holmes at oracle.com  Wed Oct 27 22:38:03 2010
From: David.Holmes at oracle.com (David Holmes)
Date: Thu, 28 Oct 2010 15:38:03 +1000
Subject: javac bug: defender method processing
In-Reply-To: <4CC901C7.2020801@oracle.com>
References: <4CC89D0E.7020303@oracle.com>	<AANLkTik6qHGtfNJFNF0pTkF6Akp1i1uFN6_X5SwKFEoi@mail.gmail.com>
	<4CC901C7.2020801@oracle.com>
Message-ID: <4CC90C3B.8060309@oracle.com>

I would think that JLS 7.4.2 is most relevant here - Unnamed Packages. 
In short in depends on the implementation as to how many unnamed 
packages exist (there must be at least one) and what form they take. 
Using the example in the JLS of an un-named package per directory, 
Brian's example, and David's, need not compile.

David Holmes

Jonathan Gibbons said the following on 10/28/10 14:53:
> David,
>> Unfortunately, a quick test shows that javac doesn't seem to fully
>> implement JLS 6.7 in regards to unnamed packages
> 6.7 simply defines Fully Qualified Names and Canonical Names. It says 
> nothing about the meaning of names. For that you need to read 6.5, and 
> 6.5.5.1 in particular:
> 
> http://java.sun.com/docs/books/jls/third_edition/html/names.html#6.5.5.1
> 
> If a type name consists of a single /Identifier/, then the identifier 
> must occur in the scope of exactly one visible declaration of a type 
> with this name, or a compile-time error occurs. The meaning of the type 
> name is that type.
> 
> -- Jon
> 
> 
> 
> 
> On 10/27/2010 06:45 PM, David Schlosnagle wrote:
>> Brian,
>>
>> I don't believe this problem is specific to lambda, it is purely a
>> combination of the interactions between the default visibility of the
>> Impl type JLS 6.6.1 [1] and unnamed packages JLS 7.4.2 [2]. If you
>> were to make the Impl class public, I would think you should be able
>> to reference it using the fully qualified name 'Impl' per JLS 6.7 [3]:
>>      The fully qualified name of a top level class or top level
>> interface that is declared in an unnamed package is the simple name of
>> the class or interface.
>>
>> Unfortunately, a quick test shows that javac doesn't seem to fully
>> implement JLS 6.7 in regards to unnamed packages, all the more reason
>> to not use unnamed packages!
>>
>> $ javac -fullversion
>> javac full version "1.7.0-internal-david_2010_07_23_16_08-b00"
>>
>> $ cat Impl.java
>> public class Impl {}
>>
>> $ cat test/TestUnnamedPackageVisibility.java
>> package test;
>> public class TestUnnamedPackageVisibility {
>>      public static void main(String... args) {
>>          System.out.println(Impl.class);
>>      }
>> }
>>
>> $ find . -name "*.java"
>> ./Impl.java
>> ./test/TestUnnamedPackageVisibility.java
>>
>> $ javac -d ../bin/ Impl.java test/TestUnnamedPackageVisibility.java
>> test/TestUnnamedPackageVisibility.java:4: cannot find symbol
>>          System.out.println(Impl.class);
>>                             ^
>>    symbol:   class Impl
>>    location: class TestUnnamedPackageVisibility
>> 1 error
>>
>>
>> Also, Java 1.4 removed the ability to explicitly import a type from an
>> unnamed package (per section 8 of the Java 1.4 compatibility [4]):
>>      The compiler now rejects import statements that import a type from the
>>      unnamed namespace. Previous versions of the compiler would accept such
>>      import declarations, even though they were arguably not allowed by the
>>      language (because the type name appearing in the import clause is not in
>>      scope). The specification is being clarified to state clearly that you
>>      cannot have a simple name in an import statement, nor can you import from
>>      the unnamed namespace.
>>
>>
>> References:
>> [1]: http://java.sun.com/docs/books/jls/third_edition/html/names.html#6.6.1
>> [2]: http://java.sun.com/docs/books/jls/third_edition/html/packages.html#7.4.2
>> [3]: http://java.sun.com/docs/books/jls/third_edition/html/names.html#6.7
>> [4]: http://java.sun.com/javase/compatibility_j2se1.4.html
>>
>> - Dave
>>
>>
>> On Wed, Oct 27, 2010 at 5:43 PM, Brian Goetz<brian.goetz at oracle.com>  wrote:
>>> I created this file:
>>>
>>> src/Impl.java (no package)
>>>
>>> class Impl {
>>>      public static int one() { return 1 };
>>> }
>>>
>>> and this test file:
>>>
>>> src/junit/SimpleDefenderTest.java:
>>>
>>> package junit;
>>>
>>> import junit.framework.TestCase;
>>>
>>> public class SimpleDefenderTest extends TestCase {
>>>      private static interface A {
>>>          public extension int get() default Impl.one;
>>>      }
>>>
>>>      private static class C implements A {
>>>      }
>>>
>>>      public void testSimpleWeave() {
>>>          C c = new C();
>>>          assertEquals(1, c.get());
>>>      }
>>> }
>>>
>>>
>>> It failed to compile, with this error:
>>>
>>>      [javac] src/junit/SimpleDefenderTest.java:7: cannot find symbol
>>>      [javac]         public extension int get() default Impl.one;
>>>      [javac]                              ^
>>>      [javac]   symbol:   variable Impl
>>>      [javac]   location: interface A
>>>      [javac] 1 error
>>>
>>>
>>> The problem seems to be either that Impl was in the empty package, or maybe
>>> that it was just in another package.  I moved it to the same package and it
>>> worked.
>>>
>>>
>>>
>>>
> 
> 

From maurizio.cimadamore at oracle.com  Thu Oct 28 01:31:58 2010
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Thu, 28 Oct 2010 09:31:58 +0100
Subject: javac bug: defender method processing
In-Reply-To: <4CC90C3B.8060309@oracle.com>
References: <4CC89D0E.7020303@oracle.com>	<AANLkTik6qHGtfNJFNF0pTkF6Akp1i1uFN6_X5SwKFEoi@mail.gmail.com>	<4CC901C7.2020801@oracle.com>
	<4CC90C3B.8060309@oracle.com>
Message-ID: <4CC934FE.4000008@oracle.com>

On 28/10/10 06:38, David Holmes wrote:
> I would think that JLS 7.4.2 is most relevant here - Unnamed Packages.
> In short in depends on the implementation as to how many unnamed
> packages exist (there must be at least one) and what form they take.
> Using the example in the JLS of an un-named package per directory,
> Brian's example, and David's, need not compile.
>    
I agree that this has nothing to do with lambda. A simpler test case 
also fails with both jdk 6/7:

src/A.java

public class A {}

src/pkg/B.java

package pkg;

public class B extends A {}


You need A to be in a named package here.

Maurizio

> David Holmes
>
> Jonathan Gibbons said the following on 10/28/10 14:53:
>    
>> David,
>>      
>>> Unfortunately, a quick test shows that javac doesn't seem to fully
>>> implement JLS 6.7 in regards to unnamed packages
>>>        
>> 6.7 simply defines Fully Qualified Names and Canonical Names. It says
>> nothing about the meaning of names. For that you need to read 6.5, and
>> 6.5.5.1 in particular:
>>
>> http://java.sun.com/docs/books/jls/third_edition/html/names.html#6.5.5.1
>>
>> If a type name consists of a single /Identifier/, then the identifier
>> must occur in the scope of exactly one visible declaration of a type
>> with this name, or a compile-time error occurs. The meaning of the type
>> name is that type.
>>
>> -- Jon
>>
>>
>>
>>
>> On 10/27/2010 06:45 PM, David Schlosnagle wrote:
>>      
>>> Brian,
>>>
>>> I don't believe this problem is specific to lambda, it is purely a
>>> combination of the interactions between the default visibility of the
>>> Impl type JLS 6.6.1 [1] and unnamed packages JLS 7.4.2 [2]. If you
>>> were to make the Impl class public, I would think you should be able
>>> to reference it using the fully qualified name 'Impl' per JLS 6.7 [3]:
>>>       The fully qualified name of a top level class or top level
>>> interface that is declared in an unnamed package is the simple name of
>>> the class or interface.
>>>
>>> Unfortunately, a quick test shows that javac doesn't seem to fully
>>> implement JLS 6.7 in regards to unnamed packages, all the more reason
>>> to not use unnamed packages!
>>>
>>> $ javac -fullversion
>>> javac full version "1.7.0-internal-david_2010_07_23_16_08-b00"
>>>
>>> $ cat Impl.java
>>> public class Impl {}
>>>
>>> $ cat test/TestUnnamedPackageVisibility.java
>>> package test;
>>> public class TestUnnamedPackageVisibility {
>>>       public static void main(String... args) {
>>>           System.out.println(Impl.class);
>>>       }
>>> }
>>>
>>> $ find . -name "*.java"
>>> ./Impl.java
>>> ./test/TestUnnamedPackageVisibility.java
>>>
>>> $ javac -d ../bin/ Impl.java test/TestUnnamedPackageVisibility.java
>>> test/TestUnnamedPackageVisibility.java:4: cannot find symbol
>>>           System.out.println(Impl.class);
>>>                              ^
>>>     symbol:   class Impl
>>>     location: class TestUnnamedPackageVisibility
>>> 1 error
>>>
>>>
>>> Also, Java 1.4 removed the ability to explicitly import a type from an
>>> unnamed package (per section 8 of the Java 1.4 compatibility [4]):
>>>       The compiler now rejects import statements that import a type from the
>>>       unnamed namespace. Previous versions of the compiler would accept such
>>>       import declarations, even though they were arguably not allowed by the
>>>       language (because the type name appearing in the import clause is not in
>>>       scope). The specification is being clarified to state clearly that you
>>>       cannot have a simple name in an import statement, nor can you import from
>>>       the unnamed namespace.
>>>
>>>
>>> References:
>>> [1]: http://java.sun.com/docs/books/jls/third_edition/html/names.html#6.6.1
>>> [2]: http://java.sun.com/docs/books/jls/third_edition/html/packages.html#7.4.2
>>> [3]: http://java.sun.com/docs/books/jls/third_edition/html/names.html#6.7
>>> [4]: http://java.sun.com/javase/compatibility_j2se1.4.html
>>>
>>> - Dave
>>>
>>>
>>> On Wed, Oct 27, 2010 at 5:43 PM, Brian Goetz<brian.goetz at oracle.com>   wrote:
>>>        
>>>> I created this file:
>>>>
>>>> src/Impl.java (no package)
>>>>
>>>> class Impl {
>>>>       public static int one() { return 1 };
>>>> }
>>>>
>>>> and this test file:
>>>>
>>>> src/junit/SimpleDefenderTest.java:
>>>>
>>>> package junit;
>>>>
>>>> import junit.framework.TestCase;
>>>>
>>>> public class SimpleDefenderTest extends TestCase {
>>>>       private static interface A {
>>>>           public extension int get() default Impl.one;
>>>>       }
>>>>
>>>>       private static class C implements A {
>>>>       }
>>>>
>>>>       public void testSimpleWeave() {
>>>>           C c = new C();
>>>>           assertEquals(1, c.get());
>>>>       }
>>>> }
>>>>
>>>>
>>>> It failed to compile, with this error:
>>>>
>>>>       [javac] src/junit/SimpleDefenderTest.java:7: cannot find symbol
>>>>       [javac]         public extension int get() default Impl.one;
>>>>       [javac]                              ^
>>>>       [javac]   symbol:   variable Impl
>>>>       [javac]   location: interface A
>>>>       [javac] 1 error
>>>>
>>>>
>>>> The problem seems to be either that Impl was in the empty package, or maybe
>>>> that it was just in another package.  I moved it to the same package and it
>>>> worked.
>>>>
>>>>
>>>>
>>>>
>>>>          
>>
>>      
>    


From maurizio.cimadamore at oracle.com  Thu Oct 28 04:16:52 2010
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Thu, 28 Oct 2010 12:16:52 +0100
Subject: javac bug: dispatch to multiply inherited defenders
In-Reply-To: <4CC8E82B.4050907@oracle.com>
References: <4CC8E82B.4050907@oracle.com>
Message-ID: <4CC95BA4.1040909@oracle.com>

On 28/10/10 04:04, Brian Goetz wrote:
> class MultipleInheritanceTest extends DefenderTestCase {
>       private interface A {
>           public extension int get() default Implementations.one;
>       }
>
>       private interface B {
>           public extension int get() default Implementations.one;
>       }
>
>       private static class X implements A, B { }
>
>       public void testValidMI() {
>           assertDefender(X.class, "get", new Class[] { },
> Implementations.class, "one");
>           X x = new X();
>           assertEquals(1, x.get());        // @@@
>           assertEquals(1, ((A) x).get());
>           assertEquals(1, ((B) x).get());
>       }
> }
>    
Not sure about this one - if Implementations defines two methods like:

class Implementations {
    static int one(MultipleInheritanceTest.A a) { ... }
    static int one(MultipleInheritanceTest.B b) { ... }
}

Then the compiler (correctly) rejects the whole thing with the following 
message:

Test.java:15: types B and A are incompatible; both define get(), but 
with unrelated default implementations
      private static class X implements A, B { }
                     ^
1 error

If Implementations only define a method like:

class Implementations {
    static int one(Object o) { ... }
}

The compiler seems to be able to accept this w/o problems. But this 
could be a consequence of the latest changes I have in my repo - I will 
push changes soon.

Maurizio

From maurizio.cimadamore at oracle.com  Thu Oct 28 05:05:32 2010
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Thu, 28 Oct 2010 12:05:32 +0000
Subject: hg: lambda/lambda/langtools: Misc bug fixes:
Message-ID: <20101028120538.8DF07474B9@hg.openjdk.java.net>

Changeset: 76f6f9e8b0ec
Author:    mcimadamore
Date:      2010-10-28 13:04 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/76f6f9e8b0ec

Misc bug fixes:
*) SAM conversion where target type is erroneous lead to spurious diagnostic
*) Issues with SAM conversion and generic class hierarchies
*) Overhaul of extension method resolution algorithm

! 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/Resolve.java
+ test/tools/javac/defender/Neg02.java
+ test/tools/javac/defender/Neg02.out
+ test/tools/javac/defender/Pos05.java
+ test/tools/javac/defender/Pos06.java
+ test/tools/javac/lambda/LambdaConv11.java


From brian.goetz at oracle.com  Thu Oct 28 07:46:14 2010
From: brian.goetz at oracle.com (Brian Goetz)
Date: Thu, 28 Oct 2010 10:46:14 -0400
Subject: latest push
Message-ID: <4CC98CB6.1080603@oracle.com>

The latest push seems to have resolved the two issues I raised yesterday -- 
thanks!

Unfortunately there's also been a regression since yesterday.  Given

public interface Collection {
     public extension void foo() default Defaults.foo;
     public extension void bar() default Defaults.foo;
}

public interface Set extends Collection {
     public extension void foo() default Defaults.foo;
}

(both have the same method foo() with the same default).

If I have a class

public class SetImpl implements Set {
}

everything is fine.  But if I write it like this:

public class SetImpl implements Set, Collection {
}

I get this error message

test-compile:
     [javac] Compiling 10 source files to 
/home/brian/work/mangler/trunk/defender/build/test-classes
     [javac] 
/home/brian/work/mangler/trunk/defender/test/src/foo/SetImpl.java:6: types 
Collection and Set are incompatible; both define foo(), but with unrelated 
default implementations
     [javac] public class SetImpl implements Set, Collection {
     [javac]        ^
     [javac] Note: 
/home/brian/work/mangler/trunk/defender/test/src/junit/DefenderTestCase.java 
uses unchecked or unsafe operations.

This compiled properly under yesterday's build.


From maurizio.cimadamore at oracle.com  Thu Oct 28 09:18:01 2010
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Thu, 28 Oct 2010 17:18:01 +0100
Subject: latest push
In-Reply-To: <4CC98CB6.1080603@oracle.com>
References: <4CC98CB6.1080603@oracle.com>
Message-ID: <4CC9A239.5080607@oracle.com>

This is not a regression. It seems like the prototype has problems 
associated with compilation order; this doesn't work:

class Defaults {
static void foo(Collection o) {}
}

interface Collection {
      public extension void foo() default Defaults.foo;
      public extension void bar() default Defaults.foo;
}

class SetImpl1 implements Set, Collection {}

interface Set extends Collection {
      public extension void foo() default Defaults.foo;
}

while the following does (swapped SetImpl with Set):

class Defaults {
static void foo(Collection o) {}
}

interface Collection {
      public extension void foo() default Defaults.foo;
      public extension void bar() default Defaults.foo;
}

interface Set extends Collection {
      public extension void foo() default Defaults.foo;
}


class SetImpl1 implements Set, Collection {}


Maurizio

On 28/10/10 15:46, Brian Goetz wrote:
> The latest push seems to have resolved the two issues I raised yesterday --
> thanks!
>
> Unfortunately there's also been a regression since yesterday.  Given
>
> public interface Collection {
>       public extension void foo() default Defaults.foo;
>       public extension void bar() default Defaults.foo;
> }
>
> public interface Set extends Collection {
>       public extension void foo() default Defaults.foo;
> }
>
> (both have the same method foo() with the same default).
>
> If I have a class
>
> public class SetImpl implements Set {
> }
>
> everything is fine.  But if I write it like this:
>
> public class SetImpl implements Set, Collection {
> }
>
> I get this error message
>
> test-compile:
>       [javac] Compiling 10 source files to
> /home/brian/work/mangler/trunk/defender/build/test-classes
>       [javac]
> /home/brian/work/mangler/trunk/defender/test/src/foo/SetImpl.java:6: types
> Collection and Set are incompatible; both define foo(), but with unrelated
> default implementations
>       [javac] public class SetImpl implements Set, Collection {
>       [javac]        ^
>       [javac] Note:
> /home/brian/work/mangler/trunk/defender/test/src/junit/DefenderTestCase.java
> uses unchecked or unsafe operations.
>
> This compiled properly under yesterday's build.
>
>
>    


From brian.goetz at oracle.com  Thu Oct 28 10:51:59 2010
From: brian.goetz at oracle.com (Brian Goetz)
Date: Thu, 28 Oct 2010 13:51:59 -0400
Subject: javac bug: Resolving conflicting defenders in interfaces
Message-ID: <4CC9B83F.5090901@oracle.com>

Here, we have interfaces with conflicting defenders, and we try and resolve 
the conflict in a subinterface:

     private interface A {
         public extension int get() default Implementations.one;
     }

     private interface E {
         public extension int get() default Implementations.two;
     }

     private interface F extends A, E {
         public extension int get() default Implementations.two;
     }

test-compile:
     [javac] Compiling 1 source file to 
/home/brian/work/mangler/trunk/defender/build/test-classes
     [javac] 
/home/brian/work/mangler/trunk/defender/test/src/junit/MultipleInheritanceTest.java:25: 
types E and A are incompatible; both define get(), but with unrelated default 
implementations
     [javac]     private interface F extends A, E {
     [javac]             ^
     [javac] 1 error


I would argue this case should be allowed because F provides an unambiguous 
default for get().  (The resolution rules say that any defender provided by F 
"shadows" the defender provided by F's superinterfaces.)

The compiler does get this right when F is a real class and F provides an 
implementation of get().


From alex.buckley at oracle.com  Thu Oct 28 11:39:41 2010
From: alex.buckley at oracle.com (Alex Buckley)
Date: Thu, 28 Oct 2010 11:39:41 -0700
Subject: javac bug: Resolving conflicting defenders in interfaces
In-Reply-To: <4CC9B83F.5090901@oracle.com>
References: <4CC9B83F.5090901@oracle.com>
Message-ID: <4CC9C36D.3070606@oracle.com>

Interface F is even free to override get() _without giving a default_. 
As soon as F declares get() that's override-equivalent to A.get() and 
E.get(), the abstract methods A.get() and E.get() become irrelevant, as 
do their defaults.

Alex

On 10/28/2010 10:51 AM, Brian Goetz wrote:
> Here, we have interfaces with conflicting defenders, and we try and resolve 
> the conflict in a subinterface:
> 
>      private interface A {
>          public extension int get() default Implementations.one;
>      }
> 
>      private interface E {
>          public extension int get() default Implementations.two;
>      }
> 
>      private interface F extends A, E {
>          public extension int get() default Implementations.two;
>      }
> 
> test-compile:
>      [javac] Compiling 1 source file to 
> /home/brian/work/mangler/trunk/defender/build/test-classes
>      [javac] 
> /home/brian/work/mangler/trunk/defender/test/src/junit/MultipleInheritanceTest.java:25: 
> types E and A are incompatible; both define get(), but with unrelated default 
> implementations
>      [javac]     private interface F extends A, E {
>      [javac]             ^
>      [javac] 1 error
> 
> 
> I would argue this case should be allowed because F provides an unambiguous 
> default for get().  (The resolution rules say that any defender provided by F 
> "shadows" the defender provided by F's superinterfaces.)
> 
> The compiler does get this right when F is a real class and F provides an 
> implementation of get().
> 
> 

From maurizio.cimadamore at oracle.com  Thu Oct 28 12:09:25 2010
From: maurizio.cimadamore at oracle.com (maurizio cimadamore)
Date: Thu, 28 Oct 2010 20:09:25 +0100
Subject: javac bug: Resolving conflicting defenders in interfaces
In-Reply-To: <4CC9B83F.5090901@oracle.com>
References: <4CC9B83F.5090901@oracle.com>
Message-ID: <4CC9CA65.7080108@oracle.com>

I agree this should compile

Maurizio

On 28/10/2010 18:51, Brian Goetz wrote:
> Here, we have interfaces with conflicting defenders, and we try and resolve
> the conflict in a subinterface:
>
>       private interface A {
>           public extension int get() default Implementations.one;
>       }
>
>       private interface E {
>           public extension int get() default Implementations.two;
>       }
>
>       private interface F extends A, E {
>           public extension int get() default Implementations.two;
>       }
>
> test-compile:
>       [javac] Compiling 1 source file to
> /home/brian/work/mangler/trunk/defender/build/test-classes
>       [javac]
> /home/brian/work/mangler/trunk/defender/test/src/junit/MultipleInheritanceTest.java:25:
> types E and A are incompatible; both define get(), but with unrelated default
> implementations
>       [javac]     private interface F extends A, E {
>       [javac]             ^
>       [javac] 1 error
>
>
> I would argue this case should be allowed because F provides an unambiguous
> default for get().  (The resolution rules say that any defender provided by F
> "shadows" the defender provided by F's superinterfaces.)
>
> The compiler does get this right when F is a real class and F provides an
> implementation of get().
>
>


From maurizio.cimadamore at oracle.com  Fri Oct 29 05:39:18 2010
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Fri, 29 Oct 2010 12:39:18 +0000
Subject: hg: lambda/lambda/langtools: More extension method fixes:
Message-ID: <20101029123924.119274750D@hg.openjdk.java.net>

Changeset: fa6868eac2c4
Author:    mcimadamore
Date:      2010-10-29 13:38 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/fa6868eac2c4

More extension method fixes:
*) Interface defining common overrider should resolve extension method conflicts in supertypes
*) Default method should be attributed lazily (possibly during Symbol completion) - this is to avoid spurious failures that depend on the compilation-order

! 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/comp/Lower.java
! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java
! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java
+ test/tools/javac/defender/Pos07.java
+ test/tools/javac/defender/Pos08.java


From maurizio.cimadamore at oracle.com  Fri Oct 29 10:12:57 2010
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Fri, 29 Oct 2010 17:12:57 +0000
Subject: hg: lambda/lambda/langtools: Fixed issue with defender method and
	separate compilation.
Message-ID: <20101029171259.DA58247517@hg.openjdk.java.net>

Changeset: cd26d488d641
Author:    mcimadamore
Date:      2010-10-29 18:11 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/cd26d488d641

Fixed issue with defender method and separate compilation.
Default method symbol was not restored by ClassReader.

! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java
! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java
+ test/tools/javac/defender/Pos09.java
+ test/tools/javac/defender/pkg1/A.java


From thomas.andreas.jung at googlemail.com  Sat Oct 30 09:39:38 2010
From: thomas.andreas.jung at googlemail.com (Thomas Jung)
Date: Sat, 30 Oct 2010 18:39:38 +0200
Subject: thrown types cannot be inferred from lambda body because of cyclic
	inference
Message-ID: <AANLkTimVib3F0yOATr_naCTp+LDB8qThg+DWp6mBxeq9@mail.gmail.com>

Hi,

the following does not compile:

import com.google.common.base.*;
class X{
	private Predicate<Integer> x = new Predicate<Integer>(){
		public boolean apply(Integer v) { return  v % 3 == 0; }
	};
	Predicate<Integer> y = #{Integer v -> v % 3 == 0 };
	Predicate<Integer> z = #{v -> v % 3 == 0 }; //does not compile
}

X.java:11: warning: thrown types cannot be inferred from lambda body
because of cyclic inference
	Predicate<Integer> z = #{v -> v % 3 == 0 }; //does not compile
	                       ^
  explicit type required for the following parameter: v
1 warning

The error message is a bit strange. I can't see a cycle. Could someone
explain it?

Thomas

From howard.lovatt at gmail.com  Sat Oct 30 16:40:51 2010
From: howard.lovatt at gmail.com (Howard Lovatt)
Date: Sun, 31 Oct 2010 10:40:51 +1100
Subject: 2 problems making JDK7
Message-ID: <AANLkTimTpT6RSH6jxY=9syavrPBx=7DS+cqP3JYNHmCv@mail.gmail.com>

Hi,

When I try and make JDK7 I get 2 errors:

1. Conflict during merge:

warning: conflicts during merge.
merging .hgtags failed!
warning: detected divergent renames of
test/tools/javac/tree/TreeScannerTest.java to:
 test/tools/javac/tree/AbstractTreeScannerTest.java
 test/tools/javac/tree/JavacTreeScannerTest.java
 test/tools/javac/tree/SourceTreeScannerTest.java
363 files updated, 0 files merged, 5 files removed, 1 files unresolved


2. Compilation error:

    [javac] /Users/lov080/Downloads/MLVM/JDK7/langtools/src/share/classes/com/sun/tools/javac/nio/JavacPathFileManager.java:372:
method does not override or implement a method from a supertype
    [javac]             @Override
    [javac]             ^
    [javac] 1 error

BUILD FAILED
/Users/lov080/Downloads/MLVM/JDK7/langtools/make/build.xml:413: The
following error occurred while executing this line:
/Users/lov080/Downloads/MLVM/JDK7/langtools/make/build.xml:777:
Compile failed; see the compiler error output for details.


I am making on a Mac - details of build:

http://mail.openjdk.java.net/pipermail/lambda-dev/2010-September/002434.html

Cheers,

? -- Howard.

From jonathan.gibbons at oracle.com  Sat Oct 30 17:25:21 2010
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Sat, 30 Oct 2010 17:25:21 -0700
Subject: 2 problems making JDK7
In-Reply-To: <AANLkTimTpT6RSH6jxY=9syavrPBx=7DS+cqP3JYNHmCv@mail.gmail.com>
References: <AANLkTimTpT6RSH6jxY=9syavrPBx=7DS+cqP3JYNHmCv@mail.gmail.com>
Message-ID: <4CCCB771.8070107@oracle.com>

Howard,

I can't speak to the conflicts regarding the .hgtags file.

The warning about divergent renames is expected and can be ignored.

The compilation error indicates you are using an older version of JDK7 
-- you need to get and use a more recent build.

-- Jon


On 10/30/2010 04:40 PM, Howard Lovatt wrote:
> Hi,
>
> When I try and make JDK7 I get 2 errors:
>
> 1. Conflict during merge:
>
> warning: conflicts during merge.
> merging .hgtags failed!
> warning: detected divergent renames of
> test/tools/javac/tree/TreeScannerTest.java to:
>   test/tools/javac/tree/AbstractTreeScannerTest.java
>   test/tools/javac/tree/JavacTreeScannerTest.java
>   test/tools/javac/tree/SourceTreeScannerTest.java
> 363 files updated, 0 files merged, 5 files removed, 1 files unresolved
>
>
> 2. Compilation error:
>
>      [javac] /Users/lov080/Downloads/MLVM/JDK7/langtools/src/share/classes/com/sun/tools/javac/nio/JavacPathFileManager.java:372:
> method does not override or implement a method from a supertype
>      [javac]             @Override
>      [javac]             ^
>      [javac] 1 error
>
> BUILD FAILED
> /Users/lov080/Downloads/MLVM/JDK7/langtools/make/build.xml:413: The
> following error occurred while executing this line:
> /Users/lov080/Downloads/MLVM/JDK7/langtools/make/build.xml:777:
> Compile failed; see the compiler error output for details.
>
>
> I am making on a Mac - details of build:
>
> http://mail.openjdk.java.net/pipermail/lambda-dev/2010-September/002434.html
>
> Cheers,
>
>    -- Howard.
>


From howard.lovatt at gmail.com  Sat Oct 30 20:03:30 2010
From: howard.lovatt at gmail.com (Howard Lovatt)
Date: Sun, 31 Oct 2010 14:03:30 +1100
Subject: 2 problems making JDK7
Message-ID: <AANLkTi=-azg5EHqpDN_6O83ceG++A-mYfVUj0kf6yu+h@mail.gmail.com>

Jon,

Thanks for the help. I deleted my repository and made a new clone and
the hg errors went away.

However the compilation error remains, the version of java I am using
to build JDK is:

Howards-MacBookPro-2007:MLVM lov080$ 1.7.0_2010_09_25/Home/bin/java -version
openjdk version "1.7.0-internal-fastdebug"
OpenJDK Runtime Environment (build
1.7.0-internal-fastdebug-stephen_2010_09_25_21_05-b00)
OpenJDK 64-Bit Server VM (build 19.0-b03-fastdebug, mixed mode)

From:

http://www.concord.org/~sbannasch/mlvm/

Do you know which minimum build number I should use?

? -- Howard.


Jonathan Gibbons jonathan.gibbons at oracle.com Sat Oct 30 17:25:21
PDT 2010 wrote:
Howard,

I can't speak to the conflicts regarding the .hgtags file.

The warning about divergent renames is expected and can be ignored.

The compilation error indicates you are using an older version of JDK7
-- you need to get and use a more recent build.

-- Jon

From jonathan.gibbons at oracle.com  Sat Oct 30 22:23:35 2010
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Sat, 30 Oct 2010 22:23:35 -0700
Subject: 2 problems making JDK7
In-Reply-To: <AANLkTi=-azg5EHqpDN_6O83ceG++A-mYfVUj0kf6yu+h@mail.gmail.com>
References: <AANLkTi=-azg5EHqpDN_6O83ceG++A-mYfVUj0kf6yu+h@mail.gmail.com>
Message-ID: <4CCCFD57.8020406@oracle.com>

On 10/30/2010 08:03 PM, Howard Lovatt wrote:
> Jon,
>
> Thanks for the help. I deleted my repository and made a new clone and
> the hg errors went away.
>
> However the compilation error remains, the version of java I am using
> to build JDK is:
>
> Howards-MacBookPro-2007:MLVM lov080$ 1.7.0_2010_09_25/Home/bin/java -version
> openjdk version "1.7.0-internal-fastdebug"
> OpenJDK Runtime Environment (build
> 1.7.0-internal-fastdebug-stephen_2010_09_25_21_05-b00)
> OpenJDK 64-Bit Server VM (build 19.0-b03-fastdebug, mixed mode)
>
> From:
>
> http://www.concord.org/~sbannasch/mlvm/
>
> Do you know which minimum build number I should use?
>
>    -- Howard.
>
>
> Jonathan Gibbons jonathan.gibbons at oracle.com Sat Oct 30 17:25:21
> PDT 2010 wrote:
> Howard,
>
> I can't speak to the conflicts regarding the .hgtags file.
>
> The warning about divergent renames is expected and can be ignored.
>
> The compilation error indicates you are using an older version of JDK7
> -- you need to get and use a more recent build.
>
> -- Jon
>


Probably after 114, and definitely dated October or later.  There were 
corresponding fixes that went into the repos on 10/04 or so.

-- Jon

From maurizio.cimadamore at oracle.com  Sun Oct 31 04:13:58 2010
From: maurizio.cimadamore at oracle.com (maurizio cimadamore)
Date: Sun, 31 Oct 2010 11:13:58 +0000
Subject: thrown types cannot be inferred from lambda body because of cyclic
	inference
In-Reply-To: <AANLkTimVib3F0yOATr_naCTp+LDB8qThg+DWp6mBxeq9@mail.gmail.com>
References: <AANLkTimVib3F0yOATr_naCTp+LDB8qThg+DWp6mBxeq9@mail.gmail.com>
Message-ID: <4CCD4F76.9010401@oracle.com>

On 30/10/2010 17:39, Thomas Jung wrote:
> Hi,
>
> the following does not compile:
>
> import com.google.common.base.*;
> class X{
> 	private Predicate<Integer>  x = new Predicate<Integer>(){
> 		public boolean apply(Integer v) { return  v % 3 == 0; }
> 	};
> 	Predicate<Integer>  y = #{Integer v ->  v % 3 == 0 };
> 	Predicate<Integer>  z = #{v ->  v % 3 == 0 }; //does not compile
> }
>
> X.java:11: warning: thrown types cannot be inferred from lambda body
> because of cyclic inference
> 	Predicate<Integer>  z = #{v ->  v % 3 == 0 }; //does not compile
> 	                       ^
>    explicit type required for the following parameter: v
> 1 warning
>
> The error message is a bit strange. I can't see a cycle. Could someone
> explain it?
The message means that the body of the lambda expression cannot be 
attributed before the target type (Predicate<Integer>) is known. In this 
particular example, this has no effect; if you were calling a generic 
method with some 'throws' type-variable there could have been problems 
though. I think that in examples like this, where the target type is 
provided in an assignment context, the compiler could do better job than 
this.

Maurizio
> Thomas
>