RFR 8234423 : More accurate handling of modification counter in ArrayList.SubList.Iterator

Hello! When a sublist of a sublist of an ArrayList is created, its modCount is initialized from the ArrayList root, and not from its immediate parent. This means that modifying that 2nd level sublist will reset modCounts of the entire chain up to the root, and consequently the 1st level subli

Re: Turkish Time Zone name string and translation

Hi Naoto, Thank you for the suggestions! I've added a new webrev: https://cr.openjdk.java.net/~xliu/8234288/webrev.01/ Letu On 11/18/19, 9:09 AM, "naoto.s...@oracle.com" wrote: Hi Letu, Here are my comments to your changes: - You will need a regression test for this fi

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

Correction ... On 21/11/2019 9:10 am, David Holmes wrote: Hi Vicente, Not sure the best mailing list for this review ... jdk-dev may not be well monitored. Is there a separate review thread for the actual tool removal (jdk.pack) I overlooked the removal of jdk.pack (scrolling too fast thr

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

On 21/11/2019 11:01 am, Mandy Chung wrote: (bcc jdk-dev.   The review can continue on core-libs-dev) Hi Vicente, The following files should also be removed.    make/launcher/Launcher-jdk.pack.gmk There are a number of build changes to be made: ./make/autoconf/compare.sh.in:export UNPACK200=

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

(bcc jdk-dev.   The review can continue on core-libs-dev) Hi Vicente, The following files should also be removed.    make/launcher/Launcher-jdk.pack.gmk test/jdk/java/util/jar/Pack200/* The following files reference pack200 in its comment.  I'm not sure if they need update or not. src/java.b

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

moving the discussion to core-libs. I have updated the webrev [1], after removing the reference found by David and another one I found with a help text at: src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties Thanks, Vicente [1] http://cr.openjdk.java.net/~vromero/8234542/webr

RFR [14/java.xml] 8233548: Update CUP to v0.11b

Hi, Please review an update to Java CUP. This is an effort to move to the latest version, v0.11b. JCUP is used by Xalan to generate XPathParser. Included in the JDK are runtime classes and XPathParser. In CUP 0.11b, the main additions to the runtime were SymbolFactory and ComplexSymbol that w

Re: RFR: JDK-8234402: revert change that stopped providing JPackageToolProvider

Looks good. On 11/20/2019 6:36 AM, Andy Herrick wrote: webrev revised in place at [2]. /Andy On 11/19/2019 9:00 PM, Alexey Semenyuk wrote: Andy, I guess http://cr.openjdk.java.net/~herrick/8234402/webrev.02/test/jdk/tools/jpackage/helpers/jdk/jpackage/test/JavaTool.java.sdiff.html can be r

JDK-8234076 bug fix candidate

Hello core-libs-dev, I'm a VM engineer at Microsoft and new to this mailing list. I took a look at JDK- 8234076 and the root cause is similar to a prior thread on a Windows launcher bug for JDK- 8231863, after the command line arguments are processed, the static variable firstAppArgIndex in sr

Re: RFR: 8234089: (zipfs) Remove classes JarFileSystemProvider and JarFileSystem

Hi Christoph, Again, thank you for your efforts here. Overall I think your latest changes look fine. I would like to suggest that for the methods that you added for MR support, that we make sure the 1st character in the comment is capitalized prior to your push of the changes. I know this wa

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

I posted new composite webrev [7], and git patch [8] after pushing fix for JDK-8234402 [6]. [7] http://cr.openjdk.java.net/~herrick/8212780/webrev.EA-11/ [8] http://cr.openjdk.java.net/~herrick/8212780/JDK-EA-11.git.patch /Andy On 11/19/2019 3:13 PM, Kevin Rushforth wrote: I took the "git dif

Re: RFR: 8234335: Remove line break in class declaration in java.base

+1 Thanks, Roger On 11/20/19 12:02 PM, Lance Andersen wrote: Looks Good Julia On Nov 20, 2019, at 5:52 AM, Julia Boes wrote: Seems to be a “your milage varies”. I am fine with whatever the final decision is. However, I do believe the comment above reads better and aligns the methods bett

Re: Class-Path (in jar file) semantics different between Java 11 and 13 (on Windows)?

On 20/11/2019 17:02, David Lloyd wrote: I'll see where the usages are. I believe at least one usage is out of our control though, and I'm pretty sure that Maven uses absolute paths for surefire and failsafe (test) launching. Let us know on that. I remember we ran into issues with Sunfire abu

Re: RFR: JDK-8234402: revert change that stopped providing JPackageToolProvider

Looks good. - Alexey On 11/20/2019 9:36 AM, Andy Herrick wrote: webrev revised in place at [2]. /Andy On 11/19/2019 9:00 PM, Alexey Semenyuk wrote: Andy, I guess http://cr.openjdk.java.net/~herrick/8234402/webrev.02/test/jdk/tools/jpackage/helpers/jdk/jpackage/test/JavaTool.java.sdiff.html

Re: RFR: 8234335: Remove line break in class declaration in java.base

Looks Good Julia > On Nov 20, 2019, at 5:52 AM, Julia Boes wrote: > Seems to be a “your milage varies”. I am fine with whatever the final decision is. However, I do believe the comment above reads better and aligns the methods better. >>> FWIW, and as author of many of the lines

Re: Class-Path (in jar file) semantics different between Java 11 and 13 (on Windows)?

On Wed, Nov 20, 2019 at 8:59 AM Alan Bateman wrote: > > On 20/11/2019 13:50, David Lloyd wrote: > > : > > OK, but this decision violates both the old and updated spec (and > > makes it difficult to write code that works in both cases: in > > situations that reject absolute URLs (javac) and in situ

Re: Class-Path (in jar file) semantics different between Java 11 and 13 (on Windows)?

On Wed, Nov 20, 2019 at 9:26 AM Scott Palmer wrote: > > /C:/blah... is “root relative”. The (old) spec says the URL must be "relative > to the code base". What does "code base" mean when not referring to Applets > or RMI? "code base" is generally the URL of the class path entry itself. It's m

Re: Class-Path (in jar file) semantics different between Java 11 and 13 (on Windows)?

/C:/blah... is “root relative”. The (old) spec says the URL must be "relative to the code base". What does "code base" mean when not referring to Applets or RMI? This seems like a bad idea (security hole) that worked by accident. Scott On Wed, Nov 20, 2019 at 10:00 AM Alan Bateman wrote: > On

Re: RFR [XS] : 8234339: replace JLI_StrTok in java_md_solinux.c

Hi Matthias, Good to see the switch to strtok_r. Looks fine. Thanks, Roger On 11/19/19 4:23 AM, Baesken, Matthias wrote: Hello, please review this small change . JLI_StrTok is only used in one function, so the define can be replaced, probably we should use the "safer" strtok_r (the MT safet

Re: RFR: 8234089: (zipfs) Remove classes JarFileSystemProvider and JarFileSystem

On 20/11/2019 13:39, Langer, Christoph wrote: Hi Alan, makes sense. I’ve updated the patch: http://cr.openjdk.java.net/~clanger/webrevs/8234089.4/ The updated test looks okay. -Alan

Re: Class-Path (in jar file) semantics different between Java 11 and 13 (on Windows)?

On 20/11/2019 13:50, David Lloyd wrote: : OK, but this decision violates both the old and updated spec (and makes it difficult to write code that works in both cases: in situations that reject absolute URLs (javac) and in situations that reject drive letters (this code)), so I would request that

Re: RFR: JDK-8234402: revert change that stopped providing JPackageToolProvider

Looks good. -- Kevin On 11/20/2019 6:36 AM, Andy Herrick wrote: webrev revised in place at [2]. /Andy On 11/19/2019 9:00 PM, Alexey Semenyuk wrote: Andy, I guess http://cr.openjdk.java.net/~herrick/8234402/webrev.02/test/jdk/tools/jpackage/helpers/jdk/jpackage/test/JavaTool.java.sdiff.htm

Re: RFR: JDK-8234402: revert change that stopped providing JPackageToolProvider

webrev revised in place at [2]. /Andy On 11/19/2019 9:00 PM, Alexey Semenyuk wrote: Andy, I guess http://cr.openjdk.java.net/~herrick/8234402/webrev.02/test/jdk/tools/jpackage/helpers/jdk/jpackage/test/JavaTool.java.sdiff.html can be reverted to its initial state now: --- public ToolProvide

Re: RFR: JDK-8234402: revert change that stopped providing JPackageToolProvider

On 11/19/2019 9:00 PM, Alexey Semenyuk wrote: Andy, I guess http://cr.openjdk.java.net/~herrick/8234402/webrev.02/test/jdk/tools/jpackage/helpers/jdk/jpackage/test/JavaTool.java.sdiff.html can be reverted to its initial state now: --- public ToolProvider asToolProvider() {     return ToolPr

Re: Class-Path (in jar file) semantics different between Java 11 and 13 (on Windows)?

On Wed, Nov 20, 2019 at 2:25 AM Alan Bateman wrote: > > On 19/11/2019 23:25, David Lloyd wrote: > > : > > OK, having read the updated specification (thanks Alan!) I'm now quite > > curious why `/C:/helloworld.jar` is considered invalid. It is in fact > > a valid relative URL (colons are allowed i

RE: RFR: 8234089: (zipfs) Remove classes JarFileSystemProvider and JarFileSystem

Hi Alan, makes sense. I’ve updated the patch: http://cr.openjdk.java.net/~clanger/webrevs/8234089.4/ Best regards Christoph From: Alan Bateman Sent: Mittwoch, 20. November 2019 09:33 To: Langer, Christoph ; Lance Andersen Cc: nio-dev ; core-libs-dev@openjdk.java.net Subject: Re: RFR: 8234089

Re: [14] RFR (S): 8234401: ConstantCallSite may stuck in non-frozen state

Thanks for review, Paul. Best regards, Vladimir Ivanov On 19.11.2019 21:25, Paul Sandoz wrote: +1 On Nov 19, 2019, at 10:12 AM, Vladimir Ivanov wrote: Thanks, Paul. CallSite: public class CallSite { - // The actual payload of this call site: + // The actual payload of this call site.

Re: RFR: 8234335: Remove line break in class declaration in java.base

Seems to be a “your milage varies”. I am fine with whatever the final decision is. However, I do believe the comment above reads better and aligns the methods better. FWIW, and as author of many of the lines being changed, I prefer that comment on a separate from the actual modifiers. I think

Re: RFR: 8234089: (zipfs) Remove classes JarFileSystemProvider and JarFileSystem

On 20/11/2019 08:15, Langer, Christoph wrote: Hi Lance, I’ve taken care of ModulesInCustomFileSystem then, too. Updated webrev in place… If the ModulesInCustomFileSystem test really needs to be changed then the private method that has been renamed to testZipFileSystem shoud have its para

Re: Class-Path (in jar file) semantics different between Java 11 and 13 (on Windows)?

On 19/11/2019 23:25, David Lloyd wrote: : OK, having read the updated specification (thanks Alan!) I'm now quite curious why `/C:/helloworld.jar` is considered invalid. It is in fact a valid relative URL (colons are allowed in path segments, and the leading `/` unambiguously delineates the URL p

RE: RFR: 8234089: (zipfs) Remove classes JarFileSystemProvider and JarFileSystem

Hi Lance, I’ve taken care of ModulesInCustomFileSystem then, too. Updated webrev in place… Cheers Christoph From: Lance Andersen Sent: Dienstag, 19. November 2019 23:42 To: Langer, Christoph Cc: core-libs-dev@openjdk.java.net; nio-dev Subject: Re: RFR: 8234089: (zipfs) Remove classes JarFile

Re: RFR: 8234185: Cleanup usage of canonicalize function between libjava, hotspot and libinstrument

Thanks, Christoph! I forgot to tell that my recommendation is for the serviceability (j.l.instrument) coverage only. Thanks, Serguei On 11/19/19 23:47, Langer, Christoph wrote: Hi Serguei, thanks for the review. The patch successfully ran through our nightly test system which covers all th