Re: [JDK 9] RFR: 8041781: Need new regression tests for PBE keys

Looks fine to me. Would you like also add tests for PBEMAC, e.g., PBEWithHmacSHA1? Thanks, Xuelei On 6/27/2014 5:02 AM, Rajan Halade wrote: Ping...can someone help review this please. Thanks, Rajan On 6/18/14, 3:36 PM, Rajan Halade wrote: May I request you to review these 3 new tests to be a

Re: RFR 8027575: b113 causing a lot of memory allocation and regression for wls_webapp_atomics

Looks fine to me. On 6/27/2014 5:51 AM, Valerie Peng wrote: Xuelei and Tony, Please find the updated webrev at http://cr.openjdk.java.net/~valeriep/8027575/webrev.01/ I enhanced existing regression test and modified the fix slightly regarding to when to copy out the input for the same-src/dest

Re: ThreadLocalRandom clinit troubles

On 6/26/2014 4:10 PM, Doug Lea wrote: This seems to be the best idea yet, assuming that people are OK with the changes to sun.security.provider.SeedGenerator and NativeSeedGenerator.java I've been meaning to review this thread, but have been chasing several urgent escalations. Brad

Re: ThreadLocalRandom clinit troubles

Peter: Thanks very much for attacking the shocking impact/complexity of getting a few seed bits. On 06/25/2014 01:41 PM, Peter Levart wrote: Peeking around in the sun.security.provider package, I found there already is a minimal internal infrastructure for obtaining random seed. It's encapsula

Re: ThreadLocalRandom clinit troubles

To sum-up: We have a problem with TLR initialization since by default it uses networking code to compute initial "seeder" value which can execute user code in at least two situations: - when "sun.net.spi.nameservice.provider" system property is defined to use custom NameService provider - whe

Re: A Bug in AccessControlContext.equals() and hashCode()?

>On 6/16/2014 10:40 PM, David M. Lloyd wrote: >On 06/16/2014 09:19 AM, Frank Ding wrote: >> Hi Jeff, >> Thanks for your reply. One further question is that you confirmed >> that two AccessControlContext objects considered equal via method >> equals() should return same results for >> AccessContr

Re: RFR 8027575: b113 causing a lot of memory allocation and regression for wls_webapp_atomics

Xuelei and Tony, Please find the updated webrev at http://cr.openjdk.java.net/~valeriep/8027575/webrev.01/ I enhanced existing regression test and modified the fix slightly regarding to when to copy out the input for the same-src/dest-buffer case, i.e. do the encryption/decryption operation in

Re: RFR 8043406: Change default policy for JCE providers to run with as few privileges,as possible

Updated the webrev in place (still at webrev.01), now that Mandy has putback'ed her fix for the ClassLoader.loadLibrary issue. Thanks, Valerie On 6/20/2014 3:30 PM, Valerie Peng wrote: Webrev is updated at: http://cr.openjdk.java.net/~valeriep/8043406/webrev.01 Sure, I will file a bug aft

Re: [JDK 9] RFR: 8041781: Need new regression tests for PBE keys

Ping...can someone help review this please. Thanks, Rajan On 6/18/14, 3:36 PM, Rajan Halade wrote: May I request you to review these 3 new tests to be added for PBE keys. New tests are added to address following: - seal/unseal works correctly with PBE algorithms - key wrapper works correctly w

Re: RFR [8048080] (smartcardio) javax.smartcardio.Card.openLogicalChannel() dosn't work on MacOSX

Looks good. Thanks, Valerie On 6/26/2014 7:56 AM, Ivan Gerasimov wrote: Hello! This bug is very similar to JDK-7195480, in the sense it is due to the structure misalignment under MacOSX. I didn't fix it together with JDK-7195480 because I hadn't had a testcase in hands at that time to verify

RFR [8048080] (smartcardio) javax.smartcardio.Card.openLogicalChannel() dosn't work on MacOSX

Hello! This bug is very similar to JDK-7195480, in the sense it is due to the structure misalignment under MacOSX. I didn't fix it together with JDK-7195480 because I hadn't had a testcase in hands at that time to verify the change. Now, I've got a testcase from SQE and it confirms the change