Hi Serguei,
I uploaded new webrev:
http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.02/
>>> I'd expect a check for some exception name, not for details like: For
>>> input string: "apa".
>>
>>
>> Should we remove this comparison?
>
>
> I don't understand. Why do remove?
> Would it
On 11/7/17 9:04 AM, Harsha Wardhana B wrote:
Hi Mandy,
To summarize the changes,
1. The header will not contain the file modification timestamp.
Instead when the password file is modified, a debug log will be
printed. The log will contain the timestamp.
2. The password file is now
On 11/6/17 04:31, Yasumasa Suenaga wrote:
Hi Serguei,
On 2017/11/06 20:06, serguei.spit...@oracle.com wrote:
Hi Yasumasa,
The changes looks good.
Thank you for making them!
Thanks!
On 11/3/17 05:10, Yasumasa Suenaga wrote:
Hi Serguei,
Thank you for your comment!
I uploaded new webrev:
Hi Vladimir,
I also considered calling nm->make_not_entrant(), but came to the same
conclusion as you.
thanks,
Chris
On 11/7/17 10:39 AM, Vladimir Kozlov wrote:
Looks good to me too. I assume you will add NULL check as Dan suggested.
I thought that you may need to call
Looks good to me too. I assume you will add NULL check as Dan suggested.
I thought that you may need to call nm->make_not_entrant() to deoptimize method. But on other hand you may still want to
run compiled code in other threads. So your fix should is good for your problem.
Thanks,
Vladimir
Hi Roger,
kindly see my understanding below.
On 11/7/2017 9:10 PM, Roger Riggs wrote:
Hi Ujwal,
MBeanOperationInfo:163:
Since the values are fixed, you could more concisely just compare
impact >=0 and impact <= UNKNOWN.
As there are only 4 constants, I thought it would be better to include
Hi Harsha,
HashedPasswordManager.java:
I'd suggest to use java.nio.charset.StandardCharset.UTF_8 instead of
Charset.forName("UTF-8");
The reading of the password file should probably not be allowed if
some process (this one or another one) is currently writing to it,
because you could just
Hi Mandy,
To summarize the changes,
1. The header will not contain the file modification timestamp. Instead
when the password file is modified, a debug log will be printed. The log
will contain the timestamp.
2. The password file is now protected from concurrent writes from within
the JVM.
On 11/7/17 8:26 AM, Harsha Wardhana B wrote:
Hi,
Please find below the webrev addressing Daniel and Mandy's comments.
http://cr.openjdk.java.net/~hb/5016517/webrev.07/
Can you summarize the change?
I thought we agree to only replace the clear passwords with the hashes
and not to alter
Hi,
Please find below the webrev addressing Daniel and Mandy's comments.
http://cr.openjdk.java.net/~hb/5016517/webrev.07/
-Harsha
On Wednesday 01 November 2017 09:42 PM, Daniel Fuchs wrote:
On 31/10/2017 17:07, mandy chung wrote:
On 10/31/17 8:55 AM, Harsha Wardhana B wrote:
Hi Mandy,
Hi Ujwal,
MBeanOperationInfo:163:
Since the values are fixed, you could more concisely just compare impact
>=0 and impact <= UNKNOWN.
257/263: I don't see a reason to change the toString in the default
case for getImpact().
A suggestion would be to introduce an Enum for the action values
Kindly review the fix for bug below.
https://bugs.openjdk.java.net/browse/JDK-8024352
webrev :
http://cr.openjdk.java.net/~uvangapally/webrev/2017/8024352/webrev.00/
Thanks,
Ujwal.
Thanks for the review Mandy,
built image and verified everything is as expected.
Ujwal.
On 11/7/2017 11:45 AM, mandy chung wrote:
Looks good to me.
Please do make docs target to verify.
Mandy
On 11/6/17 9:34 PM, Ujwal Vangapally wrote:
Hi,
kindly take a look at latest changes.
webrev:
Thank you very much, Sharath, for the review. My response inline:
On 11/3/2017 3:44 PM, Sharath Ballal wrote:
Hi Jini,
You have appended 'Field' for most of the SA variables. Example:
private static CIntegerField pcOffsetField;
pcOffsetField = type.getCIntegerField("_pc_offset");
However
14 matches
Mail list logo
