From jlahoda at openjdk.java.net Tue Mar 2 12:05:49 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Tue, 2 Mar 2021 12:05:49 GMT Subject: Integrated: 8261606: Surprising behavior of step over in String switch In-Reply-To: <0a3sZjMZTAs_4DnM4IfyTTLmLzbzNyfV4lq05hCuWQc=.e1ba29e8-8517-4977-b68f-730e39128716@github.com> References: <0a3sZjMZTAs_4DnM4IfyTTLmLzbzNyfV4lq05hCuWQc=.e1ba29e8-8517-4977-b68f-730e39128716@github.com> Message-ID: On Mon, 15 Feb 2021 08:12:10 GMT, Jan Lahoda wrote: > Consider code like: > public class Test { > public static void main(String... args) { > new Test().test("a"); > } > private void test(String s) { > if (s != null) { > switch (s) { > case "a": > System.out.println("a"); //breakpoint here, and continue with step-over > break; > default: > System.out.println("default"); //the program counter will be shown here eventually > } > } else { > System.out.println("null"); > } > } > } > > Placing breakpoint at the marked line (with `System.out.println("a");`), running debugger and performing step-over, the execution eventually is shown to stop at the line with `System.out.println("default");`. > > The reason for this is (roughly) because the switch-over-string is desugared into a block, but that block does not have an end position set. So the LineNumberTable point for the closing bracket of the block is not generated, and hence the last previous point is used, which is the last line of the last case (branch) of the switch. > > The proposal is to set the end position for the synthetic block generated for the switch-over-string. This pull request has now been integrated. Changeset: 85a5ae8c Author: Jan Lahoda URL: https://git.openjdk.java.net/jdk/commit/85a5ae8c Stats: 80 lines in 5 files changed: 79 ins; 0 del; 1 mod 8261606: Surprising behavior of step over in String switch Reviewed-by: vromero ------------- PR: https://git.openjdk.java.net/jdk/pull/2569 From duke at openjdk.java.net Tue Mar 2 17:02:40 2021 From: duke at openjdk.java.net (duke) Date: Tue, 2 Mar 2021 17:02:40 GMT Subject: Withdrawn: 8241187: ToolBox::grep should allow for negative filtering In-Reply-To: References: Message-ID: <4BZ-snLcal2cFsb6yWPG0h9KTP84e8tOKcZMPX3bM4I=.3142d1b5-e446-4273-91f5-8e68bc8e660a@github.com> On Mon, 4 Jan 2021 17:17:58 GMT, Guoxiong Li wrote: > Hi all, > > This patch adds two methods in `ToolBox` to do the negative filtering. Although the label `noreg-self` was added, I write a test for this enhancement to verify the code. And the method name `grepNotMatch` may need to be improved. Any idea is appreciated. > > Thank you for taking the time to review. > > Best Regards. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/1934 From duke at openjdk.java.net Tue Mar 2 17:08:44 2021 From: duke at openjdk.java.net (duke) Date: Tue, 2 Mar 2021 17:08:44 GMT Subject: Withdrawn: 8198317: Enhance JavacTool.getTask for flexibility In-Reply-To: References: Message-ID: On Fri, 25 Dec 2020 16:26:39 GMT, Guoxiong Li wrote: > Hi all, > > This little patch enhances the setting of `Log` in `JavacTool.getTask`. > > Thank you for taking the time to review. > > Best Regards. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/1896 From jlahoda at openjdk.java.net Tue Mar 2 17:46:41 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Tue, 2 Mar 2021 17:46:41 GMT Subject: RFR: 8198317: Enhance JavacTool.getTask for flexibility [v3] In-Reply-To: References: <1C7URguurLTNecDlWJUVnuzOMKjxWYTbtMALA7_zujM=.34d4f580-4695-4790-afbd-16d5a2b8120b@github.com> Message-ID: On Tue, 5 Jan 2021 14:29:25 GMT, Guoxiong Li wrote: >> Given that the `langtools/tier1` pre-submit tests worked for Linux and Windows, you're OK on the "newline" front. > > @jonathan-gibbons I updated the code according to your comments. Thank you for taking the time to review. @lgxbslgx, could you please re-open this PR? Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/1896 From jai.forums2013 at gmail.com Wed Mar 3 10:14:18 2021 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Wed, 3 Mar 2021 15:44:18 +0530 Subject: RFR: 8173970: jar tool should have a way to extract to a directory In-Reply-To: References: <1BB8805F-174A-4EB9-B26A-060B2251A40C@oracle.com> <6242cfe8-cef7-0603-33fc-b3428209a1ac@gmail.com> Message-ID: Thank you Lance. So I think there's some level of agreement on using -C and --dir (or --directory) for the option names. Anymore opinion on the directory creation semantics and any other aspects to consider? -Jaikiran On 28/02/21 5:38 pm, Lance Andersen wrote: > Hi Jaikiran, > > Thank you for this. ?I went through this myself yesterday in addition > to what you have below here are a few more: > > 7zip: ? ? ? -o > Info-zip: ?-d ?(MacOS version of zip) > Bandzip: -o:{dir} > jpackage: -d ?dest > jlink ?output > > > Thinking about this some more, I might suggest supporting > > -C > ?dir > ?directory > > Best > Lance > >> On Feb 27, 2021, at 11:19 PM, Jaikiran Pai > > wrote: >> >> Hello Alan, >> >> On 27/02/21 2:23 pm, Alan Bateman wrote: >>> >>> Yes, the option name will need to be agreed. It would be useful to >>> enumerate the options that the other tools are using to specify the >>> location where to extract. If you see JBS issues mentioning tar -C >>> not supporting chdir when extracting then it might be Solaris tar, >>> which isn't the same as GNU tar which has different options. It >>> might be better to look at more main stream tools, like unzip >>> although jar -d is already taken. It would be nice if there were >>> some consistency with other tools in the JDK that doing extracting >>> (The jmod and jimage extract commands use use --dir for example). >> >> I had a look at both tar and unzip commands on MacOS and Linux >> (CentOS) setup that I had access to. >> >> -------------- >> tar on MacOS: >> -------------- >> >> tar --version >> bsdtar 3.3.2 - libarchive 3.3.2 zlib/1.2.11 liblzma/5.0.5 bz2lib/1.0.6 >> >> The version of this tool has: >> >> -C directory, --cd directory, --directory directory >> ???????????? In c and r mode, this changes the directory before >> adding the following files. >> ???????????? In x mode, change directories after opening the archive >> but before extracting >> ???????????? entries from the archive. >> >> A command like "tar -xzf foo.tar.gz -C /tmp/bar/" works fine and >> extracts the foo.tar.gz from current directory to a target directory >> /tmp/bar/ >> >> -------------- >> tar on CentOS: >> -------------- >> >> tar --version >> tar (GNU tar) 1.26 >> >> This version of the tool has: >> >> Common options: >> ?????? -C, --directory=DIR >> ????????????? change to directory DIR >> >> Although the wording isn't clear that, when used with -x, it extracts >> to the directory specified in -C, it does indeed behave that way. >> >> Specifically, a command like "tar -xzf foo.tar.gz -C /tmp/bar/" works >> fine and extracts the foo.tar.gz from current directory to a target >> directory /tmp/bar/ >> >> ------------------------------- >> unzip on both MacOS and CentOS: >> ------------------------------- >> >> unzip -v >> UnZip 6.00 of 20 April 2009, by Info-ZIP.? Maintained by C. Spieler. >> >> This version of the tool has: >> >> [-d exdir] >> ????????????? An optional directory to which to extract files.? By >> default, all files and sub- >> ????????????? directories are recreated in the current directory; the >> -d option allows extrac- >> ????????????? tion in an arbitrary directory (always assuming one has >> permission to? write? to >> ????????????? the? directory).? This option need not appear at the >> end of the command line; it >> ????????????? is also accepted before the zipfile specification >> (with? the? normal? options), >> ????????????? immediately? after? the zipfile specification, or >> between the file(s) and the -x >> ????????????? option.? The option and directory may be concatenated >> without? any? white? space >> ????????????? between? them,? but? note? that? this may cause normal >> shell behavior to be sup- >> ????????????? pressed.? In particular, ``-d ~'' (tilde) is expanded >> by Unix C shells into? the >> ????????????? name of the user's home directory, but ``-d~'' is >> treated as a literal subdirec- >> ????????????? tory ``~'' of the current directory. >> >> unzip foo.zip -d /tmp/bar/ works fine and extracts the foo.zip from >> current directory to /tmp/bar/ >> >> --------------- >> jimage and jmod >> --------------- >> >> The jimage and jmod as you note use the --dir option for extracting >> to that specified directory. >> >> >> Those were the tools I looked at. I think using the -d option with -x >> for the jar command is ruled out since it already is used for a >> different purpose, although for a different "main" operation of the >> jar command. >> >> As for using --dir for this new feature, I don't think it alone will >> be enough. Specifically, I couldn't find a "short form" option for >> the --dir option in the jimage or jmod commands. For the jar extract >> feature that we are discussing here, I think having a short form >> option (in addition to the longer form) is necessary to have it match >> the usage expectations of similar other options that the jar command >> exposes. So even if we do choose --dir as the long form option, we >> would still need a short form for it and since -d is already taken >> for something else, we would still need to come up with a different >> one. The short form of this option could be -C (see below). >> >> >> I think reusing the -C option, for this new feature, perhaps is a >> good thing. The -C is currently used by the update and create "main" >> operation of the jar command and the man page for this option states: >> >> -C dir >> ????????????? When creating (c) or updating (u) a JAR file, this >> option temporarily changes >> ????????????? the directory while processing files specified by the >> file operands. Its >> ????????????? operation is intended to be similar to the -C option of >> the UNIX tar utility.For >> ????????????? example, the following command changes to the classes >> directory and adds the >> ????????????? Bar.class file from that directory to my.jar: >> >> ????????????? jar uf my.jar -C classes Bar.class >> .... >> >> Using the -C option would indeed align it with the tar command. For >> the "long form" of this option, the tar command (both on MacOS and >> CentOS) uses --directory. For this jar extract feature though, we >> could perhaps just use --dir to have it align with the jimage and the >> jmod tools. >> >> So I think the combination of -C (short form) and --dir (long form) >> would perhaps be suitable for this feature. >> >> >>> >>> There are other discussion points around the behavior when the >>> target directory exists or does not exist, to ensure there is some >>> consistency with main stream tools. >> >> I'm guessing you mean the behaviour of creating a directory (or a >> hierarchy of directories) if the target directory is not present? My >> testing with the tar tool (both on MacOS and CentOS) shows that if >> the specified target directory doesn't exist, then the extract fails. >> The tar extract command doesn't create the target directory during >> extract. On the other hand, the unzip tool, does create the directory >> if it doesn't exist. However, interestingly, the unzip tool creates >> only one level of that directory if it doesn't exist. Specifically, >> if you specify: >> >> unzip foo.zip -d /tmp/blah/ >> >> and if "blah/" isn't a directory inside /tmp/ directory, then it >> creates the "blah/" directory inside /tmp/ and then extracts the >> contents of the zip into it. >> >> However, >> >> unzip foo.zip -d /tmp/blah/hello/ >> >> and if "blah/" isn't a directory inside /tmp/ directory, then this >> command fails with an error and it doesn't create the hierarchy of >> the target directories. >> >> Coming to the jimage and the jmod commands, both these commands >> create the entire directory hierarchy if the target directory >> specified during extract, using --dir, doesn't exist. So a command like: >> >> jimage extract --dir /tmp/blah/foo/bar/ jdkmodules >> >> will create the blah/foo/bar/ directory hierarchy if blah doesn't >> exist in /tmp/, while extracting the "jdkmodules" image. >> >> From the user point of view, I think this behaviour of creating the >> directories if the target directory doesn't exist, is probably the >> most intuitive and useful and if we did decide to use this approach >> for this new option for jar extract command, then it would align with >> what we already do in jimage and jmod commands. >> >> One another minor detail, while we are at this, is that, IMO we >> should let the jar extract command to continue to behave the way it >> currently does when it comes to overwriting existing files. If the >> jar being extracted contains a file by the same name, in the target >> directory (hierarchy) then it should continue to overwrite that file. >> In other words, I don't think we should change the way the jar >> extract command currently behaves where it overwrites existing files >> when extracting. >> >> >> -Jaikiran >> >> > > > > > Lance Andersen| Principal?Member of Technical Staff?| +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: oracle_sig_logo.gif Type: image/gif Size: 658 bytes Desc: not available URL: From jlahoda at openjdk.java.net Wed Mar 3 12:41:56 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Wed, 3 Mar 2021 12:41:56 GMT Subject: Integrated: 8259235: javac crashes while attributing super method invocation In-Reply-To: References: Message-ID: On Tue, 5 Jan 2021 16:47:26 GMT, Jan Lahoda wrote: > Code like: > public class SuperMethodCallBroken extends Undef implements I { > public void test() { > I.super.test(); > } > } > interface I { > public default void test() {} > } > > crashes javac. The reason is that when `I.super` is being attributed, the interfaces of the enclosing class are pruned to remove subtypes - but `Undef` is erroneous and is a subtype of every type. So `I` is removed from the list of interfaces to check, and javac crashes then. > > The proposed fix is to ignore erroneous supertypes when looking for subtypes. This pull request has now been integrated. Changeset: 6d3c858c Author: Jan Lahoda URL: https://git.openjdk.java.net/jdk/commit/6d3c858c Stats: 18 lines in 3 files changed: 17 ins; 0 del; 1 mod 8259235: javac crashes while attributing super method invocation Reviewed-by: vromero ------------- PR: https://git.openjdk.java.net/jdk/pull/1945 From lance.andersen at oracle.com Wed Mar 3 15:44:32 2021 From: lance.andersen at oracle.com (Lance Andersen) Date: Wed, 3 Mar 2021 15:44:32 +0000 Subject: RFR: 8173970: jar tool should have a way to extract to a directory In-Reply-To: References: <1BB8805F-174A-4EB9-B26A-060B2251A40C@oracle.com> <6242cfe8-cef7-0603-33fc-b3428209a1ac@gmail.com> Message-ID: Hi Jaikiran, It should not be too difficult to support the options listed below via GNUStyleOptions. Some other things needed to be defined and agreed upon in order to move forward * The behavior if the path does not exist * If the option is specified more than once on the command line * Clarify the behavior if any of the files exist in the specified target directory. Once you have a chance to consider the above, please send your proposal back to the alias to continue the discussion Best Lance On Mar 3, 2021, at 5:14 AM, Jaikiran Pai > wrote: Thank you Lance. So I think there's some level of agreement on using -C and --dir (or --directory) for the option names. Anymore opinion on the directory creation semantics and any other aspects to consider? -Jaikiran On 28/02/21 5:38 pm, Lance Andersen wrote: Hi Jaikiran, Thank you for this. I went through this myself yesterday in addition to what you have below here are a few more: 7zip: -o Info-zip: -d (MacOS version of zip) Bandzip: -o:{dir} jpackage: -d ?dest jlink ?output Thinking about this some more, I might suggest supporting -C ?dir ?directory Best Lance On Feb 27, 2021, at 11:19 PM, Jaikiran Pai > wrote: Hello Alan, On 27/02/21 2:23 pm, Alan Bateman wrote: Yes, the option name will need to be agreed. It would be useful to enumerate the options that the other tools are using to specify the location where to extract. If you see JBS issues mentioning tar -C not supporting chdir when extracting then it might be Solaris tar, which isn't the same as GNU tar which has different options. It might be better to look at more main stream tools, like unzip although jar -d is already taken. It would be nice if there were some consistency with other tools in the JDK that doing extracting (The jmod and jimage extract commands use use --dir for example). I had a look at both tar and unzip commands on MacOS and Linux (CentOS) setup that I had access to. -------------- tar on MacOS: -------------- tar --version bsdtar 3.3.2 - libarchive 3.3.2 zlib/1.2.11 liblzma/5.0.5 bz2lib/1.0.6 The version of this tool has: -C directory, --cd directory, --directory directory In c and r mode, this changes the directory before adding the following files. In x mode, change directories after opening the archive but before extracting entries from the archive. A command like "tar -xzf foo.tar.gz -C /tmp/bar/" works fine and extracts the foo.tar.gz from current directory to a target directory /tmp/bar/ -------------- tar on CentOS: -------------- tar --version tar (GNU tar) 1.26 This version of the tool has: Common options: -C, --directory=DIR change to directory DIR Although the wording isn't clear that, when used with -x, it extracts to the directory specified in -C, it does indeed behave that way. Specifically, a command like "tar -xzf foo.tar.gz -C /tmp/bar/" works fine and extracts the foo.tar.gz from current directory to a target directory /tmp/bar/ ------------------------------- unzip on both MacOS and CentOS: ------------------------------- unzip -v UnZip 6.00 of 20 April 2009, by Info-ZIP. Maintained by C. Spieler. This version of the tool has: [-d exdir] An optional directory to which to extract files. By default, all files and sub- directories are recreated in the current directory; the -d option allows extrac- tion in an arbitrary directory (always assuming one has permission to write to the directory). This option need not appear at the end of the command line; it is also accepted before the zipfile specification (with the normal options), immediately after the zipfile specification, or between the file(s) and the -x option. The option and directory may be concatenated without any white space between them, but note that this may cause normal shell behavior to be sup- pressed. In particular, ``-d ~'' (tilde) is expanded by Unix C shells into the name of the user's home directory, but ``-d~'' is treated as a literal subdirec- tory ``~'' of the current directory. unzip foo.zip -d /tmp/bar/ works fine and extracts the foo.zip from current directory to /tmp/bar/ --------------- jimage and jmod --------------- The jimage and jmod as you note use the --dir option for extracting to that specified directory. Those were the tools I looked at. I think using the -d option with -x for the jar command is ruled out since it already is used for a different purpose, although for a different "main" operation of the jar command. As for using --dir for this new feature, I don't think it alone will be enough. Specifically, I couldn't find a "short form" option for the --dir option in the jimage or jmod commands. For the jar extract feature that we are discussing here, I think having a short form option (in addition to the longer form) is necessary to have it match the usage expectations of similar other options that the jar command exposes. So even if we do choose --dir as the long form option, we would still need a short form for it and since -d is already taken for something else, we would still need to come up with a different one. The short form of this option could be -C (see below). I think reusing the -C option, for this new feature, perhaps is a good thing. The -C is currently used by the update and create "main" operation of the jar command and the man page for this option states: -C dir When creating (c) or updating (u) a JAR file, this option temporarily changes the directory while processing files specified by the file operands. Its operation is intended to be similar to the -C option of the UNIX tar utility.For example, the following command changes to the classes directory and adds the Bar.class file from that directory to my.jar: jar uf my.jar -C classes Bar.class .... Using the -C option would indeed align it with the tar command. For the "long form" of this option, the tar command (both on MacOS and CentOS) uses --directory. For this jar extract feature though, we could perhaps just use --dir to have it align with the jimage and the jmod tools. So I think the combination of -C (short form) and --dir (long form) would perhaps be suitable for this feature. There are other discussion points around the behavior when the target directory exists or does not exist, to ensure there is some consistency with main stream tools. I'm guessing you mean the behaviour of creating a directory (or a hierarchy of directories) if the target directory is not present? My testing with the tar tool (both on MacOS and CentOS) shows that if the specified target directory doesn't exist, then the extract fails. The tar extract command doesn't create the target directory during extract. On the other hand, the unzip tool, does create the directory if it doesn't exist. However, interestingly, the unzip tool creates only one level of that directory if it doesn't exist. Specifically, if you specify: unzip foo.zip -d /tmp/blah/ and if "blah/" isn't a directory inside /tmp/ directory, then it creates the "blah/" directory inside /tmp/ and then extracts the contents of the zip into it. However, unzip foo.zip -d /tmp/blah/hello/ and if "blah/" isn't a directory inside /tmp/ directory, then this command fails with an error and it doesn't create the hierarchy of the target directories. Coming to the jimage and the jmod commands, both these commands create the entire directory hierarchy if the target directory specified during extract, using --dir, doesn't exist. So a command like: jimage extract --dir /tmp/blah/foo/bar/ jdkmodules will create the blah/foo/bar/ directory hierarchy if blah doesn't exist in /tmp/, while extracting the "jdkmodules" image. From the user point of view, I think this behaviour of creating the directories if the target directory doesn't exist, is probably the most intuitive and useful and if we did decide to use this approach for this new option for jar extract command, then it would align with what we already do in jimage and jmod commands. One another minor detail, while we are at this, is that, IMO we should let the jar extract command to continue to behave the way it currently does when it comes to overwriting existing files. If the jar being extracted contains a file by the same name, in the target directory (hierarchy) then it should continue to overwrite that file. In other words, I don't think we should change the way the jar extract command currently behaves where it overwrites existing files when extracting. -Jaikiran Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com [cid:E1C4E2F0-ECD0-4C9D-ADB4-B16CA7BCB7FC at home] Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: oracle_sig_logo.gif Type: image/gif Size: 658 bytes Desc: oracle_sig_logo.gif URL: From jlahoda at openjdk.java.net Wed Mar 3 16:47:54 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Wed, 3 Mar 2021 16:47:54 GMT Subject: RFR: 8261450: JShell crashes with SIOOBE in tab completion Message-ID: `reflowTillNow` will strip trailing spaces, but then `reflownTo` may point after the full content of `result`. Need to fix `reflownTo` to not point after the full content of `result`, otherwise a `StringIndexOutOfBoundsException` may occur. ------------- Commit messages: - 8261450: JShell crashes with SIOOBE in tab completion Changes: https://git.openjdk.java.net/jdk/pull/2812/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2812&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261450 Stats: 16 lines in 2 files changed: 13 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/2812.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2812/head:pull/2812 PR: https://git.openjdk.java.net/jdk/pull/2812 From vromero at openjdk.java.net Wed Mar 3 19:18:39 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Wed, 3 Mar 2021 19:18:39 GMT Subject: RFR: 8261450: JShell crashes with SIOOBE in tab completion In-Reply-To: References: Message-ID: On Wed, 3 Mar 2021 16:43:02 GMT, Jan Lahoda wrote: > `reflowTillNow` will strip trailing spaces, but then `reflownTo` may point after the full content of `result`. Need to fix `reflownTo` to not point after the full content of `result`, otherwise a `StringIndexOutOfBoundsException` may occur. lgtm! ------------- Marked as reviewed by vromero (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2812 From jai.forums2013 at gmail.com Thu Mar 4 02:40:40 2021 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Thu, 4 Mar 2021 08:10:40 +0530 Subject: RFR: 8173970: jar tool should have a way to extract to a directory In-Reply-To: References: <1BB8805F-174A-4EB9-B26A-060B2251A40C@oracle.com> <6242cfe8-cef7-0603-33fc-b3428209a1ac@gmail.com> Message-ID: <1e14f8e1-c4d2-1e11-df88-8af083bac8f9@gmail.com> Hello Lance, On 03/03/21 9:14 pm, Lance Andersen wrote: > > > Some other things needed to be defined and agreed upon in order to > move forward > > * The behavior if the path does not exist > * If the option is specified more than once on the command line > * Clarify the behavior if any of the files exist in the specified > target directory. > One of my previous reply included the details of how I think it should behave for 2 of the above cases. I'll paste that here again for easier visibility. As for how it should behave if the option is specified more than once, I'll spend some time today to see how the jar tool currently behaves for some of the other options in this aspect and send back my response. Thank you for your help so far. Pasting below my proposal from a previous reply for the other 2 cases: > > There are other discussion points around the behavior when the target > directory exists or does not exist, to ensure there is some > consistency with main stream tools. I'm guessing you mean the behaviour of creating a directory (or a hierarchy of directories) if the target directory is not present? My testing with the tar tool (both on MacOS and CentOS) shows that if the specified target directory doesn't exist, then the extract fails. The tar extract command doesn't create the target directory during extract. On the other hand, the unzip tool, does create the directory if it doesn't exist. However, interestingly, the unzip tool creates only one level of that directory if it doesn't exist. Specifically, if you specify: unzip foo.zip -d /tmp/blah/ and if "blah/" isn't a directory inside /tmp/ directory, then it creates the "blah/" directory inside /tmp/ and then extracts the contents of the zip into it. However, unzip foo.zip -d /tmp/blah/hello/ and if "blah/" isn't a directory inside /tmp/ directory, then this command fails with an error and it doesn't create the hierarchy of the target directories. Coming to the jimage and the jmod commands, both these commands create the entire directory hierarchy if the target directory specified during extract, using --dir, doesn't exist. So a command like: jimage extract --dir /tmp/blah/foo/bar/ jdkmodules will create the blah/foo/bar/ directory hierarchy if blah doesn't exist in /tmp/, while extracting the "jdkmodules" image. From the user point of view, I think this behaviour of creating the directories if the target directory doesn't exist, is probably the most intuitive and useful and if we did decide to use this approach for this new option for jar extract command, then it would align with what we already do in jimage and jmod commands. One another minor detail, while we are at this, is that, IMO we should let the jar extract command to continue to behave the way it currently does when it comes to overwriting existing files. If the jar being extracted contains a file by the same name, in the target directory (hierarchy) then it should continue to overwrite that file. In other words, I don't think we should change the way the jar extract command currently behaves where it overwrites existing files when extracting. -Jaikiran -------------- next part -------------- An HTML attachment was scrubbed... URL: From lance.andersen at oracle.com Thu Mar 4 12:01:35 2021 From: lance.andersen at oracle.com (Lance Andersen) Date: Thu, 4 Mar 2021 12:01:35 +0000 Subject: RFR: 8173970: jar tool should have a way to extract to a directory In-Reply-To: <1e14f8e1-c4d2-1e11-df88-8af083bac8f9@gmail.com> References: <1BB8805F-174A-4EB9-B26A-060B2251A40C@oracle.com> <6242cfe8-cef7-0603-33fc-b3428209a1ac@gmail.com> <1e14f8e1-c4d2-1e11-df88-8af083bac8f9@gmail.com> Message-ID: <9B159F65-A7CC-4FEA-BAB8-77D66D7AD5AB@oracle.com> Hi Jaikiran From https://docs.oracle.com/en/java/javase/15/docs/specs/man/jar.html The jar man page includes the following : The syntax for the jar command resembles the syntax for the tar command. Because of the above, I feel that we should support: ??? -C ?dir ?directory ???? The addition of ?-dir? adds support for an option used by some of the other java command line tools. I would suggest for the next step is flush/write out your proposed syntax as it would be included in an updated version of the jar man page. Given the other java command line tools create the directory if it does not exist, I think that is reasonable to propose that. Your change should not modify the longstanding overwrite behavior of jar. Another thing to think about is whether there should be any additional output when the -v option is specified In summary, I think you are moving in the right direction. The next step is to make a pass at creating the man page updates so that we can reach consensus on the syntax and behavior. Thank you again for your efforts on this Best Lance On Mar 3, 2021, at 9:40 PM, Jaikiran Pai > wrote: Hello Lance, On 03/03/21 9:14 pm, Lance Andersen wrote: Some other things needed to be defined and agreed upon in order to move forward * The behavior if the path does not exist * If the option is specified more than once on the command line * Clarify the behavior if any of the files exist in the specified target directory. One of my previous reply included the details of how I think it should behave for 2 of the above cases. I'll paste that here again for easier visibility. As for how it should behave if the option is specified more than once, I'll spend some time today to see how the jar tool currently behaves for some of the other options in this aspect and send back my response. Thank you for your help so far. Pasting below my proposal from a previous reply for the other 2 cases: There are other discussion points around the behavior when the target directory exists or does not exist, to ensure there is some consistency with main stream tools. I'm guessing you mean the behaviour of creating a directory (or a hierarchy of directories) if the target directory is not present? My testing with the tar tool (both on MacOS and CentOS) shows that if the specified target directory doesn't exist, then the extract fails. The tar extract command doesn't create the target directory during extract. On the other hand, the unzip tool, does create the directory if it doesn't exist. However, interestingly, the unzip tool creates only one level of that directory if it doesn't exist. Specifically, if you specify: unzip foo.zip -d /tmp/blah/ and if "blah/" isn't a directory inside /tmp/ directory, then it creates the "blah/" directory inside /tmp/ and then extracts the contents of the zip into it. However, unzip foo.zip -d /tmp/blah/hello/ and if "blah/" isn't a directory inside /tmp/ directory, then this command fails with an error and it doesn't create the hierarchy of the target directories. Coming to the jimage and the jmod commands, both these commands create the entire directory hierarchy if the target directory specified during extract, using --dir, doesn't exist. So a command like: jimage extract --dir /tmp/blah/foo/bar/ jdkmodules will create the blah/foo/bar/ directory hierarchy if blah doesn't exist in /tmp/, while extracting the "jdkmodules" image. From the user point of view, I think this behaviour of creating the directories if the target directory doesn't exist, is probably the most intuitive and useful and if we did decide to use this approach for this new option for jar extract command, then it would align with what we already do in jimage and jmod commands. One another minor detail, while we are at this, is that, IMO we should let the jar extract command to continue to behave the way it currently does when it comes to overwriting existing files. If the jar being extracted contains a file by the same name, in the target directory (hierarchy) then it should continue to overwrite that file. In other words, I don't think we should change the way the jar extract command currently behaves where it overwrites existing files when extracting. -Jaikiran [cid:E1C4E2F0-ECD0-4C9D-ADB4-B16CA7BCB7FC at home] Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: oracle_sig_logo.gif Type: image/gif Size: 658 bytes Desc: oracle_sig_logo.gif URL: From jlahoda at openjdk.java.net Thu Mar 4 12:39:53 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Thu, 4 Mar 2021 12:39:53 GMT Subject: Integrated: 8261450: JShell crashes with SIOOBE in tab completion In-Reply-To: References: Message-ID: <31uyvFuqG4QyrVPBCkEH2V3xDCkVzCnvj0OQujfPcO4=.acd1ff4b-cd7f-4223-b016-87c5edf5650f@github.com> On Wed, 3 Mar 2021 16:43:02 GMT, Jan Lahoda wrote: > `reflowTillNow` will strip trailing spaces, but then `reflownTo` may point after the full content of `result`. Need to fix `reflownTo` to not point after the full content of `result`, otherwise a `StringIndexOutOfBoundsException` may occur. This pull request has now been integrated. Changeset: 94f26e4d Author: Jan Lahoda URL: https://git.openjdk.java.net/jdk/commit/94f26e4d Stats: 16 lines in 2 files changed: 13 ins; 0 del; 3 mod 8261450: JShell crashes with SIOOBE in tab completion Reviewed-by: vromero ------------- PR: https://git.openjdk.java.net/jdk/pull/2812 From duke at openjdk.java.net Thu Mar 4 14:25:40 2021 From: duke at openjdk.java.net (duke) Date: Thu, 4 Mar 2021 14:25:40 GMT Subject: Withdrawn: 8150303: Rewrite test/tools/javac/Paths/Diagnostics.sh In-Reply-To: References: Message-ID: On Wed, 6 Jan 2021 14:18:49 GMT, Guoxiong Li wrote: > Hi all, > > This patch rewrites Diagnostics.sh to java code by using ToolBox API. > And I have a question: What does the `elts` mean in the following comments? Is it `elements`? > I think that a meaningful name should be used. > > // Warn for missing elts in user-specified paths > // No warning for missing elts in "system" paths > > Thank you for taking the time to review. > > Best Regards. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/1959 From mcimadamore at openjdk.java.net Fri Mar 5 22:02:16 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 5 Mar 2021 22:02:16 GMT Subject: RFR: 8057543: Replace javac's Filter with Predicate (and lambdas) In-Reply-To: References: Message-ID: On Sun, 27 Dec 2020 14:54:16 GMT, Guoxiong Li wrote: > Hi all, > > This patch replaces javac's `Filter` with `Predicate` and sets `Filter` as `Deprecated`. > Two existing tests failed and I fixed it. > Currently, all the tests in `test/langtools` passed locally by using the following command. > > make test CONF=linux-x86_64-server-release JOBS=4 TEST=test/langtools/ > > Thank you for taking the time to review. > > Best Regards. This looks very good - sorry I missed it. If you reopen I will approve! ------------- PR: https://git.openjdk.java.net/jdk/pull/1898 From jjg at openjdk.java.net Sat Mar 6 09:00:19 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Sat, 6 Mar 2021 09:00:19 GMT Subject: RFR: JDK-8258957: DocLint: check for HTML start element at end of body Message-ID: Please review a moderately simple fix to improve DocLint's checking for empty tags, and in particular, bad use of `

` as a paragraph terminator. This will help detect this bad usage at doclint-time, instead of later, with doccheck. There was already code to check if tags were empty. (`warnIfEmpty`), and code to check for open tags at the end of the comment. The change is primarily to invoke the "check for open tags" at the end of main body of a comment and at the end of each block tag (i.e including all that allow HTML content in the body of the block tag.) There is a secondary minor edit to check if a tag was empty when auto-closing it. The changes discovered 5 instances of bad use of `

` in the JDK docs. These are being fixed separately in https://bugs.openjdk.java.net/browse/JDK-8263104 ------------- Commit messages: - JDK-8258957: DocLint: check for HTML start element at end of body Changes: https://git.openjdk.java.net/jdk/pull/2853/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2853&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258957 Stats: 85 lines in 5 files changed: 82 ins; 1 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/2853.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2853/head:pull/2853 PR: https://git.openjdk.java.net/jdk/pull/2853 From github.com+741251+turbanoff at openjdk.java.net Sun Mar 7 20:31:08 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Sun, 7 Mar 2021 20:31:08 GMT Subject: RFR: 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy [v11] In-Reply-To: References: <6zhT8ySP8rFE4wV5vva0oKRDSxDnSYYZ-sXAQJ6F_DM=.b83a0f88-7231-4796-a0b5-d51b5950d316@github.com> Message-ID: On Fri, 19 Feb 2021 15:03:11 GMT, Sean Mullan wrote: >> As I can see only ByteArrayInputStream is actually passed in `InputStream` in current JDK code: >> >> PKCS7 pkcs7 = new PKCS7(is.readAllBytes()); >> private static List parsePKCS7(InputStream is) >> certs = parsePKCS7(is); >> public X509CertPath(InputStream is, String encoding) >> return new X509CertPath(new ByteArrayInputStream(data), encoding); >> >> PKCS7 pkcs7 = new PKCS7(is.readAllBytes()); >> private static List parsePKCS7(InputStream is) >> certs = parsePKCS7(is); >> public X509CertPath(InputStream is, String encoding) >> this(is, PKIPATH_ENCODING); >> public X509CertPath(InputStream is) throws CertificateException { >> return new X509CertPath(new ByteArrayInputStream(encoding)); >> >> ![???????????](https://user-images.githubusercontent.com/741251/108475587-f4f61080-72a1-11eb-91e0-ac2b98c7c490.png) >> >> Perhaps original marking approach was lost during refactoring? > > You are right, the code was refactored (way back in 2010) [1] to read one block at a time, so this check on mark can be removed. So, in this case, I think it is probably safe to just pass the InputStream as-is to PKCS7(InputStream), but maybe you can add a comment that says this should always be a ByteArrayInputStream. We can look at refactoring this code and clean it up a bit more later. > > [1] https://hg.openjdk.java.net/jdk/jdk/rev/337ae296b6d6 I find implementation of `sun.security.pkcs.PKCS7#PKCS7(java.io.InputStream)` a bit confusing (or even buggy). It uses only `InputStream.available()` to parse block. So I would prefer to not use it. ------------- PR: https://git.openjdk.java.net/jdk/pull/1853 From jlahoda at openjdk.java.net Mon Mar 8 11:26:25 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Mon, 8 Mar 2021 11:26:25 GMT Subject: RFR: 8198317: Enhance JavacTool.getTask for flexibility Message-ID: This is a clone of https://github.com/openjdk/jdk/pull/1896, which got closed by Skara. @lgxbslgx, please let me know if you would prefer to resubmit the PR yourself. ------------- Commit messages: - Revise test code. Fix typo. - Revise test. - Add a test case. - 8198317: Enhance JavacTool.getTask for flexibility Changes: https://git.openjdk.java.net/jdk/pull/2871/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2871&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8198317 Stats: 137 lines in 2 files changed: 135 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/2871.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2871/head:pull/2871 PR: https://git.openjdk.java.net/jdk/pull/2871 From github.com+7806504+liach at openjdk.java.net Tue Mar 9 01:27:07 2021 From: github.com+7806504+liach at openjdk.java.net (liach) Date: Tue, 9 Mar 2021 01:27:07 GMT Subject: RFR: 8198317: Enhance JavacTool.getTask for flexibility In-Reply-To: References: Message-ID: On Mon, 8 Mar 2021 11:21:38 GMT, Jan Lahoda wrote: > This is a clone of https://github.com/openjdk/jdk/pull/1896, which got closed by Skara. > > @lgxbslgx, please let me know if you would prefer to resubmit the PR yourself. test/langtools/tools/javac/api/8198317/T8198317.java line 54: > 52: import static toolbox.ToolBox.lineSeparator; > 53: > 54: public class T8198317 extends TestRunner{ formatting ------------- PR: https://git.openjdk.java.net/jdk/pull/2871 From jjg at openjdk.java.net Tue Mar 9 05:26:07 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Tue, 9 Mar 2021 05:26:07 GMT Subject: RFR: 8198317: Enhance JavacTool.getTask for flexibility In-Reply-To: References: Message-ID: On Mon, 8 Mar 2021 11:21:38 GMT, Jan Lahoda wrote: > This is a clone of https://github.com/openjdk/jdk/pull/1896, which got closed by Skara. > > @lgxbslgx, please let me know if you would prefer to resubmit the PR yourself. Changes requested by jjg (Reviewer). test/langtools/tools/javac/api/8198317/T8198317.java line 54: > 52: import static toolbox.ToolBox.lineSeparator; > 53: > 54: public class T8198317 extends TestRunner{ These days, it is considered bad form to base a test name on a bug number. It's better to come up with a meaningful name for the test. That probably applies to the enclosing directory as well. ------------- PR: https://git.openjdk.java.net/jdk/pull/2871 From shade at openjdk.java.net Fri Mar 12 13:57:18 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 12 Mar 2021 13:57:18 GMT Subject: RFR: 8263514: Minor issue in JavacFileManager.SortFiles.REVERSE Message-ID: SonarCloud reports the problem in JavacFileManager.SortFiles.REVERSE definition: Neither "Math.abs" nor negation should be used on numbers that could be "MIN_VALUE" REVERSE { @Override public int compare(Path f1, Path f2) { return -f1.getFileName().compareTo(f2.getFileName()); } } Since `compareTo` can technically return `MIN_VALUE`, we cannot simply negate it. Luckily, we can just swap the `f1` and `f2` comparison order to achieve the same effect without exposing us to this corner case. ------------- Commit messages: - 8263514: Minor issue in JavacFileManager.SortFiles.REVERSE Changes: https://git.openjdk.java.net/jdk/pull/2970/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2970&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263514 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2970.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2970/head:pull/2970 PR: https://git.openjdk.java.net/jdk/pull/2970 From vromero at openjdk.java.net Fri Mar 12 21:04:06 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Fri, 12 Mar 2021 21:04:06 GMT Subject: RFR: JDK-8258957: DocLint: check for HTML start element at end of body In-Reply-To: References: Message-ID: On Fri, 5 Mar 2021 21:44:20 GMT, Jonathan Gibbons wrote: > Please review a moderately simple fix to improve DocLint's checking for empty tags, and in particular, bad use of `

` as a paragraph terminator. This will help detect this bad usage at doclint-time, instead of later, with doccheck. > > There was already code to check if tags were empty. (`warnIfEmpty`), and code to check for open tags at the end of the comment. The change is primarily to invoke the "check for open tags" at the end of main body of a comment and at the end of each block tag (i.e including all that allow HTML content in the body of the block tag.) > > There is a secondary minor edit to check if a tag was empty when auto-closing it. > > The changes discovered 5 instances of bad use of `

` in the JDK docs. These are being fixed separately in https://bugs.openjdk.java.net/browse/JDK-8263104 looks good ------------- Marked as reviewed by vromero (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2853 From jlahoda at openjdk.java.net Mon Mar 15 11:23:38 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Mon, 15 Mar 2021 11:23:38 GMT Subject: RFR: 8198317: Enhance JavacTool.getTask for flexibility [v2] In-Reply-To: References: Message-ID: > This is a clone of https://github.com/openjdk/jdk/pull/1896, which got closed by Skara. > > @lgxbslgx, please let me know if you would prefer to resubmit the PR yourself. Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: Updating test per review comments. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2871/files - new: https://git.openjdk.java.net/jdk/pull/2871/files/909140e1..ec3c8927 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2871&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2871&range=00-01 Stats: 7 lines in 1 file changed: 0 ins; 3 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/2871.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2871/head:pull/2871 PR: https://git.openjdk.java.net/jdk/pull/2871 From jboes at openjdk.java.net Mon Mar 15 12:55:11 2021 From: jboes at openjdk.java.net (Julia Boes) Date: Mon, 15 Mar 2021 12:55:11 GMT Subject: RFR: 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy In-Reply-To: References: <5s4i5725zJd8QrefwYyc8sn2fQXad3hAGLVflkFttmY=.abe55236-e258-482b-b8be-be75e1eb086c@github.com> Message-ID: On Thu, 18 Feb 2021 07:12:34 GMT, Andrey Turbanov wrote: >> Hi @turbanoff, I'm happy to sponsor but I see two comments by @marschall - have they been addressed? >> https://github.com/openjdk/jdk/pull/1853#discussion_r572815422 >> https://github.com/openjdk/jdk/pull/1853#discussion_r572380746 > > @FrauBoes fixed in the last commit. Is there any way to de-_integrate_ PR (to include last commit)? @turbanoff Given that this PR has been lingering for a while, you could drop the change in `X509CertPath.java` for now and integrate the remaining changes. I'm happy to sponsor in that case. ------------- PR: https://git.openjdk.java.net/jdk/pull/1853 From github.com+741251+turbanoff at openjdk.java.net Mon Mar 15 14:50:24 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Mon, 15 Mar 2021 14:50:24 GMT Subject: RFR: 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy [v13] In-Reply-To: References: Message-ID: > 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy drop changes in X509CertPath ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1853/files - new: https://git.openjdk.java.net/jdk/pull/1853/files/1b30471d..96920ee6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1853&range=12 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1853&range=11-12 Stats: 25 lines in 1 file changed: 22 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/1853.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1853/head:pull/1853 PR: https://git.openjdk.java.net/jdk/pull/1853 From vromero at openjdk.java.net Mon Mar 15 17:25:08 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Mon, 15 Mar 2021 17:25:08 GMT Subject: RFR: 8263514: Minor issue in JavacFileManager.SortFiles.REVERSE In-Reply-To: References: Message-ID: On Fri, 12 Mar 2021 13:52:51 GMT, Aleksey Shipilev wrote: > SonarCloud reports the problem in JavacFileManager.SortFiles.REVERSE definition: > Neither "Math.abs" nor negation should be used on numbers that could be "MIN_VALUE" > > REVERSE { > @Override > public int compare(Path f1, Path f2) { > return -f1.getFileName().compareTo(f2.getFileName()); > } > } > > Since `compareTo` can technically return `MIN_VALUE`, we cannot simply negate it. Luckily, we can just swap the `f1` and `f2` comparison order to achieve the same effect without exposing us to this corner case. looks good ------------- Marked as reviewed by vromero (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2970 From shade at openjdk.java.net Mon Mar 15 17:41:10 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 15 Mar 2021 17:41:10 GMT Subject: RFR: 8263514: Minor issue in JavacFileManager.SortFiles.REVERSE In-Reply-To: References: Message-ID: On Mon, 15 Mar 2021 17:22:12 GMT, Vicente Romero wrote: >> SonarCloud reports the problem in JavacFileManager.SortFiles.REVERSE definition: >> Neither "Math.abs" nor negation should be used on numbers that could be "MIN_VALUE" >> >> REVERSE { >> @Override >> public int compare(Path f1, Path f2) { >> return -f1.getFileName().compareTo(f2.getFileName()); >> } >> } >> >> Since `compareTo` can technically return `MIN_VALUE`, we cannot simply negate it. Luckily, we can just swap the `f1` and `f2` comparison order to achieve the same effect without exposing us to this corner case. > > looks good Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/2970 From shade at openjdk.java.net Mon Mar 15 17:41:11 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 15 Mar 2021 17:41:11 GMT Subject: Integrated: 8263514: Minor issue in JavacFileManager.SortFiles.REVERSE In-Reply-To: References: Message-ID: On Fri, 12 Mar 2021 13:52:51 GMT, Aleksey Shipilev wrote: > SonarCloud reports the problem in JavacFileManager.SortFiles.REVERSE definition: > Neither "Math.abs" nor negation should be used on numbers that could be "MIN_VALUE" > > REVERSE { > @Override > public int compare(Path f1, Path f2) { > return -f1.getFileName().compareTo(f2.getFileName()); > } > } > > Since `compareTo` can technically return `MIN_VALUE`, we cannot simply negate it. Luckily, we can just swap the `f1` and `f2` comparison order to achieve the same effect without exposing us to this corner case. This pull request has now been integrated. Changeset: 5ab52448 Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/5ab52448 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8263514: Minor issue in JavacFileManager.SortFiles.REVERSE Reviewed-by: vromero ------------- PR: https://git.openjdk.java.net/jdk/pull/2970 From jlahoda at openjdk.java.net Mon Mar 15 18:05:24 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Mon, 15 Mar 2021 18:05:24 GMT Subject: RFR: 8263590: Rawtypes warnings should be produced for pattern matching in instanceof Message-ID: For code like: Object o = null; boolean b = o instanceof List l; There should be a raw-type warning for `List`, as we are effectively declaring a variable with a raw type. Code like: Object o = null; boolean b = o instanceof List; Will not produce a warning (as it doesn't so far), as the (raw) type is not used in a problematic context. ------------- Commit messages: - 8263589: Rawtypes warnings should be produced for pattern matching in instanceof Changes: https://git.openjdk.java.net/jdk/pull/3016/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3016&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263590 Stats: 17 lines in 3 files changed: 16 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3016.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3016/head:pull/3016 PR: https://git.openjdk.java.net/jdk/pull/3016 From mcimadamore at openjdk.java.net Mon Mar 15 18:13:10 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Mon, 15 Mar 2021 18:13:10 GMT Subject: RFR: 8263590: Rawtypes warnings should be produced for pattern matching in instanceof In-Reply-To: References: Message-ID: On Mon, 15 Mar 2021 17:59:33 GMT, Jan Lahoda wrote: > For code like: > Object o = null; > boolean b = o instanceof List l; > > There should be a raw-type warning for `List`, as we are effectively declaring a variable with a raw type. > > Code like: > Object o = null; > boolean b = o instanceof List; > > Will not produce a warning (as it doesn't so far), as the (raw) type is not used in a problematic context. Looks good! ------------- Marked as reviewed by mcimadamore (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3016 From jboes at openjdk.java.net Mon Mar 15 18:52:17 2021 From: jboes at openjdk.java.net (Julia Boes) Date: Mon, 15 Mar 2021 18:52:17 GMT Subject: RFR: 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy In-Reply-To: References: <5s4i5725zJd8QrefwYyc8sn2fQXad3hAGLVflkFttmY=.abe55236-e258-482b-b8be-be75e1eb086c@github.com> Message-ID: <4Bae_Uh8Zakn4cnmbXkUcV9xRTus1hgHCEPVthHuEyc=.fb959963-ff7a-4067-b888-e178d9f70e91@github.com> On Thu, 18 Feb 2021 07:12:34 GMT, Andrey Turbanov wrote: >> Hi @turbanoff, I'm happy to sponsor but I see two comments by @marschall - have they been addressed? >> https://github.com/openjdk/jdk/pull/1853#discussion_r572815422 >> https://github.com/openjdk/jdk/pull/1853#discussion_r572380746 > > @FrauBoes fixed in the last commit. Is there any way to de-_integrate_ PR (to include last commit)? @turbanoff Tier 1-3 still all clear. If you /integrate, I will sponsor this tomorrow. ------------- PR: https://git.openjdk.java.net/jdk/pull/1853 From github.com+741251+turbanoff at openjdk.java.net Tue Mar 16 10:13:11 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Tue, 16 Mar 2021 10:13:11 GMT Subject: Integrated: 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy In-Reply-To: References: Message-ID: On Sun, 20 Dec 2020 17:05:21 GMT, Andrey Turbanov wrote: > 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy This pull request has now been integrated. Changeset: 68deb24b Author: Andrey Turbanov Committer: Julia Boes URL: https://git.openjdk.java.net/jdk/commit/68deb24b Stats: 105 lines in 7 files changed: 3 ins; 78 del; 24 mod 8080272: Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy Reviewed-by: mcimadamore, alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/1853 From prappo at openjdk.java.net Tue Mar 16 16:42:18 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Tue, 16 Mar 2021 16:42:18 GMT Subject: RFR: 8263688: Coordinate equals, hashCode and compareTo of JavacFileManager.PathAndContainer Message-ID: Please review this trivial change. Note that the change is not accompanied by a dedicated test. I don't think such a test would be warranted. ------------- Commit messages: - fix Changes: https://git.openjdk.java.net/jdk/pull/3034/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3034&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263688 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/3034.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3034/head:pull/3034 PR: https://git.openjdk.java.net/jdk/pull/3034 From vromero at openjdk.java.net Tue Mar 16 17:09:14 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Tue, 16 Mar 2021 17:09:14 GMT Subject: RFR: 8263688: Coordinate equals, hashCode and compareTo of JavacFileManager.PathAndContainer In-Reply-To: References: Message-ID: <2YkwilkHrSQRYZrPWofWsyQTxPJUgPgxbsxPgJQfkYM=.7fd12075-cdde-4401-a2df-6d9bf2df4038@github.com> On Tue, 16 Mar 2021 16:37:51 GMT, Pavel Rappo wrote: > Please review this trivial change. Note that the change is not accompanied by a dedicated test. I don't think such a test would be warranted. lgtm ------------- Marked as reviewed by vromero (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3034 From prappo at openjdk.java.net Tue Mar 16 17:34:06 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Tue, 16 Mar 2021 17:34:06 GMT Subject: RFR: 8263688: Coordinate equals, hashCode and compareTo of JavacFileManager.PathAndContainer In-Reply-To: <2YkwilkHrSQRYZrPWofWsyQTxPJUgPgxbsxPgJQfkYM=.7fd12075-cdde-4401-a2df-6d9bf2df4038@github.com> References: <2YkwilkHrSQRYZrPWofWsyQTxPJUgPgxbsxPgJQfkYM=.7fd12075-cdde-4401-a2df-6d9bf2df4038@github.com> Message-ID: On Tue, 16 Mar 2021 17:06:25 GMT, Vicente Romero wrote: >> Please review this trivial change. Note that the change is not accompanied by a dedicated test. I don't think such a test would be warranted. > > lgtm @vicente-romero-oracle thanks for reviewing this. I note that although that class could be promoted to a record, it should be done separately when mass-retrofitting compiler code with newer language features. ------------- PR: https://git.openjdk.java.net/jdk/pull/3034 From vromero at openjdk.java.net Tue Mar 16 19:41:08 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Tue, 16 Mar 2021 19:41:08 GMT Subject: Integrated: 8260959: remove RECORDS from PreviewFeature.Feature enum In-Reply-To: References: Message-ID: On Tue, 2 Feb 2021 18:33:18 GMT, Vicente Romero wrote: > Please review this simple fix that is removing the RECORDS enum constant from the PreviewFeature.Feature enum, now that RECORDS are final in 16 this constant can be safely removed. > > Thanks, > Vicente This pull request has now been integrated. Changeset: 9cb9af68 Author: Vicente Romero URL: https://git.openjdk.java.net/jdk/commit/9cb9af68 Stats: 6 lines in 1 file changed: 0 ins; 6 del; 0 mod 8260959: remove RECORDS from PreviewFeature.Feature enum Reviewed-by: jlahoda ------------- PR: https://git.openjdk.java.net/jdk/pull/2360 From prappo at openjdk.java.net Wed Mar 17 10:35:50 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Wed, 17 Mar 2021 10:35:50 GMT Subject: Integrated: 8263688: Coordinate equals, hashCode and compareTo of JavacFileManager.PathAndContainer In-Reply-To: References: Message-ID: On Tue, 16 Mar 2021 16:37:51 GMT, Pavel Rappo wrote: > Please review this trivial change. Note that the change is not accompanied by a dedicated test. I don't think such a test would be warranted. This pull request has now been integrated. Changeset: 23fc2a4d Author: Pavel Rappo URL: https://git.openjdk.java.net/jdk/commit/23fc2a4d Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8263688: Coordinate equals, hashCode and compareTo of JavacFileManager.PathAndContainer Reviewed-by: vromero ------------- PR: https://git.openjdk.java.net/jdk/pull/3034 From jlahoda at openjdk.java.net Thu Mar 18 09:17:58 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Thu, 18 Mar 2021 09:17:58 GMT Subject: RFR: 8263432: javac may report an invalid package/class clash on case insensitive filesystems Message-ID: To implement the package/class clash check as per JLS 7.1, javac creates "phantom" packages with the same names as the classes and checks if these packages exist (implemented as a check if it has seen a source or class file in the corresponding directory). Every package created (phantom or not) gets registered to its enclosing `ModuleSymbol`, and when `ModuleSymbol.getEnclosedElements()` is called, the package is completed (i.e. its directory is listed). This can cause an invalid package/class clash error to be reported in specific cases if there is a package and a class with names differing only in letter cases (like `org.jruby.runtime.callsite` and `org.jruby.runtime.CallSite`). What happens here is: the phantom package for the `org.jruby.runtime.CallSite` package is created, the package/class clash check is performed and passes (no errors). Then annotation processing calls `ModuleSymbol.getEnclosedElements()`, the phantom package's directory (`org/jruby/runtime/CallSite`) is listed from the filesystem, and contains some source files, so appears non-empty/existing (due to the case insensitive filesystem, the content of `org/jruby/runtime/callsite` directory is listed in fact). Then another round of annotation processing happens, and the package/class clash check is performed again. This time, the package appears to exist, and hence the check fails. The proposal here is to avoid creating of the phantom packages (and hence registering them into `ModuleSymbol`) for the package/class clash check. That should prevent listing the package with the wrong name unnecessarily/unintentionally. ------------- Commit messages: - 8263432: javac may report an invalid package/class clash on case insensitive filesystems Changes: https://git.openjdk.java.net/jdk/pull/3069/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3069&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263432 Stats: 108 lines in 2 files changed: 103 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/3069.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3069/head:pull/3069 PR: https://git.openjdk.java.net/jdk/pull/3069 From jlahoda at openjdk.java.net Thu Mar 18 12:40:41 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Thu, 18 Mar 2021 12:40:41 GMT Subject: Integrated: 8263590: Rawtypes warnings should be produced for pattern matching in instanceof In-Reply-To: References: Message-ID: On Mon, 15 Mar 2021 17:59:33 GMT, Jan Lahoda wrote: > For code like: > Object o = null; > boolean b = o instanceof List l; > > There should be a raw-type warning for `List`, as we are effectively declaring a variable with a raw type. > > Code like: > Object o = null; > boolean b = o instanceof List; > > Will not produce a warning (as it doesn't so far), as the (raw) type is not used in a problematic context. This pull request has now been integrated. Changeset: 9cd21b68 Author: Jan Lahoda URL: https://git.openjdk.java.net/jdk/commit/9cd21b68 Stats: 17 lines in 3 files changed: 16 ins; 0 del; 1 mod 8263590: Rawtypes warnings should be produced for pattern matching in instanceof Reviewed-by: mcimadamore ------------- PR: https://git.openjdk.java.net/jdk/pull/3016 From shade at openjdk.java.net Mon Mar 22 18:26:47 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 22 Mar 2021 18:26:47 GMT Subject: RFR: 8263995: Incorrect double-checked locking in Types.arraySuperType() Message-ID: In Types.arraySuperType(), SonarCloud reports: Remove this dangerous instance of double-checked locking. Indeed, the `arraySuperType` is not `volatile`, while `IntersectionClassType` has non-`final` fields (both in itself and in superclasses). This is an incorrect DCL. ------------- Commit messages: - 8263995: Incorrect double-checked locking in Types.arraySuperType() Changes: https://git.openjdk.java.net/jdk/pull/3129/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3129&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263995 Stats: 8 lines in 1 file changed: 3 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/3129.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3129/head:pull/3129 PR: https://git.openjdk.java.net/jdk/pull/3129 From mcimadamore at openjdk.java.net Mon Mar 22 18:33:38 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Mon, 22 Mar 2021 18:33:38 GMT Subject: RFR: 8263995: Incorrect double-checked locking in Types.arraySuperType() In-Reply-To: References: Message-ID: On Mon, 22 Mar 2021 18:19:39 GMT, Aleksey Shipilev wrote: > In Types.arraySuperType(), SonarCloud reports: > Remove this dangerous instance of double-checked locking. > > Indeed, the `arraySuperType` is not `volatile`, while `IntersectionClassType` has non-`final` fields (both in itself and in superclasses). This is an incorrect DCL. I'm a bit surprised to see use of volatile/synchronized here as I'm pretty sure that javac is *not* thread safe. It seems like the synchronized block has been there from a long time (e.g. it was there since the dawn of OpenJDK :-)). I wonder if a better fix would be simply to drop synchronization and volatileness. ------------- PR: https://git.openjdk.java.net/jdk/pull/3129 From shade at openjdk.java.net Mon Mar 22 19:06:00 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 22 Mar 2021 19:06:00 GMT Subject: RFR: 8263995: Incorrect double-checked locking in Types.arraySuperType() [v2] In-Reply-To: References: Message-ID: > In Types.arraySuperType(), SonarCloud reports: > Remove this dangerous instance of double-checked locking. > > Indeed, the `arraySuperType` is not `volatile`, while `IntersectionClassType` has non-`final` fields (both in itself and in superclasses). This is an incorrect DCL. Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: Drop synchronization and volatileness ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3129/files - new: https://git.openjdk.java.net/jdk/pull/3129/files/e8092ca6..aeee7536 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3129&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3129&range=00-01 Stats: 13 lines in 1 file changed: 0 ins; 7 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/3129.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3129/head:pull/3129 PR: https://git.openjdk.java.net/jdk/pull/3129 From shade at openjdk.java.net Mon Mar 22 19:06:00 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 22 Mar 2021 19:06:00 GMT Subject: RFR: 8263995: Incorrect double-checked locking in Types.arraySuperType() [v2] In-Reply-To: References: Message-ID: On Mon, 22 Mar 2021 18:31:01 GMT, Maurizio Cimadamore wrote: >> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: >> >> Drop synchronization and volatileness > > I'm a bit surprised to see use of volatile/synchronized here as I'm pretty sure that javac is *not* thread safe. > It seems like the synchronized block has been there from a long time (e.g. it was there since the dawn of OpenJDK :-)). I wonder if a better fix would be simply to drop synchronization and volatileness. > I'm a bit surprised to see use of volatile/synchronized here as I'm pretty sure that javac is _not_ thread safe. > It seems like the synchronized block has been there from a long time (e.g. it was there since the dawn of OpenJDK :-)). I wonder if a better fix would be simply to drop synchronization and volatileness. Yeah, I just did the most obvious semantics-preserving thing in this first patch. See new commit that drops `synchronized` instead as to not confuse both humans and tools about this. Still passes `langtools:tier1`. ------------- PR: https://git.openjdk.java.net/jdk/pull/3129 From jlahoda at openjdk.java.net Mon Mar 22 20:19:41 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Mon, 22 Mar 2021 20:19:41 GMT Subject: RFR: 8263995: Incorrect double-checked locking in Types.arraySuperType() [v2] In-Reply-To: References: Message-ID: <81T9SO6edqkmA5vDJPJWupRzHTU5g0eNlRAbebyGENo=.b17fc75b-8d08-4d0e-a106-77ec3cb95afc@github.com> On Mon, 22 Mar 2021 19:06:00 GMT, Aleksey Shipilev wrote: >> In Types.arraySuperType(), SonarCloud reports: >> Remove this dangerous instance of double-checked locking. >> >> Indeed, the `arraySuperType` is not `volatile`, while `IntersectionClassType` has non-`final` fields (both in itself and in superclasses). This is an incorrect DCL. > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Drop synchronization and volatileness Looks good to me! ------------- Marked as reviewed by jlahoda (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3129 From mcimadamore at openjdk.java.net Mon Mar 22 21:00:47 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Mon, 22 Mar 2021 21:00:47 GMT Subject: RFR: 8263995: Incorrect double-checked locking in Types.arraySuperType() [v2] In-Reply-To: References: Message-ID: <9CxHNdzqaGrf-9eCLrCWuZviT46oNl0E1aLFmPwoRUg=.90bd8475-01d7-4ad9-b150-38ab2f449039@github.com> On Mon, 22 Mar 2021 19:06:00 GMT, Aleksey Shipilev wrote: >> In Types.arraySuperType(), SonarCloud reports: >> Remove this dangerous instance of double-checked locking. >> >> Indeed, the `arraySuperType` is not `volatile`, while `IntersectionClassType` has non-`final` fields (both in itself and in superclasses). This is an incorrect DCL. > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Drop synchronization and volatileness Looks good ------------- Marked as reviewed by mcimadamore (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3129 From shade at openjdk.java.net Tue Mar 23 17:51:39 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 23 Mar 2021 17:51:39 GMT Subject: Integrated: 8263995: Incorrect double-checked locking in Types.arraySuperType() In-Reply-To: References: Message-ID: On Mon, 22 Mar 2021 18:19:39 GMT, Aleksey Shipilev wrote: > In Types.arraySuperType(), SonarCloud reports: > Remove this dangerous instance of double-checked locking. > > Indeed, the `arraySuperType` is not `volatile`, while `IntersectionClassType` has non-`final` fields (both in itself and in superclasses). This is an incorrect DCL. This pull request has now been integrated. Changeset: c087f3ed Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/c087f3ed Stats: 8 lines in 1 file changed: 0 ins; 4 del; 4 mod 8263995: Incorrect double-checked locking in Types.arraySuperType() Reviewed-by: mcimadamore, jlahoda ------------- PR: https://git.openjdk.java.net/jdk/pull/3129 From jpai at openjdk.java.net Wed Mar 24 10:45:09 2021 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Wed, 24 Mar 2021 10:45:09 GMT Subject: RFR: 8173970: jar tool should have a way to extract to a directory [v2] In-Reply-To: References: Message-ID: > Can I please get a review for this patch which proposes to implement the enhancement request noted in https://bugs.openjdk.java.net/browse/JDK-8173970? > > The commit in this PR introduces the `-o` and `--output-dir` option to the `jar` command. The option takes a path to a destination directory as a value and extracts the contents of the jar into that directory. This is an optional option and the changes in the commit continue to maintain backward compatibility where the jar is extracted into current directory, if no `-o` or `--output-dir` option has been specified. > > As far as I know, there hasn't been any discussion on what the name of this new option should be. I was initially thinking of using `-d` but that is currently used by the `jar` command for a different purpose. So I decided to use `-o` and `--output-dir`. This is of course open for change depending on any suggestions in this PR. > > The commit in this PR also updates the `jar.properties` file which contains the English version of the jar command's `--help` output. However, no changes have been done to the internationalization files corresponding to this one (for example: `jar_de.properties`), because I don't know what process needs to be followed to have those files updated (if at all they need to be updated). > > The commit also includes a jtreg testcase which verifies the usage of this new option. Jaikiran Pai 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 one additional commit since the last revision: 8173970: jar tool should have a way to extract to a directory ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2752/files - new: https://git.openjdk.java.net/jdk/pull/2752/files/3a8e329d..a9954240 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2752&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2752&range=00-01 Stats: 62407 lines in 2851 files changed: 39040 ins; 14156 del; 9211 mod Patch: https://git.openjdk.java.net/jdk/pull/2752.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2752/head:pull/2752 PR: https://git.openjdk.java.net/jdk/pull/2752 From jjg at openjdk.java.net Thu Mar 25 00:02:18 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Thu, 25 Mar 2021 00:02:18 GMT Subject: Integrated: JDK-8258957: DocLint: check for HTML start element at end of body In-Reply-To: References: Message-ID: On Fri, 5 Mar 2021 21:44:20 GMT, Jonathan Gibbons wrote: > Please review a moderately simple fix to improve DocLint's checking for empty tags, and in particular, bad use of `

` as a paragraph terminator. This will help detect this bad usage at doclint-time, instead of later, with doccheck. > > There was already code to check if tags were empty. (`warnIfEmpty`), and code to check for open tags at the end of the comment. The change is primarily to invoke the "check for open tags" at the end of main body of a comment and at the end of each block tag (i.e including all that allow HTML content in the body of the block tag.) > > There is a secondary minor edit to check if a tag was empty when auto-closing it. > > The changes discovered 5 instances of bad use of `

` in the JDK docs. These are being fixed separately in https://bugs.openjdk.java.net/browse/JDK-8263104 This pull request has now been integrated. Changeset: 0ff81682 Author: Jonathan Gibbons URL: https://git.openjdk.java.net/jdk/commit/0ff81682 Stats: 85 lines in 5 files changed: 82 ins; 1 del; 2 mod 8258957: DocLint: check for HTML start element at end of body Reviewed-by: vromero ------------- PR: https://git.openjdk.java.net/jdk/pull/2853 From jjg at openjdk.java.net Thu Mar 25 00:02:17 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Thu, 25 Mar 2021 00:02:17 GMT Subject: RFR: JDK-8258957: DocLint: check for HTML start element at end of body [v2] In-Reply-To: References: Message-ID: > Please review a moderately simple fix to improve DocLint's checking for empty tags, and in particular, bad use of `

` as a paragraph terminator. This will help detect this bad usage at doclint-time, instead of later, with doccheck. > > There was already code to check if tags were empty. (`warnIfEmpty`), and code to check for open tags at the end of the comment. The change is primarily to invoke the "check for open tags" at the end of main body of a comment and at the end of each block tag (i.e including all that allow HTML content in the body of the block tag.) > > There is a secondary minor edit to check if a tag was empty when auto-closing it. > > The changes discovered 5 instances of bad use of `

` in the JDK docs. These are being fixed separately in https://bugs.openjdk.java.net/browse/JDK-8263104 Jonathan Gibbons 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 two additional commits since the last revision: - Merge remote-tracking branch 'upstream/master' into trailing-p - JDK-8258957: DocLint: check for HTML start element at end of body ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2853/files - new: https://git.openjdk.java.net/jdk/pull/2853/files/46cc37a6..4003b531 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2853&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2853&range=00-01 Stats: 57590 lines in 2835 files changed: 35107 ins; 12845 del; 9638 mod Patch: https://git.openjdk.java.net/jdk/pull/2853.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2853/head:pull/2853 PR: https://git.openjdk.java.net/jdk/pull/2853 From alanb at openjdk.java.net Sat Mar 27 16:05:26 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Sat, 27 Mar 2021 16:05:26 GMT Subject: RFR: 8173970: jar tool should have a way to extract to a directory In-Reply-To: References: Message-ID: On Fri, 26 Feb 2021 17:03:11 GMT, Jaikiran Pai wrote: > Can I please get a review for this patch which proposes to implement the enhancement request noted in https://bugs.openjdk.java.net/browse/JDK-8173970? > > The commit in this PR introduces the `-o` and `--output-dir` option to the `jar` command. The option takes a path to a destination directory as a value and extracts the contents of the jar into that directory. This is an optional option and the changes in the commit continue to maintain backward compatibility where the jar is extracted into current directory, if no `-o` or `--output-dir` option has been specified. > > As far as I know, there hasn't been any discussion on what the name of this new option should be. I was initially thinking of using `-d` but that is currently used by the `jar` command for a different purpose. So I decided to use `-o` and `--output-dir`. This is of course open for change depending on any suggestions in this PR. > > The commit in this PR also updates the `jar.properties` file which contains the English version of the jar command's `--help` output. However, no changes have been done to the internationalization files corresponding to this one (for example: `jar_de.properties`), because I don't know what process needs to be followed to have those files updated (if at all they need to be updated). > > The commit also includes a jtreg testcase which verifies the usage of this new option. I think the summary is that we've converged on -C/--dir. We might have to tweak the usage message for -C so that it starts with the existing "Change to the specified directory ..." rather than changing it to start with the extract case. Are you, or Lance, going to create the CSR for this? ------------- PR: https://git.openjdk.java.net/jdk/pull/2752 From lance.andersen at oracle.com Sat Mar 27 17:19:17 2021 From: lance.andersen at oracle.com (Lance Andersen) Date: Sat, 27 Mar 2021 17:19:17 +0000 Subject: RFR: 8173970: jar tool should have a way to extract to a directory In-Reply-To: References: Message-ID: <1C26247B-1293-424F-AED8-4EDB4B957349@oracle.com> On Mar 27, 2021, at 12:05 PM, Alan Bateman > wrote: On Fri, 26 Feb 2021 17:03:11 GMT, Jaikiran Pai > wrote: Can I please get a review for this patch which proposes to implement the enhancement request noted in https://bugs.openjdk.java.net/browse/JDK-8173970? The commit in this PR introduces the `-o` and `--output-dir` option to the `jar` command. The option takes a path to a destination directory as a value and extracts the contents of the jar into that directory. This is an optional option and the changes in the commit continue to maintain backward compatibility where the jar is extracted into current directory, if no `-o` or `--output-dir` option has been specified. As far as I know, there hasn't been any discussion on what the name of this new option should be. I was initially thinking of using `-d` but that is currently used by the `jar` command for a different purpose. So I decided to use `-o` and `--output-dir`. This is of course open for change depending on any suggestions in this PR. The commit in this PR also updates the `jar.properties` file which contains the English version of the jar command's `--help` output. However, no changes have been done to the internationalization files corresponding to this one (for example: `jar_de.properties`), because I don't know what process needs to be followed to have those files updated (if at all they need to be updated). The commit also includes a jtreg testcase which verifies the usage of this new option. I think the summary is that we've converged on -C/--dir. We might have to tweak the usage message for -C so that it starts with the existing "Change to the specified directory ..." rather than changing it to start with the extract case. Are you, or Lance, going to create the CSR for this? I have not had a chance to go through the latest update from Jaikiran or his revised PR yet. Yes, once we flush everything out, I will work with Jaikiran on the CSR and determine which of us will create the CSR. On the todo list for next week. Best Lance ------------- PR: https://git.openjdk.java.net/jdk/pull/2752 [cid:E1C4E2F0-ECD0-4C9D-ADB4-B16CA7BCB7FC at home] Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: oracle_sig_logo.gif Type: image/gif Size: 658 bytes Desc: oracle_sig_logo.gif URL: From jai.forums2013 at gmail.com Sun Mar 28 13:24:48 2021 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Sun, 28 Mar 2021 18:54:48 +0530 Subject: RFR: 8173970: jar tool should have a way to extract to a directory In-Reply-To: References: <1BB8805F-174A-4EB9-B26A-060B2251A40C@oracle.com> <6242cfe8-cef7-0603-33fc-b3428209a1ac@gmail.com> <1e14f8e1-c4d2-1e11-df88-8af083bac8f9@gmail.com> <9B159F65-A7CC-4FEA-BAB8-77D66D7AD5AB@oracle.com> <73dcce4d-0b53-23bd-b706-bf4fdbcbe256@oracle.com> <9030C4FE-9D94-496B-9E06-C8B9B7664651@oracle.com> <2a54cca7-1132-37e6-d8cc-9f9db7b3f6b5@oracle.com> <69369159-FB85-4812-976B-53019FCD5FC6@oracle.com> <237e6c14-8593-69df-5866-4a238e020fce@oracle.com> Message-ID: Lance ran some tests against the proposed patch and that has exposed an area which we haven't yet taken into account for this feature. The jar tool has a (hidden) option "-P" which can be used with the "c" (create), "u" (update) and "x" (extract) main operations. When this -P option is used, the jar tool will preserve/won't strip leading slash and ".." component from file name. So imagine a jar created with the -P option as follows: jar -cfP foo.jar /tmp/blah.txt This will add /tmp/blah.txt with the the leading / preserved, so the contents of the jar will be: jar -tf foo.jar META-INF/ META-INF/MANIFEST.MF /tmp/blah.txt Consider being in /home/me/ directory and running the jar -xfP command against this jar. When you do that, the /tmp/blah.txt will get extracted to the /tmp/blah.txt absolute path and the META-INF and the other entries get extracted inside the /home/me/ directory. This is how the jar tool currently behaves when the leading slashes (and ..) are involved with the -P option. Now coming to this new feature we are talking about, IMO, we cannot break this existing behaviour. So when the user continues to use: jar -xfP foo.jar without any explicit -C or --dir option, then IMO, the extract should continue to work just like it does now and continue to extract the /tmp/blah.txt to that absolute location. Now when the user explicitly specifies the new -C or --dir option with the -P option for extract, something like: jar -xfP foo.jar -C /tmp/hello/ I think we should continue to extract the /tmp/blah.txt to that absolute location instead of making it relative to the /tmp/hello/ directory. Given that -P is a hidden option, I am not sure if this should be documented in some manner (other than maybe code comments), but I wanted to bring this up so that we can come to a decision and have the proposed implementation work in that manner. -Jaikiran On 24/03/21 4:10 pm, Jaikiran Pai wrote: > Based on the inputs so far, I've updated the PR to include the > provided feedback. Since the PR code review hadn't yet started, I > decided to do a force push to the PR so that we can start it afresh. > > Command option: > > In this current discussion, we seem to have an agreement for using -C > and --dir as the short and long options for this feature. The > implementation in this PR now uses these options. There was also a > suggestion to additionally allow --directory as an option too. I > haven't added that yet, since I wasn't sure if we really want that. It > was suggested that if we do use --directory, we should "hide" --dir. > If we do need the --directory option, I can add that in, in subsequent > updates to this PR. > > > Directories creation: > > There was an agreement in our discussion that if the destination > directory hierarchy isn't present, then we should create that whole > hierarchy and extract the jar into it. The implementation in this PR > matches this decision. > > > Verbose logging: > > During the discussion, there was a question whether this feature > should introduce any new verbose logs during extraction. IMO, it's a > good idea to log the target directory to which the jar is being > extracted. So, in the implementation, I have introduced a new > (resource bundle backed) verbose log message which prints the absolute > path to which the jar will be extracted. Do note that this verbose log > message will be printed even if you don't explicitly specify any > target directory. i.e. even when the default current directory is > used, this verbose log message will be printed if the "-v" option is > used. > > Repeatability of the newly introduce options: > > Unlike in the other main operations of the jar command, the -C option > that we use during the extract main operation, IMO, shouldn't be > allowed to be used more than once. More specifically the destination > directory to which the jar needs to be extracted must only be > specified once, irrespective of whether it's through the use of -C or > --dir. The code in the PR, explicitly throws an error when such > repeatition is encountered. > > An alternate approach would have been to allow the -C and/or --dir > option to be repeated, but use the last specified value of these > options. However, I decided not to pursue that approach, to keep it > simple as well as to avoid any confusion on the command usage. > > > Overwriting of contents in existing target directory: > > No specific change has been done when it comes to dealing with the > extraction logic itself. Specifically, when the explicitly specified > or the default current directory already has directories/files that > belong to the jar being extracted, those files/dirs will continue to > be overwritten. > > Compatibility mode: > > The code in this PR also supports the compatibility mode for this > option. Specifically, a command like: > > jar -xvf somejar.jar -C /tmp/foo/ > > will work fine and the jar will be extracted into /tmp/foo directory. > > > Message/error internationalization: > > I have only updated the jar.properties for the English version of the > new output and error messages. I don't know what the process is for > adding this to other languages, if at all that needs to be done in > this PR. > > > jar --help output: > > Currently the jar --help output only talks about creation and updation > of the jar. There's no mention of using the tool for extracting the > jar content: > > "jar creates an archive for classes and resources, and can manipulate or > restore individual classes or resources from an archive." > > It does mention "manipulate" but doesn't specifically say extraction. > The examples in the help command output don't have any examples for > extraction. Should we add an example for extracting the jar file, in > this help output? > > > Testing: > > A new jtreg test has been introduced which tests various aspects of > this feature. It runs most of those tests against both absolute and > relative paths. > > A couple of tests in the new introduced test case, check for the > output/error messages. The jar tool uses resource bundles to print out > these messages. I need input on whether I should enforce a specific > locale to run these tests so that I can compare the error/output > messages for expected strings? See testExtractFailWithMultipleDir() or > testHelpOutput() for what I mean. > > > Man page: > > This one I need input on. I have tried to see how these man pages are > generated and from what I can understand it looks like these man pages > are autogenerated during the build process using pandoc. Is that > right? The hints that I see in the Docs.gmk seems to suggest that > there are some markdown source files from which these man pages get > generated. However, I can't seem to locate any such markdown files for > this or other tools, from which the man pages get generated. Any help > on how I should go about editing/updating the man page for the jar tool? > > > Example usage: > > Here are some example usages: > > jar -x -f somejar.jar -C /tmp/foo/bar/ > > This command extracts the somejar.jar file to the /tmp/foo/bar/ > directory, creating it if necessary. > > > jar -x -f somejar.jar --dir /tmp/foo/bar/ > > Same as above, except uses the long form --dir option > > > jar -x -f somejar.jar -C /tmp/foo/bar/ f1.txt d1/f2.txt > > Assuming somejar.jar contains "f1.txt" (at root), "d1/f2.txt" and > other files, then the above command extracts only "f1.txt" and > "d1/f2.txt" into the /tmp/foo/bar/ directory. > > > -Jaikiran > > On 14/03/21 6:21 pm, Alan Bateman wrote: >> On 12/03/2021 12:18, Lance Andersen wrote: >>> >>> : >>> >>> I don?t have a strong preference but lean slightly towards >>> ?-directory? as it is more descriptive, similar to the other >>> GNU-style commands jar currently supports . ?Tar supports ??cd?, >>> ??directory? in addition to ?-C? which is why I suggested supporting >>> ?both GNU-style long options. >>> >>> Perhaps jpackage should also support ?dir/directory in addition to >>> ??dest' if we are looking at consistency between java tools. >>> >>> I do agree that it would be nice to be consistent across the java >>> tools for options so if we go the ?-directory?, we should follow >>> your suggestion and make it the primary and remove ??dir? from the >>> usage output. >> My comment on consistency was limited to the long option to specify >> the directory when extracting, didn't mean to suggest doing anything >> with the other tools that specify an output/destination directory. In >> any case, I think we have enough to make progress on this issue now. >> >> -Alan >> From github.com+76791+alblue at openjdk.java.net Sun Mar 28 14:00:50 2021 From: github.com+76791+alblue at openjdk.java.net (Alex Blewitt) Date: Sun, 28 Mar 2021 14:00:50 GMT Subject: RFR: 8264331: Use the blessed modifier order in jdk.compiler Message-ID: 8264331: Use the blessed modifier order in jdk.compiler ------------- Commit messages: - 8264331: Use the blessed modifier order in jdk.compiler Changes: https://git.openjdk.java.net/jdk/pull/3235/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3235&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264331 Stats: 108 lines in 34 files changed: 0 ins; 0 del; 108 mod Patch: https://git.openjdk.java.net/jdk/pull/3235.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3235/head:pull/3235 PR: https://git.openjdk.java.net/jdk/pull/3235 From lance.andersen at oracle.com Sun Mar 28 16:22:03 2021 From: lance.andersen at oracle.com (Lance Andersen) Date: Sun, 28 Mar 2021 16:22:03 +0000 Subject: RFR: 8173970: jar tool should have a way to extract to a directory In-Reply-To: References: <1BB8805F-174A-4EB9-B26A-060B2251A40C@oracle.com> <6242cfe8-cef7-0603-33fc-b3428209a1ac@gmail.com> <1e14f8e1-c4d2-1e11-df88-8af083bac8f9@gmail.com> <9B159F65-A7CC-4FEA-BAB8-77D66D7AD5AB@oracle.com> <73dcce4d-0b53-23bd-b706-bf4fdbcbe256@oracle.com> <9030C4FE-9D94-496B-9E06-C8B9B7664651@oracle.com> <2a54cca7-1132-37e6-d8cc-9f9db7b3f6b5@oracle.com> <69369159-FB85-4812-976B-53019FCD5FC6@oracle.com> <237e6c14-8593-69df-5866-4a238e020fce@oracle.com> Message-ID: On Mar 28, 2021, at 9:24 AM, Jaikiran Pai > wrote: Lance ran some tests against the proposed patch and that has exposed an area which we haven't yet taken into account for this feature. The jar tool has a (hidden) option "-P" which can be used with the "c" (create), "u" (update) and "x" (extract) main operations. When this -P option is used, the jar tool will preserve/won't strip leading slash and ".." component from file name. So imagine a jar created with the -P option as follows: jar -cfP foo.jar /tmp/blah.txt This will add /tmp/blah.txt with the the leading / preserved, so the contents of the jar will be: jar -tf foo.jar META-INF/ META-INF/MANIFEST.MF /tmp/blah.txt Consider being in /home/me/ directory and running the jar -xfP command against this jar. When you do that, the /tmp/blah.txt will get extracted to the /tmp/blah.txt absolute path and the META-INF and the other entries get extracted inside the /home/me/ directory. This is how the jar tool currently behaves when the leading slashes (and ..) are involved with the -P option. Now coming to this new feature we are talking about, IMO, we cannot break this existing behaviour. So when the user continues to use: jar -xfP foo.jar without any explicit -C or --dir option, then IMO, the extract should continue to work just like it does now and continue to extract the /tmp/blah.txt to that absolute location. Agree Now when the user explicitly specifies the new -C or --dir option with the -P option for extract, something like: jar -xfP foo.jar -C /tmp/hello/ Given the support of -C/-dir is new and -P is there for backwards compatibility then I see the choices are: * Issue an error when -P and -C/-dir are specified together with -x * Silently ignore the -P option * Ignore -C/-dir and the behavior is if -xfP was specified. I am leaning towards an error given this is a new feature when -P and -C/-dir are specified with -x Best Lance I think we should continue to extract the /tmp/blah.txt to that absolute location instead of making it relative to the /tmp/hello/ directory. Given that -P is a hidden option, I am not sure if this should be documented in some manner (other than maybe code comments), but I wanted to bring this up so that we can come to a decision and have the proposed implementation work in that manner. -Jaikiran On 24/03/21 4:10 pm, Jaikiran Pai wrote: Based on the inputs so far, I've updated the PR to include the provided feedback. Since the PR code review hadn't yet started, I decided to do a force push to the PR so that we can start it afresh. Command option: In this current discussion, we seem to have an agreement for using -C and --dir as the short and long options for this feature. The implementation in this PR now uses these options. There was also a suggestion to additionally allow --directory as an option too. I haven't added that yet, since I wasn't sure if we really want that. It was suggested that if we do use --directory, we should "hide" --dir. If we do need the --directory option, I can add that in, in subsequent updates to this PR. Directories creation: There was an agreement in our discussion that if the destination directory hierarchy isn't present, then we should create that whole hierarchy and extract the jar into it. The implementation in this PR matches this decision. Verbose logging: During the discussion, there was a question whether this feature should introduce any new verbose logs during extraction. IMO, it's a good idea to log the target directory to which the jar is being extracted. So, in the implementation, I have introduced a new (resource bundle backed) verbose log message which prints the absolute path to which the jar will be extracted. Do note that this verbose log message will be printed even if you don't explicitly specify any target directory. i.e. even when the default current directory is used, this verbose log message will be printed if the "-v" option is used. Repeatability of the newly introduce options: Unlike in the other main operations of the jar command, the -C option that we use during the extract main operation, IMO, shouldn't be allowed to be used more than once. More specifically the destination directory to which the jar needs to be extracted must only be specified once, irrespective of whether it's through the use of -C or --dir. The code in the PR, explicitly throws an error when such repeatition is encountered. An alternate approach would have been to allow the -C and/or --dir option to be repeated, but use the last specified value of these options. However, I decided not to pursue that approach, to keep it simple as well as to avoid any confusion on the command usage. Overwriting of contents in existing target directory: No specific change has been done when it comes to dealing with the extraction logic itself. Specifically, when the explicitly specified or the default current directory already has directories/files that belong to the jar being extracted, those files/dirs will continue to be overwritten. Compatibility mode: The code in this PR also supports the compatibility mode for this option. Specifically, a command like: jar -xvf somejar.jar -C /tmp/foo/ will work fine and the jar will be extracted into /tmp/foo directory. Message/error internationalization: I have only updated the jar.properties for the English version of the new output and error messages. I don't know what the process is for adding this to other languages, if at all that needs to be done in this PR. jar --help output: Currently the jar --help output only talks about creation and updation of the jar. There's no mention of using the tool for extracting the jar content: "jar creates an archive for classes and resources, and can manipulate or restore individual classes or resources from an archive." It does mention "manipulate" but doesn't specifically say extraction. The examples in the help command output don't have any examples for extraction. Should we add an example for extracting the jar file, in this help output? Testing: A new jtreg test has been introduced which tests various aspects of this feature. It runs most of those tests against both absolute and relative paths. A couple of tests in the new introduced test case, check for the output/error messages. The jar tool uses resource bundles to print out these messages. I need input on whether I should enforce a specific locale to run these tests so that I can compare the error/output messages for expected strings? See testExtractFailWithMultipleDir() or testHelpOutput() for what I mean. Man page: This one I need input on. I have tried to see how these man pages are generated and from what I can understand it looks like these man pages are autogenerated during the build process using pandoc. Is that right? The hints that I see in the Docs.gmk seems to suggest that there are some markdown source files from which these man pages get generated. However, I can't seem to locate any such markdown files for this or other tools, from which the man pages get generated. Any help on how I should go about editing/updating the man page for the jar tool? Example usage: Here are some example usages: jar -x -f somejar.jar -C /tmp/foo/bar/ This command extracts the somejar.jar file to the /tmp/foo/bar/ directory, creating it if necessary. jar -x -f somejar.jar --dir /tmp/foo/bar/ Same as above, except uses the long form --dir option jar -x -f somejar.jar -C /tmp/foo/bar/ f1.txt d1/f2.txt Assuming somejar.jar contains "f1.txt" (at root), "d1/f2.txt" and other files, then the above command extracts only "f1.txt" and "d1/f2.txt" into the /tmp/foo/bar/ directory. -Jaikiran On 14/03/21 6:21 pm, Alan Bateman wrote: On 12/03/2021 12:18, Lance Andersen wrote: : I don?t have a strong preference but lean slightly towards ?-directory? as it is more descriptive, similar to the other GNU-style commands jar currently supports . Tar supports ??cd?, ??directory? in addition to ?-C? which is why I suggested supporting both GNU-style long options. Perhaps jpackage should also support ?dir/directory in addition to ??dest' if we are looking at consistency between java tools. I do agree that it would be nice to be consistent across the java tools for options so if we go the ?-directory?, we should follow your suggestion and make it the primary and remove ??dir? from the usage output. My comment on consistency was limited to the long option to specify the directory when extracting, didn't mean to suggest doing anything with the other tools that specify an output/destination directory. In any case, I think we have enough to make progress on this issue now. -Alan [cid:E1C4E2F0-ECD0-4C9D-ADB4-B16CA7BCB7FC at home] Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: oracle_sig_logo.gif Type: image/gif Size: 658 bytes Desc: oracle_sig_logo.gif URL: From jai.forums2013 at gmail.com Mon Mar 29 10:46:37 2021 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Mon, 29 Mar 2021 16:16:37 +0530 Subject: RFR: 8173970: jar tool should have a way to extract to a directory In-Reply-To: References: <1BB8805F-174A-4EB9-B26A-060B2251A40C@oracle.com> <6242cfe8-cef7-0603-33fc-b3428209a1ac@gmail.com> <1e14f8e1-c4d2-1e11-df88-8af083bac8f9@gmail.com> <9B159F65-A7CC-4FEA-BAB8-77D66D7AD5AB@oracle.com> <73dcce4d-0b53-23bd-b706-bf4fdbcbe256@oracle.com> <9030C4FE-9D94-496B-9E06-C8B9B7664651@oracle.com> <2a54cca7-1132-37e6-d8cc-9f9db7b3f6b5@oracle.com> <69369159-FB85-4812-976B-53019FCD5FC6@oracle.com> <237e6c14-8593-69df-5866-4a238e020fce@oracle.com> Message-ID: <495db34e-48a8-489d-8a86-36ba74870d60@gmail.com> On 28/03/21 9:52 pm, Lance Andersen wrote: > > >> On Mar 28, 2021, at 9:24 AM, Jaikiran Pai > > wrote: >> >> >> Now when the user explicitly specifies the new -C or --dir option >> with the -P option for extract, something like: >> >> jar -xfP foo.jar -C /tmp/hello/ > > Given the support of -C/-dir is new and -P is there for backwards > compatibility then I see the choices are: > > * Issue an error when -P and -C/-dir are specified together with -x > * Silently ignore the -P option > * Ignore -C/-dir and the behavior is if -xfP was specified. > > > I am leaning towards an error given this is a new feature when -P and > -C/-dir are specified with -x That sounds reasonable to me. I'll update the PR accordingly to take this into account. -Jaikiran -------------- next part -------------- An HTML attachment was scrubbed... URL: From jpai at openjdk.java.net Mon Mar 29 14:04:10 2021 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Mon, 29 Mar 2021 14:04:10 GMT Subject: RFR: 8173970: jar tool should have a way to extract to a directory [v3] In-Reply-To: References: Message-ID: > Can I please get a review for this patch which proposes to implement the enhancement request noted in https://bugs.openjdk.java.net/browse/JDK-8173970? > > The commit in this PR introduces the `-o` and `--output-dir` option to the `jar` command. The option takes a path to a destination directory as a value and extracts the contents of the jar into that directory. This is an optional option and the changes in the commit continue to maintain backward compatibility where the jar is extracted into current directory, if no `-o` or `--output-dir` option has been specified. > > As far as I know, there hasn't been any discussion on what the name of this new option should be. I was initially thinking of using `-d` but that is currently used by the `jar` command for a different purpose. So I decided to use `-o` and `--output-dir`. This is of course open for change depending on any suggestions in this PR. > > The commit in this PR also updates the `jar.properties` file which contains the English version of the jar command's `--help` output. However, no changes have been done to the internationalization files corresponding to this one (for example: `jar_de.properties`), because I don't know what process needs to be followed to have those files updated (if at all they need to be updated). > > The commit also includes a jtreg testcase which verifies the usage of this new option. Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision: - Alan's review feedback for -C help text - Keep -xfP backward compatible but don't allow -C/--dir with -xfP ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2752/files - new: https://git.openjdk.java.net/jdk/pull/2752/files/a9954240..3df602d2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2752&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2752&range=01-02 Stats: 88 lines in 3 files changed: 78 ins; 3 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/2752.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2752/head:pull/2752 PR: https://git.openjdk.java.net/jdk/pull/2752 From darcy at openjdk.java.net Mon Mar 29 21:21:02 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Mon, 29 Mar 2021 21:21:02 GMT Subject: RFR: 8264148: Update spec for exceptions retrofitted for exception chaining Message-ID: 8264148: Update spec for exceptions retrofitted for exception chaining ------------- Commit messages: - Respond to review feedback. - Respond to review feedback. - Merge branch 'master' into 8264148 - Merge branch 'master' into 8264148 - 8264148: Update spec for exceptions retrofitted for exception chaining Changes: https://git.openjdk.java.net/jdk/pull/3182/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3182&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264148 Stats: 84 lines in 22 files changed: 8 ins; 44 del; 32 mod Patch: https://git.openjdk.java.net/jdk/pull/3182.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3182/head:pull/3182 PR: https://git.openjdk.java.net/jdk/pull/3182 From smarks at openjdk.java.net Mon Mar 29 21:21:02 2021 From: smarks at openjdk.java.net (Stuart Marks) Date: Mon, 29 Mar 2021 21:21:02 GMT Subject: RFR: 8264148: Update spec for exceptions retrofitted for exception chaining In-Reply-To: References: Message-ID: <6OMPZyYBcENA0hYJp2fEMiwyhvAIT7cXwPoMVQ0TIUc=.65348cfa-1afe-4a3d-8d18-002f2be28d7d@github.com> On Wed, 24 Mar 2021 23:17:46 GMT, Joe Darcy wrote: > 8264148: Update spec for exceptions retrofitted for exception chaining The removal of the obsolescent "As of release 1.4, this exception has been retrofitted..." is good. Changing the calls from the other exception-getting methods to `getCause()` is also good. I'm less sure of the utility of deprecating these older methods. The deprecation will issue warning messages; is there any benefit to the calling code to migrating from the older methods to `getCause()`? If they're exactly equivalent, then I think the benefits are small, compared to the cost of dealing with warnings. Thus for most of these cases I think that not deprecating the older methods is reasonable, and perhaps the explanation should be converted to an `@apiNote`. (The considerations for the JDK itself are different, though, which is why I support changing the call sites.) One special case is the **public field** in `WriteAbortedException`. This is really bad and something ought to be done about this, including deprecation, and maybe more. This implies that the exception is mutable, right? Hrrmph. Isn't there a general rule that once the cause has been set (either via a constructor or via initCause) the exception is immutable? Maybe the field should be deprecated, and `getCause()` should return the cause from the superclass. That's a behavior change of course, and I don't know how to assess the compatibility impact. But the current situation just seems wrong. ------------- PR: https://git.openjdk.java.net/jdk/pull/3182 From darcy at openjdk.java.net Mon Mar 29 21:21:03 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Mon, 29 Mar 2021 21:21:03 GMT Subject: RFR: 8264148: Update spec for exceptions retrofitted for exception chaining In-Reply-To: <6OMPZyYBcENA0hYJp2fEMiwyhvAIT7cXwPoMVQ0TIUc=.65348cfa-1afe-4a3d-8d18-002f2be28d7d@github.com> References: <6OMPZyYBcENA0hYJp2fEMiwyhvAIT7cXwPoMVQ0TIUc=.65348cfa-1afe-4a3d-8d18-002f2be28d7d@github.com> Message-ID: On Thu, 25 Mar 2021 18:52:54 GMT, Stuart Marks wrote: >> 8264148: Update spec for exceptions retrofitted for exception chaining > > The removal of the obsolescent "As of release 1.4, this exception has been retrofitted..." is good. Changing the calls from the other exception-getting methods to `getCause()` is also good. I'm less sure of the utility of deprecating these older methods. The deprecation will issue warning messages; is there any benefit to the calling code to migrating from the older methods to `getCause()`? If they're exactly equivalent, then I think the benefits are small, compared to the cost of dealing with warnings. Thus for most of these cases I think that not deprecating the older methods is reasonable, and perhaps the explanation should be converted to an `@apiNote`. > > (The considerations for the JDK itself are different, though, which is why I support changing the call sites.) > > One special case is the **public field** in `WriteAbortedException`. This is really bad and something ought to be done about this, including deprecation, and maybe more. This implies that the exception is mutable, right? Hrrmph. Isn't there a general rule that once the cause has been set (either via a constructor or via initCause) the exception is immutable? Maybe the field should be deprecated, and `getCause()` should return the cause from the superclass. That's a behavior change of course, and I don't know how to assess the compatibility impact. But the current situation just seems wrong. Some discussion of the proposed changes here. While the history with respect to the introduction of the chained exception mechanism may have been relevant in times past, those comments have little utility today. Per guidance from Dr. Deprecator, I've removed deprecation of the redundant methods and only kept deprecation of the mutable field in WriteAbortedException. The legacy wrapped exception accessing methods in ClassNotFoundException, ExceptionInInitializerError, and UndeclaredThrowableException are equivalent to getCause. The legacy method in PrivilegedActionException returns the same value, but narrowed to Exception rather than Throwable. Once the rest of the change is agree to, I'll update copyrights and do a CSR for the deprecation and other spec changes. ------------- PR: https://git.openjdk.java.net/jdk/pull/3182 From github.com+28367473+jmehrens at openjdk.java.net Tue Mar 30 04:01:57 2021 From: github.com+28367473+jmehrens at openjdk.java.net (jmehrens) Date: Tue, 30 Mar 2021 04:01:57 GMT Subject: RFR: 8264148: Update spec for exceptions retrofitted for exception chaining In-Reply-To: <6OMPZyYBcENA0hYJp2fEMiwyhvAIT7cXwPoMVQ0TIUc=.65348cfa-1afe-4a3d-8d18-002f2be28d7d@github.com> References: <6OMPZyYBcENA0hYJp2fEMiwyhvAIT7cXwPoMVQ0TIUc=.65348cfa-1afe-4a3d-8d18-002f2be28d7d@github.com> Message-ID: On Thu, 25 Mar 2021 18:52:54 GMT, Stuart Marks wrote: > One special case is the **public field** in `WriteAbortedException`. This is really bad and something ought to be done about this, including deprecation, and maybe more. This implies that the exception is mutable, right? Hrrmph. Isn't there a general rule that once the cause has been set (either via a constructor or via initCause) the exception is immutable? Maybe the field should be deprecated, and `getCause()` should return the cause from the superclass. That's a behavior change of course, and I don't know how to assess the compatibility impact. But the current situation just seems wrong. Agreed. WriteAbortedException should get similar treatment as the others like it: - http://cr.openjdk.java.net/~dmeetry/8009581/webrev.5/ - http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-May/016908.html - http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/017594.html - https://mail.openjdk.java.net/pipermail/core-libs-dev/2018-February/051341.html The only twist is that we would have to keep the public field as deprecated. ------------- PR: https://git.openjdk.java.net/jdk/pull/3182 From jlahoda at openjdk.java.net Tue Mar 30 06:29:03 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Tue, 30 Mar 2021 06:29:03 GMT Subject: RFR: 8264306: Non deterministic generation of java/lang/invoke/MemberName.class Message-ID: When hoisting binding variables to the outer scope, we should use `LinkedHashMap` instead of `HashMap`, so that `javac` produces reproducible classfiles. ------------- Commit messages: - 8264306: Non deterministic generation of java/lang/invoke/MemberName.class Changes: https://git.openjdk.java.net/jdk/pull/3257/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3257&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264306 Stats: 121 lines in 2 files changed: 119 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3257.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3257/head:pull/3257 PR: https://git.openjdk.java.net/jdk/pull/3257 From shade at openjdk.java.net Tue Mar 30 07:28:42 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 30 Mar 2021 07:28:42 GMT Subject: RFR: 8264306: Non deterministic generation of java/lang/invoke/MemberName.class In-Reply-To: References: Message-ID: On Tue, 30 Mar 2021 06:19:22 GMT, Jan Lahoda wrote: > When hoisting binding variables to the outer scope, we should use `LinkedHashMap` instead of `HashMap`, so that `javac` produces reproducible classfiles. This makes sense to me (and it looks trivial). ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3257 From jfranck at openjdk.java.net Tue Mar 30 08:46:49 2021 From: jfranck at openjdk.java.net (Joel =?UTF-8?B?Qm9yZ2dyw6luLUZyYW5jaw==?=) Date: Tue, 30 Mar 2021 08:46:49 GMT Subject: RFR: 8264306: Non deterministic generation of java/lang/invoke/MemberName.class In-Reply-To: References: Message-ID: On Tue, 30 Mar 2021 06:19:22 GMT, Jan Lahoda wrote: > When hoisting binding variables to the outer scope, we should use `LinkedHashMap` instead of `HashMap`, so that `javac` produces reproducible classfiles. Marked as reviewed by jfranck (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3257 From rriggs at openjdk.java.net Tue Mar 30 13:29:23 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 30 Mar 2021 13:29:23 GMT Subject: RFR: 8264148: Update spec for exceptions retrofitted for exception chaining In-Reply-To: References: Message-ID: <-rMQxHXFk7yEM-DmoZOmE9eePkkvaklW5YyWhsJEek4=.8456ad76-b965-4098-a66b-1e80f396cf7c@github.com> On Wed, 24 Mar 2021 23:17:46 GMT, Joe Darcy wrote: > 8264148: Update spec for exceptions retrofitted for exception chaining I agree that the public field in WriteAbortedException could be remediated. But it is also mostly harmless. src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/VMObjectFactory.java line 62: > 60: catch (java.lang.reflect.InvocationTargetException ite) { > 61: if (ite.getCause() instanceof RuntimeException) { > 62: throw (RuntimeException)ite.getCause(); This might be a place to use the new instanceof pattern form: `if (ite.getCause() instanceof RuntimeException rex) throw rex.getCause(); ` src/jdk.jconsole/share/classes/sun/tools/jconsole/inspector/Utils.java line 293: > 291: Throwable t = e.getCause(); > 292: if (t instanceof Exception) { > 293: throw (Exception) t; Ditto: ` if (t instanceof Exception ex) throw ex` ------------- Marked as reviewed by rriggs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3182 From github.com+28367473+jmehrens at openjdk.java.net Tue Mar 30 13:43:22 2021 From: github.com+28367473+jmehrens at openjdk.java.net (jmehrens) Date: Tue, 30 Mar 2021 13:43:22 GMT Subject: RFR: 8264148: Update spec for exceptions retrofitted for exception chaining In-Reply-To: References: Message-ID: On Wed, 24 Mar 2021 23:17:46 GMT, Joe Darcy wrote: > 8264148: Update spec for exceptions retrofitted for exception chaining src/java.base/share/classes/java/io/WriteAbortedException.java line 86: > 84: @Override > 85: public Throwable getCause() { > 86: return detail; Use SuppressWarnings?? ------------- PR: https://git.openjdk.java.net/jdk/pull/3182 From joe.darcy at oracle.com Tue Mar 30 15:55:20 2021 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 30 Mar 2021 08:55:20 -0700 Subject: RFR: 8264148: Update spec for exceptions retrofitted for exception chaining In-Reply-To: References: Message-ID: <76cee601-67a3-adbd-ea45-ded1f2dc592e@oracle.com> On 3/30/2021 6:43 AM, jmehrens wrote: > On Wed, 24 Mar 2021 23:17:46 GMT, Joe Darcy wrote: > >> 8264148: Update spec for exceptions retrofitted for exception chaining > src/java.base/share/classes/java/io/WriteAbortedException.java line 86: > >> 84: @Override >> 85: public Throwable getCause() { >> 86: return detail; > Use SuppressWarnings?? There is no warning to suppress since the detail field is defined in the same class. -Joe From joe.darcy at oracle.com Tue Mar 30 16:00:50 2021 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 30 Mar 2021 09:00:50 -0700 Subject: RFR: 8264148: Update spec for exceptions retrofitted for exception chaining In-Reply-To: <-rMQxHXFk7yEM-DmoZOmE9eePkkvaklW5YyWhsJEek4=.8456ad76-b965-4098-a66b-1e80f396cf7c@github.com> References: <-rMQxHXFk7yEM-DmoZOmE9eePkkvaklW5YyWhsJEek4=.8456ad76-b965-4098-a66b-1e80f396cf7c@github.com> Message-ID: <0627b7e4-6db3-50bc-fba5-35877647d038@oracle.com> On 3/30/2021 6:29 AM, Roger Riggs wrote: > On Wed, 24 Mar 2021 23:17:46 GMT, Joe Darcy wrote: > >> 8264148: Update spec for exceptions retrofitted for exception chaining > I agree that the public field in WriteAbortedException could be remediated. > But it is also mostly harmless. > > src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/VMObjectFactory.java line 62: > >> 60: catch (java.lang.reflect.InvocationTargetException ite) { >> 61: if (ite.getCause() instanceof RuntimeException) { >> 62: throw (RuntimeException)ite.getCause(); > This might be a place to use the new instanceof pattern form: > `if (ite.getCause() instanceof RuntimeException rex) > throw rex.getCause(); > ` > > src/jdk.jconsole/share/classes/sun/tools/jconsole/inspector/Utils.java line 293: > >> 291: Throwable t = e.getCause(); >> 292: if (t instanceof Exception) { >> 293: throw (Exception) t; > Ditto: > ` if (t instanceof Exception ex) throw ex` > I think the use of the new instanceof form would be better left for a follow-up refactoring. Thanks, -Joe From vromero at openjdk.java.net Tue Mar 30 16:55:37 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Tue, 30 Mar 2021 16:55:37 GMT Subject: RFR: 8264373: javac hangs when annotation is declared with sealed public modifier Message-ID: Please review this one liner fix. Although the title mentions the `sealed` modifier, the issue is not strictly related to it. Basically the situation is the following: modifiers `sealed` + `annotation` can't be applied together meaning that this declaration: sealed public @interface SealedTest { } should be rejected by the compiler. We check this assertion at method: `Check::checkFlags` which then invokes `Check::checkDisjoint` which at the end invokes `TreeInfo::firstFlag` to find out what is the first low order bit set to 1 in the intersection between the current symbol flags and subset of them. Now the current implementation of this method is: public static long firstFlag(long flags) { long flag = 1; while ((flag & flags & ExtendedStandardFlags) == 0) flag = flag << 1; return flag; } but given that `ExtendedStandardFlags` is defined as: `StandardFlags | DEFAULT | SEALED | NON_SEALED` and `StandardFlags` is: `0x0FFF` which if we intersect with the ANNOTATION flag (1<<13) will always return 0, the the loop executes forever. I guess we didn't see this issue before because we didn't had a constraint involving a flag with a value > 0x0FFF and less than 0xFFFF which is the case of the ANNOTATION flag. It seems to me that we can safely drop the `& ExtendedStandardFlags` in method `TreeInfo::firstFlag` given that it is used only by Check::checkDisjoint and it is invoked with an intersection of the current flags and the subset the invoking method cares about. So it won't be possible for the argument of `TreeInfo::firstFlag` to contain some javac internal flags we don't want a compiler user to see. What do you think? ------------- Commit messages: - 8264373: javac hangs when annotation is declared with sealed public modifier Changes: https://git.openjdk.java.net/jdk/pull/3273/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3273&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264373 Stats: 3 lines in 2 files changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/3273.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3273/head:pull/3273 PR: https://git.openjdk.java.net/jdk/pull/3273 From smarks at openjdk.java.net Tue Mar 30 17:06:32 2021 From: smarks at openjdk.java.net (Stuart Marks) Date: Tue, 30 Mar 2021 17:06:32 GMT Subject: RFR: 8264148: Update spec for exceptions retrofitted for exception chaining In-Reply-To: References: Message-ID: On Wed, 24 Mar 2021 23:17:46 GMT, Joe Darcy wrote: > 8264148: Update spec for exceptions retrofitted for exception chaining Marked as reviewed by smarks (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3182 From darcy at openjdk.java.net Tue Mar 30 20:03:18 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 30 Mar 2021 20:03:18 GMT Subject: Integrated: 8264148: Update spec for exceptions retrofitted for exception chaining In-Reply-To: References: Message-ID: On Wed, 24 Mar 2021 23:17:46 GMT, Joe Darcy wrote: > 8264148: Update spec for exceptions retrofitted for exception chaining This pull request has now been integrated. Changeset: 815248ab Author: Joe Darcy URL: https://git.openjdk.java.net/jdk/commit/815248ab Stats: 84 lines in 22 files changed: 8 ins; 44 del; 32 mod 8264148: Update spec for exceptions retrofitted for exception chaining Reviewed-by: rriggs, smarks ------------- PR: https://git.openjdk.java.net/jdk/pull/3182 From github.com+76791+alblue at openjdk.java.net Wed Mar 31 12:36:19 2021 From: github.com+76791+alblue at openjdk.java.net (Alex Blewitt) Date: Wed, 31 Mar 2021 12:36:19 GMT Subject: RFR: 8264331: Use the blessed modifier order in jdk.compiler In-Reply-To: References: Message-ID: On Sun, 28 Mar 2021 13:55:30 GMT, Alex Blewitt wrote: > 8264331: Use the blessed modifier order in jdk.compiler Would anyone mind reviewing this change, please? It swaps the order of "final static" for "static final" across a bunch of files. ------------- PR: https://git.openjdk.java.net/jdk/pull/3235 From vromero at openjdk.java.net Wed Mar 31 13:01:30 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Wed, 31 Mar 2021 13:01:30 GMT Subject: RFR: 8264331: Use the blessed modifier order in jdk.compiler In-Reply-To: References: Message-ID: <7TUHVI-PsuCR_EEf0ntn7RaegiTZWNqc5TmwO6fomHc=.75fed414-7a85-4f11-b03f-96cfff9912fa@github.com> On Sun, 28 Mar 2021 13:55:30 GMT, Alex Blewitt wrote: > 8264331: Use the blessed modifier order in jdk.compiler looks good ------------- Marked as reviewed by vromero (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3235 From jpai at openjdk.java.net Wed Mar 31 13:40:09 2021 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Wed, 31 Mar 2021 13:40:09 GMT Subject: RFR: 8173970: jar tool should have a way to extract to a directory In-Reply-To: References: Message-ID: On Sat, 27 Mar 2021 16:02:55 GMT, Alan Bateman wrote: >> Can I please get a review for this patch which proposes to implement the enhancement request noted in https://bugs.openjdk.java.net/browse/JDK-8173970? >> >> The commit in this PR introduces the `-o` and `--output-dir` option to the `jar` command. The option takes a path to a destination directory as a value and extracts the contents of the jar into that directory. This is an optional option and the changes in the commit continue to maintain backward compatibility where the jar is extracted into current directory, if no `-o` or `--output-dir` option has been specified. >> >> As far as I know, there hasn't been any discussion on what the name of this new option should be. I was initially thinking of using `-d` but that is currently used by the `jar` command for a different purpose. So I decided to use `-o` and `--output-dir`. This is of course open for change depending on any suggestions in this PR. >> >> The commit in this PR also updates the `jar.properties` file which contains the English version of the jar command's `--help` output. However, no changes have been done to the internationalization files corresponding to this one (for example: `jar_de.properties`), because I don't know what process needs to be followed to have those files updated (if at all they need to be updated). >> >> The commit also includes a jtreg testcase which verifies the usage of this new option. > > I think the summary is that we've converged on -C/--dir. We might have to tweak the usage message for -C so that it starts with the existing "Change to the specified directory ..." rather than changing it to start with the extract case. > Are you, or Lance, going to create the CSR for this? A CSR for this enhancement has now been created https://bugs.openjdk.java.net/browse/JDK-8264510 ------------- PR: https://git.openjdk.java.net/jdk/pull/2752 From lancea at openjdk.java.net Wed Mar 31 15:57:13 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Wed, 31 Mar 2021 15:57:13 GMT Subject: RFR: 8173970: jar tool should have a way to extract to a directory [v3] In-Reply-To: References: Message-ID: On Mon, 29 Mar 2021 14:04:10 GMT, Jaikiran Pai wrote: >> Can I please get a review for this patch which proposes to implement the enhancement request noted in https://bugs.openjdk.java.net/browse/JDK-8173970? >> >> The commit in this PR introduces the `-o` and `--output-dir` option to the `jar` command. The option takes a path to a destination directory as a value and extracts the contents of the jar into that directory. This is an optional option and the changes in the commit continue to maintain backward compatibility where the jar is extracted into current directory, if no `-o` or `--output-dir` option has been specified. >> >> As far as I know, there hasn't been any discussion on what the name of this new option should be. I was initially thinking of using `-d` but that is currently used by the `jar` command for a different purpose. So I decided to use `-o` and `--output-dir`. This is of course open for change depending on any suggestions in this PR. >> >> The commit in this PR also updates the `jar.properties` file which contains the English version of the jar command's `--help` output. However, no changes have been done to the internationalization files corresponding to this one (for example: `jar_de.properties`), because I don't know what process needs to be followed to have those files updated (if at all they need to be updated). >> >> The commit also includes a jtreg testcase which verifies the usage of this new option. > > Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision: > > - Alan's review feedback for -C help text > - Keep -xfP backward compatible but don't allow -C/--dir with -xfP Hi Jaikiran Overall this looks good. I have a few comments below and will look at the CSR shortly. src/jdk.jartool/share/classes/sun/tools/jar/Main.java line 1427: > 1425: return rc; // leading '/' or 'dot-dot' only path > 1426: } > 1427: File f = new File(xdestDir, name.replace('/', File.separatorChar)); Could you please add a comment regarding xdestDir and also correct the typo on line 1418 'requres' -> 'requires' src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties line 62: > 60: Could not create a temporary file > 61: error.extract.multiple.dest.dir=\ > 62: You may not specify more than one directory for extracting the jar Perhaps something similar to: You may not specify the '-C' or '--dir' option more than once with the '-x' option src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties line 64: > 62: You may not specify more than one directory for extracting the jar > 63: error.extract.pflag.not.allowed=\ > 64: -P option cannot be used when extracting a jar to a specific location Perhaps something similar to You may not specify '-Px' with the '-C' or '--dir' options src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties line 167: > 165: (in = {0}) (out= {1}) > 166: out.extract.dir=\ > 167: extracting to {0} Perhaps 'Extracting to directory: {0}' src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties line 249: > 247: \ -C DIR Change to the specified directory and include the\n\ > 248: \ following file. When used in extract mode, extracts\n\ > 249: \ the jar to the specified directory Should this be updated on line 187 as well in the compatibility mode section? test/jdk/tools/jar/JarExtractTest.java line 152: > 150: return abs; > 151: } > 152: Please add a comment to each test giving a high level overview of what it does as it will help future maintainers test/jdk/tools/jar/JarExtractTest.java line 307: > 305: // make sure only the specific files were extracted > 306: final Stream paths = Files.walk(Path.of(tmpDir)); > 307: Assert.assertEquals(paths.count(), 6, "Unexpected number of files/dirs in " + tmpDir); Should '6' be in a local variable to make it clearer or at a minimum a comment test/jdk/tools/jar/JarExtractTest.java line 367: > 365: } > 366: > 367: private static Path createJarWithPFlagSemantics() throws IOException { Perhaps add a comment as to what the method does ------------- PR: https://git.openjdk.java.net/jdk/pull/2752 From iris at openjdk.java.net Wed Mar 31 16:20:09 2021 From: iris at openjdk.java.net (Iris Clark) Date: Wed, 31 Mar 2021 16:20:09 GMT Subject: RFR: 8264331: Use the blessed modifier order in jdk.compiler In-Reply-To: References: Message-ID: On Sun, 28 Mar 2021 13:55:30 GMT, Alex Blewitt wrote: > 8264331: Use the blessed modifier order in jdk.compiler Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3235 From lancea at openjdk.java.net Wed Mar 31 17:26:19 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Wed, 31 Mar 2021 17:26:19 GMT Subject: RFR: 8173970: jar tool should have a way to extract to a directory [v3] In-Reply-To: References: Message-ID: On Mon, 29 Mar 2021 14:04:10 GMT, Jaikiran Pai wrote: >> Can I please get a review for this patch which proposes to implement the enhancement request noted in https://bugs.openjdk.java.net/browse/JDK-8173970? >> >> The commit in this PR introduces the `-o` and `--output-dir` option to the `jar` command. The option takes a path to a destination directory as a value and extracts the contents of the jar into that directory. This is an optional option and the changes in the commit continue to maintain backward compatibility where the jar is extracted into current directory, if no `-o` or `--output-dir` option has been specified. >> >> As far as I know, there hasn't been any discussion on what the name of this new option should be. I was initially thinking of using `-d` but that is currently used by the `jar` command for a different purpose. So I decided to use `-o` and `--output-dir`. This is of course open for change depending on any suggestions in this PR. >> >> The commit in this PR also updates the `jar.properties` file which contains the English version of the jar command's `--help` output. However, no changes have been done to the internationalization files corresponding to this one (for example: `jar_de.properties`), because I don't know what process needs to be followed to have those files updated (if at all they need to be updated). >> >> The commit also includes a jtreg testcase which verifies the usage of this new option. > > Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision: > > - Alan's review feedback for -C help text > - Keep -xfP backward compatible but don't allow -C/--dir with -xfP Some additional comments basically suggesting that we test --extract in addition to -x test/jdk/tools/jar/JarExtractTest.java line 175: > 173: final String dest = "foo-bar"; > 174: System.out.println("Extracting " + testJarPath + " to " + dest); > 175: final int exitCode = JAR_TOOL.run(System.out, System.err, "-x", "-f", testJarPath.toString(), Perhaps add a DataProvider so you can test --extract as well? test/jdk/tools/jar/JarExtractTest.java line 216: > 214: final Path jarPath = createJarWithPFlagSemantics(); > 215: // extract with -P flag without any explicit destination directory (expect the extraction to work fine) > 216: final String[] args = new String[]{"-xvfP", jarPath.toString()}; Perhaps add a DataProvider so you can test --extract as well? test/jdk/tools/jar/JarExtractTest.java line 239: > 237: */ > 238: @Test > 239: public void testExtractWithDirPFlagNotAllowed() throws Exception { I would include --extract in your testing options test/jdk/tools/jar/JarExtractTest.java line 240: > 238: @Test > 239: public void testExtractWithDirPFlagNotAllowed() throws Exception { > 240: final String expectedErrMsg = "-P option cannot be used when extracting a jar to a specific location"; Probably need to add a comment that this must match the entry in jar.properties test/jdk/tools/jar/JarExtractTest.java line 247: > 245: cmdArgs.add(new String[]{"-x", "-f", testJarPath.toString(), "-P", "-C", "."}); > 246: cmdArgs.add(new String[]{"-x", "-f", testJarPath.toString(), "-P", "--dir", "."}); > 247: cmdArgs.add(new String[]{"-xvfP", testJarPath.toString(), "-C", tmpDir}); Perhaps add a DataProvider so you can test --extract as well? test/jdk/tools/jar/JarExtractTest.java line 262: > 260: */ > 261: @Test > 262: public void testLegacyCompatibilityMode() throws Exception { Perhaps add a DataProvider so you can test --extract as well? test/jdk/tools/jar/JarExtractTest.java line 282: > 280: cmdArgs.add(new String[]{"-x", "-f", testJarPath.toString(), "-C", tmpDir, "-C", tmpDir}); > 281: cmdArgs.add(new String[]{"-x", "-f", testJarPath.toString(), "--dir", tmpDir, "--dir", tmpDir}); > 282: cmdArgs.add(new String[]{"-x", "-f", testJarPath.toString(), "--dir", tmpDir, "-C", tmpDir}); Perhaps use a DataProvider so you can test --extract as well? test/jdk/tools/jar/JarExtractTest.java line 300: > 298: public void testExtractPartialContent() throws Exception { > 299: final String tmpDir = Files.createTempDirectory(Path.of("."), "8173970-").toString(); > 300: final String[] cmdArgs = new String[]{"-x", "-f", testJarPath.toString(), "--dir", tmpDir, Perhaps add a DataProvider so you can test --extract as well? test/jdk/tools/jar/JarExtractTest.java line 332: > 330: */ > 331: private void testExtract(final String dest) throws Exception { > 332: final String[] args = new String[]{"-x", "-f", testJarPath.toString(), "-C", dest}; Perhaps add a DataProvider so you can test --extract as well? ------------- PR: https://git.openjdk.java.net/jdk/pull/2752