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: <sRNM0ABivEQD0cppdO7mSjxUBhVGPDTUykXM2UJ4kb0=.2086cd5a-3609-4430-b861-b392cd55debf@github.com>

On Mon, 15 Feb 2021 08:12:10 GMT, Jan Lahoda <jlahoda at openjdk.org> 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 <jlahoda at openjdk.org>
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: <IgfH4qwqZwjwcu9PiObG0fJ0YhTo5oqabUFpLI8Wuro=.bb2584a1-6c61-460c-879c-2ffb5e072021@github.com>
References: <IgfH4qwqZwjwcu9PiObG0fJ0YhTo5oqabUFpLI8Wuro=.bb2584a1-6c61-460c-879c-2ffb5e072021@github.com>
Message-ID: <4BZ-snLcal2cFsb6yWPG0h9KTP84e8tOKcZMPX3bM4I=.3142d1b5-e446-4273-91f5-8e68bc8e660a@github.com>

On Mon, 4 Jan 2021 17:17:58 GMT, Guoxiong Li <github.com+13688759+lgxbslgx at openjdk.org> 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: <wd62mmsecdHYCNEAhc-2qsTSRJy0v7QA70Dl4-hXKQA=.a3cc5eba-97ed-4b75-b004-e394edfeb98b@github.com>
References: <wd62mmsecdHYCNEAhc-2qsTSRJy0v7QA70Dl4-hXKQA=.a3cc5eba-97ed-4b75-b004-e394edfeb98b@github.com>
Message-ID: <kDIfnuA9C2GrIKnrSJbZkXT5I1IqbnWALsbHRWpoNW0=.124c3e7f-8844-4060-8b6a-0446d958ef4a@github.com>

On Fri, 25 Dec 2020 16:26:39 GMT, Guoxiong Li <github.com+13688759+lgxbslgx at openjdk.org> 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: <IuffxoxpXLsRxsyHihUGCtJ0vhom46ak7apoAYPJ2s0=.d982a842-05bf-482f-a30e-639b61aafaf4@github.com>
References: <wd62mmsecdHYCNEAhc-2qsTSRJy0v7QA70Dl4-hXKQA=.a3cc5eba-97ed-4b75-b004-e394edfeb98b@github.com>
 <JX-iyXc_sJJURjgud46jHz7kLSJt7Jvf-7XkeRtNjLU=.29e853a7-4932-413b-9f98-ac619dcd5069@github.com>
 <1C7URguurLTNecDlWJUVnuzOMKjxWYTbtMALA7_zujM=.34d4f580-4695-4790-afbd-16d5a2b8120b@github.com>
 <hSAOOWfjpir1YS6CcWYjFRE49HCzBTeNDjUcEhYc5hU=.778e45ae-647d-4dde-937e-616d1fc2ca80@github.com>
 <IuffxoxpXLsRxsyHihUGCtJ0vhom46ak7apoAYPJ2s0=.d982a842-05bf-482f-a30e-639b61aafaf4@github.com>
Message-ID: <o4xTQDIrHZjw02AW1glt9ULZvdu5xL8Ku9hSOg0GlH4=.90917478-7737-453e-9cd9-c729980799ca@github.com>

On Tue, 5 Jan 2021 14:29:25 GMT, Guoxiong Li <github.com+13688759+lgxbslgx at openjdk.org> 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: <C1A35D8F-B1D3-4233-AE2F-1D699BF74B65@oracle.com>
References: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
 <1BB8805F-174A-4EB9-B26A-060B2251A40C@oracle.com>
 <e88d6a73-f126-6848-45a2-3960d9726de8@oracle.com>
 <6242cfe8-cef7-0603-33fc-b3428209a1ac@gmail.com>
 <C1A35D8F-B1D3-4233-AE2F-1D699BF74B65@oracle.com>
Message-ID: <ab9bcc11-1f1b-b82e-2dfe-ae17ea630d7f@gmail.com>

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 <jai.forums2013 at gmail.com 
>> <mailto:jai.forums2013 at gmail.com>> 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 <mailto:Lance.Andersen at oracle.com>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20210303/64f0359a/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: oracle_sig_logo.gif
Type: image/gif
Size: 658 bytes
Desc: not available
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20210303/64f0359a/oracle_sig_logo-0001.gif>

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: <GVxbhQG4b59QeL6dAqnFOu2xTiIYJ1ZTwuK9nKF7-mw=.3c6072eb-6d05-4332-b29b-b669fbc84286@github.com>
References: <GVxbhQG4b59QeL6dAqnFOu2xTiIYJ1ZTwuK9nKF7-mw=.3c6072eb-6d05-4332-b29b-b669fbc84286@github.com>
Message-ID: <ZTyqeLHND01QKFPQ6sq8k-sT28xauVZiRJOmb8L3oCA=.fe84aba2-d404-4c08-8d59-21ee8bd2d2aa@github.com>

On Tue, 5 Jan 2021 16:47:26 GMT, Jan Lahoda <jlahoda at openjdk.org> 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 <jlahoda at openjdk.org>
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: <ab9bcc11-1f1b-b82e-2dfe-ae17ea630d7f@gmail.com>
References: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
 <1BB8805F-174A-4EB9-B26A-060B2251A40C@oracle.com>
 <e88d6a73-f126-6848-45a2-3960d9726de8@oracle.com>
 <6242cfe8-cef7-0603-33fc-b3428209a1ac@gmail.com>
 <C1A35D8F-B1D3-4233-AE2F-1D699BF74B65@oracle.com>
 <ab9bcc11-1f1b-b82e-2dfe-ae17ea630d7f@gmail.com>
Message-ID: <F7E99E98-2000-4ACD-B3A9-CEBE4903D26D@oracle.com>

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 <jai.forums2013 at gmail.com<mailto:jai.forums2013 at gmail.com>> 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 <jai.forums2013 at gmail.com<mailto:jai.forums2013 at gmail.com>> 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



<oracle_sig_logo.gif>



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<mailto: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<mailto:Lance.Andersen at oracle.com>



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20210303/ee33848d/attachment-0001.htm>
-------------- 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: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20210303/ee33848d/oracle_sig_logo-0001.gif>

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: <IYTZ3smSm6Cxs9hVql4TOjBJl76BGTmZSbsGE5TNrLA=.1e881119-44b7-48fd-8a42-3af94673ee0f@github.com>

`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: <IYTZ3smSm6Cxs9hVql4TOjBJl76BGTmZSbsGE5TNrLA=.1e881119-44b7-48fd-8a42-3af94673ee0f@github.com>
References: <IYTZ3smSm6Cxs9hVql4TOjBJl76BGTmZSbsGE5TNrLA=.1e881119-44b7-48fd-8a42-3af94673ee0f@github.com>
Message-ID: <oXOijAkwVm3eHaCMgPgyX48s9a8zyc5ylC2NbznTMuA=.b7aa805c-6931-432b-aaae-30f8327c282b@github.com>

On Wed, 3 Mar 2021 16:43:02 GMT, Jan Lahoda <jlahoda at openjdk.org> 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: <F7E99E98-2000-4ACD-B3A9-CEBE4903D26D@oracle.com>
References: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
 <1BB8805F-174A-4EB9-B26A-060B2251A40C@oracle.com>
 <e88d6a73-f126-6848-45a2-3960d9726de8@oracle.com>
 <6242cfe8-cef7-0603-33fc-b3428209a1ac@gmail.com>
 <C1A35D8F-B1D3-4233-AE2F-1D699BF74B65@oracle.com>
 <ab9bcc11-1f1b-b82e-2dfe-ae17ea630d7f@gmail.com>
 <F7E99E98-2000-4ACD-B3A9-CEBE4903D26D@oracle.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: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20210304/dedf34b2/attachment.htm>

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: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
 <1BB8805F-174A-4EB9-B26A-060B2251A40C@oracle.com>
 <e88d6a73-f126-6848-45a2-3960d9726de8@oracle.com>
 <6242cfe8-cef7-0603-33fc-b3428209a1ac@gmail.com>
 <C1A35D8F-B1D3-4233-AE2F-1D699BF74B65@oracle.com>
 <ab9bcc11-1f1b-b82e-2dfe-ae17ea630d7f@gmail.com>
 <F7E99E98-2000-4ACD-B3A9-CEBE4903D26D@oracle.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 <jai.forums2013 at gmail.com<mailto:jai.forums2013 at gmail.com>> 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<mailto:Lance.Andersen at oracle.com>



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20210304/13818262/attachment-0001.htm>
-------------- 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: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20210304/13818262/oracle_sig_logo-0001.gif>

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: <IYTZ3smSm6Cxs9hVql4TOjBJl76BGTmZSbsGE5TNrLA=.1e881119-44b7-48fd-8a42-3af94673ee0f@github.com>
References: <IYTZ3smSm6Cxs9hVql4TOjBJl76BGTmZSbsGE5TNrLA=.1e881119-44b7-48fd-8a42-3af94673ee0f@github.com>
Message-ID: <31uyvFuqG4QyrVPBCkEH2V3xDCkVzCnvj0OQujfPcO4=.acd1ff4b-cd7f-4223-b016-87c5edf5650f@github.com>

On Wed, 3 Mar 2021 16:43:02 GMT, Jan Lahoda <jlahoda at openjdk.org> 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 <jlahoda at openjdk.org>
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: <TgjX8geptRG_9gyfSXWeAZ4pGYHJmtvA8MTIKvI-MDI=.a3db92df-23cd-4ea1-9adc-86406de85d72@github.com>
References: <TgjX8geptRG_9gyfSXWeAZ4pGYHJmtvA8MTIKvI-MDI=.a3db92df-23cd-4ea1-9adc-86406de85d72@github.com>
Message-ID: <XENKhx6BJ3aNdrdn51oJxw0VD0k8O41JoZxAZecG64o=.a0621d7d-3054-4816-8762-bbcbb7d7536e@github.com>

On Wed, 6 Jan 2021 14:18:49 GMT, Guoxiong Li <github.com+13688759+lgxbslgx at openjdk.org> 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: <bpkysQEcqriD_LisrpETmgXnbEBfM4Yw6p6MNMLPhnA=.7c55eccf-00ca-48d5-8bdf-7e2d7e68d631@github.com>
References: <bpkysQEcqriD_LisrpETmgXnbEBfM4Yw6p6MNMLPhnA=.7c55eccf-00ca-48d5-8bdf-7e2d7e68d631@github.com>
Message-ID: <PMCKdl-wruSSgvBpylJrWLbU9te3WH_JhfXG9dVXY1g=.8a96ea89-96d4-41fc-a449-546109db6b6b@github.com>

On Sun, 27 Dec 2020 14:54:16 GMT, Guoxiong Li <github.com+13688759+lgxbslgx at openjdk.org> 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: <Zp7LEfXjLQTrTgi7eP1DShVrdoafpYNr1_kJfxEgssY=.d59db3e7-770d-4a04-9469-2f632af562be@github.com>

Please review a moderately simple fix to improve DocLint's checking for empty tags, and in particular, bad use of `<p>` 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 `<p>` 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: <fPIf2TG2r9A2gJKfY2q8ifG4fHP7Ed1lHJ1KyExwI-U=.59c5f061-4e65-4db1-8a86-64a97a323b24@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <djPl7TL8j0qwyuLjwnZI96g7UPmw3XamdbVltf8fbos=.36a5bbe7-1fd0-496b-999f-7c49d06fc0a8@github.com>
 <6zhT8ySP8rFE4wV5vva0oKRDSxDnSYYZ-sXAQJ6F_DM=.b83a0f88-7231-4796-a0b5-d51b5950d316@github.com>
 <KKuuOtcyAwZLESU78ZnNaF5LmeoQeWzxj-yO-xCj5ZM=.ea9ff05f-ffea-477f-b7eb-b94df1f186f3@github.com>
 <fPIf2TG2r9A2gJKfY2q8ifG4fHP7Ed1lHJ1KyExwI-U=.59c5f061-4e65-4db1-8a86-64a97a323b24@github.com>
Message-ID: <FtDgzqkxbiUrEEutqoTjnbPiDE5VmJFH4pYDN97jbqA=.92524dca-6010-4d6b-8b29-6801297e1a34@github.com>

On Fri, 19 Feb 2021 15:03:11 GMT, Sean Mullan <mullan at openjdk.org> 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<X509Certificate> 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<X509Certificate> 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: <zYNAgZhbcvtkYmuvcllZahjFLrKOFmlixja3puW9vnQ=.25837f2e-c51f-482f-a9c1-ea063d201b83@github.com>

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: <zYNAgZhbcvtkYmuvcllZahjFLrKOFmlixja3puW9vnQ=.25837f2e-c51f-482f-a9c1-ea063d201b83@github.com>
References: <zYNAgZhbcvtkYmuvcllZahjFLrKOFmlixja3puW9vnQ=.25837f2e-c51f-482f-a9c1-ea063d201b83@github.com>
Message-ID: <w-4j6MBnNAEc5g3u1MI1oEalHb_OCzPrd78ZHQVRsV4=.144b55c2-7fdd-4560-bd24-4b779e9280e0@github.com>

On Mon, 8 Mar 2021 11:21:38 GMT, Jan Lahoda <jlahoda at openjdk.org> 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: <zYNAgZhbcvtkYmuvcllZahjFLrKOFmlixja3puW9vnQ=.25837f2e-c51f-482f-a9c1-ea063d201b83@github.com>
References: <zYNAgZhbcvtkYmuvcllZahjFLrKOFmlixja3puW9vnQ=.25837f2e-c51f-482f-a9c1-ea063d201b83@github.com>
Message-ID: <yCFmotKS0yV1nTfRWa8zJkfzBiv5PLzj6V68zJWa7ew=.59c0a458-8f4e-4c8a-8884-89cce2f63ee4@github.com>

On Mon, 8 Mar 2021 11:21:38 GMT, Jan Lahoda <jlahoda at openjdk.org> 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: <T1PiFrNwlewkITLqXiZMcXwq6wFQMlRl2uyPxDf_038=.d4afe725-54f9-4e72-b222-ff103d8bf512@github.com>

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: <Zp7LEfXjLQTrTgi7eP1DShVrdoafpYNr1_kJfxEgssY=.d59db3e7-770d-4a04-9469-2f632af562be@github.com>
References: <Zp7LEfXjLQTrTgi7eP1DShVrdoafpYNr1_kJfxEgssY=.d59db3e7-770d-4a04-9469-2f632af562be@github.com>
Message-ID: <MXRZ-_M6dCqF9XMmTHETa-ujlJpbNd2pr67sRJzsDPA=.b943e746-dfc7-41eb-9898-705bd3593ace@github.com>

On Fri, 5 Mar 2021 21:44:20 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a moderately simple fix to improve DocLint's checking for empty tags, and in particular, bad use of `<p>` 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 `<p>` 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: <zYNAgZhbcvtkYmuvcllZahjFLrKOFmlixja3puW9vnQ=.25837f2e-c51f-482f-a9c1-ea063d201b83@github.com>
References: <zYNAgZhbcvtkYmuvcllZahjFLrKOFmlixja3puW9vnQ=.25837f2e-c51f-482f-a9c1-ea063d201b83@github.com>
Message-ID: <jL7jiiU3lYsPz9Bzd1fya2WwXZ2m7o2hl1x_MQOY4I4=.e3bf1893-7540-4567-80e0-cf2944f8ddcf@github.com>

> 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: <klPrlAvPsVYcAtWjox3cWGgbEIjbHXoaFtYu7iBPCxc=.22a22c0a-7d04-4abf-b9ff-0e2a423a6b18@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <5s4i5725zJd8QrefwYyc8sn2fQXad3hAGLVflkFttmY=.abe55236-e258-482b-b8be-be75e1eb086c@github.com>
 <klPrlAvPsVYcAtWjox3cWGgbEIjbHXoaFtYu7iBPCxc=.22a22c0a-7d04-4abf-b9ff-0e2a423a6b18@github.com>
Message-ID: <yTKkQHWG8Qd3WtteVvA2tqZz4hH1c_qA1jOhtHl9NjM=.6d67bde5-0fa3-4973-857b-f539cab13a32@github.com>

On Thu, 18 Feb 2021 07:12:34 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> 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: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
Message-ID: <IuYcSqYk7zxG7hAU605DouLqEQ7zCfLH1VsulI-Zk0A=.aeb9dcfd-d720-4fd2-9577-8bc454dd77a1@github.com>

> 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: <T1PiFrNwlewkITLqXiZMcXwq6wFQMlRl2uyPxDf_038=.d4afe725-54f9-4e72-b222-ff103d8bf512@github.com>
References: <T1PiFrNwlewkITLqXiZMcXwq6wFQMlRl2uyPxDf_038=.d4afe725-54f9-4e72-b222-ff103d8bf512@github.com>
Message-ID: <xFyKyik4cygIz4-ghC-Mm7cAVWWx6FXmPK0y4tMrNZs=.c1664397-b171-4141-a6d6-15975cba5cd3@github.com>

On Fri, 12 Mar 2021 13:52:51 GMT, Aleksey Shipilev <shade at openjdk.org> 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: <xFyKyik4cygIz4-ghC-Mm7cAVWWx6FXmPK0y4tMrNZs=.c1664397-b171-4141-a6d6-15975cba5cd3@github.com>
References: <T1PiFrNwlewkITLqXiZMcXwq6wFQMlRl2uyPxDf_038=.d4afe725-54f9-4e72-b222-ff103d8bf512@github.com>
 <xFyKyik4cygIz4-ghC-Mm7cAVWWx6FXmPK0y4tMrNZs=.c1664397-b171-4141-a6d6-15975cba5cd3@github.com>
Message-ID: <jqeGDkzexAkUkABC5wtYGG7MXQ5KH7rjC0VStDnd9BY=.de2bb9ea-1c78-428e-8cd2-3c9642bdd851@github.com>

On Mon, 15 Mar 2021 17:22:12 GMT, Vicente Romero <vromero at openjdk.org> 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: <T1PiFrNwlewkITLqXiZMcXwq6wFQMlRl2uyPxDf_038=.d4afe725-54f9-4e72-b222-ff103d8bf512@github.com>
References: <T1PiFrNwlewkITLqXiZMcXwq6wFQMlRl2uyPxDf_038=.d4afe725-54f9-4e72-b222-ff103d8bf512@github.com>
Message-ID: <hwjiO_8B0Tit99PftDcMDC4WL4_kvQWhfw2R9nVhwdA=.b5815e5b-2060-4077-9cbe-269c1cc85d17@github.com>

On Fri, 12 Mar 2021 13:52:51 GMT, Aleksey Shipilev <shade at openjdk.org> 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 <shade at openjdk.org>
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: <LDbdieK8GQSJxCJUlSDumQORO3ShcN4h843jKGmH9XU=.7d26ffaa-d259-4af5-98c4-8b63a26cd901@github.com>

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: <LDbdieK8GQSJxCJUlSDumQORO3ShcN4h843jKGmH9XU=.7d26ffaa-d259-4af5-98c4-8b63a26cd901@github.com>
References: <LDbdieK8GQSJxCJUlSDumQORO3ShcN4h843jKGmH9XU=.7d26ffaa-d259-4af5-98c4-8b63a26cd901@github.com>
Message-ID: <XGcUlywRvaNgHxHlkWgDY4Lrq2glIXeZW2JopWo92wU=.d053dcbe-5e1a-4cd9-aff7-e9fc0788a3d9@github.com>

On Mon, 15 Mar 2021 17:59:33 GMT, Jan Lahoda <jlahoda at openjdk.org> 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: <klPrlAvPsVYcAtWjox3cWGgbEIjbHXoaFtYu7iBPCxc=.22a22c0a-7d04-4abf-b9ff-0e2a423a6b18@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <5s4i5725zJd8QrefwYyc8sn2fQXad3hAGLVflkFttmY=.abe55236-e258-482b-b8be-be75e1eb086c@github.com>
 <klPrlAvPsVYcAtWjox3cWGgbEIjbHXoaFtYu7iBPCxc=.22a22c0a-7d04-4abf-b9ff-0e2a423a6b18@github.com>
Message-ID: <4Bae_Uh8Zakn4cnmbXkUcV9xRTus1hgHCEPVthHuEyc=.fb959963-ff7a-4067-b888-e178d9f70e91@github.com>

On Thu, 18 Feb 2021 07:12:34 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> 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: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
Message-ID: <Gm7s8Wp6sP7u0kYiTeTblJgRC5aCdi2LSB3zUiWWhKc=.a19637ca-c449-4176-96af-ae7dc0e09b26@github.com>

On Sun, 20 Dec 2020 17:05:21 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> 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 <turbanoff at gmail.com>
Committer: Julia Boes <jboes at openjdk.org>
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: <mTPLToahD7LVVrpkLNna3YfUJhD76MU9mthNsDRzcNU=.e46d2e81-5b92-4790-a905-2340ecb12507@github.com>

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: <mTPLToahD7LVVrpkLNna3YfUJhD76MU9mthNsDRzcNU=.e46d2e81-5b92-4790-a905-2340ecb12507@github.com>
References: <mTPLToahD7LVVrpkLNna3YfUJhD76MU9mthNsDRzcNU=.e46d2e81-5b92-4790-a905-2340ecb12507@github.com>
Message-ID: <2YkwilkHrSQRYZrPWofWsyQTxPJUgPgxbsxPgJQfkYM=.7fd12075-cdde-4401-a2df-6d9bf2df4038@github.com>

On Tue, 16 Mar 2021 16:37:51 GMT, Pavel Rappo <prappo at openjdk.org> 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: <mTPLToahD7LVVrpkLNna3YfUJhD76MU9mthNsDRzcNU=.e46d2e81-5b92-4790-a905-2340ecb12507@github.com>
 <2YkwilkHrSQRYZrPWofWsyQTxPJUgPgxbsxPgJQfkYM=.7fd12075-cdde-4401-a2df-6d9bf2df4038@github.com>
Message-ID: <Qzy4j2peZ8aXQvgmAnznuiVha-FwCRXdyU2ATXboRc0=.70967940-b8cc-40e1-8a39-dc6808ddd603@github.com>

On Tue, 16 Mar 2021 17:06:25 GMT, Vicente Romero <vromero at openjdk.org> 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: <AwCW8S7x-ls9hLA6AmLnkYLL6hcpSsGT_hEd5swj6n8=.4e4413d6-781a-4169-bf6b-bf592b76708b@github.com>
References: <AwCW8S7x-ls9hLA6AmLnkYLL6hcpSsGT_hEd5swj6n8=.4e4413d6-781a-4169-bf6b-bf592b76708b@github.com>
Message-ID: <E6pJc-l0zC6I7dCrxZ0YWvQn-F8KVjTfYRoeQ-KWyv4=.b7f5d20a-2deb-4d6d-82bb-6f42afe8c22f@github.com>

On Tue, 2 Feb 2021 18:33:18 GMT, Vicente Romero <vromero at openjdk.org> 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 <vromero at openjdk.org>
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: <mTPLToahD7LVVrpkLNna3YfUJhD76MU9mthNsDRzcNU=.e46d2e81-5b92-4790-a905-2340ecb12507@github.com>
References: <mTPLToahD7LVVrpkLNna3YfUJhD76MU9mthNsDRzcNU=.e46d2e81-5b92-4790-a905-2340ecb12507@github.com>
Message-ID: <sNJZxQqGxeUJ9P833sFLa69a3qX1ti11-q-P8w-8A7o=.aa4ad67b-f786-4da9-a672-cbcf01d2d202@github.com>

On Tue, 16 Mar 2021 16:37:51 GMT, Pavel Rappo <prappo at openjdk.org> 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 <prappo at openjdk.org>
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: <XVY3kmwWCWjj3JOIbj8cwSOHK-RDSVH4OpMpVKcN-gM=.4a82383d-0114-471f-8b5c-3aae562f2c1e@github.com>

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: <LDbdieK8GQSJxCJUlSDumQORO3ShcN4h843jKGmH9XU=.7d26ffaa-d259-4af5-98c4-8b63a26cd901@github.com>
References: <LDbdieK8GQSJxCJUlSDumQORO3ShcN4h843jKGmH9XU=.7d26ffaa-d259-4af5-98c4-8b63a26cd901@github.com>
Message-ID: <gGdl6R3T1v6gLHm29Otw77SAw1dRQmjeR6nJTubOYO4=.08884aa8-f8ab-4c17-927e-85bd5d2d6b9d@github.com>

On Mon, 15 Mar 2021 17:59:33 GMT, Jan Lahoda <jlahoda at openjdk.org> 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 <jlahoda at openjdk.org>
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: <MNt2HdkWDfxOU_3iYGpbmGeSZzgig4i0kOxo8egUWek=.7d1e8d37-500b-4114-8082-69ad9a597acf@github.com>

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: <MNt2HdkWDfxOU_3iYGpbmGeSZzgig4i0kOxo8egUWek=.7d1e8d37-500b-4114-8082-69ad9a597acf@github.com>
References: <MNt2HdkWDfxOU_3iYGpbmGeSZzgig4i0kOxo8egUWek=.7d1e8d37-500b-4114-8082-69ad9a597acf@github.com>
Message-ID: <BkmEJhFgOdiysm8JWXgKTAM-6ACipCkrU0wU04YgpBc=.48cba020-4195-4b33-80b0-85f5a919e200@github.com>

On Mon, 22 Mar 2021 18:19:39 GMT, Aleksey Shipilev <shade at openjdk.org> 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: <MNt2HdkWDfxOU_3iYGpbmGeSZzgig4i0kOxo8egUWek=.7d1e8d37-500b-4114-8082-69ad9a597acf@github.com>
References: <MNt2HdkWDfxOU_3iYGpbmGeSZzgig4i0kOxo8egUWek=.7d1e8d37-500b-4114-8082-69ad9a597acf@github.com>
Message-ID: <bEO6Eh3Ou6CmXIh7ycrr8ZcZFWwO9zSJJHnqUKPmiJ4=.1b5eb36c-2c6a-4f05-a59d-1373c1e95694@github.com>

> 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: <BkmEJhFgOdiysm8JWXgKTAM-6ACipCkrU0wU04YgpBc=.48cba020-4195-4b33-80b0-85f5a919e200@github.com>
References: <MNt2HdkWDfxOU_3iYGpbmGeSZzgig4i0kOxo8egUWek=.7d1e8d37-500b-4114-8082-69ad9a597acf@github.com>
 <BkmEJhFgOdiysm8JWXgKTAM-6ACipCkrU0wU04YgpBc=.48cba020-4195-4b33-80b0-85f5a919e200@github.com>
Message-ID: <pPtptMsLy2CqVVjZvMxMh6HkIF8WAyLjyMmBJ38eK_I=.3684026c-eef8-4416-b86c-fb902bfa9e8f@github.com>

On Mon, 22 Mar 2021 18:31:01 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> 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: <bEO6Eh3Ou6CmXIh7ycrr8ZcZFWwO9zSJJHnqUKPmiJ4=.1b5eb36c-2c6a-4f05-a59d-1373c1e95694@github.com>
References: <MNt2HdkWDfxOU_3iYGpbmGeSZzgig4i0kOxo8egUWek=.7d1e8d37-500b-4114-8082-69ad9a597acf@github.com>
 <bEO6Eh3Ou6CmXIh7ycrr8ZcZFWwO9zSJJHnqUKPmiJ4=.1b5eb36c-2c6a-4f05-a59d-1373c1e95694@github.com>
Message-ID: <81T9SO6edqkmA5vDJPJWupRzHTU5g0eNlRAbebyGENo=.b17fc75b-8d08-4d0e-a106-77ec3cb95afc@github.com>

On Mon, 22 Mar 2021 19:06:00 GMT, Aleksey Shipilev <shade at openjdk.org> 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: <bEO6Eh3Ou6CmXIh7ycrr8ZcZFWwO9zSJJHnqUKPmiJ4=.1b5eb36c-2c6a-4f05-a59d-1373c1e95694@github.com>
References: <MNt2HdkWDfxOU_3iYGpbmGeSZzgig4i0kOxo8egUWek=.7d1e8d37-500b-4114-8082-69ad9a597acf@github.com>
 <bEO6Eh3Ou6CmXIh7ycrr8ZcZFWwO9zSJJHnqUKPmiJ4=.1b5eb36c-2c6a-4f05-a59d-1373c1e95694@github.com>
Message-ID: <9CxHNdzqaGrf-9eCLrCWuZviT46oNl0E1aLFmPwoRUg=.90bd8475-01d7-4ad9-b150-38ab2f449039@github.com>

On Mon, 22 Mar 2021 19:06:00 GMT, Aleksey Shipilev <shade at openjdk.org> 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: <MNt2HdkWDfxOU_3iYGpbmGeSZzgig4i0kOxo8egUWek=.7d1e8d37-500b-4114-8082-69ad9a597acf@github.com>
References: <MNt2HdkWDfxOU_3iYGpbmGeSZzgig4i0kOxo8egUWek=.7d1e8d37-500b-4114-8082-69ad9a597acf@github.com>
Message-ID: <RjkHK36Dq2SjAUcA2_h-4uh-Z5UJXSS7CqzuixgB7GM=.5268319a-5e0d-4a11-b2de-b9b35fc3d293@github.com>

On Mon, 22 Mar 2021 18:19:39 GMT, Aleksey Shipilev <shade at openjdk.org> 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 <shade at openjdk.org>
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: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
References: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
Message-ID: <meFutvzak1vZH5GImfEtLovcxXS5VuWAZYoXf-KoHxw=.c1c21965-9039-4b65-9a12-663d2123d23f@github.com>

> 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: <Zp7LEfXjLQTrTgi7eP1DShVrdoafpYNr1_kJfxEgssY=.d59db3e7-770d-4a04-9469-2f632af562be@github.com>
References: <Zp7LEfXjLQTrTgi7eP1DShVrdoafpYNr1_kJfxEgssY=.d59db3e7-770d-4a04-9469-2f632af562be@github.com>
Message-ID: <MaKnpp2gEpy_bFQWZdRVjo30OZUrFZklmitacsPfRTo=.c73febb6-b690-4d20-b4d2-5986ea19138d@github.com>

On Fri, 5 Mar 2021 21:44:20 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a moderately simple fix to improve DocLint's checking for empty tags, and in particular, bad use of `<p>` 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 `<p>` 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 <jjg at openjdk.org>
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: <Zp7LEfXjLQTrTgi7eP1DShVrdoafpYNr1_kJfxEgssY=.d59db3e7-770d-4a04-9469-2f632af562be@github.com>
References: <Zp7LEfXjLQTrTgi7eP1DShVrdoafpYNr1_kJfxEgssY=.d59db3e7-770d-4a04-9469-2f632af562be@github.com>
Message-ID: <YxReykJmZ5ij7WoA3udbUdENRwVKGlvPE074Bf3vLas=.15e0cd64-f70c-4afc-858d-ee1de781cae7@github.com>

> Please review a moderately simple fix to improve DocLint's checking for empty tags, and in particular, bad use of `<p>` 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 `<p>` 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: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
References: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
Message-ID: <p-_HnI7N66Tgv3ksgxXBfa7uSaj9VBe-3eQYSIpNep8=.10b43b7a-6a14-488a-9b98-95afa10846a7@github.com>

On Fri, 26 Feb 2021 17:03:11 GMT, Jaikiran Pai <jpai at openjdk.org> 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: <p-_HnI7N66Tgv3ksgxXBfa7uSaj9VBe-3eQYSIpNep8=.10b43b7a-6a14-488a-9b98-95afa10846a7@github.com>
References: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
 <p-_HnI7N66Tgv3ksgxXBfa7uSaj9VBe-3eQYSIpNep8=.10b43b7a-6a14-488a-9b98-95afa10846a7@github.com>
Message-ID: <1C26247B-1293-424F-AED8-4EDB4B957349@oracle.com>



On Mar 27, 2021, at 12:05 PM, Alan Bateman <alanb at openjdk.java.net<mailto:alanb at openjdk.java.net>> wrote:

On Fri, 26 Feb 2021 17:03:11 GMT, Jaikiran Pai <jpai at openjdk.org<mailto:jpai at openjdk.org>> 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<mailto:Lance.Andersen at oracle.com>



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20210327/8f3af85f/attachment-0001.htm>
-------------- 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: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20210327/8f3af85f/oracle_sig_logo-0001.gif>

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: <b10be763-cf85-a144-87bb-0653f3a0a1ec@gmail.com>
References: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
 <1BB8805F-174A-4EB9-B26A-060B2251A40C@oracle.com>
 <e88d6a73-f126-6848-45a2-3960d9726de8@oracle.com>
 <6242cfe8-cef7-0603-33fc-b3428209a1ac@gmail.com>
 <C1A35D8F-B1D3-4233-AE2F-1D699BF74B65@oracle.com>
 <ab9bcc11-1f1b-b82e-2dfe-ae17ea630d7f@gmail.com>
 <F7E99E98-2000-4ACD-B3A9-CEBE4903D26D@oracle.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>
 <b10be763-cf85-a144-87bb-0653f3a0a1ec@gmail.com>
Message-ID: <e24c6f02-2672-4dfa-e699-c8a34cb617f9@gmail.com>

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: <EDJdI4MRZtGY1p2bcG6v6m-j_KewSBJV7JHRIaAhhJ4=.6f0a7b4e-7e26-43e8-903b-4d4986aad152@github.com>

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: <e24c6f02-2672-4dfa-e699-c8a34cb617f9@gmail.com>
References: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
 <1BB8805F-174A-4EB9-B26A-060B2251A40C@oracle.com>
 <e88d6a73-f126-6848-45a2-3960d9726de8@oracle.com>
 <6242cfe8-cef7-0603-33fc-b3428209a1ac@gmail.com>
 <C1A35D8F-B1D3-4233-AE2F-1D699BF74B65@oracle.com>
 <ab9bcc11-1f1b-b82e-2dfe-ae17ea630d7f@gmail.com>
 <F7E99E98-2000-4ACD-B3A9-CEBE4903D26D@oracle.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>
 <b10be763-cf85-a144-87bb-0653f3a0a1ec@gmail.com>
 <e24c6f02-2672-4dfa-e699-c8a34cb617f9@gmail.com>
Message-ID: <BAA7024A-3C04-4F8C-A5A5-B9CD1B361C41@oracle.com>



On Mar 28, 2021, at 9:24 AM, Jaikiran Pai <jai.forums2013 at gmail.com<mailto:jai.forums2013 at gmail.com>> 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<mailto:Lance.Andersen at oracle.com>



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20210328/12bdedc7/attachment-0001.htm>
-------------- 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: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20210328/12bdedc7/oracle_sig_logo-0001.gif>

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: <BAA7024A-3C04-4F8C-A5A5-B9CD1B361C41@oracle.com>
References: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
 <1BB8805F-174A-4EB9-B26A-060B2251A40C@oracle.com>
 <e88d6a73-f126-6848-45a2-3960d9726de8@oracle.com>
 <6242cfe8-cef7-0603-33fc-b3428209a1ac@gmail.com>
 <C1A35D8F-B1D3-4233-AE2F-1D699BF74B65@oracle.com>
 <ab9bcc11-1f1b-b82e-2dfe-ae17ea630d7f@gmail.com>
 <F7E99E98-2000-4ACD-B3A9-CEBE4903D26D@oracle.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>
 <b10be763-cf85-a144-87bb-0653f3a0a1ec@gmail.com>
 <e24c6f02-2672-4dfa-e699-c8a34cb617f9@gmail.com>
 <BAA7024A-3C04-4F8C-A5A5-B9CD1B361C41@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 <jai.forums2013 at gmail.com 
>> <mailto:jai.forums2013 at gmail.com>> 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: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20210329/5dfc1e5e/attachment.htm>

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: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
References: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
Message-ID: <wJWTT4pJBi4VAIR8MpsVhzm_9iy42ehwzec9JxHXHsc=.5b981f07-a864-4f53-baa4-00df1116c73a@github.com>

> 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: <SDZpx2KGw9fZcD5wSksgQ0A4EGJsyXdtUAiWUqRvN44=.6dd1e8d3-1c84-40e0-b873-ffb3e5d326af@github.com>

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: <SDZpx2KGw9fZcD5wSksgQ0A4EGJsyXdtUAiWUqRvN44=.6dd1e8d3-1c84-40e0-b873-ffb3e5d326af@github.com>
References: <SDZpx2KGw9fZcD5wSksgQ0A4EGJsyXdtUAiWUqRvN44=.6dd1e8d3-1c84-40e0-b873-ffb3e5d326af@github.com>
Message-ID: <6OMPZyYBcENA0hYJp2fEMiwyhvAIT7cXwPoMVQ0TIUc=.65348cfa-1afe-4a3d-8d18-002f2be28d7d@github.com>

On Wed, 24 Mar 2021 23:17:46 GMT, Joe Darcy <darcy at openjdk.org> 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: <SDZpx2KGw9fZcD5wSksgQ0A4EGJsyXdtUAiWUqRvN44=.6dd1e8d3-1c84-40e0-b873-ffb3e5d326af@github.com>
 <6OMPZyYBcENA0hYJp2fEMiwyhvAIT7cXwPoMVQ0TIUc=.65348cfa-1afe-4a3d-8d18-002f2be28d7d@github.com>
Message-ID: <YGY3e5JZUid7DXjezumgNg-peG8xsYydHM1F_ZVbZ7o=.f2c5de76-0340-43aa-9698-dec84018dc6a@github.com>

On Thu, 25 Mar 2021 18:52:54 GMT, Stuart Marks <smarks at openjdk.org> 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: <SDZpx2KGw9fZcD5wSksgQ0A4EGJsyXdtUAiWUqRvN44=.6dd1e8d3-1c84-40e0-b873-ffb3e5d326af@github.com>
 <6OMPZyYBcENA0hYJp2fEMiwyhvAIT7cXwPoMVQ0TIUc=.65348cfa-1afe-4a3d-8d18-002f2be28d7d@github.com>
Message-ID: <dGNio-0tGjN8jEVGIMK8y212esY7r1g9L8CjyJYbcDE=.a43a1fd2-9dba-4971-96c1-d84a716f746a@github.com>

On Thu, 25 Mar 2021 18:52:54 GMT, Stuart Marks <smarks at openjdk.org> 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: <UydoIlgIn3ktldbgbS8eJgE5jK_4dqSMJWY2AsdXwf0=.8ee46224-d981-478a-bccb-319446f65c83@github.com>

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: <UydoIlgIn3ktldbgbS8eJgE5jK_4dqSMJWY2AsdXwf0=.8ee46224-d981-478a-bccb-319446f65c83@github.com>
References: <UydoIlgIn3ktldbgbS8eJgE5jK_4dqSMJWY2AsdXwf0=.8ee46224-d981-478a-bccb-319446f65c83@github.com>
Message-ID: <GLLO5mc-7mSiNPMKDnT4n6OtW9X9V_KONXsYcr6OZS4=.74f58b1e-f2c2-4910-a902-76716ce09a8f@github.com>

On Tue, 30 Mar 2021 06:19:22 GMT, Jan Lahoda <jlahoda at openjdk.org> 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: <UydoIlgIn3ktldbgbS8eJgE5jK_4dqSMJWY2AsdXwf0=.8ee46224-d981-478a-bccb-319446f65c83@github.com>
References: <UydoIlgIn3ktldbgbS8eJgE5jK_4dqSMJWY2AsdXwf0=.8ee46224-d981-478a-bccb-319446f65c83@github.com>
Message-ID: <sd4jzkwoFNQFw7qI2D9QxtWoZmJzh9TR5b7GZDv-muU=.cceea0b0-f17d-437b-be7d-585fd0ae7fb4@github.com>

On Tue, 30 Mar 2021 06:19:22 GMT, Jan Lahoda <jlahoda at openjdk.org> 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: <SDZpx2KGw9fZcD5wSksgQ0A4EGJsyXdtUAiWUqRvN44=.6dd1e8d3-1c84-40e0-b873-ffb3e5d326af@github.com>
References: <SDZpx2KGw9fZcD5wSksgQ0A4EGJsyXdtUAiWUqRvN44=.6dd1e8d3-1c84-40e0-b873-ffb3e5d326af@github.com>
Message-ID: <-rMQxHXFk7yEM-DmoZOmE9eePkkvaklW5YyWhsJEek4=.8456ad76-b965-4098-a66b-1e80f396cf7c@github.com>

On Wed, 24 Mar 2021 23:17:46 GMT, Joe Darcy <darcy at openjdk.org> 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: <SDZpx2KGw9fZcD5wSksgQ0A4EGJsyXdtUAiWUqRvN44=.6dd1e8d3-1c84-40e0-b873-ffb3e5d326af@github.com>
References: <SDZpx2KGw9fZcD5wSksgQ0A4EGJsyXdtUAiWUqRvN44=.6dd1e8d3-1c84-40e0-b873-ffb3e5d326af@github.com>
Message-ID: <k1pS0P2Zl6vFFpNo2Fq30IZYZjel2QSHPDAqPZFlFik=.c94d3533-7b16-42ec-b803-d4725851de35@github.com>

On Wed, 24 Mar 2021 23:17:46 GMT, Joe Darcy <darcy at openjdk.org> 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: <k1pS0P2Zl6vFFpNo2Fq30IZYZjel2QSHPDAqPZFlFik=.c94d3533-7b16-42ec-b803-d4725851de35@github.com>
References: <SDZpx2KGw9fZcD5wSksgQ0A4EGJsyXdtUAiWUqRvN44=.6dd1e8d3-1c84-40e0-b873-ffb3e5d326af@github.com>
 <k1pS0P2Zl6vFFpNo2Fq30IZYZjel2QSHPDAqPZFlFik=.c94d3533-7b16-42ec-b803-d4725851de35@github.com>
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 <darcy at openjdk.org> 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: <SDZpx2KGw9fZcD5wSksgQ0A4EGJsyXdtUAiWUqRvN44=.6dd1e8d3-1c84-40e0-b873-ffb3e5d326af@github.com>
 <-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 <darcy at openjdk.org> 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: <J355B6uV8DqWLzGyKNxsLu5hv6N4BRK3V1qJHtVydes=.c285eff5-490f-47c8-999c-7634dd86fac7@github.com>

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: <SDZpx2KGw9fZcD5wSksgQ0A4EGJsyXdtUAiWUqRvN44=.6dd1e8d3-1c84-40e0-b873-ffb3e5d326af@github.com>
References: <SDZpx2KGw9fZcD5wSksgQ0A4EGJsyXdtUAiWUqRvN44=.6dd1e8d3-1c84-40e0-b873-ffb3e5d326af@github.com>
Message-ID: <XaOfh6DMc2x_a0qsP15eZNL4BNIlr5sZdA5in2dfBVo=.ae0724db-ccc6-4f84-ab43-d698b3042113@github.com>

On Wed, 24 Mar 2021 23:17:46 GMT, Joe Darcy <darcy at openjdk.org> 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: <SDZpx2KGw9fZcD5wSksgQ0A4EGJsyXdtUAiWUqRvN44=.6dd1e8d3-1c84-40e0-b873-ffb3e5d326af@github.com>
References: <SDZpx2KGw9fZcD5wSksgQ0A4EGJsyXdtUAiWUqRvN44=.6dd1e8d3-1c84-40e0-b873-ffb3e5d326af@github.com>
Message-ID: <DLYKwabnY95L4xZ2RniMmrgFe7bbxZx5oq6uzIP-wvE=.8605c32a-3628-444e-bc16-8546bfaa87c1@github.com>

On Wed, 24 Mar 2021 23:17:46 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> 8264148: Update spec for exceptions retrofitted for exception chaining

This pull request has now been integrated.

Changeset: 815248ab
Author:    Joe Darcy <darcy at openjdk.org>
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: <EDJdI4MRZtGY1p2bcG6v6m-j_KewSBJV7JHRIaAhhJ4=.6f0a7b4e-7e26-43e8-903b-4d4986aad152@github.com>
References: <EDJdI4MRZtGY1p2bcG6v6m-j_KewSBJV7JHRIaAhhJ4=.6f0a7b4e-7e26-43e8-903b-4d4986aad152@github.com>
Message-ID: <XgfNHI3IDzOtsbSM3aLxuH_clUUyZd5s3ScW1BvfWD4=.219ca8fb-c07c-4939-8df6-307b774b45d4@github.com>

On Sun, 28 Mar 2021 13:55:30 GMT, Alex Blewitt <github.com+76791+alblue at openjdk.org> 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: <EDJdI4MRZtGY1p2bcG6v6m-j_KewSBJV7JHRIaAhhJ4=.6f0a7b4e-7e26-43e8-903b-4d4986aad152@github.com>
References: <EDJdI4MRZtGY1p2bcG6v6m-j_KewSBJV7JHRIaAhhJ4=.6f0a7b4e-7e26-43e8-903b-4d4986aad152@github.com>
Message-ID: <7TUHVI-PsuCR_EEf0ntn7RaegiTZWNqc5TmwO6fomHc=.75fed414-7a85-4f11-b03f-96cfff9912fa@github.com>

On Sun, 28 Mar 2021 13:55:30 GMT, Alex Blewitt <github.com+76791+alblue at openjdk.org> 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: <p-_HnI7N66Tgv3ksgxXBfa7uSaj9VBe-3eQYSIpNep8=.10b43b7a-6a14-488a-9b98-95afa10846a7@github.com>
References: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
 <p-_HnI7N66Tgv3ksgxXBfa7uSaj9VBe-3eQYSIpNep8=.10b43b7a-6a14-488a-9b98-95afa10846a7@github.com>
Message-ID: <Lnpf7HVinfNW1KkmTzDhO4CsYIhmYjHeU-oX5RRS5Bc=.48ac3f40-0359-4d56-9252-f5460687e5c9@github.com>

On Sat, 27 Mar 2021 16:02:55 GMT, Alan Bateman <alanb at openjdk.org> 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: <wJWTT4pJBi4VAIR8MpsVhzm_9iy42ehwzec9JxHXHsc=.5b981f07-a864-4f53-baa4-00df1116c73a@github.com>
References: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
 <wJWTT4pJBi4VAIR8MpsVhzm_9iy42ehwzec9JxHXHsc=.5b981f07-a864-4f53-baa4-00df1116c73a@github.com>
Message-ID: <dMjYy1GsCRKWd1GE9BIIkE7OJDU0Cazk3q8bld_oXCw=.9e1e85e0-7753-4fab-8c32-4f9e8665a0c4@github.com>

On Mon, 29 Mar 2021 14:04:10 GMT, Jaikiran Pai <jpai at openjdk.org> 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<Path> 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: <EDJdI4MRZtGY1p2bcG6v6m-j_KewSBJV7JHRIaAhhJ4=.6f0a7b4e-7e26-43e8-903b-4d4986aad152@github.com>
References: <EDJdI4MRZtGY1p2bcG6v6m-j_KewSBJV7JHRIaAhhJ4=.6f0a7b4e-7e26-43e8-903b-4d4986aad152@github.com>
Message-ID: <UIhpQit5wj2OAhFrgPLzFJ-RNZwb4N0g_szwjO8kD7k=.3a60c70e-513f-418f-ae3d-f8c6dd4ddec7@github.com>

On Sun, 28 Mar 2021 13:55:30 GMT, Alex Blewitt <github.com+76791+alblue at openjdk.org> 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: <wJWTT4pJBi4VAIR8MpsVhzm_9iy42ehwzec9JxHXHsc=.5b981f07-a864-4f53-baa4-00df1116c73a@github.com>
References: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
 <wJWTT4pJBi4VAIR8MpsVhzm_9iy42ehwzec9JxHXHsc=.5b981f07-a864-4f53-baa4-00df1116c73a@github.com>
Message-ID: <UX_PIU0pgWPZnI_jsSBiE6w-D5KD0PQGSOORZKtRzQY=.d126b8fc-0658-4adc-b6cc-bb57e9d054ca@github.com>

On Mon, 29 Mar 2021 14:04:10 GMT, Jaikiran Pai <jpai at openjdk.org> 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