Re: RFR: 8236569: -Xss not multiple of 4K does not work for the main thread on macOS [v5]

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

Re: RFR: 8236569: -Xss not multiple of 4K does not work for the main thread on macOS [v6]

stackLeak(); > } > > public static void main(String[] args) { > var test = new StackLeak(); > try { > test.stackLeak(); > } catch (Throwable e) { > System.out.println(test.depth); > } > } > } Henry

Re: RFR: 8236569: -Xss not multiple of 4K does not work for the main thread on macOS [v5]

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

Re: RFR: 8236569: -Xss not multiple of 4K does not work for the main thread on macOS [v5]

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

Re: RFR: 8236569: -Xss not multiple of 4K does not work for the main thread on macOS [v5]

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

Re: RFR: 8236569: -Xss not multiple of 4K does not work for the main thread on macOS [v5]

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

Re: RFR: 8236569: -Xss not multiple of 4K does not work for the main thread on macOS [v5]

stackLeak(); > } > > public static void main(String[] args) { > var test = new StackLeak(); > try { > test.stackLeak(); > } catch (Throwable e) { > System.out.println(test.depth); > } > } >

Re: RFR: 8236569: -Xss not multiple of 4K does not work for the main thread on macOS [v4]

stackLeak(); > } > > public static void main(String[] args) { > var test = new StackLeak(); > try { > test.stackLeak(); > } catch (Throwable e) { > System.out.println(test.depth); > } > } > } Henry

Re: RFR: 8236569: -Xss not multiple of 4K does not work for the main thread on macOS [v3]

stackLeak(); > } > > public static void main(String[] args) { > var test = new StackLeak(); > try { > test.stackLeak(); > } catch (Throwable e) { > System.out.println(test.depth); > } > } >

Re: RFR: 8236569: -Xss not multiple of 4K does not work for the main thread on macOS [v2]

stackLeak(); > } > > public static void main(String[] args) { > var test = new StackLeak(); > try { > test.stackLeak(); > } catch (Throwable e) { > System.out.println(test.depth); > } > } > } Henry

Withdrawn: 8236569: -Xss not multiple of 4K does not work for the main thread on macOS

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

Re: RFR: 8236569: -Xss not multiple of 4K does not work for the main thread on macOS

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

Re: RFR: 8236569: -Xss not multiple of 4K does not work for the main thread on macOS

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

RFR: 8236569: -Xss not multiple of 4K does not work for the main thread on macOS

…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,

Integrated: 8261785: Calling "main" method in anonymous nested class crashes the JVM

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

Re: RFR: 8261785: Calling "main" method in anonymous nested class crashes the JVM [v3]

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

Re: RFR: 8261785: Calling "main" method in anonymous nested class crashes the JVM [v3]

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

Re: RFR: 8261785: Calling "main" method in anonymous nested class crashes the JVM [v2]

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

Re: RFR: 8261785: Calling "main" method in anonymous nested class crashes the JVM

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,

Re: RFR: 8261785: Calling "main" method in anonymous nested class crashes the JVM

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

RFR: 8261785: Calling "main" method in anonymous nested class crashes the JVM

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

Re: RFR(S): 8241638: launcher time metrics alway report 1 on Linux when _JAVA_LAUNCHER_DEBUG set(Internet mail)

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

Re: RFR(S): 8241638: launcher time metrics alway report 1 on Linux when _JAVA_LAUNCHER_DEBUG set(Internet mail)

. 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:

Re: RFR(S): 8241638: launcher time metrics alway report 1 on Linux when _JAVA_LAUNCHER_DEBUG set(Internet mail)

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 >

Re: RFR(S): 8241638: launcher time metrics alway report 1 on Linux when _JAVA_LAUNCHER_DEBUG set(Internet mail)

> 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

Re: RFR(S): 8241638: launcher time metrics alway report 1 on Linux when _JAVA_LAUNCHER_DEBUG set(Internet mail)

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) >

Re: RFR(S): 8241638: launcher time metrics alway report 1 on Linux when _JAVA_LAUNCHER_DEBUG set(Internet mail)

> > 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

Re: RFR(S): 8241638: launcher time metrics alway report 1 on Linux when _JAVA_LAUNCHER_DEBUG set(Internet mail)

> >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

Re: RFR(S): 8241638: launcher time metrics alway report 1 on Linux when _JAVA_LAUNCHER_DEBUG set

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

Re: RFR: 8240629: argfiles parsing broken for argfiles with comment cross 4096 bytes chunk

/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

RFR: 8240629: argfiles parsing broken for argfiles with comment cross 4096 bytes chunk

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

Re: argfiles parsing broken for argfiles > 4096 bytes

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 >

Re: [EXTERNAL] JDK-8234076 bug fix candidate

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

Re: [EXTERNAL] JDK-8234076 bug fix candidate

SRC_DIR.resolve(TEST_MODULE).toString() + "\\*.java", > +"--help")) > +.outputTo(System.out) > +.errorTo(System.out) > +.shouldContain("F--help") > +.shouldContain(&quo

Re: [EXTERNAL] JDK-8234076 bug fix candidate

;--module-path=" + dir, > +"--module=" + mid, > +"--module-path=" + dir, > +"--module=" + mid)) > +.outputTo(System.out) > +.errorTo(System.out) > +.shouldContain("argv

Re: [EXTERNAL] JDK-8234076 bug fix candidate

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

Re: RFR: JEP 367: Remove the Pack200 Tools and API

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

Re: RFR: JEP 367: Remove the Pack200 Tools and API

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

Re: [EXTERNAL] JDK-8234076 bug fix candidate

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

Re: [EXTERNAL] JDK-8234076 bug fix candidate

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

Re: JDK-8234076 bug fix candidate

> 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

Re: RFR: 8231863: Crash if classpath is read from @argument file and the main gets option argument

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

RFR: 8231863: Crash if classpath is read from @argument file and the main gets option argument

://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 > >

Re: JDK-8231863 bug fix candidate

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

Re: JDK-8231863 bug fix candidate

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

Re: JDK-8231863 bug fix candidate

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,

Re: RFR: 8215156: Deprecate the -Xfuture option

> 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

Re: RFR: 8215156: Deprecate the -Xfuture option

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/

RFR: 8215156: Deprecate the -Xfuture option

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

Re: RFR: 8218997: Xusage text, man help, etc doesn't mention -Xlog option.

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/

Re: RFR: 8218997: Xusage text, man help, etc doesn't mention -Xlog option.

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

RFR: 8218997: Xusage text, man help, etc doesn't mention -Xlog option.

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

Re: RFR: 8217216: Launcher does not defend itself against LD_LIBRARY_PATH_64 (Solaris)

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

Re: RFR: 8217216: Launcher does not defend itself against LD_LIBRARY_PATH_64 (Solaris)

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

RFR: 8217216: Launcher does not defend itself against LD_LIBRARY_PATH_64 (Solaris)

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

Re: RFR: 8215000: tools/launcher/JliLaunchTest.java fails on Windows

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: >>

RFR: 8215000: tools/launcher/JliLaunchTest.java fails on Windows

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

Re: RFR: JDK-8213362 : Could not find libjava.dylib error when initializing JVM via JNI_CreateJavaVM

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

Re: RFR: JDK-8213362 : Could not find libjava.dylib error when initializing JVM via JNI_CreateJavaVM

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.

Re: RFR: JDK-8213362 : Could not find libjava.dylib error when initializing JVM via JNI_CreateJavaVM

> 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

RFR: JDK-8213362 : Could not find libjava.dylib error when initializing JVM via JNI_CreateJavaVM

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]

Re: [RFR] 8210810: Escaped character at specific position in argument file is not handled properly

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

Re: [RFR] 8210810: Escaped character at specific position in argument file is not handled properly

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/ >> >> >

Re: [RFR] 8210810: Escaped character at specific position in argument file is not handled properly

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

[RFR] 8210810: Escaped character at specific position in argument file is not handled properly

://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: >&

Re: [PATCH] 8210810: Incorrect argument file parser behavior in certain cases

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

Re: RFR: 8199871: Deprecate pack200 and unpack200 tools

/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

RFR: JDK-8180447: Trailing space in JDK_JAVA_OPTIONS causes an application fail to launch

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/

Re: RFR [XS] : 8175000 : jexec fails to execute simple helloworld.jar

> 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 > -

Re: Review Request: JDK-8173712: Rename JAVA_OPTIONS environment variable to JDK_JAVA_OPTIONS

+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 >

Re: RFR: 8171522: Jar prints error message with old (non gnu-style options).

=\ '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

RFR: 8171522: Jar prints error message with old (non gnu-style options).

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

RFR: 8171524: jar --help doesn't provide information that stdout and stdin can be used as output and input for tool

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]

Re: RFR: 8172309: classpath wildcards code does not support --class-path

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

Re: RFR: 8172309: classpath wildcards code does not support --class-path

> 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

RFR: 8172309: classpath wildcards code does not support --class-path

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]

Updated RFR: 8170832: Add a new launcher environment variable JAVA_OPTIONS

> 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

Re: RFR: 8170832: Add a new launcher environment variable JAVA_OPTIONS

> 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

Re: RFR: 8170832: Add a new launcher environment variable JAVA_OPTIONS

> 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

RFR: 8170832: Add a new launcher environment variable 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

Re: JEP 293: Guidelines for JDK Command-Line Tool Options - @-files

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

Re: RFR: 8042148: Ensure that the java launcher help is consistent with the manpage where they report common information

...@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

Re: RFR: 8042148: Ensure that the java launcher help is consistent with the manpage where they report common information

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.

RFR: 8042148: Ensure that the java launcher help is consistent with the manpage where they report common information

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

Re: RFR: 8081388: JNI exception pending in jdk/src/windows/bin/java_md.c

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, >

RFR: 8081388: JNI exception pending in jdk/src/windows/bin/java_md.c

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

Re: [9] RFR: 8162343: non-ASCII characters in source code comments (.hpp)

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: > > > >

Re: RFR: 8132379: -J options can cause crash or "Warning: app args parsing error passing arguments as-is"

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 > >

RFR: 8132379: -J options can cause crash or "Warning: app args parsing error passing arguments as-is"

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

Re: Fwd: Files.walk() is unusable because of AccessDeniedException

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

Re: RFR: JDK-8115868: 32-bit JVM failed to start from a large network filesystem

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

Re: RFR 8144675: Add a filtering collector

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>: &

Re: RFR 8144675: Add a filtering collector

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

Re: RFR v6 - 8027634: Support @argfiles for java command-line tool

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

Re: RFR v6 - 8027634: Support @argfiles for java command-line tool

, 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

Re: RFR v5 - 8027634: Support @argfiles for java command-line tool

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

RFR v6 - 8027634: Support @argfiles for java command-line tool

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

Re: RFR v5 - 8027634: Support @argfiles for java command-line tool

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

Re: RFR v5 - 8027634: Support @argfiles for java command-line tool

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

RFR v5 - 8027634: Support @argfiles for java command-line tool

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   2   3   4   >