hg: jdk8/tl/jaxp: 8008738: Issue in com.sun.org.apache.xml.internal.serializer.Encodings causes some JCK tests to fail intermittently

[daniel . fuchs]

Changeset: 452e1a182907
Author:dfuchs
Date:  2013-05-06 18:50 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/452e1a182907

8008738: Issue in com.sun.org.apache.xml.internal.serializer.Encodings causes 
some JCK tests to fail intermittently
Summary: Encodings.java sometimes creates EncodingInfo objects whose java names 
are not recognized by the Charset API. This patch fixes that issue.
Reviewed-by: joehw, alanb

! src/com/sun/org/apache/xml/internal/serializer/Encodings.java

hg: jdk8/tl/jdk: 8008738: Issue in com.sun.org.apache.xml.internal.serializer.Encodings causes some JCK tests to fail intermittently

[daniel . fuchs]

Changeset: 2602eab5f086
Author:dfuchs
Date:  2013-05-07 11:35 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2602eab5f086

8008738: Issue in com.sun.org.apache.xml.internal.serializer.Encodings causes 
some JCK tests to fail intermittently
Summary: Encodings.java sometimes creates EncodingInfo objects whose java names 
are not recognized by the Charset API. This patch fixes that issue.
Reviewed-by: joehw, alanb

+ test/javax/xml/jaxp/Encodings/CheckEncodingPropertiesFile.java

Incorrect handling of HTTP/1.1 "Expect: 100-continue" in HttpURLConnection

[Piotr Bzdyl]

Hello,

This is my first post to this mailing list so I would like to say "Hi".

The reason I subscribed and I am writing is that I believe I have found a
bug in sun.*.HttpURLConnection class (in particular how it handles Expect:
100-continue header). I have already submitted a bug at bugs.sun.com but
after almost 3 weeks I still cannot access the bug and check its status (
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=9001773).

I would like to ask if bugs.sun.com is alive or if it is possible to report
the bug in the OpenJDK project or is there any other alternative procedure
for submitting bug reports.

Best regards,
Piotr Bzdyl

Re: RFR JDK7188517

[Chris Hegarty]

On 05/06/2013 10:28 PM, Kurchi Hazra wrote:

This looks okay to me.


Source changes look fine to me too. Probably best to add a test for '$'

In fact, Michael actually removed such a test [1] during another change. 
We should get positive agreement from Michael before pushing this.


-Chris.

[1] http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/7bd32bfc0539



- Kurchi


On 5/2/2013 10:09 AM, John Zavgren wrote:

All:
My original email was mangled by my email program (stbeehive/zimbra)
... so I'm sending a second correctly formatted copy.

I'm sorry for the inconvenience.

John
---

Please consider the following change to the cookie constructor:
http://cr.openjdk.java.net/~jzavgren/7188517/webrev.01/


Basically there are two issues:

1.) the existing cookie constructor was allowing cookie names to have
a dollar sign as their leading character,
which is "illegal". The constructor code was modified to disallow
these illegal names.

2.) the API document (notice the specdiff:
http://cr.openjdk.java.net/~jzavgren/7188517/specDiff/
) prohibited
the use of cookie names that are one of the tokens reserved for use by
the cookie protocol, and this restriction is not necessary.

Thanks!
John Zavgren


- Original Message -
From: john.zavg...@oracle.com
To: net-dev@openjdk.java.net
Sent: Thursday, May 2, 2013 10:36:38 AM GMT -05:00 US/Canada Eastern
Subject: RFR JDK7188517

Greetings: Please consider the following change to the cookie
constructor: http://cr.openjdk.java.net/~jzavgren/7188517/webrev.01/
Basically there are two issues: 1.) the existing cookie constructor
was allowing cookie names to have a dollar sign as their leading
character, which is "illegal". The constructor code was modified to
disallow these illegal names. 2.) the API document (notice the
specdiff: http://cr.openjdk.java.net/~jzavgren/7188517/specDiff/)
prohibited the use of cookie names that are one of the tokens reserved
for use by the cookie protocol, and this restriction is not necessary.
Thanks! John Zavgren


--
-Kurchi

Re: Incorrect handling of HTTP/1.1 "Expect: 100-continue" in HttpURLConnection

[Chris Hegarty]

Hi Piotr,

Your bug is accessible at
  http://bugs.sun.com/view_bug.do?bug_id=8012625

From my reading of the code the headers should be sent before waiting 
for the reply to continue.


From sun/net/www/prtotocol/http/HttpURLConnection:

getOutputStream() {

if (!checkReuseConnection())
connect();

boolean expectContinue = false;
String expects = requests.findValue("Expect");
if ("100-Continue".equalsIgnoreCase(expects)) {
http.setIgnoreContinue(false);
expectContinue = true;
}

if (streaming() && strOutputStream == null) {
writeRequests();  //  Here
}

if (expectContinue) {
expect100Continue();
}


}

Are you seeing something different?

-Chris.


On 05/07/2013 02:25 PM, Piotr Bzdyl wrote:

Hello,

This is my first post to this mailing list so I would like to say "Hi".

The reason I subscribed and I am writing is that I believe I have found
a bug in sun.*.HttpURLConnection class (in particular how it handles
Expect: 100-continue header). I have already submitted a bug at
bugs.sun.com  but after almost 3 weeks I still
cannot access the bug and check its status
(http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=9001773).

I would like to ask if bugs.sun.com  is alive or if
it is possible to report the bug in the OpenJDK project or is there any
other alternative procedure for submitting bug reports.

Best regards,
Piotr Bzdyl

Re: Incorrect handling of HTTP/1.1 "Expect: 100-continue" in HttpURLConnection

[Piotr Bzdyl]

Chris,

When I used the URL provided by you I have indeed access to my bug report.
It seems the notification email I got with confirmation of my report
submission provides the misleading URL. Is it possible to fix it in the
notification template?

When I debug the code (using the test case I attached to the bug report),
it doesn't go into the

if (streaming() && strOutputStream == null) {
writeRequests();  //  Here
}

but goes directly to expect100Continue() in:
if (expectContinue) {
expect100Continue();
}



On Tue, May 7, 2013 at 3:52 PM, Chris Hegarty wrote:

> Hi Piotr,
>
> Your bug is accessible at
>   
> http://bugs.sun.com/view_bug.**do?bug_id=8012625
>
> From my reading of the code the headers should be sent before waiting for
> the reply to continue.
>
> From sun/net/www/prtotocol/http/**HttpURLConnection:
>
> getOutputStream() {
> 
> if (!checkReuseConnection())
> connect();
>
> boolean expectContinue = false;
> String expects = requests.findValue("Expect");
> if ("100-Continue".**equalsIgnoreCase(expects)) {
> http.setIgnoreContinue(false);
> expectContinue = true;
> }
>
> if (streaming() && strOutputStream == null) {
> writeRequests();  //  Here
> }
>
> if (expectContinue) {
> expect100Continue();
> }
> 
>
> }
>
> Are you seeing something different?
>
> -Chris.
>
>
>
> On 05/07/2013 02:25 PM, Piotr Bzdyl wrote:
>
>> Hello,
>>
>> This is my first post to this mailing list so I would like to say "Hi".
>>
>> The reason I subscribed and I am writing is that I believe I have found
>> a bug in sun.*.HttpURLConnection class (in particular how it handles
>> Expect: 100-continue header). I have already submitted a bug at
>> bugs.sun.com  but after almost 3 weeks I still
>>
>> cannot access the bug and check its status
>> (http://bugs.sun.com/**bugdatabase/view_bug.do?bug_**id=9001773
>> ).
>>
>> I would like to ask if bugs.sun.com  is alive or if
>>
>> it is possible to report the bug in the OpenJDK project or is there any
>> other alternative procedure for submitting bug reports.
>>
>> Best regards,
>> Piotr Bzdyl
>>
>

Re: Incorrect handling of HTTP/1.1 "Expect: 100-continue" in HttpURLConnection

[Chris Hegarty]

On 05/07/2013 02:59 PM, Piotr Bzdyl wrote:

Chris,

When I used the URL provided by you I have indeed access to my bug
report. It seems the notification email I got with confirmation of my
report submission provides the misleading URL. Is it possible to fix it
in the notification template?


You are right the URL provided to you is pretty much useless, at this 
point. Not that is matters much, but there are separate JIRA projects 
for bugs moving from web screening to the "real" bug incidents. If it is 
any consolation, your issue has made it all the way ;-)




When I debug the code (using the test case I attached to the bug
report), it doesn't go into the

 if (streaming() && strOutputStream == null) {
 writeRequests();  //  Here
 }

but goes directly to expect100Continue() in:
 if (expectContinue) {
 expect100Continue();
 }


Ah ha. that is the bug. We should always writeRequests ( write headers ) 
when expectContinue is set. I'll update the bug with this clear comment, 
and then propose a patch for JDK8.


-Chris.





On Tue, May 7, 2013 at 3:52 PM, Chris Hegarty mailto:chris.hega...@oracle.com>> wrote:

Hi Piotr,

Your bug is accessible at
http://bugs.sun.com/view_bug.__do?bug_id=8012625


 From my reading of the code the headers should be sent before
waiting for the reply to continue.

 From sun/net/www/prtotocol/http/__HttpURLConnection:

 getOutputStream() {
 
 if (!checkReuseConnection())
 connect();

 boolean expectContinue = false;
 String expects = requests.findValue("Expect");
 if ("100-Continue".__equalsIgnoreCase(expects)) {
 http.setIgnoreContinue(false);
 expectContinue = true;
 }

 if (streaming() && strOutputStream == null) {
 writeRequests();  //  Here
 }

 if (expectContinue) {
 expect100Continue();
 }
 

 }

Are you seeing something different?

-Chris.



On 05/07/2013 02:25 PM, Piotr Bzdyl wrote:

Hello,

This is my first post to this mailing list so I would like to
say "Hi".

The reason I subscribed and I am writing is that I believe I
have found
a bug in sun.*.HttpURLConnection class (in particular how it handles
Expect: 100-continue header). I have already submitted a bug at
bugs.sun.com   but
after almost 3 weeks I still

cannot access the bug and check its status
(http://bugs.sun.com/__bugdatabase/view_bug.do?bug___id=9001773
).

I would like to ask if bugs.sun.com 
 is alive or if

it is possible to report the bug in the OpenJDK project or is
there any
other alternative procedure for submitting bug reports.

Best regards,
Piotr Bzdyl

Re: Incorrect handling of HTTP/1.1 "Expect: 100-continue" in HttpURLConnection

[Piotr Bzdyl]

Thank you very much for clarification!

Best regards,
Piotr


On Tue, May 7, 2013 at 4:05 PM, Chris Hegarty wrote:

> On 05/07/2013 02:59 PM, Piotr Bzdyl wrote:
>
>> Chris,
>>
>> When I used the URL provided by you I have indeed access to my bug
>> report. It seems the notification email I got with confirmation of my
>> report submission provides the misleading URL. Is it possible to fix it
>> in the notification template?
>>
>
> You are right the URL provided to you is pretty much useless, at this
> point. Not that is matters much, but there are separate JIRA projects for
> bugs moving from web screening to the "real" bug incidents. If it is any
> consolation, your issue has made it all the way ;-)
>
>
>
>> When I debug the code (using the test case I attached to the bug
>> report), it doesn't go into the
>>
>>  if (streaming() && strOutputStream == null) {
>>  writeRequests();  //  Here
>>  }
>>
>> but goes directly to expect100Continue() in:
>>  if (expectContinue) {
>>  expect100Continue();
>>  }
>>
>
> Ah ha. that is the bug. We should always writeRequests ( write headers )
> when expectContinue is set. I'll update the bug with this clear comment,
> and then propose a patch for JDK8.
>
> -Chris.
>
>
>>
>>
>> On Tue, May 7, 2013 at 3:52 PM, Chris Hegarty > > wrote:
>>
>> Hi Piotr,
>>
>> Your bug is accessible at
>> 
>> http://bugs.sun.com/view_bug._**_do?bug_id=8012625
>>
>> 
>> 
>> >
>>
>>  From my reading of the code the headers should be sent before
>> waiting for the reply to continue.
>>
>>  From sun/net/www/prtotocol/http/__**HttpURLConnection:
>>
>>
>>  getOutputStream() {
>>  
>>  if (!checkReuseConnection())
>>  connect();
>>
>>  boolean expectContinue = false;
>>  String expects = requests.findValue("Expect");
>>  if ("100-Continue".__**equalsIgnoreCase(expects)) {
>>
>>  http.setIgnoreContinue(false);
>>  expectContinue = true;
>>  }
>>
>>  if (streaming() && strOutputStream == null) {
>>  writeRequests();  //  Here
>>  }
>>
>>  if (expectContinue) {
>>  expect100Continue();
>>  }
>>  
>>
>>  }
>>
>> Are you seeing something different?
>>
>> -Chris.
>>
>>
>>
>> On 05/07/2013 02:25 PM, Piotr Bzdyl wrote:
>>
>> Hello,
>>
>> This is my first post to this mailing list so I would like to
>> say "Hi".
>>
>> The reason I subscribed and I am writing is that I believe I
>> have found
>> a bug in sun.*.HttpURLConnection class (in particular how it
>> handles
>> Expect: 100-continue header). I have already submitted a bug at
>> bugs.sun.com   but
>>
>> after almost 3 weeks I still
>>
>> cannot access the bug and check its status
>> (http://bugs.sun.com/__**bugdatabase/view_bug.do?bug___**
>> id=9001773
>> 
>> 
>> >).
>>
>>
>> I would like to ask if bugs.sun.com 
>>  is alive or if
>>
>> it is possible to report the bug in the OpenJDK project or is
>> there any
>> other alternative procedure for submitting bug reports.
>>
>> Best regards,
>> Piotr Bzdyl
>>
>>
>>

Re: Incorrect handling of HTTP/1.1 "Expect: 100-continue" in HttpURLConnection

[Piotr Bzdyl]

In this case I will have to double check the SAAJ SoapConnection (as we
encountered the problem indirectly when using SAAJ SoapConnection). The
code invoking the SOAP service was setting Expect: 100-continue header as
the SOAP message header and SoapConnection propagated it to
HttpURLConnection. I need to confirm that it is even allowed and if it is I
will report the bug in SAAJ project.

Best regards,
Piotr

On Tue, May 7, 2013 at 4:29 PM, Chris Hegarty wrote:

> I replied too quick. This is not a bug per say, but a limitation of the
> existing API.
>
> Expect: 100-continue is only supported with streaming requests, i.e.
> setChunkedStreamingMode(int), or setFixedLengthStreamingMode(**long).
>
> With the above API's the appropriate header, content-length or
> Transfer-Encoding: chunked, can be set before return the OutputStream (
> from getOutputStream() ). Without either of the above calls the
> content-length is only determinable after the returned output stream is
> closed, and this happens after the return from getOutptuStream().
>
> So I would say this is a limitation of the API. But the workaround is
> quite straight forward, use streaming.
>
> -Chris.
>
>
> On 05/07/2013 03:05 PM, Chris Hegarty wrote:
>
>> On 05/07/2013 02:59 PM, Piotr Bzdyl wrote:
>>
>>> Chris,
>>>
>>> When I used the URL provided by you I have indeed access to my bug
>>> report. It seems the notification email I got with confirmation of my
>>> report submission provides the misleading URL. Is it possible to fix it
>>> in the notification template?
>>>
>>
>> You are right the URL provided to you is pretty much useless, at this
>> point. Not that is matters much, but there are separate JIRA projects
>> for bugs moving from web screening to the "real" bug incidents. If it is
>> any consolation, your issue has made it all the way ;-)
>>
>>
>>> When I debug the code (using the test case I attached to the bug
>>> report), it doesn't go into the
>>>
>>>  if (streaming() && strOutputStream == null) {
>>>  writeRequests();  //  Here
>>>  }
>>>
>>> but goes directly to expect100Continue() in:
>>>  if (expectContinue) {
>>>  expect100Continue();
>>>  }
>>>
>>
>> Ah ha. that is the bug. We should always writeRequests ( write headers )
>> when expectContinue is set. I'll update the bug with this clear comment,
>> and then propose a patch for JDK8.
>>
>> -Chris.
>>
>>
>>>
>>>
>>> On Tue, May 7, 2013 at 3:52 PM, Chris Hegarty >> > wrote:
>>>
>>> Hi Piotr,
>>>
>>> Your bug is accessible at
>>> 
>>> http://bugs.sun.com/view_bug._**_do?bug_id=8012625
>>> 
>>> 
>>> >
>>>
>>>  From my reading of the code the headers should be sent before
>>> waiting for the reply to continue.
>>>
>>>  From sun/net/www/prtotocol/http/__**HttpURLConnection:
>>>
>>>  getOutputStream() {
>>>  
>>>  if (!checkReuseConnection())
>>>  connect();
>>>
>>>  boolean expectContinue = false;
>>>  String expects = requests.findValue("Expect");
>>>  if ("100-Continue".__**equalsIgnoreCase(expects)) {
>>>  http.setIgnoreContinue(false);
>>>  expectContinue = true;
>>>  }
>>>
>>>  if (streaming() && strOutputStream == null) {
>>>  writeRequests();  //  Here
>>>  }
>>>
>>>  if (expectContinue) {
>>>  expect100Continue();
>>>  }
>>>  
>>>
>>>  }
>>>
>>> Are you seeing something different?
>>>
>>> -Chris.
>>>
>>>
>>>
>>> On 05/07/2013 02:25 PM, Piotr Bzdyl wrote:
>>>
>>> Hello,
>>>
>>> This is my first post to this mailing list so I would like to
>>> say "Hi".
>>>
>>> The reason I subscribed and I am writing is that I believe I
>>> have found
>>> a bug in sun.*.HttpURLConnection class (in particular how it
>>> handles
>>> Expect: 100-continue header). I have already submitted a bug at
>>> bugs.sun.com   but
>>> after almost 3 weeks I still
>>>
>>> cannot access the bug and check its status
>>> (http://bugs.sun.com/__**bugdatabase/view_bug.do?bug___**
>>> id=9001773
>>> 
>>> 
>>> >).
>>>
>>> I would like to ask if bugs.sun.com 
>>>  is alive or if
>>>
>>> it is possible to report the bug in the OpenJDK project or is
>>> there any
>>> other alternative procedure for s

Re: Incorrect handling of HTTP/1.1 "Expect: 100-continue" in HttpURLConnection

[Chris Hegarty]

I replied too quick. This is not a bug per say, but a limitation of the 
existing API.


Expect: 100-continue is only supported with streaming requests, i.e. 
setChunkedStreamingMode(int), or setFixedLengthStreamingMode(long).


With the above API's the appropriate header, content-length or 
Transfer-Encoding: chunked, can be set before return the OutputStream ( 
from getOutputStream() ). Without either of the above calls the 
content-length is only determinable after the returned output stream is 
closed, and this happens after the return from getOutptuStream().


So I would say this is a limitation of the API. But the workaround is 
quite straight forward, use streaming.


-Chris.

On 05/07/2013 03:05 PM, Chris Hegarty wrote:

On 05/07/2013 02:59 PM, Piotr Bzdyl wrote:

Chris,

When I used the URL provided by you I have indeed access to my bug
report. It seems the notification email I got with confirmation of my
report submission provides the misleading URL. Is it possible to fix it
in the notification template?


You are right the URL provided to you is pretty much useless, at this
point. Not that is matters much, but there are separate JIRA projects
for bugs moving from web screening to the "real" bug incidents. If it is
any consolation, your issue has made it all the way ;-)



When I debug the code (using the test case I attached to the bug
report), it doesn't go into the

 if (streaming() && strOutputStream == null) {
 writeRequests();  //  Here
 }

but goes directly to expect100Continue() in:
 if (expectContinue) {
 expect100Continue();
 }


Ah ha. that is the bug. We should always writeRequests ( write headers )
when expectContinue is set. I'll update the bug with this clear comment,
and then propose a patch for JDK8.

-Chris.





On Tue, May 7, 2013 at 3:52 PM, Chris Hegarty mailto:chris.hega...@oracle.com>> wrote:

Hi Piotr,

Your bug is accessible at
http://bugs.sun.com/view_bug.__do?bug_id=8012625


 From my reading of the code the headers should be sent before
waiting for the reply to continue.

 From sun/net/www/prtotocol/http/__HttpURLConnection:

 getOutputStream() {
 
 if (!checkReuseConnection())
 connect();

 boolean expectContinue = false;
 String expects = requests.findValue("Expect");
 if ("100-Continue".__equalsIgnoreCase(expects)) {
 http.setIgnoreContinue(false);
 expectContinue = true;
 }

 if (streaming() && strOutputStream == null) {
 writeRequests();  //  Here
 }

 if (expectContinue) {
 expect100Continue();
 }
 

 }

Are you seeing something different?

-Chris.



On 05/07/2013 02:25 PM, Piotr Bzdyl wrote:

Hello,

This is my first post to this mailing list so I would like to
say "Hi".

The reason I subscribed and I am writing is that I believe I
have found
a bug in sun.*.HttpURLConnection class (in particular how it
handles
Expect: 100-continue header). I have already submitted a bug at
bugs.sun.com   but
after almost 3 weeks I still

cannot access the bug and check its status
(http://bugs.sun.com/__bugdatabase/view_bug.do?bug___id=9001773
).

I would like to ask if bugs.sun.com 
 is alive or if

it is possible to report the bug in the OpenJDK project or is
there any
other alternative procedure for submitting bug reports.

Best regards,
Piotr Bzdyl

hg: jdk8/tl/jdk: 8004007: test/sun/tools/jinfo/Basic.sh fails on when runSA is set to true

[staffan . larsen]

Changeset: 100027950b05
Author:sla
Date:  2013-05-07 20:00 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/100027950b05

8004007: test/sun/tools/jinfo/Basic.sh fails on when runSA is set to true
Reviewed-by: alanb, dsamersoff

! test/sun/tools/jinfo/Basic.sh

hg: jdk8/tl/jdk: 6980985: java/lang/management/MemoryMXBean/ResetPeakMemoryUsage is not robust when getMax() returns -1; ...

[staffan . larsen]

Changeset: 7b40394ad944
Author:sla
Date:  2013-05-07 19:57 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7b40394ad944

6980985: java/lang/management/MemoryMXBean/ResetPeakMemoryUsage is not robust 
when getMax() returns -1
7181907: TEST_BUG: j/l/management/MemoryMXBean/ResetPeakMemoryUsage fails with 
NegativeArraySizeException
7148492: java/lang/management/MemoryMXBean/ResetPeakMemoryUsage.java failing 
since update to hs23-b15 or b16
Reviewed-by: mchung, brutisso

! test/ProblemList.txt
! test/java/lang/management/MemoryMXBean/ResetPeakMemoryUsage.java

hg: jdk8/tl/jdk: 8013086: NPE thrown by SimpleDateFormat with TimeZoneNameProvider supplied

[naoto . sato]

Changeset: e30396e22c6f
Author:naoto
Date:  2013-05-07 11:31 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e30396e22c6f

8013086: NPE thrown by SimpleDateFormat with TimeZoneNameProvider supplied
Reviewed-by: okutsu

! src/share/classes/sun/util/locale/provider/TimeZoneNameUtility.java
! test/java/util/Locale/LocaleProviders.java
! test/java/util/Locale/LocaleProviders.sh

hg: jdk8/tl/jdk: 4802647: Throw required NPEs from removeAll()/retainAll()

[mike . duigou]

Changeset: fe4e9bc2186f
Author:mduigou
Date:  2013-05-07 12:05 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fe4e9bc2186f

4802647: Throw required NPEs from removeAll()/retainAll()
Reviewed-by: mduigou, chegar, dholmes
Contributed-by: Brandon Passanisi 

! src/share/classes/java/util/AbstractCollection.java
! src/share/classes/java/util/AbstractSet.java
! src/share/classes/java/util/ArrayList.java
! test/java/util/Collection/MOAT.java

hg: jdk8/tl/langtools: 8004082: test/tools/javac/plugin/showtype/Test.java fails on windows: jtreg can't delete plugin.jar

[jonathan . gibbons]

Changeset: 43c2f7cb9c76
Author:jjg
Date:  2013-05-07 14:27 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/43c2f7cb9c76

8004082: test/tools/javac/plugin/showtype/Test.java fails on windows: jtreg 
can't delete plugin.jar
Reviewed-by: vromero, mcimadamore

! 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/util/ServiceLoader.java
! test/tools/javac/plugin/showtype/Test.java

hg: jdk8/tl/jdk: 8012664: Add tests for java.util.stream and lambda translation

[mike . duigou]

Changeset: 6feee75b0a8b
Author:briangoetz
Date:  2013-05-06 11:43 -0400
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6feee75b0a8b

8012664: Add tests for java.util.stream and lambda translation
Reviewed-by: mduigou, briangoetz
Contributed-by: Brian Goetz , Paul Sandoz 
, Mike Duigou , Robert Field 
, Jim Gish 

! test/Makefile
+ test/java/util/concurrent/atomic/AtomicReferenceTest.java
+ test/java/util/stream/bootlib/TEST.properties
+ test/java/util/stream/bootlib/java/util/stream/CollectorOps.java
+ 
test/java/util/stream/bootlib/java/util/stream/DoubleStreamTestDataProvider.java
+ test/java/util/stream/bootlib/java/util/stream/DoubleStreamTestScenario.java
+ test/java/util/stream/bootlib/java/util/stream/FlagDeclaringOp.java
+ test/java/util/stream/bootlib/java/util/stream/IntStreamTestDataProvider.java
+ test/java/util/stream/bootlib/java/util/stream/IntStreamTestScenario.java
+ test/java/util/stream/bootlib/java/util/stream/IntermediateTestOp.java
+ test/java/util/stream/bootlib/java/util/stream/LambdaTestHelpers.java
+ test/java/util/stream/bootlib/java/util/stream/LongStreamTestDataProvider.java
+ test/java/util/stream/bootlib/java/util/stream/LongStreamTestScenario.java
+ test/java/util/stream/bootlib/java/util/stream/OpTestCase.java
+ test/java/util/stream/bootlib/java/util/stream/SpliteratorTestHelper.java
+ test/java/util/stream/bootlib/java/util/stream/StatefulTestOp.java
+ test/java/util/stream/bootlib/java/util/stream/StatelessTestOp.java
+ test/java/util/stream/bootlib/java/util/stream/StreamOpFlagTestHelper.java
+ test/java/util/stream/bootlib/java/util/stream/StreamTestDataProvider.java
+ test/java/util/stream/bootlib/java/util/stream/StreamTestScenario.java
+ test/java/util/stream/bootlib/java/util/stream/TestData.java
+ test/java/util/stream/bootlib/java/util/stream/TestFlagExpectedOp.java
+ test/java/util/stream/boottest/TEST.properties
+ test/java/util/stream/boottest/java/util/stream/DoubleNodeTest.java
+ test/java/util/stream/boottest/java/util/stream/FlagOpTest.java
+ test/java/util/stream/boottest/java/util/stream/IntNodeTest.java
+ test/java/util/stream/boottest/java/util/stream/LongNodeTest.java
+ test/java/util/stream/boottest/java/util/stream/NodeBuilderTest.java
+ test/java/util/stream/boottest/java/util/stream/NodeTest.java
+ test/java/util/stream/boottest/java/util/stream/SpinedBufferTest.java
+ test/java/util/stream/boottest/java/util/stream/StreamFlagsTest.java
+ test/java/util/stream/boottest/java/util/stream/StreamOpFlagsTest.java
+ test/java/util/stream/boottest/java/util/stream/StreamReuseTest.java
+ test/java/util/stream/boottest/java/util/stream/UnorderedTest.java
+ test/java/util/stream/test/TEST.properties
+ 
test/java/util/stream/test/org/openjdk/tests/java/lang/invoke/DeserializeMethodTest.java
+ 
test/java/util/stream/test/org/openjdk/tests/java/lang/invoke/MHProxiesTest.java
+ 
test/java/util/stream/test/org/openjdk/tests/java/lang/invoke/SerializedLambdaTest.java
+ test/java/util/stream/test/org/openjdk/tests/java/util/FillableStringTest.java
+ test/java/util/stream/test/org/openjdk/tests/java/util/MapTest.java
+ test/java/util/stream/test/org/openjdk/tests/java/util/NullArgsTestCase.java
+ 
test/java/util/stream/test/org/openjdk/tests/java/util/stream/CollectionAndMapModifyStreamTest.java
+ 
test/java/util/stream/test/org/openjdk/tests/java/util/stream/DistinctOpTest.java
+ 
test/java/util/stream/test/org/openjdk/tests/java/util/stream/DoublePrimitiveOpsTests.java
+ 
test/java/util/stream/test/org/openjdk/tests/java/util/stream/ExplodeOpTest.java
+ 
test/java/util/stream/test/org/openjdk/tests/java/util/stream/FilterOpTest.java
+ 
test/java/util/stream/test/org/openjdk/tests/java/util/stream/FindAnyOpTest.java
+ 
test/java/util/stream/test/org/openjdk/tests/java/util/stream/FindFirstOpTest.java
+ 
test/java/util/stream/test/org/openjdk/tests/java/util/stream/ForEachOpTest.java
+ 
test/java/util/stream/test/org/openjdk/tests/java/util/stream/GroupByOpTest.java
+ 
test/java/util/stream/test/org/openjdk/tests/java/util/stream/InfiniteStreamWithLimitOpTest.java
+ 
test/java/util/stream/test/org/openjdk/tests/java/util/stream/IntPrimitiveOpsTests.java
+ 
test/java/util/stream/test/org/openjdk/tests/java/util/stream/IntReduceTest.java
+ 
test/java/util/stream/test/org/openjdk/tests/java/util/stream/IntSliceOpTest.java
+ 
test/java/util/stream/test/org/openjdk/tests/java/util/stream/IntUniqOpTest.java
+ 
test/java/util/stream/test/org/openjdk/tests/java/util/stream/LongPrimitiveOpsTests.java
+ test/java/util/stream/test/org/openjdk/tests/java/util/stream/MapOpTest.java
+ test/java/util/stream/test/org/openjdk/tests/java/util/stream/MatchOpTest.java
+ test/java/util/stream/test/org/openjdk/tests/java/util/stream/MinMaxTest.java
+ 
test/java/util/stream/test/org/openjdk/tests/java/util/stream/PrimitiveAverageOpTest.java
+ 
test/java/util/stream/test/org/openjdk/tests/java/util/stream/PrimitiveSumTest.java
+ test/java/util/stream/test/org/openjdk/tests/