Sounds fine, thank you Xuelei. Would this later be backported to Java 9 too?
-Jaikiran
On 24/02/18 12:21 AM, Xuelei Fan wrote:
Hi Jaikiran,
Thanks a lot for the update. Your code looks fine to me.
As we are working on the re-org of the implementation[1] now, I may
integrate your contributi
> On Feb 24, 2018, at 12:38 AM, Daniel Fuchs wrote:
>
> Hi Max,
>
> 85 // has larger timestamp.
> 86 entries.addFirst(t);
>
> shouldn't you set oldestTime here as well?
The order might be a little misleading, you addFirst() the latest entry and the
oldest o
Thanks for the review Brad. Yes - I'll make those changes before pushing.
regards,
Sean.
On 23/02/2018 20:14, Brad Wetmore wrote:
Minor comments. I'm ok with leaving as is, but this seems cleaner.
MyProvider.java
---
Would prefer to use the non-deprecated super call.
*Digest.jav
Minor comments. I'm ok with leaving as is, but this seems cleaner.
MyProvider.java
---
Would prefer to use the non-deprecated super call.
*Digest.java
Would you consider making these 3 duplicate classes into a single class,
with the three public derived classes within?
Looks fine to me. Thanks!
Xuelei
On 2/23/2018 11:39 AM, Roger Riggs wrote:
Please review cleanup replacements of
System.getProperty("line.separator") with System.lineSeparator().
It uses the line separator from System instead of looking it up in the
properties each time.
Also fixed one javad
Looks good Roger
> On Feb 23, 2018, at 2:39 PM, Roger Riggs wrote:
>
> Please review cleanup replacements of System.getProperty("line.separator")
> with System.lineSeparator().
> It uses the line separator from System instead of looking it up in the
> properties each time.
> Also fixed one ja
Please review cleanup replacements of
System.getProperty("line.separator") with System.lineSeparator().
It uses the line separator from System instead of looking it up in the
properties each time.
Also fixed one javadoc @see reference.
The affected files are in several packages:
com/sun/cry
Hi Jaikiran,
Thanks a lot for the update. Your code looks fine to me.
As we are working on the re-org of the implementation[1] now, I may
integrate your contribution shortly after the re-org changes.
Thanks,
Xuelei
[1]:
http://mail.openjdk.java.net/pipermail/security-dev/2018-February/0168
Hello Sean,
On 29/01/2018 04:30 μμ, Fotis Loukos wrote:
> On 26/01/2018 11:31 μμ, Sean Mullan wrote:
>> On 1/24/18 5:39 AM, Fotis Loukos wrote:
You may not be aware, but the JDK does currently support a mechanism for
blacklisting certificates. The lib/security/blacklisted.certs file
ArrayUtil.java:
===
I'm not very sure how widely this utilities will be used in the future.
Looks like only BigIntegerModuloP uses this classes. I may prefer to
define private methods for byte array swap in BigIntegerModuloP.
BigIntegerModuloP.java:
===
As thi
Updated at http://cr.openjdk.java.net/~weijun/8197518/webrev.02/.
1. ConcurrentHashMap used in MemoryCache. No more "content.remove(key)" but
it's actually useless because rc.isEmpty() will not be true normally. I'll
think about how to clean up unused AuthList objects in another RFE.
2. AuthLis
Hi Max,
85 // has larger timestamp.
86 entries.addFirst(t);
shouldn't you set oldestTime here as well?
best regards,
-- daniel
On 23/02/2018 15:21, Xuelei Fan wrote:
Looks fine to me.
Xuelei
On 2/23/2018 6:13 AM, Weijun Wang wrote:
Updated at http://cr.
Looks fine to me.
Xuelei
On 2/23/2018 6:13 AM, Weijun Wang wrote:
Updated at http://cr.openjdk.java.net/~weijun/8197518/webrev.02/.
1. ConcurrentHashMap used in MemoryCache. No more "content.remove(key)" but
it's actually useless because rc.isEmpty() will not be true normally. I'll think abou
Brilliant idea. I will do more experiment.
Thanks
Max
> On Feb 23, 2018, at 11:25 AM, Xuelei Fan wrote:
>
> Hi Weijun,
>
> I thought more about the performance impact. The impact may mainly come from
> the big size of the cached entries.
>
> The current implementation needs to go over the f
14 matches
Mail list logo
