You are right, I missed the fact that startClient has exception catch
which will allow test to call to serverThread.join(). Updated webrev
fixed this along with some more debug output.
Webrev: http://cr.openjdk.java.net/~rhalade/8158569/webrev.01/
Thanks,
Rajan
On 6/8/16 9:08 PM, Xuelei Fan w
Sean,
Can you please help reviewing this? I suppose we don't need to file CCC
for this, right? There is already an earlier one under 7191662 and this
is just updating comments in java.security file.
Bug: https://bugs.openjdk.java.net/browse/JDK-8157881
Webrev: http://cr.openjdk.java.net/~vale
Anyone can help reviewing this one-line change which removes a redundant
declaration?
As Apple provider is instantiated directly (see
sun.security.jca.ProviderConfig.java) and not loaded through
ServiceLoader , we can safely remove the line for ServiceLoader lookup.
No new regression test a
> On Jun 9, 2016, at 3:22 PM, Valerie Peng wrote:
>
>
> Anyone can help reviewing this one-line change which removes a redundant
> declaration?
>
> As Apple provider is instantiated directly (see
> sun.security.jca.ProviderConfig.java) and not loaded through ServiceLoader ,
> we can safely
Hi,
Please review this small patch for updating ProblemList.
Issue: https://bugs.openjdk.java.net/browse/JDK-8157665
Webrev: http://cr.openjdk.java.net/~jjiang/8157665/webrev.00/
Best regards,
John Jiang
Thanks for the comments. I will update the reg test, i.e.
test/java/security/Provider/DefaultProviderList.java, to check that they
are from java.base.
I don't see a need for built-in security providers to be found through
ServiceLoader.load(Provider.class) though. The expected API usage is to
> On Jun 9, 2016, at 4:22 PM, Valerie Peng wrote:
>
>
> Thanks for the comments. I will update the reg test, i.e.
> test/java/security/Provider/DefaultProviderList.java, to check that they are
> from java.base.
>
To clarify: what I mean is that you should remove the logic that skips the
bu
On 06/08/2016 10:28 AM, Valerie Peng wrote:
Tony,
Can u please help reviewing this? Most if not all of the changes here
are performance enhancements suggestions from the performance team.
I polished them and then updated the java.security file to add SHA-3.
Webrev: http://cr.openjdk.java.net/~v
I see. Looks like I misunderstood your earlier comment.
What you suggested sounds good. I will make modifications accordingly.
Thanks,
Valerie
On 6/9/2016 4:31 PM, Mandy Chung wrote:
On Jun 9, 2016, at 4:22 PM, Valerie Peng wrote:
Thanks for the comments. I will update the reg test, i.e.
te
Webrev updated at: http://cr.openjdk.java.net/~valeriep/8157489/webrev.01
Thanks,
Valerie
On 6/9/2016 4:37 PM, Valerie Peng wrote:
I see. Looks like I misunderstood your earlier comment.
What you suggested sounds good. I will make modifications accordingly.
Thanks,
Valerie
On 6/9/2016 4:31 PM
Hi,
by using a non-exported type, PropertiesWrapper, to encapsulate
Properties this change makes it impossible for a JDK developer to
accidentally leak system properties outside of java.base without
breaking encapsulation. I believe that was yours and Sean's main concern
about the API changes
Sure, I think it should be ok to skip the checks.
Webrev is updated at: http://cr.openjdk.java.net/~valeriep/8157495/webrev.01
I have removed the update on java.security file and we can address this
later if needed.
Thanks for the review,
Valerie
On 6/9/2016 4:36 PM, Anthony Scarpino wrote:
O
Hi Tony,
Could you please help reviewing this? Solaris crypto team made some
changes in the Ucrypto area since S11.3 which breaks JDK build.
This is the workaround (and some minor clean up) for S11.3. This
incompatible change will be addressed starting S12 but not S11.3 due to
their release mo
> On Jun 9, 2016, at 5:26 PM, Valerie Peng wrote:
>
> Webrev updated at: http://cr.openjdk.java.net/~valeriep/8157489/webrev.01
>
51 if (!pClass.getModule().getName().equals("java.base")) {
You can check if Module object is Object.class.getModule() instead of checking
the mod
Looks fine to me.
Thanks,
Xuelei
On 6/10/2016 7:01 AM, John Jiang wrote:
> Hi,
> Please review this small patch for updating ProblemList.
>
> Issue: https://bugs.openjdk.java.net/browse/JDK-8157665
> Webrev: http://cr.openjdk.java.net/~jjiang/8157665/webrev.00/
>
> Best regards,
> John Jiang
>
Hi Claes,
I don’t like the PropertiesWrapper idea. The caller should be cautious in
storing any sensitive information. For the system properties, these callsites
use it in the local scope that I don’t see any reason and benefit to introduce
a wrapper. I didn’t follow this discussion closely
Hi folks, can I please get a quick review for a very simple javadoc fix
in X509KeyManager?
Bug: https://bugs.openjdk.java.net/browse/JDK-8157925
Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8157925/webrev.01
Thanks!
--Jamil
Looks good.
Tony
> On Jun 9, 2016, at 5:35 PM, Valerie Peng wrote:
>
> Sure, I think it should be ok to skip the checks.
> Webrev is updated at: http://cr.openjdk.java.net/~valeriep/8157495/webrev.01
>
> I have removed the update on java.security file and we can address this later
> if need
Looks fine to me.
Tony
> On Jun 9, 2016, at 9:49 PM, Jamil Nimeh wrote:
>
> Hi folks, can I please get a quick review for a very simple javadoc fix in
> X509KeyManager?
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8157925
> Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8157925/web
19 matches
Mail list logo
