hg: jdk8/tl/jdk: 7163470: Build fails if javax.crypto src files not present
Changeset: fdf5e15293e6 Author:coffeys Date: 2012-05-10 10:45 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fdf5e15293e6 7163470: Build fails if javax.crypto src files not present Reviewed-by: valeriep ! make/com/oracle/security/ucrypto/Makefile ! make/common/shared/Defs-java.gmk ! make/sun/security/ec/Makefile ! make/sun/security/mscapi/Makefile ! make/sun/security/pkcs11/Makefile ! makefiles/com/oracle/security/ucrypto/Makefile ! makefiles/common/shared/Defs-java.gmk ! makefiles/sun/security/ec/Makefile ! makefiles/sun/security/mscapi/Makefile ! makefiles/sun/security/pkcs11/Makefile
hg: jdk8/tl/jdk: 3 new changesets
Changeset: 3e3017eba8ac Author:valeriep Date: 2012-05-08 17:57 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3e3017eba8ac 4963723: Implement SHA-224 Summary: Add support for SHA-224, SHA224withRSA, SHA224withECDSA, HmacSHA224 and OAEPwithSHA-224AndMGF1Padding. Reviewed-by: vinnie ! src/share/classes/com/sun/crypto/provider/HmacCore.java ! src/share/classes/com/sun/crypto/provider/HmacMD5.java ! src/share/classes/com/sun/crypto/provider/HmacPKCS12PBESHA1.java ! src/share/classes/com/sun/crypto/provider/HmacSHA1.java ! src/share/classes/com/sun/crypto/provider/KeyGeneratorCore.java ! src/share/classes/com/sun/crypto/provider/OAEPParameters.java ! src/share/classes/com/sun/crypto/provider/SunJCE.java ! src/share/classes/java/security/spec/MGF1ParameterSpec.java ! src/share/classes/java/security/spec/PSSParameterSpec.java ! src/share/classes/sun/security/ec/ECDSASignature.java ! src/share/classes/sun/security/ec/SunECEntries.java ! src/share/classes/sun/security/pkcs11/P11Digest.java ! src/share/classes/sun/security/pkcs11/P11Mac.java ! src/share/classes/sun/security/pkcs11/P11Signature.java ! src/share/classes/sun/security/pkcs11/SunPKCS11.java ! src/share/classes/sun/security/pkcs11/wrapper/Functions.java ! src/share/classes/sun/security/provider/DigestBase.java ! src/share/classes/sun/security/provider/MD2.java ! src/share/classes/sun/security/provider/MD4.java ! src/share/classes/sun/security/provider/MD5.java ! src/share/classes/sun/security/provider/SHA.java ! src/share/classes/sun/security/provider/SHA2.java ! src/share/classes/sun/security/provider/SHA5.java ! src/share/classes/sun/security/provider/SunEntries.java ! src/share/classes/sun/security/rsa/RSASignature.java ! src/share/classes/sun/security/rsa/SunRsaSignEntries.java ! src/share/classes/sun/security/x509/AlgorithmId.java ! src/windows/classes/sun/security/mscapi/RSASignature.java ! src/windows/classes/sun/security/mscapi/SunMSCAPI.java ! test/com/sun/crypto/provider/Cipher/RSA/TestOAEP.java ! test/com/sun/crypto/provider/Cipher/RSA/TestOAEPParameterSpec.java ! test/com/sun/crypto/provider/Cipher/RSA/TestOAEPWithParams.java ! test/com/sun/crypto/provider/KeyGenerator/Test4628062.java ! test/com/sun/crypto/provider/Mac/MacClone.java ! test/com/sun/crypto/provider/Mac/MacKAT.java ! test/sun/security/mscapi/SignUsingNONEwithRSA.java ! test/sun/security/mscapi/SignUsingSHA2withRSA.java ! test/sun/security/pkcs11/MessageDigest/DigestKAT.java ! test/sun/security/pkcs11/MessageDigest/TestCloning.java ! test/sun/security/pkcs11/Signature/TestRSAKeyLength.java ! test/sun/security/pkcs11/ec/TestCurves.java ! test/sun/security/pkcs11/rsa/TestKeyPairGenerator.java ! test/sun/security/pkcs11/rsa/TestSignatures.java ! test/sun/security/provider/MessageDigest/DigestKAT.java ! test/sun/security/provider/MessageDigest/Offsets.java ! test/sun/security/provider/MessageDigest/TestSHAClone.java ! test/sun/security/rsa/TestKeyPairGenerator.java ! test/sun/security/rsa/TestSignatures.java Changeset: dfce31760a2f Author:valeriep Date: 2012-05-08 18:57 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/dfce31760a2f Merge Changeset: 9f8210f23773 Author:valeriep Date: 2012-05-10 11:19 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9f8210f23773 Merge
Re: review request: 4244896: (process) Provide System.getPid(), System.killProcess(String pid)
Hi folks, The latest version is at: http://cr.openjdk.java.net/~robm/4244896/webrev.03/ http://cr.openjdk.java.net/%7Erobm/4244896/webrev.03/ Feedback greatly appreciated. -Rob On 19/04/12 12:05, Alan Bateman wrote: On 19/04/2012 01:05, David Holmes wrote: On 18/04/2012 11:44 PM, Jason Mehrens wrote: Rob, It looks like waitFor is calling Object.wait(long) without owning this objects monitor. If I pass Long.MAX_VALUE to waitFor, shouldn't waitFor return if the early if the process ends? Also waitFor doesn't call wait() under the guard of a looping predicate so it will suffer from lost signals and potentially spurious wakeups. I also don't see anything calling notify[All] to indicate the process has now terminated. It would appear that wait(timeout) is being used as a sleep mechanism and that is wrong on a number of levels. I assume waitFor(timout) will require 3 distinct implementations, one for Solaris/Linux/Mac, another for Windows, and a default implementations for Process implementations that exist outside of the JDK. It's likely the Solaris/Linux/Mac implementation will involve two threads, one to block in waitpid and the other to interrupt it via a signal if the timeout elapses before the child terminates. The Windows implementation should be trivial because it can be a timed wait. I assume the default implementation (which is what is being discussed here) will need to loop calling exitValue until the timeout elapses or the child terminates. Not very efficient but at least it won't be used when when creating Processes via Runtime.exec or ProcessBuilder. I think the question we need to consider is whether waitFor(timeout) is really needed. If it's something that it pushed out for another day then it brings up the question as to whether to include isAlive now or not (as waitFor without timeout gives us an isAlive equivalent too). -Alan.
hg: jdk8/tl/langtools: 7159445: (javac) emits inaccurate diagnostics for enhanced for-loops
Changeset: 833bab705918 Author:ksrini Date: 2012-05-10 12:32 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/833bab705918 7159445: (javac) emits inaccurate diagnostics for enhanced for-loops Reviewed-by: jjg Contributed-by: jan.lah...@oracle.com ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/diags/examples/ForeachBadInitialization.java ! test/tools/javac/parser/JavacParserTest.java
Re: Review Request for CR : 7144861 RMI activation tests are too slow
Please find the second webrev with your remarks applied here: http://cr.openjdk.java.net/~olagneau/7144861/webrev.01/ In addition to the way we have agreed (see below) to handle InterruptedException in this fix, I have applied all the other requests for change. Regarding RMID.start() with outer and inner timer loops, I have kept the current structure of the code, but for sure this should be totally rewritten in a further cleanup of the code. Thanks, Olivier. Stuart Marks said on date 5/10/2012 6:28 AM: On 5/9/12 8:26 AM, Olivier Lagneau wrote: Given that we want to push the code quickly, I don't think I should go for such a large IE cleanup for this fix, which is meant to provide better exceution speed only. I suggest to follow Stuart's proposal first (i.e. reassert and return immediately in my code changes) , and create a dedicated new CR regarding proper handling of IE in all the rmi tests (low priority). Do you agree with this ? Yes, this seems like a sensible approach. The new CR might also cover the cleaning/unification of all the retry-repeatedly-with-time-limit loops that are spread through this code. Thanks. s'marks
Re: Review Request for CR : 7144861 RMI activation tests are too slow
Olivier Lagneau said on date 5/11/2012 12:13 AM: Please find the second webrev with your remarks applied here: http://cr.openjdk.java.net/~olagneau/7144861/webrev.01/ In addition to the way we have agreed (see below) to handle InterruptedException in this fix, I have applied all the other requests for change. Regarding RMID.start() with outer and inner timer loops, I have kept the current structure of the code, but for sure this should be totally rewritten in a further cleanup of the code. Thanks, Olivier. Stuart Marks said on date 5/10/2012 6:28 AM: On 5/9/12 8:26 AM, Olivier Lagneau wrote: Given that we want to push the code quickly, I don't think I should go for such a large IE cleanup for this fix, which is meant to provide better exceution speed only. I suggest to follow Stuart's proposal first (i.e. reassert and return immediately in my code changes) , and create a dedicated new CR regarding proper handling of IE in all the rmi tests (low priority). Do you agree with this ? Yes, this seems like a sensible approach. The new CR might also cover the cleaning/unification of all the retry-repeatedly-with-time-limit loops that are spread through this code. Thanks. s'marks
Re: Review Request for CR : 7144861 RMI activation tests are too slow (wrong webev link fixed)
Olivier Lagneau said on date 5/11/2012 12:13 AM: Please find the second webrev with your remarks applied here: http://cr.openjdk.java.net/~olagneau/7144861/webrev.01/ Html link above is buggy. Please go to this correct location: http://cr.openjdk.java.net/~olagneau/7144861/webrev.01 In addition to the way we have agreed (see below) to handle InterruptedException in this fix, I have applied all the other requests for change. Regarding RMID.start() with outer and inner timer loops, I have kept the current structure of the code, but for sure this should be totally rewritten in a further cleanup of the code. Thanks, Olivier. Stuart Marks said on date 5/10/2012 6:28 AM: On 5/9/12 8:26 AM, Olivier Lagneau wrote: Given that we want to push the code quickly, I don't think I should go for such a large IE cleanup for this fix, which is meant to provide better exceution speed only. I suggest to follow Stuart's proposal first (i.e. reassert and return immediately in my code changes) , and create a dedicated new CR regarding proper handling of IE in all the rmi tests (low priority). Do you agree with this ? Yes, this seems like a sensible approach. The new CR might also cover the cleaning/unification of all the retry-repeatedly-with-time-limit loops that are spread through this code. Thanks. s'marks
Review Request : 7071826 : Avoid benign race condition in initialization of UUID
Hello all; A benign but potentially expensive race condition was discovered in java.util.UUID. The initialization of numberGenerator may cause the creation of a number of SecureRandom instances if multiple threads are attempting to initialize the field at the same time. This can happen because creation of the SecureRandom instances, depending upon system configuration and state, may take a significant amount of time. Using a shared SecureRandom instance for the numberGenerator is an optimization--nothing bad happens as a result of each thread using it's own instance. However, creation of multiple SecureRandom instances, especially during system startup, may be expensive or have high latency if no previous SecureRandom instances have been created. Accordingly, a holder class is used to ensure that only a single SecureRandom instance is created. The holder also serves to defer initialization of numberGenerator until randomUUID() is first called. Webrev: http://cr.openjdk.java.net/~mduigou/7071826/0/webrev/ This issue will be proposed for backport to Java 7u6 once integrated into Java 8 Thanks, Mike
Re: Review Request for CR : 7144861 RMI activation tests are too slow (wrong webev link fixed)
Looks good. Just one thing: in JavaVM.java, the declaration line for boolean started still has a comment that says updated by started() method. That method has been renamed to setStarted(). Either fix the comment or perhaps better, remove it entirely. It's pretty easy to find uses of private variables. If the comment isn't there it won't get out of date! :-) BTW I ran before-and-after tests of the java/rmi/activation tests (32 tests), and the results are as follows: before: 18m21s after: 7m52s This is great! If the comment typo is the only change then I don't think you need another webrev before you push. Oh wait, you can't push, can you. OK, I'll do the push then, and I can apply the comment fix if there aren't any other changes. I'll wait overnight to hear from Alan or David, and if there's nothing else, I'll go ahead with it tomorrow. Thanks!! s'marks On 5/10/12 3:20 PM, Olivier Lagneau wrote: Olivier Lagneau said on date 5/11/2012 12:13 AM: Please find the second webrev with your remarks applied here: http://cr.openjdk.java.net/~olagneau/7144861/webrev.01/ Html link above is buggy. Please go to this correct location: http://cr.openjdk.java.net/~olagneau/7144861/webrev.01 In addition to the way we have agreed (see below) to handle InterruptedException in this fix, I have applied all the other requests for change. Regarding RMID.start() with outer and inner timer loops, I have kept the current structure of the code, but for sure this should be totally rewritten in a further cleanup of the code. Thanks, Olivier. Stuart Marks said on date 5/10/2012 6:28 AM: On 5/9/12 8:26 AM, Olivier Lagneau wrote: Given that we want to push the code quickly, I don't think I should go for such a large IE cleanup for this fix, which is meant to provide better exceution speed only. I suggest to follow Stuart's proposal first (i.e. reassert and return immediately in my code changes) , and create a dedicated new CR regarding proper handling of IE in all the rmi tests (low priority). Do you agree with this ? Yes, this seems like a sensible approach. The new CR might also cover the cleaning/unification of all the retry-repeatedly-with-time-limit loops that are spread through this code. Thanks. s'marks
Re: Review Request for CR : 7144861 RMI activation tests are too slow (wrong webev link fixed)
IE handling seems fine. No further comments from me. Note I was not a full reviewer of this. David On 11/05/2012 11:04 AM, Stuart Marks wrote: Looks good. Just one thing: in JavaVM.java, the declaration line for boolean started still has a comment that says updated by started() method. That method has been renamed to setStarted(). Either fix the comment or perhaps better, remove it entirely. It's pretty easy to find uses of private variables. If the comment isn't there it won't get out of date! :-) BTW I ran before-and-after tests of the java/rmi/activation tests (32 tests), and the results are as follows: before: 18m21s after: 7m52s This is great! If the comment typo is the only change then I don't think you need another webrev before you push. Oh wait, you can't push, can you. OK, I'll do the push then, and I can apply the comment fix if there aren't any other changes. I'll wait overnight to hear from Alan or David, and if there's nothing else, I'll go ahead with it tomorrow. Thanks!! s'marks On 5/10/12 3:20 PM, Olivier Lagneau wrote: Olivier Lagneau said on date 5/11/2012 12:13 AM: Please find the second webrev with your remarks applied here: http://cr.openjdk.java.net/~olagneau/7144861/webrev.01/ Html link above is buggy. Please go to this correct location: http://cr.openjdk.java.net/~olagneau/7144861/webrev.01 In addition to the way we have agreed (see below) to handle InterruptedException in this fix, I have applied all the other requests for change. Regarding RMID.start() with outer and inner timer loops, I have kept the current structure of the code, but for sure this should be totally rewritten in a further cleanup of the code. Thanks, Olivier. Stuart Marks said on date 5/10/2012 6:28 AM: On 5/9/12 8:26 AM, Olivier Lagneau wrote: Given that we want to push the code quickly, I don't think I should go for such a large IE cleanup for this fix, which is meant to provide better exceution speed only. I suggest to follow Stuart's proposal first (i.e. reassert and return immediately in my code changes) , and create a dedicated new CR regarding proper handling of IE in all the rmi tests (low priority). Do you agree with this ? Yes, this seems like a sensible approach. The new CR might also cover the cleaning/unification of all the retry-repeatedly-with-time-limit loops that are spread through this code. Thanks. s'marks
