April 2011 - core-libs-dev

hg: jdk7/tl/jdk: 2 new changesets
by vincent.x.ryan＠oracle.com 21 Apr '11

21 Apr '11

Changeset: 7cd0403492b6 Author: vinnie Date: 2011-04-21 14:23 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/7cd0403492b6 6888925: SunMSCAPI's Cipher can't use RSA public keys obtained from other sources. Reviewed-by: mullan ! src/windows/classes/sun/security/mscapi/RSACipher.java ! src/windows/classes/sun/security/mscapi/RSAPublicKey.java ! src/windows/classes/sun/security/mscapi/RSASignature.java + test/sun/security/mscapi/PublicKeyInterop.java + test/sun/security/mscapi/PublicKeyInterop.sh Changeset: 401ef8c488e0 Author: vinnie Date: 2011-04-21 14:25 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/401ef8c488e0 Merge

1 0

hg: jdk7/tl/jdk: 7038501: Clarify meaning of "(optional)" in javadoc
by chris.hegarty＠oracle.com 21 Apr '11

21 Apr '11

Changeset: 7fd31e477313 Author: dl Date: 2011-04-21 13:53 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/7fd31e477313 7038501: Clarify meaning of "(optional)" in javadoc Reviewed-by: chegar ! src/share/classes/java/util/concurrent/BlockingDeque.java ! src/share/classes/java/util/concurrent/BlockingQueue.java ! src/share/classes/java/util/concurrent/ConcurrentMap.java ! src/share/classes/java/util/concurrent/CopyOnWriteArrayList.java

1 0

TL/Client bug fixes after May 2 will require approval - b142 is the last JCG integration before Rampdown Phase 2 Start
by Lana Steuck 21 Apr '11

21 Apr '11

To: TL and 2d, Awt, I18n, Swing Jdk7 Developers (Internal and External) What: b142 is the last TL/Client integration before Rampdown Phase 2 Start (RDP2) When: Mon, May 2 at 12PM PT PIT deadline for b142 is Mon, May 2 at 12PM PT (integrating on Tue, May 10). Any changes pushed to TL, 2d, Awt, I18n, and Swing forests after Mon, May 2, will require Release Team approval. For external developers, this means that someone from Oracle Jdk7 Engineering would need to file an approval request and advocate for their change. Regards, - Lana

1 0

hg: jdk7/tl/jdk: 6546713: link the word (optional) in exception specifications to the text which provides explanation and context.
by mike.duigou＠oracle.com 21 Apr '11

21 Apr '11

Changeset: d5a7ed4e72a4 Author: mduigou Date: 2011-04-20 17:20 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d5a7ed4e72a4 6546713: link the word (optional) in exception specifications to the text which provides explanation and context. Reviewed-by: dholmes, dl ! src/share/classes/java/util/AbstractSet.java ! src/share/classes/java/util/ArrayList.java ! src/share/classes/java/util/Collection.java ! src/share/classes/java/util/Collections.java ! src/share/classes/java/util/Deque.java ! src/share/classes/java/util/List.java ! src/share/classes/java/util/Map.java ! src/share/classes/java/util/Set.java ! src/share/classes/java/util/Vector.java

1 0

hg: jdk7/tl/jdk: 6896297: (rmi) fix ConcurrentModificationException causing TCK failure
by stuart.marks＠oracle.com 20 Apr '11

20 Apr '11

Changeset: 00f3997e6aeb Author: smarks Date: 2011-04-20 16:30 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/00f3997e6aeb 6896297: (rmi) fix ConcurrentModificationException causing TCK failure Reviewed-by: alanb, dholmes, peterjones ! src/share/classes/sun/rmi/log/ReliableLog.java ! src/share/classes/sun/rmi/server/Activation.java

1 0

advice & review requested for 6896297, race condition in rmid causing JCK failure
by Stuart Marks 20 Apr '11

20 Apr '11

Hi Core-Libs developers, I'd like to solicit some advice and discussion about this bug and a potential fix I'm cooking for it. Here is the bug report; it contains details about the problem and my analysis of it: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6896297 and here's a webrev of the fix I'm working on: http://cr.openjdk.java.net/~smarks/reviews/6896297/webrev.0/ Briefly, the problem is incorrect synchronization of groupTable, a HashMap field of an Activation object. The code mostly locks groupTable around any access to it. However, no such locking is done during serialization. If the groupTable is modified while it's being serialized, ConcurrentModificationException occurs. The obvious fix would be to use ConcurrentHashMap instead of Hashmap and to remove the external locking entirely. Unfortunately this will change the serialized representation of the Activation object, which I'm not sure is acceptable. Assuming that we can't change the serialized represenation, the alternative approach would be to make sure that locking is done properly during serialization. This is fairly easy to do by locking groupTable in a writeObject() method. Unfortunately, this introduces a deadlock. This deadlock occurs because, with this modification, there are now paths through the code that take locks in the opposite order. Specifically, the addLogRecord() method locks the log object and then (via serialization and the newly added writeObject() method) locks groupTable. However, the unregisterGroup() method locks groupTable and calls GroupEntry.unregisterGroup() which logs the event, which takes a lock on the log. After some analysis, I've determined that the call to GroupEntry.unregisterGroup() can be moved outside the synchronization of groupTable. This removes the ordering problem. With these fixes in place (the state of the webrev above) I can get several hundred successful test runs with neither ConcurrentModificationException nor any deadlocks. Of course, that doesn't mean the change is correct. :-) Questions: 1. Is there a requirement that the serialized form of Activation remain unchanged? If we can change it, we might as well just use ConcurrentHashMap instead of HashMap. 2. Is my lock ordering analysis correct? I've pored over the code, but not really being familiar with any RMI concepts, I'm not sure I have it right. I've written this analysis into a big comment I've added to the code. 3. There is also a potential concurrency issue with idTable, which is used similarly to groupTable. I haven't seen a test failure from it though. It seems sensible to add a lock for it in Activation.writeObject() though. I don't particularly like nesting the locks of idTable and groupTable, but locking them separately would require serializing the Activation object field by field instead of simply using defaultWriteObject(). Is this a reasonable approach? Thanks for any advice or comments. s'marks

4 11

hg: jdk7/tl/jdk: 2 new changesets
by michael.x.mcmahon＠oracle.com 20 Apr '11

20 Apr '11

Changeset: ed01737a2e9a Author: michaelm Date: 2011-04-20 12:03 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ed01737a2e9a 7034570: java.lang.Runtime.exec(String[] cmd, String[] env) can not work properly if SystemRoot not inherited Reviewed-by: dholmes, alanb ! src/share/classes/java/lang/ProcessBuilder.java ! src/share/classes/java/lang/Runtime.java ! src/windows/classes/java/lang/ProcessEnvironment.java ! test/java/lang/ProcessBuilder/Basic.java Changeset: 31aa8c35a4df Author: michaelm Date: 2011-04-20 12:05 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/31aa8c35a4df Merge

1 0

hg: jdk7/tl/jdk: 6894072: always refresh keytab
by weijun.wang＠oracle.com 20 Apr '11

20 Apr '11

Changeset: f8956ba13b37 Author: weijun Date: 2011-04-20 18:41 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f8956ba13b37 6894072: always refresh keytab Reviewed-by: valeriep ! src/share/classes/com/sun/security/auth/module/Krb5LoginModule.java + src/share/classes/javax/security/auth/kerberos/JavaxSecurityAuthKerberosAccessImpl.java ! src/share/classes/javax/security/auth/kerberos/KerberosKey.java + src/share/classes/javax/security/auth/kerberos/KeyTab.java + src/share/classes/sun/misc/JavaxSecurityAuthKerberosAccess.java ! src/share/classes/sun/misc/SharedSecrets.java ! src/share/classes/sun/security/jgss/krb5/Krb5AcceptCredential.java ! src/share/classes/sun/security/jgss/krb5/Krb5Util.java ! src/share/classes/sun/security/jgss/krb5/SubjectComber.java ! src/share/classes/sun/security/krb5/Config.java ! src/share/classes/sun/security/krb5/EncryptionKey.java ! src/share/classes/sun/security/krb5/KrbAsRep.java ! src/share/classes/sun/security/krb5/KrbAsReqBuilder.java ! src/share/classes/sun/security/krb5/internal/ktab/KeyTab.java ! src/share/classes/sun/security/ssl/ServerHandshaker.java ! src/share/classes/sun/security/ssl/krb5/Krb5ProxyImpl.java ! src/windows/classes/sun/security/krb5/internal/tools/Kinit.java ! src/windows/classes/sun/security/krb5/internal/tools/Klist.java ! src/windows/classes/sun/security/krb5/internal/tools/Ktab.java ! test/sun/security/krb5/auto/Context.java + test/sun/security/krb5/auto/DynamicKeytab.java ! test/sun/security/krb5/auto/KDC.java + test/sun/security/krb5/auto/KeyTabCompat.java ! test/sun/security/krb5/auto/LoginModuleOptions.java ! test/sun/security/krb5/auto/SSL.java + test/sun/security/krb5/auto/TwoPrinces.java ! test/sun/security/krb5/ktab/KeyTabIndex.java

1 0

Review request for 7034570
by Michael McMahon 20 Apr '11

20 Apr '11

This issue occurs on some versions of Windows since we switched compiler to VC 2010. The new C runtime library requires the "SystemRoot" environment variable to be set, when launching sub-processes via Runtime.exec() or ProcessBuilder. The problem occurs in instances where the environment is specified by the caller, rather than simply inheriting (or inheriting and adding to) the environment of the parent process. The change is simple enough. We just check for the presence of "SystemRoot" in the child process's environment, and set it if it's not there. No change will be visible to the parent process. But, to avoid ambiguity, we'd like to make the change explicit with a small spec. change. http://cr.openjdk.java.net/~michaelm/7034570/webrev.1/ Thanks, Michael.

5 47

hg: jdk7/tl/jdk: 7030579: Extra words in documentation of ListIterator may cause confusion
by mike.duigou＠oracle.com 19 Apr '11

19 Apr '11

Changeset: 495dcc360214 Author: mduigou Date: 2011-04-19 10:47 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/495dcc360214 7030579: Extra words in documentation of ListIterator may cause confusion Reviewed-by: dholmes, alanb ! src/share/classes/java/util/ListIterator.java

1 0