Changeset: 27a2e8c78bd0
Author:vromero
Date: 2013-07-02 10:21 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/27a2e8c78bd0
8019397: javap does not show SourceDebugExtension properly
Reviewed-by: jjg
Contributed-by: dmytro_she...@hotmail.com
!
Changeset: 020f023f87d1
Author:dfuchs
Date: 2013-07-02 11:30 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/020f023f87d1
8017174: NPE when using Logger.getAnonymousLogger or
LogManager.getLogManager().getLogger
Summary: This patch makes sure that LoggerContext instances
OK. Thanks.
On 2 Jul 2013, at 00:02, Xuelei Fan wrote:
On 7/1/2013 8:56 PM, Vincent Ryan wrote:
I think that wrapping a RuntimeException (in CPVE) is acceptable in this case
because the goal is to activate the failover mechanism from OCSP to CRL.
Do you want RuntimeException to be
Changeset: b1fffbbdf58c
Author:ksrini
Date: 2013-07-02 05:28 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b1fffbbdf58c
8017463: [TEST_BUG] 2 tests from tools/pack200/ remain about 1 GB of data in
work directory after execution
Reviewed-by: mchung
!
On 07/01/2013 07:02 PM, Xuelei Fan wrote:
On 7/1/2013 8:56 PM, Vincent Ryan wrote:
I think that wrapping a RuntimeException (in CPVE) is acceptable in this case
because the goal is to activate the failover mechanism from OCSP to CRL.
Do you want RuntimeException to be re-thrown?
No. It is
Changeset: 565341d436e2
Author:ksrini
Date: 2013-07-01 16:36 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/565341d436e2
8019460: tests in changeset do not have @bug tag
Reviewed-by: darcy
! test/tools/javac/warnings/AuxiliaryClass/ClassUsingAnotherAuxiliary.java
!
Changeset: 70bff2d12af0
Author:dfuchs
Date: 2013-07-02 19:47 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/70bff2d12af0
7184195: java.util.logging.Logger.getGlobal().info() doesn't log without
configuration
Summary: Due to subtle synchronization issues between LogManager
I see your point Sean. My motivation for wrapping the RuntimeException was to
ensure
that the failover mechanism (from OCSP to CRLs) did not get interrupted. But
this is a
case when the failover should be interrupted. I've filed a new bug to address
the issue:
Bug: 8019627: RuntimeException
On 07/02/2013 02:49 PM, Vincent Ryan wrote:
I see your point Sean. My motivation for wrapping the RuntimeException was to
ensure
that the failover mechanism (from OCSP to CRLs) did not get interrupted. But
this is a
case when the failover should be interrupted. I've filed a new bug to address
It's not common to use this style:
74 throw new InvalidKeySpecException
75 (Inappropriate key specification);
but rather:
throw new InvalidKeySpecException(
Inapp...);
Also, what happens in the case that the size doesn't match up with what
On 07/02/2013 02:20 PM, Brad Wetmore wrote:
It's not common to use this style:
74 throw new InvalidKeySpecException
75 (Inappropriate key specification);
but rather:
throw new InvalidKeySpecException(
Inapp...);
That was preexisting code.
Changeset: 3b4f92a3797f
Author:vromero
Date: 2013-07-02 22:49 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/3b4f92a3797f
6326693: variable x might already have been assigned, when assignment is in
catch block
Reviewed-by: mcimadamore
!
Well, I don't think there is anything wrong with the
SecretKeyFactory.generateSecret API.
DESKeySpec/DESedeKeySpec do check the length of the key bytes when
constructed.
If we were to accept the SecretKeySpec object as generic key spec, then
we should add additional checkings and throw
Hi Joe,
Please review this changeset, which fixes doclint errors and warnings in
javax.crypto, javax.security.auth, and javax.security.cert.
Webrev: http://cr.openjdk.java.net/~juh/8019772/webrev.00/
Changeset have been checked for undesirable changes with specdiff.
Thanks,
Jason
Changeset: cf7202b32a34
Author:mchung
Date: 2013-07-02 15:58 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cf7202b32a34
8007035: deprecate public void SecurityManager.checkMemberAccess(Class?
clazz, int which)
Reviewed-by: jrose, alanb, dfuchs
!
From: Sandeep Konchady [mailto:sandeep.konchady-
qhclzuegtsvqt0dzr+a...@public.gmane.org] Sent: Wednesday,
June 19, 2013 7:40 PM To: Mickey SegalCc: Java SecuritySubject:
Re: getCodeBase broken locally in 7 update 25
Hi Mickey,
The issue you are seeing is intended behavior. This was
Hi Jason,
Looks good; approved.
Thanks,
-Joe
On 7/2/2013 3:50 PM, Jason Uh wrote:
Hi Joe,
Please review this changeset, which fixes doclint errors and warnings
in javax.crypto, javax.security.auth, and javax.security.cert.
Webrev: http://cr.openjdk.java.net/~juh/8019772/webrev.00/
On 7/3/2013 4:38 AM, Sean Mullan wrote:
On 07/02/2013 02:49 PM, Vincent Ryan wrote:
I see your point Sean. My motivation for wrapping the RuntimeException
was to ensure
that the failover mechanism (from OCSP to CRLs) did not get
interrupted. But this is a
case when the failover should be
Looks fine to me.
It's a huge update. I mainly focus on the new features introduced in
this update.
In the update of GCM cipher operations, I did not find
Cipher.updateAAD() and GCMParameterSpec get called in XMLCipher. It's
OK because the default value in Oracle provider just meet the
19 matches
Mail list logo
