August 2011 - core-libs-dev

Request for review: 7084245: Update usages of InternalError to use exception chaining
by Sebastian Sickelmann 30 Aug '11

30 Aug '11

Hi, here is a webrev[1] for some cleanup that i want to integrated in tl-repositories. Alan Bateman had scanned the changes and gave me some good input[3] for further discussion here: The changes to java.util.concurrent should go through Doug Lea's upstream CVS. Alan told me that Chris Hegarty is on this topic already. The suggested changes for this is here[2]. I have changed some classes in awt / sun.java2d maybe someone of the 2d-dev maillinglist can look at these changes. I also changed some classes in java/securtiy maybe someone of security-dev maillinglist can look at these changes. Let me know if there is a need to split/rebase the main-webrev[1] to review and/or push it individually. Mostly the patch changes exception-chains. But there are some places where the patch changes behavoir: - I removed some printstackTraces in sun.java2d.pipe.LoopPipe.getStrokesSpans and sun.misc.Launcher (Alan told me that kumar maybe want to have a look at it?). - I changed java.text.Format.clone not to return null. I think it will never happen. But if so throwing an InternalError seems to be better than returning null and let all the extended classes crash in there clone Method with a NullPointerException. And so catching an Exception in java.text.DecimalFormat.clone is unnecessary. -- Sebastian [1] http://oss-patches.24.eu/openjdk8/InternalError/part2/7084245_main_0/ [2] http://oss-patches.24.eu/openjdk8/InternalError/part2/7084245_concurrent_0/ [3] http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-August/007563.html

5 9

hg: jdk8/tl/jdk: 2 new changesets
by michael.x.mcmahon＠oracle.com 30 Aug '11

30 Aug '11

Changeset: fe205518c3a7 Author: michaelm Date: 2011-08-30 14:40 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fe205518c3a7 7084560: Crash in net.dll Reviewed-by: chegar Contributed-by: luchsh(a)linux.vnet.ibm.com ! src/windows/native/java/net/NetworkInterface.c ! src/windows/native/java/net/NetworkInterface_winXP.c Changeset: ef4f24534a96 Author: michaelm Date: 2011-08-30 14:41 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ef4f24534a96 Merge

1 0

Re: [OpenJDK 2D-Dev] Request for review: 7084245: Update usages of InternalError to use exception chaining
by Sebastian Sickelmann 30 Aug '11

30 Aug '11

Am 28.08.2011 22:54, schrieb Mario Torre: > Il giorno dom, 28/08/2011 alle 21.35 +0200, Sebastian Sickelmann ha > scritto: >> Hi, here is a webrev[1] for some cleanup that i want to integrated in >> tl-repositories. > Hi, Hi created a new webrev with your suggested changes at: http://oss-patches.24.eu/openjdk8/InternalError/part2/7084245_main_1/ I have created some comments inline in this mail. > The patch seems good for me (speaking in particular about the AWT/2D > part), and I don't think it will introduce any side effects. > > Just a note: > > src/share/classes/java/lang/invoke/CallSite.java: > > } catch (ReflectiveOperationException ignore) { > - throw new InternalError(); > + throw new InternalError(ignore); > } > > Being a refactoring patch, I would not change the name from "ignore" to > the more classical "e", since we are not ignoring the exception anymore. > > Also in src/share/classes/com/sun/servicetag/BrowserSupport.java, it > seems to me that you can also aggregate the InvocationTargetException in > the multi catch. I think we should not make further aggregating on InvocationTargetException in this patch. It changes behavoir. Which of the two places to you mean we can aggregate into multi catch? > In fact, the block could be probably rewritten to take advantage of > ReflectiveOperationException. > > Same for src/share/classes/sun/misc/Launcher.java, > src/share/classes/sun/security/util/SecurityConstants.java and > src/share/classes/sun/tracing/dtrace/DTraceProvider.java Changed that to ReflectiveOperationException. > Cheers, > Mario > -- Sebastian

1 0

hg: jdk8/tl/jdk: 7083576: add javax/xml/crypto into jdk_security2
by weijun.wang＠oracle.com 30 Aug '11

30 Aug '11

Changeset: 6d6d75421e8a Author: weijun Date: 2011-08-30 10:46 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6d6d75421e8a 7083576: add javax/xml/crypto into jdk_security2 Reviewed-by: mullan ! test/Makefile ! test/javax/xml/crypto/dsig/SecurityManager/XMLDSigWithSecMgr.java

1 0

hg: jdk8/tl/jdk: 2 new changesets
by sean.mullan＠oracle.com 29 Aug '11

29 Aug '11

Changeset: d1c04dac850d Author: mullan Date: 2011-08-29 12:22 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d1c04dac850d 7024771: "\\<>" in attribute value part of X500Principal constructor parameter makes strange effect Reviewed-by: vinnie ! src/share/classes/sun/security/x509/AVA.java ! src/share/classes/sun/security/x509/X500Name.java + test/javax/security/auth/x500/X500Principal/Parse.java Changeset: c2b4e0ea3ab9 Author: mullan Date: 2011-08-29 12:23 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c2b4e0ea3ab9 Merge ! src/share/classes/sun/security/x509/X500Name.java

1 0

hg: jdk8/tl/jdk: 7059542: JNDI name operations should be locale independent
by xuelei.fan＠oracle.com 29 Aug '11

29 Aug '11

Changeset: 02c2d38f4271 Author: xuelei Date: 2011-08-29 05:55 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/02c2d38f4271 7059542: JNDI name operations should be locale independent Reviewed-by: weijun ! src/share/classes/com/sun/jndi/ldap/ClientId.java ! src/share/classes/com/sun/jndi/ldap/LdapClient.java ! src/share/classes/com/sun/jndi/ldap/LdapCtx.java ! src/share/classes/com/sun/jndi/ldap/LdapName.java ! src/share/classes/com/sun/jndi/ldap/LdapPoolManager.java ! src/share/classes/com/sun/jndi/toolkit/dir/HierMemDirCtx.java ! src/share/classes/com/sun/jndi/toolkit/dir/SearchFilter.java ! src/share/classes/com/sun/security/ntlm/NTLM.java ! src/share/classes/java/security/KeyRep.java ! src/share/classes/java/security/Security.java ! src/share/classes/javax/naming/NameImpl.java ! src/share/classes/javax/naming/directory/BasicAttributes.java ! src/share/classes/javax/naming/ldap/Rdn.java ! src/share/classes/sun/security/jgss/krb5/Krb5NameElement.java ! src/share/classes/sun/security/krb5/PrincipalName.java ! src/share/classes/sun/security/pkcs12/PKCS12KeyStore.java ! src/share/classes/sun/security/provider/JavaKeyStore.java ! src/share/classes/sun/security/provider/certpath/ldap/LDAPCertStore.java ! src/share/classes/sun/security/ssl/SSLSessionContextImpl.java ! src/share/classes/sun/security/tools/KeyStoreUtil.java ! src/share/classes/sun/security/util/HostnameChecker.java ! src/share/classes/sun/security/x509/DNSName.java ! src/share/classes/sun/security/x509/RFC822Name.java ! test/javax/naming/ldap/LdapName/CompareToEqualsTests.java

1 0

Review request for 7020513 : Add com.sun.xml.internal to the "package.access" property in java.security
by Rama Pulavarthi 29 Aug '11

29 Aug '11

Hi, Need reviewer for CR 7020513: Add com.sun.xml.internal to the "package.access" property in $JAVA_HOME/lib/security/java.security Webrev is available at http://cr.openjdk.java.net/~ohair/openjdk7/jdk7-tl-jaxws-7020513/webrev/ thanks, Rama Pulavarthi

6 12

Some questions on 6312085: The for/in statement should support Iterators/Enumerations
by Sebastian Sickelmann 28 Aug '11

28 Aug '11

Hi, i thought about what todo to enable the enhanced-for-loop for Iterators and Enumerations. And it seems to me that the main problem is that the used Iterator/Enumeration should not be used in other places( it should be "private" for the loop). As Iterable solves this through creating a new "private" Iterator for the Iterable(ex. List/Set/....) it is not geranteed that there are concurrent modifications on the Iterable. Typically the iterator solves this through checking for concurrent modifications. If i see it right it should be possible to use every Iterator/Enumeration as a source for the enhanced-for-loop which is Cloneable too. The main-problem I see is that it is not as easy to pin out which Iterator / Enumeration i can put into the for-loop and which i cannot. Additionaly i think that would lead into runtime-checks and not compiletime-checks which would be really ugly. Let Iterator / Enumeration extends Cloneable isn't a good solution because there will be some Iterators/Enumerations that are not possible to clone. Addtionaly there would be some compatibility issues, ex. let Object.clone() do the job will not for every case) and there maybe more compatibiliy issues(binary?) i don't see actually. As i haven't found any source that brings in the Cloneable Iterator/Enumeration solution into account with the enhanced-for-loop it maybe a new idea. Has some a good idea how to get to compiletime-checks with this solution and/or how to transparently give the applicationdeveloper the feedback he/she needs to intuitional use these? Thanks for feedback. -- Sebastian

1 0

Request for review: Rework cause-chaining in Exceptions was:JDK 8 code review request for 6380161 (reflect) Exception from newInstance() not chained to cause.
by Sebastian Sickelmann 28 Aug '11

28 Aug '11

Hi, some time ago, i wrote[5] with Joe and David about advancing some exception-types to the 4 standard ctors. The first Exception i have looked at was InternalError and now(after some struggeling with gnumake and hg) my patches for reviewing are ready. I uploaded them at [4] I split the changes into 3 parts. 1. Added 2 ctors to InternalError and VirtualMachineError****[1] 2. Use the two ctors of InternalError****[2] (based on [1]) 3. Chain Rootcause into InternalError**[3] (based also on [1]) I think part 1 and 2 are uncritical. Part 3 is more critical because it changes behavior (exception-chaining). But i don't think that part 3 is unimportable, because in case of an InternalError (use should not be able to recover) there shouldn't be a problem with a little longer exception-chain. Is there someone who what to sponsor this or parts of it? [1] https://bugs.openjdk.java.net/attachment.cgi?id=233 [2] https://bugs.openjdk.java.net/attachment.cgi?id=234 [3] https://bugs.openjdk.java.net/attachment.cgi?id=235 [4] https://bugs.openjdk.java.net/show_bug.cgi?id=100201 [5] http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-August/007304.html

6 19

hg: jdk8/tl/jdk: 7084040: Clearup warning in HttpsURLConnection
by xuelei.fan＠oracle.com 28 Aug '11

28 Aug '11

Changeset: e4729ad0d7b5 Author: xuelei Date: 2011-08-27 02:17 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e4729ad0d7b5 7084040: Clearup warning in HttpsURLConnection Reviewed-by: xuelei Contributed-by: nsebastian.sickelmann(a)gmx.de ! src/share/classes/javax/net/ssl/HttpsURLConnection.java

2 1