On Tue, 19 Oct 2021 04:08:12 GMT, Wu Yan wrote:
>> Hi,
>> Please help me review the change to enhance getting time zone ID from
>> /etc/localtime on linux.
>>
>> We use `realpath` instead of `readlink` to obtain the link name of
>> /etc/localtime, because `readlink` can only read the value
On Thu, 14 Oct 2021 02:08:45 GMT, Wu Yan wrote:
>> Hi,
>> Please help me review the change to enhance getting time zone ID from
>> /etc/localtime on linux.
>>
>> We use `realpath` instead of `readlink` to obtain the link name of
>> /etc/localtime, because `readlink` can only read the value
On Mon, 26 Apr 2021 01:17:43 GMT, Hamlin Li wrote:
> code like below will create Deflater before null check, although it's not a
> real mem leak, but it's better to do null check before new Deflater.
>
> try {
> DeflaterOutputStream dos = new DeflaterOu
On Mon, 26 Apr 2021 14:55:57 GMT, Lance Andersen wrote:
> Hi Hamlin,
>
> The change looks fine. Please add the noreg-trivial change to the issue given
> there is not a test update for this so that you do not get pinged by a bot
Hi Lance, Thanks for reminding.
Thanks @LanceAndersen @naotoj
On Mon, 26 Apr 2021 02:36:54 GMT, Hamlin Li wrote:
>> code like below will create Deflater before null check, although it's not a
>> real mem leak, but it's better to do null check before new Deflater.
>>
>> try {
>> DeflaterOutputStream dos =
PointerException e) {
> passed = true;
> }
> Similar issues exist in several other classes.
Hamlin Li has updated the pull request incrementally with one additional commit
since the last revision:
update copyrights.
-
Changes:
- all: https://git.openjdk.java.net/
code like below will create Deflater before null check, although it's not a
real mem leak, but it's better to do null check before new Deflater.
try {
DeflaterOutputStream dos = new DeflaterOutputStream(null);
} catch (NullPointerException e) {
passed =
On Sat, 23 Jan 2021 07:52:55 GMT, Alan Bateman wrote:
>> this is minor optimization following JDK-8254078.
>> based on my tests with jmh, it has better performance when apply following
>> patch:
>>
>> diff --git a/src/java.base/share/classes/java/io/DataOutputStream.java
>>
On Fri, 22 Jan 2021 02:57:36 GMT, Hamlin Li wrote:
> this is minor optimization following JDK-8254078.
> based on my tests with jmh, it has better performance when apply following
> patch:
>
> diff --git a/src/java.base/share/classes/java/io/DataOutputStream.java
> b/s
this is minor optimization following JDK-8254078.
based on my tests with jmh, it has better performance when apply following
patch:
diff --git a/src/java.base/share/classes/java/io/DataOutputStream.java
b/src/java.base/share/classes/java/io/DataOutputStream.java
index 9a9a687403c..4ea497fc7c0
Hi Roger,
Thanks for reviewing.
Thank you
-Hamlin
On 2019/11/27 11:09 PM, Roger Riggs wrote:
Looks good.
Thanks for the revisions, Roger
On 11/26/19 8:51 PM, Hamlin Li wrote:
Hi Roger,
Thanks for reviewing, I have updated as you suggested:
http://cr.openjdk.java.net/~mli/8232446
that the logging happened before/outside the test
for socket != null.
if (TCPTransport.tcpLog.isLoggable(Log.BRIEF)) {
TCPTransport.tcpLog.log(Log.BRIEF,"close connection, socket: " + socket);
}if (socket != null) { Thanks, Roger
On 11/22/19 2:54 AM, Hamlin Li wrote:
Hi Roger,
of and too many log levels.
Reword the log messages so they each begin with "server socket...",
or "server socket close"...
it makes it easier to grep for and coorelate related messages
Thanks, Roger
On 11/6/19 7:02 AM, Hamlin Li wrote:
On 2019/11/6
as I think it's simple/straight and sufficient to help diagnose.
And I also add log for catch blocks in other close places.
The change is updated in place at:
http://cr.openjdk.java.net/~mli/8232446/webrev.00/
Thank you
-Hamlin
Regards, Peter
On 11/6/19 3:07 AM, Hamlin Li wrote:
Would
Would you please review the patch?
bug: https://bugs.openjdk.java.net/browse/JDK-8232446
webrev: http://cr.openjdk.java.net/~mli/8232446/webrev.00/
We have some intermittent failures in rmi related to socket closing,
this is to add more logging to help diagnose the issues.
Thanks you
njdk.java.net/browse/JDK-8233105>).
Thank you
-Hamlin
$.02, Roger
BTW, verifyPortFree() would easier to understand and code with if it
returned a boolean
instead throwing an exception. The non-local exception handling makes
the code harder to follow.
On 11/1/19 12:47 AM, Hamlin Li w
This is found during fixing JDK-8233105
<https://bugs.openjdk.java.net/browse/JDK-8233105>, so please consider
test scenario in JDK-8233105
<https://bugs.openjdk.java.net/browse/JDK-8233105>
On 2019/11/1 12:47 PM, Hamlin Li wrote:
Would you please to review the following patch?
Would you please to review the following patch?
bug: https://bugs.openjdk.java.net/browse/JDK-8233313
webrev: http://cr.openjdk.java.net/~mli/8233313/webrev.00/
With following code, port used behind is not closed after unexportObject
/Registry registry = LocateRegistry.createRegistry(0);//
remove that variable.
Thanks for the information.
I think it will be more clear when JDK-8232446
<https://bugs.openjdk.java.net/browse/JDK-8232446> is finished, let see
then. :-)
Thank you
-Hamlin
On 10/16/19 1:28 AM, Hamlin Li wrote:
Thanks Roger, sorry for that I missed your re
Thanks Roger, sorry for that I missed your response. (most of time I
focus on mail send to/cc me :) )
On 2019/10/15 10:29 PM, Roger Riggs wrote:
Hi,
1. Replace the creation of the Registry with
TestLibrary.crateRegistryOnEphemeralPort
and call TestLibrary.getRegistryPort to get the port
hink about it?
Thank you
-Hamlin
Thanks,
Max
Thank you
-Hamlin
--Max
Thank you
-Hamlin
--Max
On Oct 15, 2019, at 11:04 AM, Hamlin Li wrote:
Thanks for reviewing, I updated change at:
http://cr.openjdk.java.net/~mli/8134599/webrev.01/
it does not increase minimum time time an
On 2019/10/15 7:50 PM, Weijun Wang wrote:
On Oct 15, 2019, at 5:44 PM, Hamlin Li wrote:
On 2019/10/15 2:44 PM, Weijun Wang wrote:
I am OK with the change that makes this test more robust.
Thanks Max.
However, I am not an expert in RMI and don't know why the port cannot be
released
Thanks Alan, I will add the @modules.
Please let me know your further comments, I haven't push the code yet.
Thank you
-Hamlin
On 2019/10/15 9:46 PM, Alan Bateman wrote:
On 15/10/2019 03:03, Hamlin Li wrote:
Could some help to review it?
I haven't studied the test but one thing that seems
mes. In my point of view, current logging is
sufficient for diagnosing.
Thank you
-Hamlin
--Max
On Oct 15, 2019, at 11:04 AM, Hamlin Li wrote:
Thanks for reviewing, I updated change at:
http://cr.openjdk.java.net/~mli/8134599/webrev.01/
it does not increase minimum time time and consid
Thank you for reviewing David. I will update/push the change as you
suggested.
BTW, sorry for the wrong bug number in email subject, it should be 8209824.
Thank you
-Hamlin
On 2019/10/15 10:29 AM, David Holmes wrote:
Hi Hamlin,
On 15/10/2019 12:03 pm, Hamlin Li wrote:
Could some help
0ms and
see how test behaves". So what do you think?
Thanks,
Max
On Oct 15, 2019, at 10:03 AM, Hamlin Li wrote:
Hi,
The test is failing more frequently, could some help to review it?
Thank you
-Hamlin
On 2019/9/4 11:11 AM, Hamlin Li wrote:
some background & com
Could some help to review it?
Thank you
-Hamlin
On 2019/9/4 3:16 PM, Hamlin Li wrote:
Would you please review the following patch?
bug: https://bugs.openjdk.java.net/browse/JDK-8209824
webrev: http://cr.openjdk.java.net/~mli/8209824/webrev.00/
Thank you
-Hamlin
Hi,
The test is failing more frequently, could some help to review it?
Thank you
-Hamlin
On 2019/9/4 11:11 AM, Hamlin Li wrote:
some background & comment: in most of failures, the
"test.timeout.factor" is 10.0 or 8.0, so in the test code this factor
should be considered in
Would you please review the following patch?
bug: https://bugs.openjdk.java.net/browse/JDK-8209824
webrev: http://cr.openjdk.java.net/~mli/8209824/webrev.00/
Thank you
-Hamlin
some background & comment: in most of failures, the
"test.timeout.factor" is 10.0 or 8.0, so in the test code this factor
should be considered in rmi operations such unexporting an object.
Thank you
-Hamlin
On 2019/9/4 11:01 AM, Hamlin Li wrote:
Hi,
Would you please review
Hi,
Would you please review the following patch?
Bug: https://bugs.openjdk.java.net/browse/JDK-8134599
webrev: http://cr.openjdk.java.net/~mli/8134599/webrev.00/
Thank you
-Hamlin
Hi,
Thank you for reviewing this, it's just pushed, I'm sorry for the
inconvenience.
Thank you
-Hamlin
On 2018/11/29 5:12 AM, Chris Hegarty wrote:
I think this good. Thanks.
-Chris.
On 28 Nov 2018, at 20:32, David Holmes wrote:
Hi Hamlin,
On 28/11/2018 10:52 pm, Hamlin Li wrote:
Hi
/28 9:09 PM, li.ji...@oracle.com wrote:
Hi Hamlin,
You can find some tests under sun/management/jmxremote/ failed on this
issue too.
Thanks,
Leo
On 11/28/18 7:15 PM, Hamlin Li wrote:
Hi David,
Thank a lot for double checking the usage of testlibrary.
I have updated the patch,
http
ug it's OK to just address failed tests, and
address complete removal of /lib/testlibrary/ in JDK-8214435.
Thank you
-Hamlin
On 2018/11/28 8:08 PM, David Holmes wrote:
Hi Hamlin,
On 28/11/2018 9:15 pm, Hamlin Li wrote:
Hi David,
Thank a lot for double checking the usage of testlibrary.
I ha
.* jdk.test.lib.Platform
AbstractFilePermissionTest Dummy
Cheers,
David
-
On 28/11/2018 8:14 pm, Hamlin Li wrote:
Would you please review the following patch?
This is a regression by JDK-8211975.
bug: https://bugs.openjdk.java.net/browse/JDK-8214431
patch at the bottom.
Thank you
-Hamlin
Would you please review the following patch?
This is a regression by JDK-8211975.
bug: https://bugs.openjdk.java.net/browse/JDK-8214431
patch at the bottom.
Thank you
-Hamlin
diff -r 70adb0f573a7
Would you please review the following patch?
https://bugs.openjdk.java.net/browse/JDK-8211975
http://cr.openjdk.java.net/~mli/8211975/webrev.00/
Thank you
-Hamlin
On Oct 11, 2018, at 11:28 PM, Amy Lu wrote:
On 2018/10/12 2:16 PM, Hamlin Li wrote:
yes, e.g. https://bugs.openjdk.java.net/browse/JDK-8212033
It seems mentioned bug is duplicate with
JDK-8211972: remove testlibrary/java/util/jar/Compiler.java - "suggest removing and
Ping...
On 2018/10/12 2:00 PM, Hamlin Li wrote:
Hi Igor,
It's updated in place
http://cr.openjdk.java.net/~mli/8211974/webrev.00/, please review it
again.
Thank you
-Hamlin
On 2018/10/12 1:34 PM, Igor Ignatyev wrote:
Hi Hamlin,
could you please move jdk.test.lib.util.Compiler
h existing
jdk.test.lib.compiler.CompilerUtils?
- test/lib/jdk/test/lib/util/JarBuilder.java (was
test/jdk/lib/testlibrary/java/util/jar/JarBuilder.java)
Any future plan to "merge" it with existing jdk.test.lib.util.JarUtils?
Thanks,
Amy
On 2018/10/12 2:00 PM, Hamlin Li wrote:
Hi Igor,
It's up
which have dependency on jdk.compiler and/or
java.compiler module.
it'd also be nice to put CreateMultiReleaseTestJars into a named package.
-- Igor
On Oct 11, 2018, at 10:23 PM, Hamlin Li wrote:
would you please review the following patch?
bug:
https://bugs.openjdk.java.net/browse
would you please review the following patch?
bug:
https://bugs.openjdk.java.net/browse/JDK-8211974
https://bugs.openjdk.java.net/browse/JDK-8211972
https://bugs.openjdk.java.net/browse/JDK-8211973
https://bugs.openjdk.java.net/browse/JDK-8211979
webrev:
ools/jlink/plugins/SystemModuleDescriptors/ tests.
thanks for updating webrev, I have one nit --- given ModuleUtils is
the only class in jdk/test/lib/module package, I doubt we need to
introduce this package, ModuleUtils can be put into j.t.l.util package.
-- Igor.
On Oct 10, 2018, at 11:31 PM,
t/browse/JDK-8211290
-- Igor
On Oct 10, 2018, at 8:26 PM, Hamlin Li <mailto:huaming...@oracle.com>> wrote:
Hi Igor,
Would you please clarify your concern further? I mean why
ModuleTargetHelper can be put to top level when it use non-public
APIs e.g. jdk.internal.module.*?
Thank you
-H
Hi Igor,
Would you please clarify your concern further? I mean why
ModuleTargetHelper can be put to top level when it use non-public APIs
e.g. jdk.internal.module.*?
Thank you
-Hamlin
On 2018/10/11 11:08 AM, Igor Ignatyev wrote:
Hi Hamlin,
as ModuleTargetHelper uses non-public API, I'd
Would you please review the following patch?
bug:
https://bugs.openjdk.java.net/browse/JDK-8186610
https://bugs.openjdk.java.net/browse/JDK-8211976
webrev: http://cr.openjdk.java.net/~mli/8186610/
Thank you
-Hamlin
Would you please review the following patch?
bug: https://bugs.openjdk.java.net/browse/JDK-8202756
webrev: http://cr.openjdk.java.net/~mli/8202756/webrev.00/
Thank you
-Hamlin
Is someone available to review the following patch?
Thank you
-Hamlin
On 28/04/2018 11:32 AM, Hamlin Li wrote:
would you please review the patch?
bug: https://bugs.openjdk.java.net/browse/JDK-8202291
webrev: http://cr.openjdk.java.net/~mli/8202291/webrev.00/
In original code
Hi Joe,
just a minor comment about the test in ReadWriteString.java.
For both testMalformedWrite and testMalformedRead, temp files are not
deleted, as Files.deleteIfExists(path); is skipped by the expected
IOException. File.deleteOnExit() may help.
Thank you
-Hamlin
On 27/04/2018 12:50
would you please review the patch?
bug: https://bugs.openjdk.java.net/browse/JDK-8202291
webrev: http://cr.openjdk.java.net/~mli/8202291/webrev.00/
In original code, there is a window between get registry and rebind
which could cause connection refuse.
Thank you
-Hamlin
impact on
execution time?
Paul.
On Apr 20, 2018, at 12:21 AM, Hamlin Li <huaming...@oracle.com> wrote:
Is someone available to review the following patch?
Thank you
-Hamlin
On 19/04/2018 4:17 PM, Hamlin Li wrote:
would you please review the following patch?
bug:
Is someone available to review the following patch?
Thank you
-Hamlin
On 19/04/2018 4:17 PM, Hamlin Li wrote:
would you please review the following patch?
bug: https://bugs.openjdk.java.net/browse/JDK-8201469
http://cr.openjdk.java.net/~mli/8201469/webrev.00/
( For othervm.dirs property
would you please review the following patch?
bug: https://bugs.openjdk.java.net/browse/JDK-8201469
http://cr.openjdk.java.net/~mli/8201469/webrev.00/
( For othervm.dirs property, I just reformat it. )
In my test result, with jtreg option "-concurrency:4", after apply the
patch, tier3 tests
or exception.
Thanks, Roger
On 4/11/2018 10:47 PM, Hamlin Li wrote:
would you please review the following patch?
bug: https://bugs.openjdk.java.net/browse/JDK-8078221
webrev: http://cr.openjdk.java.net/~mli/8078221/webrev.00/
Thank you
-Hamlin
would you please review the following patch?
bug: https://bugs.openjdk.java.net/browse/JDK-8078221
webrev: http://cr.openjdk.java.net/~mli/8078221/webrev.00/
Thank you
-Hamlin
it as expectException, and move it to the last parameter.
new webrev is updated in place:
http://cr.openjdk.java.net/~mli/8188897/webrev.02/
Thank you
-Hamlin
Thanks, Roger
On 4/8/2018 4:10 AM, Hamlin Li wrote:
Hi Roger,
I have changed to not use RegistryVM at all, please review the patch:
http
at it does not break any existing uses.
178: 187: The method comments are not consistent, one says forcibly
and the other gracefully
but both call requestExit and both call destroy().
Thanks, Roger
On 4/3/2018 11:35 PM, Hamlin Li wrote:
Hi Joe, Roger,
Thank you for reviewing, I have refactore
will only kill the subprocess if
it still is alive.
Roger
On 4/2/2018 6:33 AM, Hamlin Li wrote:
would you please review the following patch?
bug: https://bugs.openjdk.java.net/browse/JDK-8188897
webrev: http://cr.openjdk.java.net/~mli/8188897/webrev.00/
Thank you
-Hamlin
would you please review the following patch?
bug: https://bugs.openjdk.java.net/browse/JDK-8188897
webrev: http://cr.openjdk.java.net/~mli/8188897/webrev.00/
Thank you
-Hamlin
On 19/01/2018 3:09 PM, David Holmes wrote:
Hi Hamlin,
On 19/01/2018 4:28 PM, Hamlin Li wrote:
On 19/01/2018 2:11 PM, David Holmes wrote:
Hi Hamlin,
On 19/01/2018 3:04 PM, Hamlin Li wrote:
Hi Roger, David
Please check the updated webrev at:
http://cr.openjdk.java.net/~mli/8194284/webrev
On 19/01/2018 2:11 PM, David Holmes wrote:
Hi Hamlin,
On 19/01/2018 3:04 PM, Hamlin Li wrote:
Hi Roger, David
Please check the updated webrev at:
http://cr.openjdk.java.net/~mli/8194284/webrev.00/
RMID.java:
This comment no longer makes sense:
// when restart rmid, it may take
in computeDeadline. It is better to cleanup the
implementation of the test library
than to fudge the values. Either respect the timeouts passed in
(remove the scaling from computeDeadline)
or consistently leave it to the lower level routines. Pick 1.
Thanks, Roger
On 1/18/2018 1:59 AM, Hamlin Li
On 18/01/2018 5:07 PM, David Holmes wrote:
On 18/01/2018 6:05 PM, Hamlin Li wrote:
On 18/01/2018 3:48 PM, David Holmes wrote:
On 18/01/2018 5:41 PM, Hamlin Li wrote:
Hi David,
Sometime we will run test by command "jtreg -timeoutFactor:xxx
...", xxx
Yes but that controls
On 18/01/2018 3:48 PM, David Holmes wrote:
On 18/01/2018 5:41 PM, Hamlin Li wrote:
Hi David,
Sometime we will run test by command "jtreg -timeoutFactor:xxx ...", xxx
Yes but that controls how jtreg manages the execution of the test.
right.
How is that then being used by
de reviews.
On 18/01/2018 4:59 PM, Hamlin Li wrote:
Would you please review the following patch?
bug: https://bugs.openjdk.java.net/browse/JDK-8194284
webrev as below.
I don't agree with this. Whatever is passing the incorrect timeout to
the TestLibrary should be fixed. The bug report
d be cleaned up.
+1
( Not a reviewer.)
Thanks,
Amy
On 7/10/17 5:17 PM, Hamlin Li wrote:
Would you please review below patch?
bug: https://bugs.openjdk.java.net/browse/JDK-8184062
webrev: http://cr.openjdk.java.net/~mli/8184062/webrev.00/
<http://cr.openjdk.java.net/%7Emli/8184062/we
Would you please review below patch?
bug: https://bugs.openjdk.java.net/browse/JDK-8184062
webrev: http://cr.openjdk.java.net/~mli/8184062/webrev.00/, also attach
diff as below
Thank you
-Hamlin
diff -r 18b09cba334b
On 2017/6/17 1:31, Paul Sandoz wrote:
On 14 Jun 2017, at 23:29, Hamlin Li <huaming...@oracle.com> wrote:
Hi Alan, Paul,
Thank you for review, new webrev at:
http://cr.openjdk.java.net/~mli/8181478/webrev.01/
Please also check my comments inline.
On 2017/6/15 1:28, Alan Bateman
this looks to be a common usage, at least in encoding use cases.
-Felix
On 2017/6/16 11:40, Hamlin Li wrote:
Hi Felix,
Thank you for your suggestions.
But I think it's just a java wrapper around a shell, not a real java.
Thank you
-Hamlin
On 2017/6/16 9:41, Felix Yang wrote:
Hi Hamlin,
I
/DefaultCharsetTest.java.html
In further, you may extend and wrap such usage in ProcessTools,
because this looks to be a common usage, at least in encoding use cases.
Good point. Thank you Felix, I will do it.
Thank you
-Hamlin
-Felix
On 2017/6/16 11:40, Hamlin Li wrote:
Hi Felix,
Thank you for your suggestions
Ping.
Thank you
-Hamlin
On 2017/6/15 14:29, Hamlin Li wrote:
Hi Alan, Paul,
Thank you for review, new webrev at:
http://cr.openjdk.java.net/~mli/8181478/webrev.01/
Please also check my comments inline.
On 2017/6/15 1:28, Alan Bateman wrote:
On 14/06/2017 18:20, Paul Sandoz wrote
or user.language/user.country properties won't
affect the default encoding determination. Other properties
(file.encoding/sun.jnu.encoding) would set the default, but I am not
sure how they are supposed to be used in regression tests.
Naoto
On 6/15/17 4:59 PM, Hamlin Li wrote:
Hi Naoto,
T
the default, but I am not
sure how they are supposed to be used in regression tests.
Naoto
On 6/15/17 4:59 PM, Hamlin Li wrote:
Hi Naoto,
Thank you for comments.
Do you mean there is no way to set encoding through system property
or java API? And can I understand it as it's better to keep
the default Java Locale and/or user.* properties has nothing
to do with the default encoding. The default encoding on mac/unix
environments is determined from the environment variable LC_CTYPE.
Naoto
On 6/14/17 8:35 PM, Hamlin Li wrote:
On 2017/6/15 1:22, Alan Bateman wrote:
On 12/06/2017 09:00
Hi Alan, Paul,
Thank you for review, new webrev at:
http://cr.openjdk.java.net/~mli/8181478/webrev.01/
Please also check my comments inline.
On 2017/6/15 1:28, Alan Bateman wrote:
On 14/06/2017 18:20, Paul Sandoz wrote:
On 12 Jun 2017, at 01:00, Hamlin Li <huaming...@oracle.com>
On 2017/6/15 1:22, Alan Bateman wrote:
On 12/06/2017 09:00, Hamlin Li wrote:
Would you please review the below patch?
bug: https://bugs.openjdk.java.net/browse/JDK-8181912
webrev: http://cr.openjdk.java.net/~mli/8181912/webrev.00/
Are you sure that setting the user.* properties
Also disable to run ParallelPrefix.java in concurrency.
Ok.
Please check the new webrev: http://cr.openjdk.java.net/~mli/8179242/webrev.01/
29 * @run testng/othervm -Xms256m -Xmx1024m ParallelPrefix
Why are you setting the max heap size?
In my test result, 1024M is sufficient, and if
Ping.
Thank you
-Hamlin
On 2017/6/12 16:00, Hamlin Li wrote:
Would you please review the below patch?
bug: https://bugs.openjdk.java.net/browse/JDK-8181912
webrev: http://cr.openjdk.java.net/~mli/8181912/webrev.00/
Thank you
-Hamlin
Hi Paul,
Please check my comments inline below.
On 2017/6/14 1:23, Paul Sandoz wrote:
On 12 Jun 2017, at 20:37, Hamlin Li <huaming...@oracle.com> wrote:
Hi Paul,
Good idea. Although the downside is the test will depend on java.management and
jdk.management modules, I think it's acce
is necessary.
Thank you
-Hamlin
On 2017/6/13 21:55, Roger Riggs wrote:
Hi Hamlin,
For max memory is Runtime.maxMemory insufficient?
Thanks, Roger
On 6/12/2017 11:37 PM, Hamlin Li wrote:
Hi Paul,
Good idea. Although the downside is the test will depend on
java.management
should).
Paul.
On 12 Jun 2017, at 02:38, Hamlin Li <huaming...@oracle.com> wrote:
Would you please review the below patch?
bug: https://bugs.openjdk.java.net/browse/JDK-8179242
webrev: http://cr.openjdk.java.net/~mli/8179242/webrev.00/
Thank you
-
Would you please review the below patch?
bug: https://bugs.openjdk.java.net/browse/JDK-8179242
webrev: http://cr.openjdk.java.net/~mli/8179242/webrev.00/
Thank you
-Hamlin
the test takes about 700M on linux 64, so
Would you please review the below patch?
bug: https://bugs.openjdk.java.net/browse/JDK-8181912
webrev: http://cr.openjdk.java.net/~mli/8181912/webrev.00/
Thank you
-Hamlin
Would you please review the below patch?
bug: https://bugs.openjdk.java.net/browse/JDK-8181478
webrev: http://cr.openjdk.java.net/~mli/8181478/webrev.00/
Thank you
-Hamlin
Thank you for
-Hamlin
-- Igor
On Jun 8, 2017, at 7:58 PM, Hamlin Li <huaming...@oracle.com
<mailto:huaming...@oracle.com>> wrote:
Hi Igor,
I'm coping Jon as it needs Jon's comments.
Thank you for doing such a great refactoring, I believe it will make
tests run more stable.
I saw y
) and restore "just for safe".
The encoding check (and warnings/usage) is mainly for helping one who
tries to run it from command line.
Thanks,
Amy
On 6/9/17 10:14 AM, Hamlin Li wrote:
Hi Amy,
For refactoring MacPathTest, I wonder if it's sufficient to just
change below line?
- *
Hi Igor,
I'm coping Jon as it needs Jon's comments.
Thank you for doing such a great refactoring, I believe it will make
tests run more stable.
I saw you are adding explicit @build to lots of test, are you going to
clean up all tests to add explicit @build? If the answer is "yes", then
I
Hi Amy,
For refactoring MacPathTest, I wonder if it's sufficient to just change
below line?
- * @run shell MacPathTest.sh
+ * @run main/othervm -Duser.language=en -Duser.country=US
-Dfile.encoding=UTF-8 -Dsun.jnu.encoding=UTF-8 MacPathTest
*/
Thank you
-Hamlin
On 2017/6/7 14:14, Amy
t;, "TestEntry",
"-d"}},
You don’t need declare the allocations within array initializer blocks.
Paul.
On 4 Jun 2017, at 18:37, Hamlin Li <huaming...@oracle.com> wrote:
Ping.
Thank you
-Hamlin
On 2017/6/1 16:22, Hamlin Li wrote:
Would you please review the below p
Ping.
Thank you
-Hamlin
On 2017/6/1 16:22, Hamlin Li wrote:
Would you please review the below patch?
bug: https://bugs.openjdk.java.net/browse/JDK-8180927
webrev: http://cr.openjdk.java.net/~mli/8180927/webrev.00/
Thank you
-Hamlin
Would you please review the below patch?
bug: https://bugs.openjdk.java.net/browse/JDK-8180927
webrev: http://cr.openjdk.java.net/~mli/8180927/webrev.00/
Thank you
-Hamlin
Ping.
Thank you
-Hamlin
On 2017/5/31 8:13, Hamlin Li wrote:
Hi Alan, Sergey,
Sorry for delayed reply, I have been on vacation for last few days.
I do have a tool (still under development, it's based on javadoc
doclet) to scan versions (currently from 1.7 to 9) of jdk source, find
since
ore "{"
56: Generally, exception messages should not end in "."; they are phrases
so they could be printed with context.
In this specific case it is not important, just a pattern to follow
consistently.
Thanks, Roger
On 5/26/2017 9:14 PM, Hamlin Li wrote:
Hi Roger,
T
. As for older
versions, we only need to fix issues once, so I think it's worth to do
the necessary manual check and fix.
Thank you
-Hamlin
On 2017/5/27 14:17, Alan Bateman wrote:
On 27/05/2017 02:14, Hamlin Li wrote:
Is someone available to review the change?
I skimmed through it, crossing checking
Ping.
Thank you
-Hamlin
On 2017/5/27 9:14, Hamlin Li wrote:
Hi Roger,
Thank you for catching it, new webrev:
http://cr.openjdk.java.net/~mli/8166142/webrev.02/
Thank you
-Hamlin
On 2017/5/27 3:30, Roger Riggs wrote:
Hi Hamlin,
SubclassTest.java:37: typo" excepiton" -&
Is someone available to review the change?
Thank you
-Hamlin
On 2017/5/25 17:19, Hamlin Li wrote:
Would you please review below patch?
bug: https://bugs.openjdk.java.net/browse/JDK-8181082
webrev: http://cr.openjdk.java.net/~mli/8181082/webrev.00/
Thank you
-Hamlin
test function.
But for simplicity, perhaps just leave out the new calls to ldr1/2.close.
(There is something odd about the webrev links, the nagivation links
don't work as expected. but that's transient)
Thanks, Roger
On 5/26/2017 12:26 AM, Hamlin Li wrote:
Hi Roger,
Thank you for detailed
Regards, Roger
On 5/24/2017 5:09 AM, Hamlin Li wrote:
Would you please review the below patch?
bug: https://bugs.openjdk.java.net/browse/JDK-8166142
webrev: http://cr.openjdk.java.net/~mli/8166142/webrev.00/
Thank you
-Hamlin
Would you please review below patch?
bug: https://bugs.openjdk.java.net/browse/JDK-8181082
webrev: http://cr.openjdk.java.net/~mli/8181082/webrev.00/
Thank you
-Hamlin
Thank you for review Brent.
I still need a official reviewer to review the change.
Thank you
-Hamlin
On 2017/5/24 23:59, Brent Christian wrote:
Looks fine to me, Hamlin.
Thanks,
-Brent
On 5/24/17 2:18 AM, Hamlin Li wrote:
Hi Roger, Brent,
Thank you for reviewing, please check new webrev
1 - 100 of 220 matches
Mail list logo
