On Tue, 8 Jun 2021 13:37:10 GMT, Thomas Stuefe wrote:
>> Henry Jen has updated the pull request with a new target base due to a merge
>> or a rebase. The incremental webrev excludes the unrelated changes brought
>> in by the merge/rebase. The pull request contains seven
stackLeak();
> }
>
> public static void main(String[] args) {
> var test = new StackLeak();
> try {
> test.stackLeak();
> } catch (Throwable e) {
> System.out.println(test.depth);
> }
> }
> }
Henry
On Tue, 8 Jun 2021 08:17:54 GMT, Thomas Stuefe wrote:
>> Henry Jen has updated the pull request with a new target base due to a merge
>> or a rebase. The incremental webrev excludes the unrelated changes brought
>> in by the merge/rebase. The pull request contains seven
On Tue, 8 Jun 2021 02:36:26 GMT, David Holmes wrote:
>> Henry Jen has updated the pull request with a new target base due to a merge
>> or a rebase. The incremental webrev excludes the unrelated changes brought
>> in by the merge/rebase. The pull request contains seven
On Mon, 7 Jun 2021 03:18:32 GMT, Henry Jen wrote:
>> …d on macOS
>>
>> This patch simply round up the specified stack size to multiple of the
>> system page size.
>>
>> Test is trivial, simply run java with -Xss option against following code. O
On Mon, 7 Jun 2021 03:18:32 GMT, Henry Jen wrote:
>> …d on macOS
>>
>> This patch simply round up the specified stack size to multiple of the
>> system page size.
>>
>> Test is trivial, simply run java with -Xss option against following code. O
stackLeak();
> }
>
> public static void main(String[] args) {
> var test = new StackLeak();
> try {
> test.stackLeak();
> } catch (Throwable e) {
> System.out.println(test.depth);
> }
> }
>
stackLeak();
> }
>
> public static void main(String[] args) {
> var test = new StackLeak();
> try {
> test.stackLeak();
> } catch (Throwable e) {
> System.out.println(test.depth);
> }
> }
> }
Henry
stackLeak();
> }
>
> public static void main(String[] args) {
> var test = new StackLeak();
> try {
> test.stackLeak();
> } catch (Throwable e) {
> System.out.println(test.depth);
> }
> }
>
stackLeak();
> }
>
> public static void main(String[] args) {
> var test = new StackLeak();
> try {
> test.stackLeak();
> } catch (Throwable e) {
> System.out.println(test.depth);
> }
> }
> }
Henry
On Fri, 28 May 2021 21:55:24 GMT, Henry Jen wrote:
> …d on macOS
>
> This patch simply round up the specified stack size to multiple of the system
> page size.
>
> Test is trivial, simply run java with -Xss option against following code. On
> MacOS, before the fix, r
On Fri, 28 May 2021 21:55:24 GMT, Henry Jen wrote:
> …d on macOS
>
> This patch simply round up the specified stack size to multiple of the system
> page size.
>
> Test is trivial, simply run java with -Xss option against following code. On
> MacOS, before the fix, r
On Mon, 31 May 2021 20:23:53 GMT, Vladimir Kempik wrote:
>> src/java.base/macosx/native/libjli/java_md_macosx.m line 727:
>>
>>> 725:
>>> 726: static size_t alignUp(size_t stack_size) {
>>> 727: long page_size = sysconf(_SC_PAGESIZE);
>>
>> In hotspot we use `getpagesize()`. There is also
…d on macOS
This patch simply round up the specified stack size to multiple of the system
page size.
Test is trivial, simply run java with -Xss option against following code. On
MacOS, before the fix, running with `-Xss159k` and `-Xss160k` would get `7183`
and `649` respectively. After fix,
On Sun, 14 Mar 2021 23:34:55 GMT, Henry Jen wrote:
> This patch ensure launcher won't crash JVM for the new static Methods from
> local/anonymous class on MacOS.
>
> As @dholmes-ora pointed out in the analysis, this is a MacOS specific bug
> when the launcher trying to
On Wed, 17 Mar 2021 08:55:54 GMT, Alan Bateman wrote:
> > > Using an anonymous class for the main class looks strange and hard to
> > > believe anyone is relying on this. I wonder if we should do more checking
> > > LauncherHelper.validateMainClass to reject cases like this.
> >
> >
> > I
ity to choose such a default name. It seems to me
> the consumer of the JAVA_MAIN_CLASS_%d environment variable should be
> responsible to pick such name in case the environment variable is not set.
Henry Jen has updated the pull request incrementally with one additional commit
since the
ity to choose such a default name. It seems to me
> the consumer of the JAVA_MAIN_CLASS_%d environment variable should be
> responsible to pick such name in case the environment variable is not set.
Henry Jen has updated the pull request incrementally with one additional commit
since the
On Tue, 16 Mar 2021 15:33:37 GMT, Alan Bateman wrote:
> Using an anonymous class for the main class looks strange and hard to believe
> anyone is relying on this. I wonder if we should do more checking
> LauncherHelper.validateMainClass to reject cases like this.
I raised that same question,
On Tue, 16 Mar 2021 01:59:33 GMT, Sergey Bylokhov wrote:
>> This patch ensure launcher won't crash JVM for the new static Methods from
>> local/anonymous class on MacOS.
>>
>> As @dholmes-ora pointed out in the analysis, this is a MacOS specific bug
>> when the launcher trying to grab class
This patch ensure launcher won't crash JVM for the new static Methods from
local/anonymous class on MacOS.
As @dholmes-ora pointed out in the analysis, this is a MacOS specific bug when
the launcher trying to grab class name to be displayed as the Application name
on the menu.
The fix is to
Sure, will change the before I push. I considered that but didn’t run with it.
Cheers,
Henry
> On Apr 6, 2020, at 7:43 PM, David Holmes wrote:
>
> Hi Henry,
>
> On 7/04/2020 3:36 am, Henry Jen wrote:
>> Here is the combined webrev[1] which I think is what we shou
.
Cheers,
Henry
[1] http://cr.openjdk.java.net/~henryjen/jdk/8241638.2/webrev/
> On Apr 5, 2020, at 9:21 PM, David Holmes wrote:
>
> On 6/04/2020 12:37 pm, David Holmes wrote:
>> On 6/04/2020 12:20 pm, Henry Jen wrote:
>>> On Apr 5, 2020, at 7:15 PM, David Holmes wrote:
On Apr 5, 2020, at 7:15 PM, David Holmes wrote:
>
> On 6/04/2020 11:50 am, David Holmes wrote:
>> There is something not right here ...
>> On 4/04/2020 3:13 pm, Henry Jen wrote:
>>> Internal test shows that inline implementation is not working for some
>
> On Apr 5, 2020, at 6:52 AM, Alan Bateman wrote:
>
>
> On 05/04/2020 14:17, David Holmes wrote:
>> On 4/04/2020 3:13 pm, Henry Jen wrote:
>>> Internal test shows that inline implementation is not working for some
>>> Solaris artifacts, because the
Internal test shows that inline implementation is not working for some Solaris
artifacts, because the -DHAVE_GETHRTIME is not consistently defined, so it is
actually broken. :)
> [2020-04-03T15:59:26,981Z] Creating
> support/test/hotspot/jtreg/native/bin/jvm-test-launcher from 1 file(s)
>
>
> So, Do I need more review before push this patch?
>
> And may I ask your help to push it if a go decision is made.
>
> Thanks.
>
>
> BRs,
> Lin
>
> On 2020/3/31, 12:30 PM, "Henry Jen" wrote:
>
>OK, I agree with David gettimeofday is
> >On 2020/3/31, 8:05 AM, "David Holmes" wrote:
>>
>> On 31/03/2020 4:08 am, Henry Jen wrote:
>>> Based on my understanding to gethrtime(), the main benefit is not to be
>>> affected by settimeofday or adjtime. I think it is probably bette
Based on my understanding to gethrtime(), the main benefit is not to be
affected by settimeofday or adjtime. I think it is probably better to use
clock_gettime(CLOCK_MONOTONIC_RAW, ts);
which I checked seems to be available on both Linux and Mac. Haven’t test it
though.
Cheers,
Henry
> On
/webrev/
Cheers,
Henry
> On Mar 8, 2020, at 1:54 AM, Alan Bateman wrote:
>
> On 06/03/2020 22:40, Henry Jen wrote:
>> Hi,
>>
>> Please review the webrev[1] fix JDK-8240629 reported earlier by Robert.
>>
>> http://cr.openjdk.java.net/~henryjen/jdk/82406
Hi,
Please review the webrev[1] fix JDK-8240629 reported earlier by Robert.
http://cr.openjdk.java.net/~henryjen/jdk/8240629.0/webrev/
Cheers,
Henry
Thanks for the report and investigation, bug confirmed, JDK-8240629 is filed to
tacking the issue.
https://bugs.openjdk.java.net/browse/JDK-8240629
Cheers,
Henry
> On Mar 5, 2020, at 11:43 AM, Robert Stupp wrote:
>
> Another note: I've also seen it appending a comment-line in
>
if (!tr.testStatus) {
System.out.println(tr);
Cheers,
Henry
> On Dec 11, 2019, at 10:29 PM, Henry Jen wrote:
>
> Nikola,
>
> The change looks fine to me as well, I’ll run the test and push it before
SRC_DIR.resolve(TEST_MODULE).toString() + "\\*.java",
> +"--help"))
> +.outputTo(System.out)
> +.errorTo(System.out)
> +.shouldContain("F--help")
> +.shouldContain(&quo
;--module-path=" + dir,
> +"--module=" + mid,
> +"--module-path=" + dir,
> +"--module=" + mid))
> +.outputTo(System.out)
> +.errorTo(System.out)
> +.shouldContain("argv
s bug or if
> you think there's a potential problem with the change. If this is an
> acceptable fix I can create new webrev with set of tests for the various edge
> cases I tried, and new launcher specific tests that ensure argument expansion
> is performed on Windows with this module
c 5, 2019, at 12:21 PM, Mandy Chung wrote:
>
>
>
> On 12/5/19 12:41 AM, Alan Bateman wrote:
>> On 05/12/2019 08:16, Henry Jen wrote:
>>> Hi,
>>>
>>> Updated webrev[1] reflect comments since last webrev. Vicente had done all
>>> the heavy-l
Hi,
Updated webrev[1] reflect comments since last webrev. Vicente had done all the
heavy-lifting and hand over to me to finish up.
Changes to symbols is reverted, as we expect that only need to be updated in
next release by running make/scripts/generate-symbol-data.sh.
The jar files are
eve the
> same amount of testing. I added a new test method inside BasicTest.java and
> tested on both Windows and Linux.
>
> Please find my updated webrev here for your review:
> https://grcevski.github.io/JDK-8234076/webrev/
>
> Cheers,
>
> Nikola
>
> -Orig
I created a webrev here for the change, including a new test in Arrrghs.java:
>
> https://grcevski.github.io/JDK-8234076/webrev/
>
> I copied the test validation and assertion style of other code inside the
> test class.
>
> Please let me know if you have any commen
> I think you're in the right area but I would have expected the arg index to 0
> here. Henry Jen (cc'ed) might have some comments on this.
>
> -Alan
s. This is why it now writes out an array of bytes
>>
>> Cheers
>> Mat
>>
>>
>> From: core-libs-dev on behalf of
>> Alan Bateman
>> Sent: Friday, November 8, 2019 2:56 AM
>> To: Henry Jen ; core-libs-dev@openjdk.ja
://bugs.openjdk.java.net/browse/JDK-8231863
> On Nov 4, 2019, at 3:40 PM, Mat Carter wrote:
>
> Thanks Henry
>
> I'm working on a test, do you want me to share directly with you (incl.
> questions) or continue with comms through the mailing list
>
> Cheers
> Mat
>
>
rking on a test, do you want me to share directly with you (incl.
> questions) or continue with comms through the mailing list
>
> Cheers
> Mat
>
> From: Henry Jen
> Sent: Monday, November 4, 2019 12:47 PM
> To: Mat Carter
> Cc: core-libs-dev@openjdk.java.net
&g
Hi Mat,
I’ll sponsor this fix, let me know if you are coming up with test and I’ll work
with you to get your patch committed.
Cheers,
Henry
> On Nov 4, 2019, at 9:21 AM, Henry Jen wrote:
>
> The fix is on the spot, good catch.
>
> As the test, test/jdk/tools/launcher/Ar
The fix is on the spot, good catch.
As the test, test/jdk/tools/launcher/ArgsFileTest.java is testing the file
expansions, we can add a test case there to have an argument file not have
newline at the end, and check that we get correct arguments.
Cheers,
Henry
> On Nov 1, 2019, at 7:06 AM,
> On May 22, 2019, at 7:04 PM, David Holmes wrote:
>
> On 23/05/2019 11:56 am, Henry Jen wrote:
>> Thanks for the quick review,
>>> On May 22, 2019, at 6:34 PM, David Holmes wrote:
>>>
>>> Hi Henry,
>>>
>>> On 23/05/2019 11:07
Thanks for the quick review,
> On May 22, 2019, at 6:34 PM, David Holmes wrote:
>
> Hi Henry,
>
> On 23/05/2019 11:07 am, Henry Jen wrote:
>> Hi,
>> Please review a webrev[1] to deprecate the -Xfuture option per
>> CSR-8224524[2].
>
> src/hotspot/share/
Hi,
Please review a webrev[1] to deprecate the -Xfuture option per CSR-8224524[2].
Cheers,
Henry
[1] https://cr.openjdk.java.net/~henryjen/jdk13/8215156/open/webrev/
[2] https://bugs.openjdk.java.net/browse/JDK-8224524
ks for me. :)
>
> Thanks,
> David
>
> On 22/05/2019 9:40 am, Henry Jen wrote:
>> Good suggestion, didn’t know about that page. I took what’s in Xusage.txt.
>> Updated as following,
>> diff -r cd3c74c0
>> src/java.base/share/classes/sun/launcher/resources/
ould be redirected for
logging\&. The information written to this file is similar to the output of
Cheers,
Henry
> On May 21, 2019, at 4:11 PM, David Holmes wrote:
>
> Hi Henry,
>
> On 22/05/2019 8:41 am, Henry Jen wrote:
>> Hi,
>> Please review a trivial patch t
Hi,
Please review a trivial patch that add some hints about how to use -Xlog in
java help and man page.
diff -r cd3c74c0
src/java.base/share/classes/sun/launcher/resources/launcher.properties
--- a/src/java.base/share/classes/sun/launcher/resources/launcher.properties
Tue May 21
Thanks, Roger.
Cheers,
Henry
> On Mar 1, 2019, at 10:27 AM, Roger Riggs wrote:
>
> Hi Henry,
>
> The change looks ok, Reviewed.
>
> (I'm not that familiar with Solaris).
>
> Thanks, Roger
>
>
>
> On 3/1/19 10:45 AM, Henry Jen wrote:
>> Pi
Ping!
Any thought on this webrev restore the way for Solaris LD_LIBRARY_PATH_64
handling?
Cheers,
Henry
> On Feb 13, 2019, at 9:37 AM, Henry Jen wrote:
>
> Hi,
>
> Please review the webrev[1] for 8217216. The fix makes sure on Solaris, when
> LD_LIBRARY_PATH_6
Hi,
Please review the webrev[1] for 8217216. The fix makes sure on Solaris, when
LD_LIBRARY_PATH_64 is set, we setup LD_LIBRARY_PATH based on that value and
unset LD_LIBRARY_PATH_64 in the relaunched process.
Same approach was used before JDK-6367077, and the override is expected
behavior on
t in this patch.
>
> Mandy
>
> On 12/12/18 10:30 AM, Brent Christian wrote:
>> Hi,
>>
>> Shouldn't the lambdas be checking for v == null, rather than k == null?
>>
>> -Brent
>>
>> On 12/12/18 9:36 AM, Henry Jen wrote:
>>
Hi,
Can I get a review of following patch?
Looks like the assumption test jdk will be in PATH is simply not true, jtreg
doesn’t do that.
Also, this patch make sure the JDK to be tested is first in the search path.
Cheers,
Henry
diff -r 241b8151b6b6 test/jdk/tools/launcher/JliLaunchTest.java
Thanks for the review, Alan and Magnus.
Cheers,
Henry
> On Nov 30, 2018, at 7:20 AM, Alan Bateman wrote:
>
>
>
> On 28/11/2018 22:49, Henry Jen wrote:
>> Since there is no header file in JDK provides the function prototypes, I
>> don’t think this is consid
Since there is no header file in JDK provides the function prototypes, I don’t
think this is considered public(supported) APIs.
Anyway, in case a tools is build with launcher code, and shipped separately
from JDK, that would be impacted by this bug. So I added a test call JLI_Launch
as well.
> On Nov 28, 2018, at 12:46 AM, Alan Bateman wrote:
>
> On 27/11/2018 23:05, Henry Jen wrote:
>> Hi,
>>
>> Please review a follow up webrev[1] based on Priyanka’s patch, it simply
>> added a test case for Mac only that will link with libjli.
>> N
Hi,
Please review a follow up webrev[1] based on Priyanka’s patch, it simply added
a test case for Mac only that will link with libjli.
Note that, to use invoke API, one should probably link with libjvm, which works
for all supported platforms, not just Mac.
Cheers,
Henry
[1]
I’ll create back port requests.
Cheers,
Henry
> On Sep 27, 2018, at 11:06 PM, Bo Zhang wrote:
>
> Thanks Henry, this change looks good to me. I assume this patch will be
> backported to 11GA, will it be back ported to 10 as well?
>
> Regards,
> Bo
>
>> On 28
Will do.
Cheers,
Henry
> On Sep 28, 2018, at 3:23 AM, Alan Bateman wrote:
>
>
>
> On 27/09/2018 17:49, Henry Jen wrote:
>> Agree, please find updated webrev[1].
>>
>> [1] http://cr.openjdk.java.net/~henryjen/jdk/8210810/1/webrev/
>>
>>
>
Agree, please find updated webrev[1].
[1] http://cr.openjdk.java.net/~henryjen/jdk/8210810/1/webrev/
Cheers,
Henry
> On Sep 27, 2018, at 1:45 AM, Alan Bateman wrote:
>
> On 27/09/2018 03:58, Henry Jen wrote:
>> Hi,
>>
>> Need a quick review of the webrev[1] for
://cr.openjdk.java.net/~henryjen/jdk/8210810/webrev/
[2] https://bugs.openjdk.java.net/browse/JDK-8210810
> On Sep 26, 2018, at 6:45 PM, Bo Zhang wrote:
>
> Thank you Henry. Feel free to modify it.
>
> Regards,
> Bo
>
>> On 27 Sep 2018, at 09:39, Henry Jen wrote:
>&
Thanks for the fix. I had looked into it, it’s a nice catch, glad you find it.
The patch looks good, and test is sufficient, I have tested it with jdk.jdk
repo. I will help you to push the fix. The only minor improvement I like to see
is to verify content after the escape character, which I
/8199871/1/webrev/
Cheers,
Henry
> On Jun 8, 2018, at 6:56 PM, Henry Jen wrote:
>
> Hi,
>
> Please review this webrev[1] in which we mark Pack200 related API and tools
> deprecate, and print a warning about tools to be remove in a future JDK
> release. To avoid int
Hi,
Please review a trivial fix for JDK-8180447[1], which we also makes the output
of options picked up by the environment variable in one line instead of two for
easier extraction from output.
Cheers,
Henry
[1] http://cr.openjdk.java.net/~henryjen/jdk9/8180447/webrev/
> On Mar 1, 2017, at 3:47 AM, Thomas Stüfe wrote:
>
> Hi Matthias,
>
> the fix makes sense, this is very clearly a bug.
>
> I'd suggest a simpler fix though:
>
> end -= 4; // make sure there are 4 bytes to read at
> start
> -
+1.
Cheers,
Henry
> On Feb 7, 2017, at 1:16 PM, Mandy Chung wrote:
>
> Henry, Kumar,
>
> Can you please review this patch:
> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8173712/webrev.00/
>
> JAVA_OPTIONS was introduced by JDK-8170832 but it turns out that
>
=\
'c' flag requires manifest or input files to be specified!
error.bad.uflag=\
Cheers,
Henry
> On Feb 2, 2017, at 10:58 AM, Henry Jen <henry@oracle.com> wrote:
>
> Hi,
>
> Please review a trivial patch for JDK-8171522, basically we just add two
> missing main ope
Hi,
Please review a trivial patch for JDK-8171522, basically we just add two
missing main operations into the message. This message is appropriate for both
compatible style or new gnu style.
Cheers,
Henry
diff -r 0e2935453091
Hi,
Please review a trivial fix[1] for JDK-8171524.
The fix added a short paragraph about @argfile. Clarify stdin or stdout is used
if —file is omitted.
It also correct that -h, not -? is for the short option for —help.
Cheers,
Henry
[1]
quot; Main1.java
+Success "$javac" ${TESTTOOLVMOPTS} --class-path="GooJar/SubDir/*" Main1.java
#Same with launcher. Should not load jar in subdirectories unless specified
Failure "$java" ${TESTVMOPTS} -classpath "GooJar/*${PS}." Main1
Success "$j
> On Jan 26, 2017, at 4:09 PM, Jonathan Gibbons
> wrote:
>
> Henry,
>
> You've changed old test cases into new test cases, thereby eliminating the
> old cases, which is not so good.
>
> You should be adding new test cases, but changing old ones.
>
I am not
Hi,
Please review the webrev[1], the fix is to ensure —class-path and —class-path=
is processed correctly to expand wildcard. Changes are made in jdk repo.
However, test case to verify the bug fix is in langtool repo.
Cheers,
Henry
[1] http://cr.openjdk.java.net/~henryjen/jdk9/8172309/0/
[2]
> On Jan 25, 2017, at 12:14 PM, Henry Jen <henry@oracle.com> wrote:
>
>
>> On Jan 25, 2017, at 11:32 AM, Kumar Srinivasan
>> <kumar.x.sriniva...@oracle.com> wrote:
>>
>>
>> Hi Henry,
>>
>> I was somewhat surprised to
> On Jan 25, 2017, at 11:32 AM, Kumar Srinivasan
> wrote:
>
>
> Hi Henry,
>
> I was somewhat surprised to see changes to launcher_LANG.properties, I usually
> make the change in the english/default locale and allow the L1ON team to make
> the
> locale specific
> On Jan 24, 2017, at 12:41 PM, Mandy Chung <mandy.ch...@oracle.com> wrote:
>
>
>> On Jan 24, 2017, at 10:20 AM, Henry Jen <henry@oracle.com> wrote:
>>
>> Hi,
>>
>> Please review the webrev[1] that add support for JAVA_OPTIONS
Hi,
Please review the webrev[1] that add support for JAVA_OPTIONS environment
variable. The bug[2] describes how JAVA_OPTIONS works.
[1] http://cr.openjdk.java.net/~henryjen/jdk9/8170832/4/webrev/
[2] https://bugs.openjdk.java.net/browse/JDK-8170832
Cheers,
Henry
OS-specific encoding, but has to be ASCII friendly, modern system with UTF-8 as
system encoding should work just fine.
Space in quote should work just fine, for example, “c:\\Program Files” should
be correct. Can you post messages from JLink? Also if you can verify java is
working OK with
...@oracle.com)
wrote:
>
>
> On 08/09/2016 20:52, Henry Jen wrote:
> > Hi,
> >
> > Please review a trivial fix for bug 8042148 at following URL:
> > Webrev: http://cr.openjdk.java.net/~henryjen/jdk9/8042148/webrev/
> > Bug: https://bugs.openjdk.java.net/brows
ealtsigs use alternative signals instead of SIGUSR1 and SIGUSR2 for
> JVM internal signals
>
> Kumar
>
>
> On 9/8/2016 12:52 PM, Henry Jen wrote:
> > Hi,
> >
> > Please review a trivial fix for bug 8042148 at following URL:
> > Webrev: http://cr.openjdk.
Hi,
Please review a trivial fix for bug 8042148 at following URL:
Webrev: http://cr.openjdk.java.net/~henryjen/jdk9/8042148/webrev/
Bug: https://bugs.openjdk.java.net/browse/JDK-8042148
The fix added options asked for as discussed in the bug comments, and sort
those options in alphabetical
That’s what I think too, this is just to silent parfait.
I don’t know for sure that we always get NULL with exception pending though.
Cheers,
Henry
On September 1, 2016 at 12:34:02 AM, David Holmes (david.hol...@oracle.com)
wrote:
> On 1/09/2016 5:51 AM, Henry Jen wrote:
> > Hi,
>
Hi,
Please review a trivial fix for 8081388, in a nutshell,
- Return NULL from NewPlatformStringArray if an exception occurred
- All other places call this function already handled return value NULL
- Launcher handles exception in JavaMain, report error and exit.
Cheers,
Henry
diff --git
Looks good to me, but I am not a Reviewer.
Cheers,
Henry
On July 26, 2016 at 10:16:36 AM, Naoto Sato (naoto.s...@oracle.com) wrote:
> Ping.
>
> On 7/21/16 3:44 PM, Naoto Sato wrote:
> > Hello,
> >
> > Please review the change to the following issue:
> >
> >
Kumar,
Thanks for the review.
Cheers,
Henry
On July 13, 2016 at 6:43:09 AM, Kumar Srinivasan
(kumar.x.sriniva...@oracle.com) wrote:
>
> Henry,
>
> Thanks for fixing this. Looks good.
>
> Kumar
>
> > Hi,
> >
> > Please review a fix for JDK-8132379, the fix is to build matching index to
> >
Hi,
Please review a fix for JDK-8132379, the fix is to build matching index to the
original arguments for the application arguments, used later for the sanity
check and wildcard expansion. The fix is specific to Windows platform.
-J prefix used by launcher-based tools such as javac need to be
I think there is a work-around, use list() and flatMap() should get you what
you needed.
The API is designed to walk a tree where you suppose to have access with. If OS
level cause an IOException, that need to be dealt with. Acknowledged that
exception handling is not a strong suite in Stream
Changes looks reasonable to me.
Cheers,
Henry
> On Dec 15, 2015, at 7:54 AM, Kumar Srinivasan
> wrote:
>
> Hello,
>
> Please review fix for: JDK-8115868
>
> The webrev is here:
> http://cr.openjdk.java.net/~ksrini/8115868/webrev.0/
>
> The background:
> The
Uh, you did mention you need entry with value zero. I knew I miss something. :)
Cheers,
Henry
> On Dec 4, 2015, at 12:53 PM, ShinyaYoshida <bitterf...@gmail.com> wrote:
>
> Thank you for your comment.
>
> 2015-12-05 3:28 GMT+09:00 Henry Jen <henry@oracle.com>:
&
My first thought is what’s wrong with
stream.filter(predicate).collect(...)?
In your case, that would be,
amps.stream().filter(e -> e.getSalary() > 2000)
.collect(groupingBy(Employee::getDepartment), Collectors.counting())
That should work just fine?
Cheers,
Henry
> On Dec 3, 2015, at
Kumar, Mandy,
Thanks for reviewing.
Cheers,
Henry
On Aug 22, 2015, at 12:42 PM, Kumar Srinivasan
kumar.x.sriniva...@oracle.com wrote:
Henry,
Looks good, and thank you for taking this on.
Kumar
On 8/21/2015 3:46 PM, Henry Jen wrote:
v7 is up, changes are
- Add formfeed
, at 11:00 AM, Mandy Chung mandy.ch...@oracle.com wrote:
On 08/17/2015 09:15 PM, Henry Jen wrote:
v6 is available at
http://cr.openjdk.java.net/~henryjen/jdk9/8027634/v6/webrev/
Thanks for the update. Looks fine.
Mandy
On Aug 16, 2015, at 4:51 PM, Henry Jen henry@oracle.com wrote:
Thanks for reviewing, comment inline below,
On Aug 14, 2015, at 4:07 PM, Mandy Chung mandy.ch...@oracle.com wrote:
On Aug 14, 2015, at 1:10 PM, Henry Jen henry@oracle.com wrote:
Hi,
Another minor revision
On Aug 17, 2015, at 8:45 PM, Mandy Chung mandy.ch...@oracle.com wrote:
OK. firstAppArgIndex is not used in the parsing.
It is set in args.c:127, and stop expansion on line 369.
v6 is available at
http://cr.openjdk.java.net/~henryjen/jdk9/8027634/v6/webrev/
Changes based on Mandy’s
On Aug 17, 2015, at 7:10 AM, Henry Jen henry@oracle.com wrote:
On Aug 16, 2015, at 4:51 PM, Henry Jen henry@oracle.com wrote:
Thanks for reviewing, comment inline below,
On Aug 14, 2015, at 4:07 PM, Mandy Chung mandy.ch...@oracle.com wrote:
On Aug 14, 2015, at 1:10 PM
Thanks for reviewing, comment inline below,
On Aug 14, 2015, at 4:07 PM, Mandy Chung mandy.ch...@oracle.com wrote:
On Aug 14, 2015, at 1:10 PM, Henry Jen henry@oracle.com wrote:
Hi,
Another minor revision address comments, no real behavior changes except use
JLI_StrCmp instead
Hi,
Another minor revision address comments, no real behavior changes except use
JLI_StrCmp instead of JLI_StrCCmp in checkArg().
http://cr.openjdk.java.net/~henryjen/jdk9/8027634/v5/webrev/
Cheers,
Henry
1 - 100 of 315 matches
Mail list logo