hg: jdk8/tl/langtools: 8004133: Provide javax.lang.model.* implementation backed by core reflection

[joe . darcy]

Changeset: bcd927639039
Author:darcy
Date:  2013-05-15 00:00 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/bcd927639039

8004133: Provide javax.lang.model.* implementation backed by core reflection
Summary: Joint work by darcy and jfranck to provide sample code for JEP 119.
Reviewed-by: jjg
Contributed-by: joe.da...@oracle.com, joel.fra...@oracle.com

+ src/share/sample/language/model/CoreReflectionFactory.java

Re: Code review: 8010464: Evolve java networking same origin policy

[Chris Hegarty]

What you have in the latest version of this webrev look fine to me.

-Chris.

On 14/05/2013 12:54, Michael McMahon wrote:

I have updated the webrev for this at:

http://cr.openjdk.java.net/~michaelm/8010464/webrev.2/

Thanks
Michael.

Re: Code review: 8010464: Evolve java networking same origin policy

[Michael McMahon]

On 15/05/13 10:09, Chris Hegarty wrote:

What you have in the latest version of this webrev look fine to me.



Thanks Chris!

Michael


-Chris.

On 14/05/2013 12:54, Michael McMahon wrote:

I have updated the webrev for this at:

http://cr.openjdk.java.net/~michaelm/8010464/webrev.2/

Thanks
Michael.

Re: Code review: 8010464: Evolve java networking same origin policy

[Alan Bateman]

On 14/05/2013 12:54, Michael McMahon wrote:

I have updated the webrev for this at:

http://cr.openjdk.java.net/~michaelm/8010464/webrev.2/

I took a pass over the updated  webrev and it mostly looks good to me.

In HttpURLConnection then I wonder if it would be better if 
getInputStream, getOutputStream and followRedirect set the connecting 
flag rather than URLtoSocketPermission. The side effect on the protocol 
handler state is a bit surprising in this method. Alternatively then 
maybe the method needs a better name.


On MessageHeader then getHeaderNamesInList could use 
java.util.StringJoiner to avoid rolling your own.


Are you planning to add @bug to the tests?

I wonder if about dependency on SimpleSSLContext in the test as I don't 
think that test was originally intended to be a "test library".


-Alan.

Re: Code review: 8010464: Evolve java networking same origin policy

[Michael McMahon]

On 15/05/13 11:04, Alan Bateman wrote:

On 14/05/2013 12:54, Michael McMahon wrote:

I have updated the webrev for this at:

http://cr.openjdk.java.net/~michaelm/8010464/webrev.2/

I took a pass over the updated  webrev and it mostly looks good to me.

In HttpURLConnection then I wonder if it would be better if 
getInputStream, getOutputStream and followRedirect set the connecting 
flag rather than URLtoSocketPermission. The side effect on the 
protocol handler state is a bit surprising in this method. 
Alternatively then maybe the method needs a better name.




Yes, that did looks a little incongruous. So, I think moving it to 
getInputStream, getOutputStream

and connect() would make sense.

On MessageHeader then getHeaderNamesInList could use 
java.util.StringJoiner to avoid rolling your own.




I can see the benefit of using StringJoiner (and a lambda) if I am 
starting off from a Collection
and this is something that only struck me when looking at this. I was 
surprised

to see that Arrays.asList() doesn't have a variant that limits the number of
elements coming from the array. So, I can't use it here. Maybe this is 
something

we could look at again later, with the other changes we're contemplating?


Are you planning to add @bug to the tests?



Yes, will do that.

I wonder if about dependency on SimpleSSLContext in the test as I 
don't think that test was originally intended to be a "test library".




SimpleSSLContext isn't a test. All it does is provide the glue to build 
an SSLContext.

I've used it as a kind of library before.

I'll post one more webrev, and push it soon afterwards as I'd like to 
make the

code freeze today.

Thanks
Michael

Re: Code review: 8010464: Evolve java networking same origin policy

[Alan Bateman]

On 15/05/2013 11:34, Michael McMahon wrote:

:

On MessageHeader then getHeaderNamesInList could use 
java.util.StringJoiner to avoid rolling your own.




I can see the benefit of using StringJoiner (and a lambda) if I am 
starting off from a Collection
and this is something that only struck me when looking at this. I was 
surprised
to see that Arrays.asList() doesn't have a variant that limits the 
number of
elements coming from the array. So, I can't use it here. Maybe this is 
something

we could look at again later, with the other changes we're contemplating?
I think getHeaderNamesInList needs to be checked anyway as it looks to 
me that it just appends the keys and will never insert a comma.


The only reason I suggested StringJoiner here is because I thought this 
method was trying to do this:


StringJoiner joiner = new StringJoiner(",");
for (int i=0; i

I'll post one more webrev, and push it soon afterwards as I'd like to 
make the

code freeze today.

Okay.

Re: Code review: 8010464: Evolve java networking same origin policy

[Michael McMahon]

On 15/05/13 12:02, Alan Bateman wrote:

On 15/05/2013 11:34, Michael McMahon wrote:

:

On MessageHeader then getHeaderNamesInList could use 
java.util.StringJoiner to avoid rolling your own.




I can see the benefit of using StringJoiner (and a lambda) if I am 
starting off from a Collection
and this is something that only struck me when looking at this. I was 
surprised
to see that Arrays.asList() doesn't have a variant that limits the 
number of
elements coming from the array. So, I can't use it here. Maybe this 
is something

we could look at again later, with the other changes we're contemplating?
I think getHeaderNamesInList needs to be checked anyway as it looks to 
me that it just appends the keys and will never insert a comma.


The only reason I suggested StringJoiner here is because I thought 
this method was trying to do this:


StringJoiner joiner = new StringJoiner(",");
for (int i=0; i

well spotted and that's a simpler way of doing it. I messed the change 
up from the previous revision.
It's unfortunate the actual end to end HttpURLConnection tests only use 
one header in each

request. So, they didn't catch that. I'll update the test as well.

Thanks
Michael




I'll post one more webrev, and push it soon afterwards as I'd like to 
make the

code freeze today.

Okay.

Re: Code review: 8010464: Evolve java networking same origin policy

[Michael McMahon]

On 15/05/13 12:12, Michael McMahon wrote:

On 15/05/13 12:02, Alan Bateman wrote:

On 15/05/2013 11:34, Michael McMahon wrote:



...


I'll post one more webrev, and push it soon afterwards as I'd like 
to make the

code freeze today.

Okay.




updated here:

http://cr.openjdk.java.net/~michaelm/8010464/webrev.3/

Michael.

Re: RFR JDK7188517

[John Zavgren]

Greetings:

Can I get a show of hands on this RFR 
(http://cr.openjdk.java.net/~jzavgren/7188517/webrev.04/)?

It's CCC request has been accepted and I'd like to wrap it up ASAP.

Thanks!
John Zavgren

On 05/09/2013 02:22 PM, John Zavgren wrote:

Greetings:
I made a mistake in my last RFR posting... the URL for the latest modifications 
is:
http://cr.openjdk.java.net/~jzavgren/7188517/webrev.04/
instead of:
http://cr.openjdk.java.net/~jzavgren/7188517/webrev.03/

The most recent change is to reinstate the original test that tested for cookie 
names that lead with a dollar sign.

I'm sorry about the confusion.

Thanks!
John


On 05/09/2013 03:42 PM, John Zavgren wrote:

Chris, et alia:
I put the reinstated the old test.
http://cr.openjdk.java.net/~jzavgren/7188517/webrev.03/

John

- Original Message -
From: chris.hega...@oracle.com
To: john.zavg...@oracle.com
Cc: kurchi.subhra.ha...@oracle.com, net-dev@openjdk.java.net
Sent: Thursday, May 9, 2013 4:39:29 AM GMT -05:00 US/Canada Eastern
Subject: Re: RFR JDK7188517

John,

I think you can simply reinstate

http://hg.openjdk.java.net/jdk8/jdk8/jdk/diff/7bd32bfc0539/test/java/net/CookieHandler/TestHttpCookie.java

-Chris.

On 05/08/2013 09:02 PM, Kurchi Hazra wrote:

I would have thrown an exception if the IllegalArgumentException is not
obtained, otherwise the test looses its
purpose, and will pass silently if someone mistakenly removes the $
check in our code.

- Kurchi

On 5/8/2013 12:10 PM, John Zavgren wrote:

Greetings:

I added a test for the leading dollar sign character in cookie names:
http://cr.openjdk.java.net/~jzavgren/7188517/webrev.03/

Thanks!
John


On 05/08/2013 08:33 AM, Michael McMahon wrote:

On 08/05/13 09:50, Chris Hegarty wrote:

On 08/05/2013 10:35, Michael McMahon wrote:

On 07/05/13 14:43, Chris Hegarty wrote:

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.


Yes, that was a positive test for for a cookie whose name began
with '$'.
I agree we should add a negative test now for a similar cookie.

Source changes look fine to me too.

Thanks Michael,

In which case, I believe the check that a cookie the name
'$Customer' throws IAE can be re-instated in TestHttpCookie.java


Right. I didn't realise the test was able to handle the IAE. I see
now that it does and it should
be possible to put the same test back.

Michael

-Chris.


Michael


-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






--
John Zavgren
john.zavg...@oracle.com
603-821-0904
US-Burlington-MA

Re: Code review: 8010464: Evolve java networking same origin policy

[Alan Bateman]

On 15/05/2013 12:46, Michael McMahon wrote:


updated here:

http://cr.openjdk.java.net/~michaelm/8010464/webrev.3/

Michael.


This looks much better.

In HttpURLConnection then odd formatting in the declaration of 
followRedirect0 (which probably needs a better name, maybe 
implFollowRedirect?) A couple of indentation issues that probably should 
be fixed too, L980 and L2951  for example.


I don't see any other issues.

-Alan

[OFFLIST] Re: RFR JDK7188517

[Chris Hegarty]

[OFFLIST]

I believe the reviews on the open list are complete. The CCC has been 
accepted, nut it needs to be make final, then the CCC committee need to 
vote again.


I did send mail to you about making it final ( one step process ), but 
you may not have seen it.


-Chris.

On 15/05/2013 12:54, John Zavgren wrote:

Greetings:

Can I get a show of hands on this RFR
(http://cr.openjdk.java.net/~jzavgren/7188517/webrev.04/)?
It's CCC request has been accepted and I'd like to wrap it up ASAP.

Thanks!
John Zavgren

On 05/09/2013 02:22 PM, John Zavgren wrote:

Greetings:
I made a mistake in my last RFR posting... the URL for the latest
modifications is:
http://cr.openjdk.java.net/~jzavgren/7188517/webrev.04/
instead of:
http://cr.openjdk.java.net/~jzavgren/7188517/webrev.03/

The most recent change is to reinstate the original test that tested
for cookie names that lead with a dollar sign.

I'm sorry about the confusion.

Thanks!
John


On 05/09/2013 03:42 PM, John Zavgren wrote:

Chris, et alia:
I put the reinstated the old test.
http://cr.openjdk.java.net/~jzavgren/7188517/webrev.03/

John

- Original Message -
From: chris.hega...@oracle.com
To: john.zavg...@oracle.com
Cc: kurchi.subhra.ha...@oracle.com, net-dev@openjdk.java.net
Sent: Thursday, May 9, 2013 4:39:29 AM GMT -05:00 US/Canada Eastern
Subject: Re: RFR JDK7188517

John,

I think you can simply reinstate

http://hg.openjdk.java.net/jdk8/jdk8/jdk/diff/7bd32bfc0539/test/java/net/CookieHandler/TestHttpCookie.java


-Chris.

On 05/08/2013 09:02 PM, Kurchi Hazra wrote:

I would have thrown an exception if the IllegalArgumentException is not
obtained, otherwise the test looses its
purpose, and will pass silently if someone mistakenly removes the $
check in our code.

- Kurchi

On 5/8/2013 12:10 PM, John Zavgren wrote:

Greetings:

I added a test for the leading dollar sign character in cookie names:
http://cr.openjdk.java.net/~jzavgren/7188517/webrev.03/

Thanks!
John


On 05/08/2013 08:33 AM, Michael McMahon wrote:

On 08/05/13 09:50, Chris Hegarty wrote:

On 08/05/2013 10:35, Michael McMahon wrote:

On 07/05/13 14:43, Chris Hegarty wrote:

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.


Yes, that was a positive test for for a cookie whose name began
with '$'.
I agree we should add a negative test now for a similar cookie.

Source changes look fine to me too.

Thanks Michael,

In which case, I believe the check that a cookie the name
'$Customer' throws IAE can be re-instated in TestHttpCookie.java


Right. I didn't realise the test was able to handle the IAE. I see
now that it does and it should
be possible to put the same test back.

Michael

-Chris.


Michael


-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: RFR JDK7188517

[Chris Hegarty]

On 15/05/2013 13:02, Chris Hegarty wrote:


I believe the reviews on the open list are complete. The CCC has been
accepted, nut it needs to be make final, then the CCC committee need to
vote again.

I did send mail to you about making it final ( one step process ), but
you may not have seen it.


Sorry about the noise on the list, this mail was intended for John only. 
But the point still stands.


-Chris.

hg: jdk8/tl/langtools: 3 new changesets

[maurizio . cimadamore]

Changeset: 05ec778794d0
Author:mcimadamore
Date:  2013-05-15 14:00 +0100
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/05ec778794d0

8012003: Method diagnostics resolution need to be simplified in some cases
Summary: Unfold method resolution diagnostics when they mention errors in poly 
expressions
Reviewed-by: jjg, vromero

! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/Resolve.java
! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java
! src/share/classes/com/sun/tools/javac/main/Option.java
! src/share/classes/com/sun/tools/javac/resources/compiler.properties
! src/share/classes/com/sun/tools/javac/resources/javac.properties
! src/share/classes/com/sun/tools/javac/util/JCDiagnostic.java
! src/share/classes/com/sun/tools/javac/util/List.java
! src/share/classes/com/sun/tools/javac/util/Log.java
+ test/tools/javac/Diagnostics/compressed/T8012003a.java
+ test/tools/javac/Diagnostics/compressed/T8012003a.out
+ test/tools/javac/Diagnostics/compressed/T8012003b.java
+ test/tools/javac/Diagnostics/compressed/T8012003b.out
+ test/tools/javac/Diagnostics/compressed/T8012003c.java
+ test/tools/javac/Diagnostics/compressed/T8012003c.out
! test/tools/javac/diags/examples/BadArgTypesInLambda.java
+ test/tools/javac/diags/examples/CompressedDiags.java
! test/tools/javac/diags/examples/KindnameConstructor.java
+ test/tools/javac/diags/examples/ProbFoundReqFragment.java
! test/tools/javac/lambda/TargetType66.out

Changeset: 33d1937af1a3
Author:mcimadamore
Date:  2013-05-15 14:02 +0100
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/33d1937af1a3

8012685: Spurious raw types warning when using unbound method references
Summary: Spurious raw type warning when unbound method reference qualifier 
parameter types are inferred from target
Reviewed-by: jjg, vromero

! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/Check.java
+ test/tools/javac/lambda/MethodReference67.java
+ test/tools/javac/lambda/MethodReference67.out

Changeset: 78717f2d00e8
Author:mcimadamore
Date:  2013-05-15 14:03 +0100
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/78717f2d00e8

8013222: Javac issues spurious raw type warnings when lambda has implicit 
parameter types
Summary: Bad warnings and position for lambda inferred parameter types
Reviewed-by: jjg, vromero

! src/share/classes/com/sun/tools/javac/comp/Attr.java
+ test/tools/javac/lambda/NoWarnOnImplicitParams.java
+ test/tools/javac/lambda/NoWarnOnImplicitParams.out

hg: jdk8/tl/jdk: 8013730: JSR 310 DateTime API Updates III

[xueming . shen]

Changeset: ef04044f77d2
Author:sherman
Date:  2013-05-15 07:48 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ef04044f77d2

8013730: JSR 310 DateTime API Updates III
Summary: Integration of JSR310 Date/Time API update III
Reviewed-by: naoto
Contributed-by: scolebou...@joda.org, roger.ri...@oracle.com, 
masayoshi.oku...@oracle.com, patrick.zh...@oracle.com

! src/share/classes/java/time/Clock.java
! src/share/classes/java/time/DateTimeException.java
! src/share/classes/java/time/DayOfWeek.java
! src/share/classes/java/time/Duration.java
! src/share/classes/java/time/Instant.java
! src/share/classes/java/time/LocalDate.java
! src/share/classes/java/time/LocalDateTime.java
! src/share/classes/java/time/LocalTime.java
! src/share/classes/java/time/Month.java
! src/share/classes/java/time/MonthDay.java
! src/share/classes/java/time/OffsetDateTime.java
! src/share/classes/java/time/OffsetTime.java
! src/share/classes/java/time/Period.java
! src/share/classes/java/time/Ser.java
! src/share/classes/java/time/Year.java
! src/share/classes/java/time/YearMonth.java
! src/share/classes/java/time/ZoneId.java
! src/share/classes/java/time/ZoneOffset.java
! src/share/classes/java/time/ZoneRegion.java
! src/share/classes/java/time/ZonedDateTime.java
! src/share/classes/java/time/chrono/ChronoDateImpl.java
! src/share/classes/java/time/chrono/ChronoLocalDate.java
! src/share/classes/java/time/chrono/ChronoLocalDateTime.java
! src/share/classes/java/time/chrono/ChronoLocalDateTimeImpl.java
! src/share/classes/java/time/chrono/ChronoZonedDateTime.java
! src/share/classes/java/time/chrono/ChronoZonedDateTimeImpl.java
! src/share/classes/java/time/chrono/Chronology.java
! src/share/classes/java/time/chrono/Era.java
! src/share/classes/java/time/chrono/HijrahChronology.java
! src/share/classes/java/time/chrono/HijrahDate.java
! src/share/classes/java/time/chrono/HijrahEra.java
! src/share/classes/java/time/chrono/IsoChronology.java
! src/share/classes/java/time/chrono/IsoEra.java
! src/share/classes/java/time/chrono/JapaneseChronology.java
! src/share/classes/java/time/chrono/JapaneseDate.java
! src/share/classes/java/time/chrono/JapaneseEra.java
! src/share/classes/java/time/chrono/MinguoChronology.java
! src/share/classes/java/time/chrono/MinguoDate.java
! src/share/classes/java/time/chrono/MinguoEra.java
! src/share/classes/java/time/chrono/Ser.java
! src/share/classes/java/time/chrono/ThaiBuddhistChronology.java
! src/share/classes/java/time/chrono/ThaiBuddhistDate.java
! src/share/classes/java/time/chrono/ThaiBuddhistEra.java
- src/share/classes/java/time/format/DateTimeFormatSymbols.java
! src/share/classes/java/time/format/DateTimeFormatter.java
! src/share/classes/java/time/format/DateTimeFormatterBuilder.java
! src/share/classes/java/time/format/DateTimeParseContext.java
! src/share/classes/java/time/format/DateTimeParseException.java
! src/share/classes/java/time/format/DateTimePrintContext.java
! src/share/classes/java/time/format/DateTimeTextProvider.java
+ src/share/classes/java/time/format/DecimalStyle.java
! src/share/classes/java/time/format/FormatStyle.java
! src/share/classes/java/time/format/Parsed.java
! src/share/classes/java/time/format/ResolverStyle.java
! src/share/classes/java/time/format/SignStyle.java
! src/share/classes/java/time/format/TextStyle.java
! src/share/classes/java/time/format/package-info.java
! src/share/classes/java/time/temporal/ChronoField.java
! src/share/classes/java/time/temporal/ChronoUnit.java
! src/share/classes/java/time/temporal/IsoFields.java
! src/share/classes/java/time/temporal/JulianFields.java
! src/share/classes/java/time/temporal/Temporal.java
! src/share/classes/java/time/temporal/TemporalAccessor.java
! src/share/classes/java/time/temporal/TemporalAdjuster.java
! src/share/classes/java/time/temporal/TemporalAmount.java
! src/share/classes/java/time/temporal/TemporalField.java
! src/share/classes/java/time/temporal/TemporalQuery.java
! src/share/classes/java/time/temporal/TemporalUnit.java
! src/share/classes/java/time/temporal/UnsupportedTemporalTypeException.java
! src/share/classes/java/time/temporal/ValueRange.java
! src/share/classes/java/time/temporal/WeekFields.java
! src/share/classes/java/time/zone/Ser.java
! src/share/classes/java/time/zone/ZoneOffsetTransition.java
! src/share/classes/java/time/zone/ZoneOffsetTransitionRule.java
! src/share/classes/java/time/zone/ZoneRules.java
! src/share/classes/java/time/zone/ZoneRulesException.java
! src/share/classes/java/time/zone/ZoneRulesProvider.java
! src/share/classes/java/util/JapaneseImperialCalendar.java
! src/share/classes/sun/util/calendar/LocalGregorianCalendar.java
! test/java/time/tck/java/time/TCKInstant.java
! test/java/time/tck/java/time/TCKLocalTime.java
! test/java/time/tck/java/time/TCKOffsetTime.java
! test/java/time/tck/java/time/TCKYear.java
! test/java/time/tck/java/time/TCKYearMonth.java
! test/java/time/tck/java/time/TCKZoneOffset.java
! test/java/time/tck/java/time/chrono

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

[Michael McMahon]

Piotr,

We took a look at this issue again, and while it is still the case that 
to get Expect: Continue
to work properly, you need to enable one of the streaming modes. 
However, prior to jdk7
there was partial support for this mechanism, where it obeyed the 
protocol at least
when you set the Expect header. What it didn't do is delay sending the 
request body until
the 100 response is received. However, that might not have been a 
problem in many cases,
and it looks like in jdk7 this specific mode is not working exactly the 
same as before. One problem

is that a 5 second delay can be seen.

Anyhow, we will fix the problem in jdk 8 so that the exact same behavior 
as jdk 6 is seen.

I'll send a webrev with a fix soon.

Thanks
Michael

On 07/05/13 15:40, Piotr Bzdyl wrote:
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 
mailto:chris.hega...@oracle.com>> 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
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 see

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

[Michael McMahon]

This is the webrev for the bug

http://cr.openjdk.java.net/~michaelm/8012625/webrev.1/

Thanks
Michael

On 15/05/13 17:03, Michael McMahon wrote:

Piotr,

We took a look at this issue again, and while it is still the case 
that to get Expect: Continue
to work properly, you need to enable one of the streaming modes. 
However, prior to jdk7
there was partial support for this mechanism, where it obeyed the 
protocol at least
when you set the Expect header. What it didn't do is delay sending the 
request body until
the 100 response is received. However, that might not have been a 
problem in many cases,
and it looks like in jdk7 this specific mode is not working exactly 
the same as before. One problem

is that a 5 second delay can be seen.

Anyhow, we will fix the problem in jdk 8 so that the exact same 
behavior as jdk 6 is seen.

I'll send a webrev with a fix soon.

Thanks
Michael

On 07/05/13 15:40, Piotr Bzdyl wrote:
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 
mailto:chris.hega...@oracle.com>> 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
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) {

hg: jdk8/tl/jdk: 8014677: Correct docs warning for Objects.requireNonNull(T, Supplier)

[joe . darcy]

Changeset: bad8f5237f10
Author:darcy
Date:  2013-05-15 09:54 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bad8f5237f10

8014677: Correct docs warning for Objects.requireNonNull(T, Supplier)
Reviewed-by: alanb

! src/share/classes/java/util/Objects.java

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

[Chris Hegarty]

The change looks fine to me.

-Chris

On 15 May 2013, at 17:33, Michael McMahon  wrote:

> This is the webrev for the bug
> 
> http://cr.openjdk.java.net/~michaelm/8012625/webrev.1/
> 
> Thanks
> Michael
> 
> On 15/05/13 17:03, Michael McMahon wrote:
>> Piotr,
>> 
>> We took a look at this issue again, and while it is still the case that to 
>> get Expect: Continue
>> to work properly, you need to enable one of the streaming modes. However, 
>> prior to jdk7
>> there was partial support for this mechanism, where it obeyed the protocol 
>> at least
>> when you set the Expect header. What it didn't do is delay sending the 
>> request body until
>> the 100 response is received. However, that might not have been a problem in 
>> many cases,
>> and it looks like in jdk7 this specific mode is not working exactly the same 
>> as before. One problem
>> is that a 5 second delay can be seen. 
>> 
>> Anyhow, we will fix the problem in jdk 8 so that the exact same behavior as 
>> jdk 6 is seen.
>> I'll send a webrev with a fix soon.
>> 
>> Thanks
>> Michael
>> 
>> On 07/05/13 15:40, Piotr Bzdyl wrote:
>>> 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();

hg: jdk8/tl/langtools: 8006879: Detection of windows in sjavac fails.

[jonathan . gibbons]

Changeset: 445b8b5ae9f4
Author:jjg
Date:  2013-05-15 10:39 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/445b8b5ae9f4

8006879: Detection of windows in sjavac fails.
Reviewed-by: jjg
Contributed-by: erik.joels...@oracle.com

! src/share/classes/com/sun/tools/sjavac/server/CompilerThread.java

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

[Alan Bateman]

On 15/05/2013 18:09, Chris Hegarty wrote:

The change looks fine to me.

-Chris

On 15 May 2013, at 17:33, Michael McMahon 
mailto:michael.x.mcma...@oracle.com>> 
wrote:



This is the webrev for the bug

http://cr.openjdk.java.net/~michaelm/8012625/webrev.1/

Thanks
Michael

The fix looks okay to me too.

For the test then is there any reason that is has to run in othervm 
mode? Just wondering if you could shutdown the http server when done. 
Also not clear why the fields are static when they are initialized in 
the ctor. Alignment issue at L93.


-Alan.

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

[Piotr Bzdyl]

Thank you again for taking time to look at the issue. The proposed fix will
eliminate the surprise we encountered as there will be no delay when Expect
header and no streaming is used.

Best regards,
Piotr


On Wed, May 15, 2013 at 6:33 PM, Michael McMahon <
michael.x.mcma...@oracle.com> wrote:

>  This is the webrev for the bug
>
> http://cr.openjdk.java.net/~michaelm/8012625/webrev.1/
>
> Thanks
> Michael
>
>
> On 15/05/13 17:03, Michael McMahon wrote:
>
> Piotr,
>
> We took a look at this issue again, and while it is still the case that to
> get Expect: Continue
> to work properly, you need to enable one of the streaming modes. However,
> prior to jdk7
> there was partial support for this mechanism, where it obeyed the protocol
> at least
> when you set the Expect header. What it didn't do is delay sending the
> request body until
> the 100 response is received. However, that might not have been a problem
> in many cases,
> and it looks like in jdk7 this specific mode is not working exactly the
> same as before. One problem
> is that a 5 second delay can be seen.
>
> Anyhow, we will fix the problem in jdk 8 so that the exact same behavior
> as jdk 6 is seen.
> I'll send a webrev with a fix soon.
>
> Thanks
> Michael
>
> On 07/05/13 15:40, Piotr Bzdyl wrote:
>
>  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();
  }
  
>

Re: Non-standard socket options?

[Brian Call]

I just asked Neil if that option was supported for ipv6 and he said that he 
doesn't think so... Likely once adoption of ipv6 reaches critical mass and 
enough people complain, it will be added. We can only hope... 

Please let me know if I can be of any more assistance. 

-Brian 

On May 11, 2013, at 8:42 AM, Alan Bateman  wrote:

> On 10/05/2013 17:14, Brian Call wrote:
>> 
>> Thanks for your help guys!
>> 
>> It would be most excellent to have that socket option turned off by default. 
>> It would certainly make multicast receivers written in java behave the same 
>> way across all the major platforms. Not sure why this wasn't considered a 
>> bug in Linux and, in fact, it's vehemently defended as absolutely adhering 
>> to the multicast spec.
>> 
> There is a long history there.
> 
> One thing that isn't clear about IP_MULTICAST_ALL is whether there is an 
> equivalent for IPv6, that might need more investigation.
> 
> -Alan
> 

Blessings,

Brian Call
brian.c...@soterawireless.com

PRIVILEGED AND CONFIDENTIAL COMMUNICATION: This electronic transmission, and 
any documents attached hereto, may contain confidential and/or legally 
privileged information.  The information is intended only for use by the 
recipient named above. If you have received this electronic message in error, 
please notify the sender and delete the electronic message. Any disclosure, 
copying, distribution, or use of the contents of information received in error 
is strictly prohibited.

Code Review Request: 7150552: network test hangs [macosx]

[Kurchi Hazra]

Hi,

Two regression tests in jdk/test were hanging on Mac OS X 
intermittently. Although it is difficult to reproduce
the problem, I suspect it is the use of the buggy httpserver test 
library (jdk/test/sun/net/www/httptest) - we anyway want
to move away from using it. I have re-written parts of these tests to 
use com.sun.net.httpserver instead.


I have also unleashed the tests from the ProblemList and will keep a 
closer watch on test runs.


Bug: http://bugs.sun.com/view_bug.do?bug_id=7150552
Webrev: http://cr.openjdk.java.net/~khazra/7150552/webrev.00/


Thanks!
Kurchi

hg: jdk8/tl/jdk: 5 new changesets

[valerie . peng]

Changeset: 2ec31660cc0e
Author:valeriep
Date:  2013-05-07 14:04 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2ec31660cc0e

8010134: A finalizer in sun.security.pkcs11.wrapper.PKCS11 perhaps should be 
protected
Summary: Change the finalize method of PKCS11 class to be protected.
Reviewed-by: xuelei

! src/share/classes/sun/security/pkcs11/wrapper/PKCS11.java

Changeset: 991420add35d
Author:valeriep
Date:  2013-05-07 14:06 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/991420add35d

7196009: SunPkcs11 provider fails to parse config path containing parenthesis
Summary: Enhanced to allow quoted string as library path values.
Reviewed-by: weijun

! src/share/classes/sun/security/pkcs11/Config.java
! test/sun/security/pkcs11/Provider/ConfigShortPath.java
+ test/sun/security/pkcs11/Provider/cspQuotedPath.cfg

Changeset: 804da1e9bd04
Author:ascarpino
Date:  2013-05-07 14:13 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/804da1e9bd04

8001284: Buffer problems with SunPKCS11-Solaris and CKM_AES_CTR
Summary: Changed output length calculation to include incomplete blocks for CTR 
mode.
Reviewed-by: valeriep

! src/share/classes/sun/security/pkcs11/P11Cipher.java
! test/sun/security/pkcs11/Cipher/TestSymmCiphersNoPad.java

Changeset: fc70416beef3
Author:valeriep
Date:  2013-05-13 16:52 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fc70416beef3

Merge

- make/com/sun/script/Makefile
- make/sun/org/Makefile
- make/sun/org/mozilla/Makefile
- make/sun/org/mozilla/javascript/Makefile
- src/share/classes/com/sun/script/javascript/ExternalScriptable.java
- src/share/classes/com/sun/script/javascript/JSAdapter.java
- src/share/classes/com/sun/script/javascript/JavaAdapter.java
- 
src/share/classes/com/sun/script/javascript/META-INF/services/javax.script.ScriptEngineFactory
- src/share/classes/com/sun/script/javascript/RhinoClassShutter.java
- src/share/classes/com/sun/script/javascript/RhinoCompiledScript.java
- src/share/classes/com/sun/script/javascript/RhinoScriptEngine.java
- src/share/classes/com/sun/script/javascript/RhinoScriptEngineFactory.java
- src/share/classes/com/sun/script/javascript/RhinoTopLevel.java
- src/share/classes/com/sun/script/javascript/RhinoWrapFactory.java
- src/share/classes/com/sun/script/util/BindingsBase.java
- src/share/classes/com/sun/script/util/BindingsEntrySet.java
- src/share/classes/com/sun/script/util/BindingsImpl.java
- src/share/classes/com/sun/script/util/InterfaceImplementor.java
- src/share/classes/com/sun/script/util/ScriptEngineFactoryBase.java
- src/share/classes/java/beans/ReflectionUtils.java
- 
test/java/awt/Focus/OverrideRedirectWindowActivationTest/OverrideRedirectWindowActivationTest.java
- test/sun/security/provider/certpath/X509CertPath/ForwardBuildCompromised.java
- test/sun/security/provider/certpath/X509CertPath/ReverseBuildCompromised.java
- test/sun/security/provider/certpath/X509CertPath/ValidateCompromised.java

Changeset: 59357ea7f131
Author:valeriep
Date:  2013-05-15 18:38 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/59357ea7f131

Merge

- src/share/classes/java/time/format/DateTimeFormatSymbols.java
- 
src/share/classes/sun/nio/cs/ext/META-INF/services/java.nio.charset.spi.CharsetProvider
- test/java/time/tck/java/time/format/TCKDateTimeFormatSymbols.java
- test/java/time/test/java/time/format/TestDateTimeFormatSymbols.java