hg: jdk8/tl/jdk: 8021429: Fix lint warnings in java.lang.ref

[joe . darcy]

Changeset: 86a827321c39
Author:darcy
Date:  2013-07-25 20:03 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/86a827321c39

8021429: Fix lint warnings in java.lang.ref
Reviewed-by: lancea, mduigou, alanb

! src/share/classes/java/lang/ref/FinalReference.java
! src/share/classes/java/lang/ref/Finalizer.java
! src/share/classes/java/lang/ref/Reference.java
! src/share/classes/java/lang/ref/ReferenceQueue.java

hg: jdk8/tl/jdk: 2 new changesets

[sean . mullan]

Changeset: 1744a32d3db3
Author:mullan
Date:  2013-07-25 20:12 -0400
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1744a32d3db3

8012288: XML DSig API allows wrong tag names and extra elements in SignedInfo
Reviewed-by: xuelei

! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMKeyValue.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMManifest.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMReference.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMRetrievalMethod.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMSignatureProperties.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMSignedInfo.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMUtils.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMX509IssuerSerial.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMXMLSignature.java

Changeset: 4100ab44ba4f
Author:mullan
Date:  2013-07-25 20:30 -0400
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4100ab44ba4f

Merge

Re: code review request: 8012971 PKCS11Test hiding exception failures

[Valerie (Yu-Ching) Peng]

Looks good~
Thanks,
Valerie

On 07/25/13 15:17, Anthony Scarpino wrote:

On 07/24/2013 06:37 PM, Valerie (Yu-Ching) Peng wrote:

On 07/24/13 13:53, Anthony Scarpino wrote:

On 07/23/2013 06:00 PM, Valerie (Yu-Ching) Peng wrote:




263 System.arraycopy(data, 900, data, 0, 100);
264 is.read(data, 0,  900);

Do you really mean to overwrite the data[0..99] that you just 
copied on

line 263 with line 264?



Good catch.. I would have thought all my testing would have tripped me
up on this, but it appears it didn't.

In addition, don't you want to know how much is read in order to 
exclude
the data from earlier read(...) calls in case that the current read 
only

returns a few bytes?


Yeah, the end of the file read is a bit sloppy, even though it should
never see the end of the file as all the nss libraries have the header
in it.


Hmm, I think the String object should be constructed w/ the bytes that's
just read, i.e. new String(data, 0, read)

  256 s = new String(data);

And line 272 should be update to "read = 100 + is.read(data, 100, 900);"
Also, the value of variable s is only set once on line 256 and yet the
content of 'data' may change on line 271-272. This may lead to
inconsistency between 's' and 'data' if the while-loop (line 255) is
exited due to read <= 0 on line 272.


I wasn't overly concerned about what happens at the end of the file 
because it shouldn't get to that point.  There should always be a 
header and if one was not found, the check has for the most part failed.
'data' is not used outside the loop, so any inconsistency with the 
String isn't a problem.


That being said, I'm fine with changing it.  I couldn't add 100 to the 
read because the while-loop looks for read to equal 0, and the 
inconsistency on the read length made the original code troublesome, 
so I rewrote it and I think it looks cleaner now.


http://cr.openjdk.java.net/~ascarpino/8020424/webrev.02/



After seeing all these checks and list of known bugs for testing 
against

NSS, I think we probably need a README or some wiki page to keep track
all this...


I can throw a readme in the directory with the bug IDs and even my
theory that the DER is 480280.


I didn't find the NSS pre-3.12 check in TestECDH.java?


Yeah, that one has a different check.  I'll remove it from that comment.


Thanks,
Valerie


webrev updated at:
http://cr.openjdk.java.net/~ascarpino/8020424/webrev.01/


Thanks,
Valerie

On 07/17/13 13:51, Anthony Scarpino wrote:

JDK-8020424 The NSS version should be detected before running crypto
tests
http://cr.openjdk.java.net/~ascarpino/8020424/webrev.00/

Tony

Re: [8] Request for review: 8001319: Add SecurityPermission "insertProvider" target name

[Sean Mullan]

On 07/25/2013 05:08 PM, Sean Mullan wrote:

Hello,

Could you please review my fix for 8001319:

webrev: http://cr.openjdk.java.net/~mullan/webrevs/8012288/webrev.00/


Correction above

webrev: http://cr.openjdk.java.net/~mullan/webrevs/8001319/webrev.00/


bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8001319

In this fix, we are adding a new SecurityPermission "insertProvider"
target name for adding new security providers, and discouraging use of
the existing "insertProvider.{provider name}" target name. Please read
the bug report for more information.

Thanks,
Sean

Re: TLS extension needed for HTTP/2.0

[Xuelei Fan]

On 7/24/2013 6:41 AM, Zhong Yu wrote:

Hi there,

HTTP/2.0 draft (based on google's SPDY) requires the use of a new TLS
extension (ALPN), see
http://tools.ietf.org/html/draft-ietf-httpbis-http2-04#section-3.3

The current javax.net.ssl API does not support that, so it'll be a
problem for someone trying to implement the HTTP/2.0 draft on Java
platform. Is there a remedy to that?

Both HTTP 2.0 and ALPN extension are in early stage.  Java does not 
support ALPN at present.  But for a none-product environment, it is 
doable with a few update to OpenJDK by making use of the handshaking 
session.



If javax.net.ssl needs further development to be able to support ALPN,
would you give a rough estimate on when it could be released? And
would it be back ported to earlier versions of Java?

Looks like, to support ALPN, javax.net.ssl needs to design new APIs.  As 
make it hard to backport to earlier releases of Java.


Marketing and customer requirements are important factors when we design 
new features.



What kind of API change do you envision that's necessary to expose
ALPN negotiation process to applications?

I have no think about this too much. Probably, we might only need pulic 
APIs to expose the ALPN in handshaking session (SSLSession), and an 
handler to accept or reject the request (or have TrustManager do it 
instead).


   SSLSocket.getHandshakeSession()
   ExtendedSSLSession.getAppProtocols()


Note that HTTP/2.0 is in very early stage; it's possible that the
requirement of ALPN could be relaxed if there's difficulty to
implement it on popular platforms; see this thread:
http://lists.w3.org/Archives/Public/ietf-http-wg/2013JulSep/0425.html

I have not read this thread.  Is there any one suggest to use START TLS 
as an alternative solution?


Xuelei


Thank you very much,
Zhong Yu

Re: Code Review Request:8019544: Need to run ProviderTest.java in othervm mode

[Xuelei Fan]

Looks fine to me.  Thanks!

Xuelei

On 7/26/2013 6:17 AM, Rajan Halade wrote:

Could you please review the small fix for 8019544:

http://cr.openjdk.java.net/~juh/rajan/8019544/webrev.00/


This is a test only fix for test stabilization.

--
 Rajan Halade, CISSP | Senior Member of Technical
Staff
Phone: +1 4082763359 
Oracle JAVA Platform Group
4220 Network Circle, Bldg 22, #2155 | Santa Clara, CA 94538
 Oracle is committed to developing
practices and products that help protect the environment

Re: [8] Request for review: 8012288: XML DSig API allows wrong tag names and extra elements in SignedInfo

[Xuelei Fan]

On 7/26/2013 3:28 AM, Sean Mullan wrote:

On 07/24/2013 10:16 AM, Xuelei Fan wrote:

DOMUtils.java
=
It might be a little bit better to reuse the node local name checking
with a new private static method.


Good suggestion.


Otherwise, looks fine.

A minor comment is a very personal preference. I may prefer to return
null instead of throw exception in the new methods of class DOMUtils,
when there is no such node. And the caller throw the exception instead.
For example:
 public static Element getFirstChildElement(Node node,
 String localName) throws MarshalException


I considered that, but most of the time null is an exception, so it's
more concise to have the method handle this case, than the other way
around.


ok.


I have updated the webrev:
http://cr.openjdk.java.net/~mullan/webrevs/8012288/webrev.01/

Can you take a quick look at DOMUtils to see if it looks ok?


Looks fine to me.

Xuelei


Thanks,
Sean




Xuelei

On 7/23/2013 9:05 PM, Sean Mullan wrote:

Xuelei,

Could you please review my fix for 8012288:

   http://cr.openjdk.java.net/~mullan/webrevs/8012288/webrev.00/

There is already an SQE test for this, so I have added the noreg-sqe
label.

Thanks,
Sean

Re: Code Review Request:8019544: Need to run ProviderTest.java in othervm mode

[Brad Wetmore]

Looks good.

brad



On 7/25/2013 3:17 PM, Rajan Halade wrote:

Could you please review the small fix for 8019544:

http://cr.openjdk.java.net/~juh/rajan/8019544/webrev.00/


This is a test only fix for test stabilization.

--
 Rajan Halade, CISSP | Senior Member of Technical
Staff
Phone: +1 4082763359 
Oracle JAVA Platform Group
4220 Network Circle, Bldg 22, #2155 | Santa Clara, CA 94538
 Oracle is committed to developing
practices and products that help protect the environment

Code Review Request:8019544: Need to run ProviderTest.java in othervm mode

[Rajan Halade]

Could you please review the small fix for 8019544:

http://cr.openjdk.java.net/~juh/rajan/8019544/webrev.00/ 



This is a test only fix for test stabilization.

--
 Rajan Halade, CISSP | Senior Member of Technical 
Staff

Phone: +1 4082763359 
Oracle JAVA Platform Group
4220 Network Circle, Bldg 22, #2155 | Santa Clara, CA 94538
 Oracle is committed to developing 
practices and products that help protect the environment

Re: code review request: 8012971 PKCS11Test hiding exception failures

[Anthony Scarpino]

On 07/24/2013 06:37 PM, Valerie (Yu-Ching) Peng wrote:

On 07/24/13 13:53, Anthony Scarpino wrote:

On 07/23/2013 06:00 PM, Valerie (Yu-Ching) Peng wrote:




263 System.arraycopy(data, 900, data, 0, 100);
264 is.read(data, 0,  900);

Do you really mean to overwrite the data[0..99] that you just copied on
line 263 with line 264?



Good catch.. I would have thought all my testing would have tripped me
up on this, but it appears it didn't.


In addition, don't you want to know how much is read in order to exclude
the data from earlier read(...) calls in case that the current read only
returns a few bytes?


Yeah, the end of the file read is a bit sloppy, even though it should
never see the end of the file as all the nss libraries have the header
in it.


Hmm, I think the String object should be constructed w/ the bytes that's
just read, i.e. new String(data, 0, read)

  256 s = new String(data);

And line 272 should be update to "read = 100 + is.read(data, 100, 900);"
Also, the value of variable s is only set once on line 256 and yet the
content of 'data' may change on line 271-272. This may lead to
inconsistency between 's' and 'data' if the while-loop (line 255) is
exited due to read <= 0 on line 272.


I wasn't overly concerned about what happens at the end of the file 
because it shouldn't get to that point.  There should always be a header 
and if one was not found, the check has for the most part failed.
'data' is not used outside the loop, so any inconsistency with the 
String isn't a problem.


That being said, I'm fine with changing it.  I couldn't add 100 to the 
read because the while-loop looks for read to equal 0, and the 
inconsistency on the read length made the original code troublesome, so 
I rewrote it and I think it looks cleaner now.


http://cr.openjdk.java.net/~ascarpino/8020424/webrev.02/



After seeing all these checks and list of known bugs for testing against
NSS, I think we probably need a README or some wiki page to keep track
all this...


I can throw a readme in the directory with the bug IDs and even my
theory that the DER is 480280.


I didn't find the NSS pre-3.12 check in TestECDH.java?


Yeah, that one has a different check.  I'll remove it from that comment.


Thanks,
Valerie


webrev updated at:
http://cr.openjdk.java.net/~ascarpino/8020424/webrev.01/


Thanks,
Valerie

On 07/17/13 13:51, Anthony Scarpino wrote:

JDK-8020424 The NSS version should be detected before running crypto
tests
http://cr.openjdk.java.net/~ascarpino/8020424/webrev.00/

Tony

[8] Request for review: 8001319: Add SecurityPermission "insertProvider" target name

[Sean Mullan]

Hello,

Could you please review my fix for 8001319:

webrev: http://cr.openjdk.java.net/~mullan/webrevs/8012288/webrev.00/
bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8001319

In this fix, we are adding a new SecurityPermission "insertProvider" 
target name for adding new security providers, and discouraging use of 
the existing "insertProvider.{provider name}" target name. Please read 
the bug report for more information.


Thanks,
Sean

Re: TLS extension needed for HTTP/2.0

[Bernd Eckenfels]

Hello,

no direct response, but just a pointer: there is a third party Project by  
Ben Murphy which brings NPN to JSSE. I guess the same codebase can be used  
to add ALPN. This will allow to do experiments.


https://github.com/benmmurphy/ssl_npn

It is btw very unfortunate that there is no clear SPI for SSLSocket and  
the java package namespace makes it necesary to actually touch all classes  
to get them compiled in parallel to a normal JDK.


Gruss
Bernd

Am 25.07.2013, 16:15 Uhr, schrieb Zhong Yu :


Hi, can someone shed some light on the questions? Any information will
be greatly appreciated. Thanks,
Zhong Yu

On Tue, Jul 23, 2013 at 5:41 PM, Zhong Yu  wrote:

Hi there,

HTTP/2.0 draft (based on google's SPDY) requires the use of a new TLS
extension (ALPN), see
http://tools.ietf.org/html/draft-ietf-httpbis-http2-04#section-3.3

The current javax.net.ssl API does not support that, so it'll be a
problem for someone trying to implement the HTTP/2.0 draft on Java
platform. Is there a remedy to that?

If javax.net.ssl needs further development to be able to support ALPN,
would you give a rough estimate on when it could be released? And
would it be back ported to earlier versions of Java?

What kind of API change do you envision that's necessary to expose
ALPN negotiation process to applications?

Note that HTTP/2.0 is in very early stage; it's possible that the
requirement of ALPN could be relaxed if there's difficulty to
implement it on popular platforms; see this thread:
http://lists.w3.org/Archives/Public/ietf-http-wg/2013JulSep/0425.html

Thank you very much,
Zhong Yu



--
http://bernd.eckenfels.net

hg: jdk8/tl/jdk: 8021148: Regression in SAXParserImpl in 7u40 b34 (NPE)

[huizhe . wang]

Changeset: 662ec7782102
Author:joehw
Date:  2013-07-25 13:20 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/662ec7782102

8021148: Regression in SAXParserImpl in 7u40 b34 (NPE)
Reviewed-by: chegar, lancea, dfuchs

+ test/javax/xml/jaxp/parsers/8021148/JAXPSAXParserTest.java
+ test/javax/xml/jaxp/parsers/8021148/TestBase.java

hg: jdk8/tl/jaxp: 8021148: Regression in SAXParserImpl in 7u40 b34 (NPE)

[huizhe . wang]

Changeset: 251ca1e2ccd3
Author:joehw
Date:  2013-07-25 13:02 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/251ca1e2ccd3

8021148: Regression in SAXParserImpl in 7u40 b34 (NPE)
Reviewed-by: chegar, lancea, dfuchs

! src/com/sun/org/apache/xerces/internal/jaxp/SAXParserImpl.java

Re: [8] Request for review: 8012288: XML DSig API allows wrong tag names and extra elements in SignedInfo

[Sean Mullan]

On 07/24/2013 10:16 AM, Xuelei Fan wrote:

DOMUtils.java
=
It might be a little bit better to reuse the node local name checking
with a new private static method.


Good suggestion.


Otherwise, looks fine.

A minor comment is a very personal preference. I may prefer to return
null instead of throw exception in the new methods of class DOMUtils,
when there is no such node. And the caller throw the exception instead.
For example:
 public static Element getFirstChildElement(Node node,
 String localName) throws MarshalException


I considered that, but most of the time null is an exception, so it's 
more concise to have the method handle this case, than the other way around.


I have updated the webrev: 
http://cr.openjdk.java.net/~mullan/webrevs/8012288/webrev.01/


Can you take a quick look at DOMUtils to see if it looks ok?

Thanks,
Sean




Xuelei

On 7/23/2013 9:05 PM, Sean Mullan wrote:

Xuelei,

Could you please review my fix for 8012288:

   http://cr.openjdk.java.net/~mullan/webrevs/8012288/webrev.00/

There is already an SQE test for this, so I have added the noreg-sqe
label.

Thanks,
Sean

hg: jdk8/tl/langtools: 8007961: javax.lang.model tests for repeating annotations fail in getAnnotationsByType

[joel . franck]

Changeset: a218f7befd55
Author:jfranck
Date:  2013-07-25 11:02 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/a218f7befd55

8007961: javax.lang.model tests for repeating annotations fail in 
getAnnotationsByType
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Symbol.java
! src/share/classes/com/sun/tools/javac/model/JavacAnnoConstructs.java
! 
test/tools/javac/processing/model/element/repeatingAnnotations/MixRepeatableAndOfficialContainerInheritedA1Test.java
! 
test/tools/javac/processing/model/element/repeatingAnnotations/MixRepeatableAndOfficialContainerInheritedB1Test.java
! 
test/tools/javac/processing/model/element/repeatingAnnotations/MixRepeatableAndOfficialContainerInheritedB2Test.java
! 
test/tools/javac/processing/model/element/repeatingAnnotations/RepeatableOverrideATest.java
! 
test/tools/javac/processing/model/element/repeatingAnnotations/RepeatableOverrideBTest.java
+ test/tools/javac/processing/model/inheritedByType/EnsureOrder.java

hg: jdk8/tl/jdk: 8021421: More doclint fixes in java.net

[chris . hegarty]

Changeset: 9cd5159fa870
Author:chegar
Date:  2013-07-25 19:45 +0100
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9cd5159fa870

8021421: More doclint fixes in java.net
Reviewed-by: lancea, darcy

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

hg: jdk8/tl/jdk: 8021417: Fix doclint issues in java.util.concurrent

[chris . hegarty]

Changeset: 690dcbaa69b7
Author:chegar
Date:  2013-07-25 19:37 +0100
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/690dcbaa69b7

8021417: Fix doclint issues in java.util.concurrent
Reviewed-by: chegar, lancea
Contributed-by: Doug Lea 

! src/share/classes/java/util/concurrent/AbstractExecutorService.java
! src/share/classes/java/util/concurrent/ExecutorService.java
! src/share/classes/java/util/concurrent/Executors.java
! src/share/classes/java/util/concurrent/ForkJoinPool.java
! src/share/classes/java/util/concurrent/ForkJoinTask.java
! src/share/classes/java/util/concurrent/ScheduledExecutorService.java
! src/share/classes/java/util/concurrent/ScheduledThreadPoolExecutor.java
! src/share/classes/java/util/concurrent/TimeUnit.java
! src/share/classes/java/util/concurrent/atomic/AtomicIntegerFieldUpdater.java
! src/share/classes/java/util/concurrent/atomic/AtomicLongFieldUpdater.java
! src/share/classes/java/util/concurrent/atomic/AtomicReferenceFieldUpdater.java

hg: jdk8/tl/jdk: 8021408: Fix misc doclint issues in java.util and java.io

[joe . darcy]

Changeset: 21120e3682ef
Author:darcy
Date:  2013-07-25 09:59 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/21120e3682ef

8021408: Fix misc doclint issues in java.util and java.io
Reviewed-by: dholmes, chegar, psandoz

! src/share/classes/java/io/ObjectInputStream.java
! src/share/classes/java/io/ObjectOutputStream.java
! src/share/classes/java/util/jar/Attributes.java
! src/share/classes/java/util/jar/JarEntry.java
! src/share/classes/java/util/jar/JarFile.java
! src/share/classes/java/util/stream/StreamSupport.java

hg: jdk8/tl/jdk: 2 new changesets

[sean . mullan]

Changeset: a834ab2c1354
Author:mullan
Date:  2013-07-25 10:58 -0400
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a834ab2c1354

8010748: Add PKIXRevocationChecker NO_FALLBACK option and improve SOFT_FAIL 
option
Reviewed-by: vinnie

! src/share/classes/java/security/cert/PKIXRevocationChecker.java
! src/share/classes/sun/security/provider/certpath/OCSP.java
! src/share/classes/sun/security/provider/certpath/OCSPResponse.java
! src/share/classes/sun/security/provider/certpath/PKIXCertPathValidator.java
! src/share/classes/sun/security/provider/certpath/ReverseState.java
! src/share/classes/sun/security/provider/certpath/RevocationChecker.java
! src/share/classes/sun/security/provider/certpath/SunCertPathBuilder.java
! test/java/security/cert/PKIXRevocationChecker/UnitTest.java

Changeset: 22a391706a0b
Author:mullan
Date:  2013-07-25 11:09 -0400
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/22a391706a0b

Merge

- make/sun/xawt/ToBin.java
- makefiles/sun/awt/X11/ToBin.java
- 
src/share/classes/com/sun/org/apache/xml/internal/security/resource/log4j.properties
- 
src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/FuncHereContext.java
- 
src/share/classes/com/sun/org/apache/xml/internal/security/utils/CachedXPathAPIHolder.java
- 
src/share/classes/com/sun/org/apache/xml/internal/security/utils/CachedXPathFuncHereAPI.java
- 
src/share/classes/com/sun/org/apache/xml/internal/security/utils/XPathFuncHereAPI.java
- src/share/classes/java/security/acl/package.html
- src/share/classes/java/security/cert/package.html
- src/share/classes/java/security/interfaces/package.html
- src/share/classes/java/security/package.html
- src/share/classes/java/security/spec/package.html
- src/share/classes/java/util/stream/StreamBuilder.java
- src/share/classes/javax/security/auth/callback/package.html
- src/share/classes/javax/security/auth/kerberos/package.html
- src/share/classes/javax/security/auth/login/package.html
- src/share/classes/javax/security/auth/package.html
- src/share/classes/javax/security/auth/spi/package.html
- src/share/classes/javax/security/auth/x500/package.html
- src/share/classes/javax/security/cert/package.html
- src/share/classes/javax/security/sasl/package.html
- src/share/classes/sun/misc/Hashing.java
- src/share/classes/sun/security/krb5/internal/rcache/CacheTable.java
- src/share/classes/sun/security/krb5/internal/rcache/ReplayCache.java
! src/share/classes/sun/security/provider/certpath/RevocationChecker.java
- src/solaris/classes/sun/awt/X11/XIconInfo.java
- src/solaris/classes/sun/awt/X11/security-icon-bw16.png
- src/solaris/classes/sun/awt/X11/security-icon-bw24.png
- src/solaris/classes/sun/awt/X11/security-icon-bw32.png
- src/solaris/classes/sun/awt/X11/security-icon-bw48.png
- src/solaris/classes/sun/awt/X11/security-icon-interim16.png
- src/solaris/classes/sun/awt/X11/security-icon-interim24.png
- src/solaris/classes/sun/awt/X11/security-icon-interim32.png
- src/solaris/classes/sun/awt/X11/security-icon-interim48.png
- src/solaris/classes/sun/awt/X11/security-icon-yellow16.png
- src/solaris/classes/sun/awt/X11/security-icon-yellow24.png
- src/solaris/classes/sun/awt/X11/security-icon-yellow32.png
- src/solaris/classes/sun/awt/X11/security-icon-yellow48.png
- src/solaris/classes/sun/awt/fontconfigs/linux.fontconfig.Fedora.properties
- src/solaris/classes/sun/awt/fontconfigs/linux.fontconfig.SuSE.properties
- src/solaris/classes/sun/awt/fontconfigs/linux.fontconfig.Ubuntu.properties
- src/solaris/classes/sun/awt/fontconfigs/linux.fontconfig.properties
- test/java/lang/invoke/7196190/MHProxyTest.java
- test/java/util/Collections/EmptySortedSet.java
- test/java/util/Comparators/BasicTest.java
- test/sun/misc/Hashing.java
- test/sun/security/krb5/auto/ReplayCache.java

hg: jdk8/tl/nashorn: 3 new changesets

[sundararajan . athijegannathan]

Changeset: 5c035c4ccc61
Author:sundar
Date:  2013-07-25 14:05 +0530
URL:   http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/5c035c4ccc61

8021252: invokeMethod throws NoSuchMethodException when script object is from 
different script context
Reviewed-by: lagergren, hannesw

! src/jdk/nashorn/api/scripting/NashornScriptEngine.java
! src/jdk/nashorn/api/scripting/ScriptObjectMirror.java
! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java

Changeset: f74faac51bfb
Author:hannesw
Date:  2013-07-25 11:56 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/f74faac51bfb

8021244: Inconsistent stackmap with splitter threshold set very low
Reviewed-by: sundar, lagergren

! src/jdk/nashorn/internal/codegen/Lower.java
! src/jdk/nashorn/internal/ir/Block.java

Changeset: f22ca0f9b6ee
Author:sundar
Date:  2013-07-25 20:10 +0530
URL:   http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/f22ca0f9b6ee

8021361: ClassCastException:.ScriptObjectMirror -> ScriptObject when 
getInterface called on object from different ScriptContext
Reviewed-by: jlaskey, attila

! src/jdk/nashorn/api/scripting/NashornScriptEngine.java
! src/jdk/nashorn/api/scripting/ScriptObjectMirror.java
+ src/jdk/nashorn/api/scripting/resources/Messages.properties
! src/jdk/nashorn/internal/runtime/ScriptObject.java
! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java

Re: TLS extension needed for HTTP/2.0

[Zhong Yu]

Hi, can someone shed some light on the questions? Any information will
be greatly appreciated. Thanks,
Zhong Yu

On Tue, Jul 23, 2013 at 5:41 PM, Zhong Yu  wrote:
> Hi there,
>
> HTTP/2.0 draft (based on google's SPDY) requires the use of a new TLS
> extension (ALPN), see
> http://tools.ietf.org/html/draft-ietf-httpbis-http2-04#section-3.3
>
> The current javax.net.ssl API does not support that, so it'll be a
> problem for someone trying to implement the HTTP/2.0 draft on Java
> platform. Is there a remedy to that?
>
> If javax.net.ssl needs further development to be able to support ALPN,
> would you give a rough estimate on when it could be released? And
> would it be back ported to earlier versions of Java?
>
> What kind of API change do you envision that's necessary to expose
> ALPN negotiation process to applications?
>
> Note that HTTP/2.0 is in very early stage; it's possible that the
> requirement of ALPN could be relaxed if there's difficulty to
> implement it on popular platforms; see this thread:
> http://lists.w3.org/Archives/Public/ietf-http-wg/2013JulSep/0425.html
>
> Thank you very much,
> Zhong Yu

hg: jdk8/tl/langtools: 3 new changesets

[maurizio . cimadamore]

Changeset: 3155e77d2676
Author:mcimadamore
Date:  2013-07-25 14:47 +0100
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/3155e77d2676

8020804: javac crashes when speculative attribution infers intersection type 
with array component
Summary: Assertion is causing javac to crash because of lack of support for 
arrays in intersection types
Reviewed-by: jjg

! 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/Infer.java
+ test/tools/javac/lambda/8020804/T8020804.java

Changeset: b02f28bf7f1c
Author:mcimadamore
Date:  2013-07-25 14:49 +0100
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/b02f28bf7f1c

8016081: field initialized with lambda in annotation types doesn't compile
Summary: check for annotation attributes should skip over synthetic methods
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/Check.java
+ test/tools/javac/lambda/8016081/T8016081.java

Changeset: dae52d74c1fc
Author:mcimadamore
Date:  2013-07-25 14:51 +0100
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/dae52d74c1fc

8020843: javac crashes on accessibility check with method reference with 
typevar receiver
Summary: method reference overload check doesn't walk through type-variable 
receivers
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/Resolve.java
! src/share/classes/com/sun/tools/javac/resources/compiler.properties
+ test/tools/javac/diags/examples/ReportAccessFragment.java
+ test/tools/javac/lambda/8020843/T8020843a.java
+ test/tools/javac/lambda/8020843/T8020843a.out
+ test/tools/javac/lambda/8020843/T8020843b.java
+ test/tools/javac/lambda/8020843/T8020843b.out
! test/tools/javac/lambda/MethodReference28.out

Code review request, 8013809 deadlock in SSLSocketImpl between between write and close

[Xuelei Fan]

Hi Brad,

Are you available to review this fix?

Webrev: http://cr.openjdk.java.net/~xuelei/8013809/webrev.00/

No new regression test, hard to reproduce the issue.

Thanks,
Xuelei