Re: JEP 416: Missing throws IllegalArgumentException declaration for Method::invoke?

2021-11-11 Thread Marc Hoffmann
Dear Alan,

no issue at all, I just noticed in the API diff and wanted to understand 
whether this was on purpose. Also 

Thanks for the background information!
-marc

> On 11. Nov 2021, at 09:48, Alan Bateman  wrote:
> 
> On 11/11/2021 08:21, Marc Hoffmann wrote:
>> Hi,
>> 
>> with the implementation of JEP 416 
>> (https://github.com/openjdk/jdk/commit/c6339cb8a255d387bb182ad20dd69f3d460cf1ed
>>  
>> )
>>  the throws declaration for IllegalArgumentException on Method::invoke was 
>> removed — while it is still described in JavaDoc. Was this on purpose?
>> 
>> Sorry if this was discussed before, but I was not able to find a review 
>> discussion around this commit. Also I’m not sure what the policy is whether 
>> unchecked exceptions should be declared if mentioned in JavaDoc.
> 
> Usually the method throws clause just lists the checked exceptions but there 
> cases where the source code (esp. older code) does declare that it throws 
> IllegalArgumentException, SecurityException or other unchecked exceptions. 
> All exceptions should of course be @throws documented in the method 
> description. In this case, I think it's just cleanup, the method continues to 
> document that it may throw IllegalArgumentException.
> 
> Are you running into an issue or is this just showing up with API diffs?  
> There shouldn't be a compatibility issue but maybe there is something looking 
> at the method Exceptions table that expects to see unchecked exceptions?
> 
> -Alan
> 
> 
> 



Integrated: 8275197: Remove unused fields in ThaiBuddhistChronology

2021-11-11 Thread Andrey Turbanov
On Tue, 12 Oct 2021 21:10:12 GMT, Andrey Turbanov  wrote:

> Remove 3 unused HashMap's.
> Reported here 
> https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-September/081866.html
> I did the similar PR to treetenbp and it was merged 
> https://github.com/ThreeTen/threetenbp/pull/155

This pull request has now been integrated.

Changeset: 1e941ded
Author:Andrey Turbanov 
Committer: Roger Riggs 
URL:   
https://git.openjdk.java.net/jdk/commit/1e941dedad0ff6282ca4c1d2d71512974c97fc5e
Stats: 37 lines in 1 file changed: 0 ins; 36 del; 1 mod

8275197: Remove unused fields in ThaiBuddhistChronology

Reviewed-by: naoto, rriggs, iris

-

PR: https://git.openjdk.java.net/jdk/pull/5917


Re: RFR: 8277015: Use blessed modifier order in Panama code

2021-11-11 Thread Paul Sandoz
On Thu, 11 Nov 2021 15:47:11 GMT, Maurizio Cimadamore  
wrote:

>> I ran bin/blessed-modifier-order.sh on source owned by Project Panama. This 
>> scripts verifies that modifiers are in the "blessed" order, and fixes it 
>> otherwise. I have manually checked the changes made by the script to make 
>> sure they are sound.
>> 
>> In this case, while the script did into the "correct" thing, it turns out 
>> that the method signatures in 
>> `src/jdk.incubator.vector/share/classes/jdk/incubator/vector` has some room 
>> for improvement... The files contains method headers which look like this:
>> 
>> 
>> final @Override
>> @ForceInline
>> long longToElementBits(...
>> 
>> @ForceInline
>> static long toIntegralChecked(...
>> 
>> @ForceInline
>> @Override final
>> ByteVector dummyVector(...
>> 
>> 
>> My personal opinion is that these should have been written like this:
>> 
>> 
>> @Override
>> @ForceInline
>> final long longToElementBits(...
>> 
>> @ForceInline
>> static long toIntegralChecked(...
>> 
>> @ForceInline
>> @Override
>> final ByteVector dummyVector(...
>> 
>> 
>> or possibly
>> 
>> 
>> 
>> @Override @ForceInline
>> final long longToElementBits(...
>> 
>> @ForceInline
>> static long toIntegralChecked(...
>> 
>> @ForceInline @Override
>> final ByteVector dummyVector(...
>> 
>> 
>> If you want me to make that change as well as part of the fix, let me know.
>> 
>> Furthermore, I don't know how much the code in mainline differs from the 
>> code in the Panama branches. If the discrepancy is large, you might want to 
>> run `bash bin/blessed-modifier-order.sh src/jdk.incubator.vector` and  `bash 
>> bin/blessed-modifier-order.sh src/jdk.incubator.foreign` in those branches.
>
> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteVector.java 
> line 3908:
> 
>> 3906: 
>> 3907: @ForceInline
>> 3908: @Override public
> 
> `public` should probably go on a different line? (same as for the ones that 
> follow)

Note these files are generated from a template `X-Vector.java.template` and the 
script `gen-src.sh` (not yet integrated into the build system). So the template 
requires updating, from which the script is run to generate the source. We can 
do this after integration of https://github.com/openjdk/jdk/pull/5873/

-

PR: https://git.openjdk.java.net/jdk/pull/6355


Re: RFR: 8271515: Integration of JEP 417: Vector API (Third Incubator) [v10]

2021-11-11 Thread Paul Sandoz
> This PR improves the performance of vector operations that accept masks on 
> architectures that support masking in hardware, specifically Intel AVX512 and 
> ARM SVE.
> 
> On architectures that do not support masking in hardware the same technique 
> as before is applied to most operations, specifically composition using blend.
> 
> Masked loads/stores are a special form of masked operation that require 
> additional care to ensure out-of-bounds access throw exceptions. The range 
> checking has not been fully optimized and will require further work.
> 
> No API enhancements were required and only a few additional tests were needed.

Paul Sandoz has updated the pull request with a new target base due to a merge 
or a rebase. The pull request now contains 16 commits:

 - Merge branch 'master' into JDK-8271515-vector-api
 - Add missing null check post mask unboxing.
 - Merge pull request #2 from nsjian/vector-conversion-fix
   
   AArch64: Incorrect SVE double to int and float to long vector conversion
 - Incorrect double to int and float to long vector conversion
   
   Like JDK-8276151, SVE vector double to int and float to long
   conversions have similar issue. According to Java language
   specification [1], we should convert double/float to
   integer/long directly, instead of converting to long/int and then
   narrowing/extending to target types. Test cases will be updated in
   JDK-8276151.
   
   [1] https://docs.oracle.com/javase/specs/jls/se17/html/jls-5.html#jls-5.1.3
 - Merge branch 'master' into JDK-8271515-vector-api
 - Merge pull request #1 from nsjian/JDK-8271515
   
   Address AArch64 review comments from Nick.
 - Address review comments from Nick.
 - Merge branch 'master' into JDK-8271515-vector-api
 - Resolve review comments.
 - Merge branch 'master' into JDK-8271515-vector-api
 - ... and 6 more: https://git.openjdk.java.net/jdk/compare/6f35eede...44697f8b

-

Changes: https://git.openjdk.java.net/jdk/pull/5873/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=5873=09
  Stats: 21982 lines in 104 files changed: 16217 ins; 2087 del; 3678 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5873.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5873/head:pull/5873

PR: https://git.openjdk.java.net/jdk/pull/5873


Re: RFR: 8277015: Use blessed modifier order in Panama code

2021-11-11 Thread Paul Sandoz
On Thu, 11 Nov 2021 14:50:43 GMT, Magnus Ihse Bursie  wrote:

> I ran bin/blessed-modifier-order.sh on source owned by Project Panama. This 
> scripts verifies that modifiers are in the "blessed" order, and fixes it 
> otherwise. I have manually checked the changes made by the script to make 
> sure they are sound.
> 
> In this case, while the script did into the "correct" thing, it turns out 
> that the method signatures in 
> `src/jdk.incubator.vector/share/classes/jdk/incubator/vector` has some room 
> for improvement... The files contains method headers which look like this:
> 
> 
> final @Override
> @ForceInline
> long longToElementBits(...
> 
> @ForceInline
> static long toIntegralChecked(...
> 
> @ForceInline
> @Override final
> ByteVector dummyVector(...
> 
> 
> My personal opinion is that these should have been written like this:
> 
> 
> @Override
> @ForceInline
> final long longToElementBits(...
> 
> @ForceInline
> static long toIntegralChecked(...
> 
> @ForceInline
> @Override
> final ByteVector dummyVector(...
> 
> 
> or possibly
> 
> 
> 
> @Override @ForceInline
> final long longToElementBits(...
> 
> @ForceInline
> static long toIntegralChecked(...
> 
> @ForceInline @Override
> final ByteVector dummyVector(...
> 
> 
> If you want me to make that change as well as part of the fix, let me know.
> 
> Furthermore, I don't know how much the code in mainline differs from the code 
> in the Panama branches. If the discrepancy is large, you might want to run 
> `bash bin/blessed-modifier-order.sh src/jdk.incubator.vector` and  `bash 
> bin/blessed-modifier-order.sh src/jdk.incubator.foreign` in those branches.

I would prefer to leave the Vector API PR as is, we are getting close to 
integration, and apply such changes after integration as a separate commit on 
the mainline.

-

PR: https://git.openjdk.java.net/jdk/pull/6355


Re: RFR: 8277015: Use blessed modifier order in Panama code

2021-11-11 Thread Maurizio Cimadamore
On Thu, 11 Nov 2021 20:22:25 GMT, Magnus Ihse Bursie  wrote:

> You could also do this directly in the Panama repo branches. I'll volunteer 
> to help, if you want.

I'll run the script on the PR I've submitted for the Foreign API, and I will 
update that one - thanks. Perhaps @PaulSandoz can do the same for the Vector 
API refresh?

-

PR: https://git.openjdk.java.net/jdk/pull/6355


Integrated: 8276947: Clarify how DateTimeFormatterBuilder.appendFraction handles value ranges

2021-11-11 Thread Claes Redestad
On Wed, 10 Nov 2021 13:57:21 GMT, Claes Redestad  wrote:

> This changes the specification of `DateTimeFormatterBuilder.appendFraction` 
> to more clearly specify that the formatter will throw an exception if you 
> attempt to print a value outside of the value range of the given field. 
> Changes suggested by @jodastephen in #6188.

This pull request has now been integrated.

Changeset: 0ca0acf6
Author:Claes Redestad 
URL:   
https://git.openjdk.java.net/jdk/commit/0ca0acf63cb5cec4c62a9948956a04822d6f74a5
Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8276947: Clarify how DateTimeFormatterBuilder.appendFraction handles value 
ranges

Reviewed-by: rriggs, naoto

-

PR: https://git.openjdk.java.net/jdk/pull/6335


Re: RFR: 8276947: Clarify how DateTimeFormatterBuilder.appendFraction handles value ranges

2021-11-11 Thread Claes Redestad
On Wed, 10 Nov 2021 13:57:21 GMT, Claes Redestad  wrote:

> This changes the specification of `DateTimeFormatterBuilder.appendFraction` 
> to more clearly specify that the formatter will throw an exception if you 
> attempt to print a value outside of the value range of the given field. 
> Changes suggested by @jodastephen in #6188.

Thanks Roger and Naoto. CSR has been filed and approved.

-

PR: https://git.openjdk.java.net/jdk/pull/6335


Re: RFR: 8276123: ZipFile::getEntry will not return a file entry when there is a directory entry of the same name within a Zip File [v2]

2021-11-11 Thread Claes Redestad
On Thu, 11 Nov 2021 17:19:04 GMT, Lance Andersen  wrote:

>> Hi all,
>> 
>> This patch addresses a regression introduced in JDK 15 via JDK-8242959 where 
>> you can no longer access a file entry contained within a Zip file when there 
>> is also a directory entry with the same name via ZipFile:getEntry(). 
>> 
>>  Once fixed, the behavior will be consistent with earlier JDK releases. 
>> 
>> Mach5 tiers 1-3 have been run without failure
>> 
>> Best
>> Lance
>
> Lance Andersen has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Address minor review comments

Marked as reviewed by redestad (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/6342


Re: RFR: 8277015: Use blessed modifier order in Panama code

2021-11-11 Thread Magnus Ihse Bursie
On Thu, 11 Nov 2021 14:50:43 GMT, Magnus Ihse Bursie  wrote:

> I ran bin/blessed-modifier-order.sh on source owned by Project Panama. This 
> scripts verifies that modifiers are in the "blessed" order, and fixes it 
> otherwise. I have manually checked the changes made by the script to make 
> sure they are sound.
> 
> In this case, while the script did into the "correct" thing, it turns out 
> that the method signatures in 
> `src/jdk.incubator.vector/share/classes/jdk/incubator/vector` has some room 
> for improvement... The files contains method headers which look like this:
> 
> 
> final @Override
> @ForceInline
> long longToElementBits(...
> 
> @ForceInline
> static long toIntegralChecked(...
> 
> @ForceInline
> @Override final
> ByteVector dummyVector(...
> 
> 
> My personal opinion is that these should have been written like this:
> 
> 
> @Override
> @ForceInline
> final long longToElementBits(...
> 
> @ForceInline
> static long toIntegralChecked(...
> 
> @ForceInline
> @Override
> final ByteVector dummyVector(...
> 
> 
> or possibly
> 
> 
> 
> @Override @ForceInline
> final long longToElementBits(...
> 
> @ForceInline
> static long toIntegralChecked(...
> 
> @ForceInline @Override
> final ByteVector dummyVector(...
> 
> 
> If you want me to make that change as well as part of the fix, let me know.
> 
> Furthermore, I don't know how much the code in mainline differs from the code 
> in the Panama branches. If the discrepancy is large, you might want to run 
> `bash bin/blessed-modifier-order.sh src/jdk.incubator.vector` and  `bash 
> bin/blessed-modifier-order.sh src/jdk.incubator.foreign` in those branches.

You could also do this directly in the Panama repo branches. I'll volunteer to 
help, if you want.

-

PR: https://git.openjdk.java.net/jdk/pull/6355


Re: RFR: 8277013: Allow creation of module graphs without defining modules to the VM

2021-11-11 Thread Alan Bateman
On Thu, 11 Nov 2021 14:53:13 GMT, Ivan Ristović  wrote:

> Related JBS issue: https://bugs.openjdk.java.net/browse/JDK-8277013
> 
> The GraalVM Native Image module support must create the runtime boot-module 
> layer at image build time; module instances created at build time need to 
> reflect module relations at runtime, i.e., their opens, reads, and exports. 
> To achieve this, we had to duplicate and modify a significant portion of the 
> module synthesis methods from the JDK. The GraalVM PR that demonstrates this 
> duplication can be found at:
>   
> ​https://github.com/oracle/graal/blob/9bfa3a312d7d0309eb014d52e49afd7136d9e77e/substratevm/src/com.oracle.svm.hosted.jdk11/src/com/oracle/svm/hosted/ModuleLayerFeature.java#L269
> 
> The hard-to-maintain code duplication is necessary as synthesizing module 
> graphs in the JDK unconditionally defines modules to the VM which causes an 
> error due to module redefinition. For example, methods `System.defineModule`, 
> `ModuleLayer` factories and constructor, and `Module` constructor 
> unconditionally update the VM state. All these methods eventually reach the 
> `Module` constructor or the `Modules.defineModules` method.
> 
> We propose that the `Module` constructor and the `Modules.defineModules` 
> conditionally update the VM state (similarly to 'Module.implAddReads`). The 
> JDK would call these methods so they update the VM state and GraalVM Native 
> Image would call them without updating the state.

GraalVM native image is a really interesting PoC but not clear to me that the 
JDK should be adding non-public constructors for code outside of the JDK to 
call.

If we do need to do something here then it will require cleanup so that it is 
consistent with the existing code.

-

Changes requested by alanb (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6356


RFR: 8277013: Allow creation of module graphs without defining modules to the VM

2021-11-11 Thread Ivan Ristović
Related JBS issue: https://bugs.openjdk.java.net/browse/JDK-8277013

The GraalVM Native Image module support must create the runtime boot-module 
layer at image build time; module instances created at build time need to 
reflect module relations at runtime, i.e., their opens, reads, and exports. To 
achieve this, we had to duplicate and modify a significant portion of the 
module synthesis methods from the JDK. The GraalVM PR that demonstrates this 
duplication can be found at:
  
​https://github.com/oracle/graal/blob/9bfa3a312d7d0309eb014d52e49afd7136d9e77e/substratevm/src/com.oracle.svm.hosted.jdk11/src/com/oracle/svm/hosted/ModuleLayerFeature.java#L269

The hard-to-maintain code duplication is necessary as synthesizing module 
graphs in the JDK unconditionally defines modules to the VM which causes an 
error due to module redefinition. For example, methods `System.defineModule`, 
`ModuleLayer` factories and constructor, and `Module` constructor 
unconditionally update the VM state. All these methods eventually reach the 
`Module` constructor or the `Modules.defineModules` method.

We propose that the `Module` constructor and the `Modules.defineModules` 
conditionally update the VM state (similarly to 'Module.implAddReads`). The JDK 
would call these methods so they update the VM state and GraalVM Native Image 
would call them without updating the state.

-

Commit messages:
 - Update parameter names; Add constructor overload for backward compatibility
 - Enhance Module.defineModules to accept switches to update VM state

Changes: https://git.openjdk.java.net/jdk/pull/6356/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=6356=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8277013
  Stats: 52 lines in 1 file changed: 36 ins; 0 del; 16 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6356.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6356/head:pull/6356

PR: https://git.openjdk.java.net/jdk/pull/6356


Re: RFR: 8276123: ZipFile::getEntry will not return a file entry when there is a directory entry of the same name within a Zip File [v2]

2021-11-11 Thread Lance Andersen
On Thu, 11 Nov 2021 12:04:46 GMT, Alan Bateman  wrote:

>> Lance Andersen has updated the pull request incrementally with one 
>> additional commit since the last revision:
>> 
>>   Address minor review comments
>
> test/jdk/java/util/zip/ZipFile/ZipFileDuplicateEntryTest.java line 176:
> 
>> 174: zos.closeEntry();
>> 175: } catch (IOException e) {
>> 176: e.printStackTrace();
> 
> Did you mean to catch IOException here? If the setup fails then the test will 
> still run.

Removed the catch clause

-

PR: https://git.openjdk.java.net/jdk/pull/6342


Re: RFR: 8276123: ZipFile::getEntry will not return a file entry when there is a directory entry of the same name within a Zip File [v2]

2021-11-11 Thread Lance Andersen
On Thu, 11 Nov 2021 12:50:30 GMT, Claes Redestad  wrote:

>> Thank you for that clarification.  The "addSlash" param being "false" in the 
>> call below that comment is what made me think that the comment had a typo. I 
>> read that code in a bit more detail now and I see what that comment means. 
>> It essentially says that it's now issuing a call to find a entry position 
>> (if it exists) for the name ending with a "/" character.
>
> The comment is a bit too fuzzy. What's happening here is we searched for 
> `foo` and found a match for `foo/` - but we can't be sure there's no exact 
> entry `foo` later on in the hash bucket, so we (somewhat inefficiently) redo 
> the search for `foo` without the trailing slash parameter.
> 
> I suggest clarifying to something like this:
> ```  // name + "/" entry found, keep looking for and prefer an entry which 
> exactly matches name```

I just tweaked the comment slightly

-

PR: https://git.openjdk.java.net/jdk/pull/6342


Re: RFR: 8276123: ZipFile::getEntry will not return a file entry when there is a directory entry of the same name within a Zip File [v2]

2021-11-11 Thread Lance Andersen
> Hi all,
> 
> This patch addresses a regression introduced in JDK 15 via JDK-8242959 where 
> you can no longer access a file entry contained within a Zip file when there 
> is also a directory entry with the same name via ZipFile:getEntry(). 
> 
>  Once fixed, the behavior will be consistent with earlier JDK releases. 
> 
> Mach5 tiers 1-3 have been run without failure
> 
> Best
> Lance

Lance Andersen has updated the pull request incrementally with one additional 
commit since the last revision:

  Address minor review comments

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6342/files
  - new: https://git.openjdk.java.net/jdk/pull/6342/files/2d5e5913..93b46c66

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=6342=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=6342=00-01

  Stats: 5 lines in 2 files changed: 0 ins; 4 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6342.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6342/head:pull/6342

PR: https://git.openjdk.java.net/jdk/pull/6342


Re: RFR: 8271515: Integration of JEP 417: Vector API (Third Incubator) [v9]

2021-11-11 Thread Paul Sandoz
> This PR improves the performance of vector operations that accept masks on 
> architectures that support masking in hardware, specifically Intel AVX512 and 
> ARM SVE.
> 
> On architectures that do not support masking in hardware the same technique 
> as before is applied to most operations, specifically composition using blend.
> 
> Masked loads/stores are a special form of masked operation that require 
> additional care to ensure out-of-bounds access throw exceptions. The range 
> checking has not been fully optimized and will require further work.
> 
> No API enhancements were required and only a few additional tests were needed.

Paul Sandoz has updated the pull request incrementally with one additional 
commit since the last revision:

  Add missing null check post mask unboxing.

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5873/files
  - new: https://git.openjdk.java.net/jdk/pull/5873/files/571e6f39..11906870

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=5873=08
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=5873=07-08

  Stats: 8 lines in 1 file changed: 8 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5873.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5873/head:pull/5873

PR: https://git.openjdk.java.net/jdk/pull/5873


Re: RFR: 8277015: Use blessed modifier order in Panama code

2021-11-11 Thread Maurizio Cimadamore
On Thu, 11 Nov 2021 15:58:06 GMT, Magnus Ihse Bursie  wrote:

> This is by no means urgent. If it's more convenient for you to wait until 
> after the refresh, I can certainly do so.

I guess there is a chance that after vector and foreign are re-incubated in 18, 
we might need to do this again.

-

PR: https://git.openjdk.java.net/jdk/pull/6355


Re: RFR: 8277015: Use blessed modifier order in Panama code

2021-11-11 Thread Magnus Ihse Bursie
On Thu, 11 Nov 2021 14:50:43 GMT, Magnus Ihse Bursie  wrote:

> I ran bin/blessed-modifier-order.sh on source owned by Project Panama. This 
> scripts verifies that modifiers are in the "blessed" order, and fixes it 
> otherwise. I have manually checked the changes made by the script to make 
> sure they are sound.
> 
> In this case, while the script did into the "correct" thing, it turns out 
> that the method signatures in 
> `src/jdk.incubator.vector/share/classes/jdk/incubator/vector` has some room 
> for improvement... The files contains method headers which look like this:
> 
> 
> final @Override
> @ForceInline
> long longToElementBits(...
> 
> @ForceInline
> static long toIntegralChecked(...
> 
> @ForceInline
> @Override final
> ByteVector dummyVector(...
> 
> 
> My personal opinion is that these should have been written like this:
> 
> 
> @Override
> @ForceInline
> final long longToElementBits(...
> 
> @ForceInline
> static long toIntegralChecked(...
> 
> @ForceInline
> @Override
> final ByteVector dummyVector(...
> 
> 
> or possibly
> 
> 
> 
> @Override @ForceInline
> final long longToElementBits(...
> 
> @ForceInline
> static long toIntegralChecked(...
> 
> @ForceInline @Override
> final ByteVector dummyVector(...
> 
> 
> If you want me to make that change as well as part of the fix, let me know.
> 
> Furthermore, I don't know how much the code in mainline differs from the code 
> in the Panama branches. If the discrepancy is large, you might want to run 
> `bash bin/blessed-modifier-order.sh src/jdk.incubator.vector` and  `bash 
> bin/blessed-modifier-order.sh src/jdk.incubator.foreign` in those branches.

This is by no means urgent. If it's more convenient for you to wait until after 
the refresh, I can certainly do so.

-

PR: https://git.openjdk.java.net/jdk/pull/6355


Re: RFR: 8277015: Use blessed modifier order in Panama code

2021-11-11 Thread Maurizio Cimadamore
On Thu, 11 Nov 2021 14:50:43 GMT, Magnus Ihse Bursie  wrote:

> I ran bin/blessed-modifier-order.sh on source owned by Project Panama. This 
> scripts verifies that modifiers are in the "blessed" order, and fixes it 
> otherwise. I have manually checked the changes made by the script to make 
> sure they are sound.
> 
> In this case, while the script did into the "correct" thing, it turns out 
> that the method signatures in 
> `src/jdk.incubator.vector/share/classes/jdk/incubator/vector` has some room 
> for improvement... The files contains method headers which look like this:
> 
> 
> final @Override
> @ForceInline
> long longToElementBits(...
> 
> @ForceInline
> static long toIntegralChecked(...
> 
> @ForceInline
> @Override final
> ByteVector dummyVector(...
> 
> 
> My personal opinion is that these should have been written like this:
> 
> 
> @Override
> @ForceInline
> final long longToElementBits(...
> 
> @ForceInline
> static long toIntegralChecked(...
> 
> @ForceInline
> @Override
> final ByteVector dummyVector(...
> 
> 
> or possibly
> 
> 
> 
> @Override @ForceInline
> final long longToElementBits(...
> 
> @ForceInline
> static long toIntegralChecked(...
> 
> @ForceInline @Override
> final ByteVector dummyVector(...
> 
> 
> If you want me to make that change as well as part of the fix, let me know.
> 
> Furthermore, I don't know how much the code in mainline differs from the code 
> in the Panama branches. If the discrepancy is large, you might want to run 
> `bash bin/blessed-modifier-order.sh src/jdk.incubator.vector` and  `bash 
> bin/blessed-modifier-order.sh src/jdk.incubator.foreign` in those branches.

On a  second look, changes are relatively contained. I'm ok with integrating 
this ahead of the Panama/foreign refresh. I found a possible issue in the 
vector API, with `public` being of the same line as the annotation, which looks 
odd (as you have noticed).

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteVector.java 
line 3908:

> 3906: 
> 3907: @ForceInline
> 3908: @Override public

`public` should probably go on a different line? (same as for the ones that 
follow)

-

PR: https://git.openjdk.java.net/jdk/pull/6355


Re: RFR: 8277015: Use blessed modifier order in Panama code

2021-11-11 Thread Maurizio Cimadamore

Hi Magnus,
as we're in the process of integrating new API changes (see [1]) - would 
it be possible to postpone this? I'd like to minimize merge conflicts, 
if that makes sense.


Thanks
Maurizio

[1] - https://github.com/openjdk/jdk/pull/5907

On 11/11/2021 14:57, Magnus Ihse Bursie wrote:

I ran bin/blessed-modifier-order.sh on source owned by Project Panama. This scripts 
verifies that modifiers are in the "blessed" order, and fixes it otherwise. I 
have manually checked the changes made by the script to make sure they are sound.

In this case, while the script did into the "correct" thing, it turns out that 
the method signatures in `src/jdk.incubator.vector/share/classes/jdk/incubator/vector` 
has some room for improvement... The files contains method headers which look like this:


 final @Override
 @ForceInline
 long longToElementBits(...

 @ForceInline
 static long toIntegralChecked(...

 @ForceInline
 @Override final
 ByteVector dummyVector(...


My personal opinion is that these should have been written like this:


 @Override
 @ForceInline
 final long longToElementBits(...

 @ForceInline
 static long toIntegralChecked(...

 @ForceInline
 @Override
 final ByteVector dummyVector(...


or possibly



 @Override @ForceInline
 final long longToElementBits(...

 @ForceInline
 static long toIntegralChecked(...

 @ForceInline @Override
 final ByteVector dummyVector(...


If you want me to make that change as well as part of the fix, let me know.

Furthermore, I don't know how much the code in mainline differs from the code 
in the Panama branches. If the discrepancy is large, you might want to run 
`bash bin/blessed-modifier-order.sh src/jdk.incubator.vector` and  `bash 
bin/blessed-modifier-order.sh src/jdk.incubator.foreign` in those branches.

-

Commit messages:
  - 8277015: Use blessed modifier order in Panama code

Changes: https://git.openjdk.java.net/jdk/pull/6355/files
  Webrev: https://webrevs.openjdk.java.net/?repo=jdk=6355=00
   Issue: https://bugs.openjdk.java.net/browse/JDK-8277015
   Stats: 21 lines in 13 files changed: 0 ins; 0 del; 21 mod
   Patch: https://git.openjdk.java.net/jdk/pull/6355.diff
   Fetch: git fetch https://git.openjdk.java.net/jdk pull/6355/head:pull/6355

PR: https://git.openjdk.java.net/jdk/pull/6355


Re: RFR: 8277015: Use blessed modifier order in Panama code

2021-11-11 Thread Magnus Ihse Bursie
I assume this is relevant for panama-dev as well, but I can't 
unfortunately tag the issue as such in Github/Skara. (Maybe we should 
have a mapping for jdk.incubator.vector/foreign -> panama-dev?)


/Magnus

On 2021-11-11 15:57, Magnus Ihse Bursie wrote:

I ran bin/blessed-modifier-order.sh on source owned by Project Panama. This scripts 
verifies that modifiers are in the "blessed" order, and fixes it otherwise. I 
have manually checked the changes made by the script to make sure they are sound.

In this case, while the script did into the "correct" thing, it turns out that 
the method signatures in `src/jdk.incubator.vector/share/classes/jdk/incubator/vector` 
has some room for improvement... The files contains method headers which look like this:


 final @Override
 @ForceInline
 long longToElementBits(...

 @ForceInline
 static long toIntegralChecked(...

 @ForceInline
 @Override final
 ByteVector dummyVector(...


My personal opinion is that these should have been written like this:


 @Override
 @ForceInline
 final long longToElementBits(...

 @ForceInline
 static long toIntegralChecked(...

 @ForceInline
 @Override
 final ByteVector dummyVector(...


or possibly



 @Override @ForceInline
 final long longToElementBits(...

 @ForceInline
 static long toIntegralChecked(...

 @ForceInline @Override
 final ByteVector dummyVector(...


If you want me to make that change as well as part of the fix, let me know.

Furthermore, I don't know how much the code in mainline differs from the code 
in the Panama branches. If the discrepancy is large, you might want to run 
`bash bin/blessed-modifier-order.sh src/jdk.incubator.vector` and  `bash 
bin/blessed-modifier-order.sh src/jdk.incubator.foreign` in those branches.

-

Commit messages:
  - 8277015: Use blessed modifier order in Panama code

Changes: https://git.openjdk.java.net/jdk/pull/6355/files
  Webrev: https://webrevs.openjdk.java.net/?repo=jdk=6355=00
   Issue: https://bugs.openjdk.java.net/browse/JDK-8277015
   Stats: 21 lines in 13 files changed: 0 ins; 0 del; 21 mod
   Patch: https://git.openjdk.java.net/jdk/pull/6355.diff
   Fetch: git fetch https://git.openjdk.java.net/jdk pull/6355/head:pull/6355

PR: https://git.openjdk.java.net/jdk/pull/6355




RFR: 8277015: Use blessed modifier order in Panama code

2021-11-11 Thread Magnus Ihse Bursie
I ran bin/blessed-modifier-order.sh on source owned by Project Panama. This 
scripts verifies that modifiers are in the "blessed" order, and fixes it 
otherwise. I have manually checked the changes made by the script to make sure 
they are sound.

In this case, while the script did into the "correct" thing, it turns out that 
the method signatures in 
`src/jdk.incubator.vector/share/classes/jdk/incubator/vector` has some room for 
improvement... The files contains method headers which look like this:


final @Override
@ForceInline
long longToElementBits(...

@ForceInline
static long toIntegralChecked(...

@ForceInline
@Override final
ByteVector dummyVector(...


My personal opinion is that these should have been written like this:


@Override
@ForceInline
final long longToElementBits(...

@ForceInline
static long toIntegralChecked(...

@ForceInline
@Override
final ByteVector dummyVector(...


or possibly



@Override @ForceInline
final long longToElementBits(...

@ForceInline
static long toIntegralChecked(...

@ForceInline @Override
final ByteVector dummyVector(...


If you want me to make that change as well as part of the fix, let me know.

Furthermore, I don't know how much the code in mainline differs from the code 
in the Panama branches. If the discrepancy is large, you might want to run 
`bash bin/blessed-modifier-order.sh src/jdk.incubator.vector` and  `bash 
bin/blessed-modifier-order.sh src/jdk.incubator.foreign` in those branches.

-

Commit messages:
 - 8277015: Use blessed modifier order in Panama code

Changes: https://git.openjdk.java.net/jdk/pull/6355/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=6355=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8277015
  Stats: 21 lines in 13 files changed: 0 ins; 0 del; 21 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6355.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6355/head:pull/6355

PR: https://git.openjdk.java.net/jdk/pull/6355


Integrated: 8244202: Implementation of JEP 418: Internet-Address Resolution SPI

2021-11-11 Thread Aleksei Efimov
On Tue, 5 Oct 2021 12:00:15 GMT, Aleksei Efimov  wrote:

> This change implements a new service provider interface for host name and 
> address resolution, so that java.net.InetAddress API can make use of 
> resolvers other than the platform's built-in resolver.
> 
> The following API classes are added to `java.net.spi` package to facilitate 
> this:
> - `InetAddressResolverProvider` -  abstract class defining a service, and is, 
> essentially, a factory for `InetAddressResolver` resolvers.
> - `InetAddressResolverProvider.Configuration ` - an interface describing the 
> platform's built-in configuration for resolution operations that could be 
> used to bootstrap a resolver construction, or to implement partial delegation 
> of lookup operations.
> - `InetAddressResolver` - an interface that defines methods for the 
> fundamental forward and reverse lookup operations.
> - `InetAddressResolver.LookupPolicy` - a class whose instances describe the 
> characteristics of one forward lookup operation.  
> 
> More details in [JEP-418](https://openjdk.java.net/jeps/418).
> 
> Testing: new and existing `tier1:tier3` tests

This pull request has now been integrated.

Changeset: 2ca4ff87
Author:Aleksei Efimov 
URL:   
https://git.openjdk.java.net/jdk/commit/2ca4ff87b7c31d56542bbdcea70e828be33f4e97
Stats: 3141 lines in 56 files changed: 2848 ins; 155 del; 138 mod

8244202: Implementation of JEP 418: Internet-Address Resolution SPI

Co-authored-by: Chris Hegarty 
Co-authored-by: Daniel Fuchs 
Co-authored-by: Alan Bateman 
Reviewed-by: dfuchs, alanb, michaelm, chegar

-

PR: https://git.openjdk.java.net/jdk/pull/5822


RFR: JDK-8273056 java.util.random does not correctly sample exponential or Gaussian distributions

2021-11-11 Thread Jim Laskey
The modified ziggurat algorithm is not correctly implemented in 
`java.base/jdk/internal/util/random/RandomSupport.java`. 

Create a histogram of a million samples using 2000 uniform bins with the 
following range: 
Exponential range from 0 to 12. Gaussian range from -8 to 8. 

This does not pass a Chi-square test. If you look at the histogram it is 
obviously not showing the shape of the PDF for these distributions. Look 
closely at the range around zero (e.g. +/- 0.5).

-

Commit messages:
 - 8273056 - java.util.random does not correctly sample exponential or Gaussian 
distributions

Changes: https://git.openjdk.java.net/jdk/pull/6353/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=6353=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8273056
  Stats: 15 lines in 1 file changed: 6 ins; 4 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6353.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6353/head:pull/6353

PR: https://git.openjdk.java.net/jdk/pull/6353


Re: RFR: 8275007: Java fails to start with null charset if LC_ALL is set to certain locales [v2]

2021-11-11 Thread Ichiroh Takiguchi
On Tue, 9 Nov 2021 19:38:01 GMT, Naoto Sato  wrote:

>> Please review the subject fix. In light of JEP400, Java runtime can/should 
>> start in UTF-8 charset if the underlying native encoding is not supported.
>
> Naoto Sato has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Emit a warning on unsupported jnu encoding

I applied same kind of patch into jdk17u.
The situation was same.

$ env LC_ALL=kk_KZ.pt154 
./build/linux-x86_64-server-release/images/jdk/bin/java -showversion Hello.java 
WARNING: The encoding of the underlying platform's file system is not supported 
by the JVM: PT154
openjdk version "17.0.1-internal" 2021-10-19
OpenJDK Runtime Environment (build 17.0.1-internal+0-adhoc.jdktest.jdk17u)
OpenJDK 64-Bit Server VM (build 17.0.1-internal+0-adhoc.jdktest.jdk17u, mixed 
mode, sharing)
Error: A JNI error has occurred, please check your installation and try again
Exception in thread "main" java.util.ServiceConfigurationError: 
java.nio.charset.spi.CharsetProvider: Unable to load 
sun.nio.cs.ext.ExtendedCharsets
at java.base/java.util.ServiceLoader.fail(ServiceLoader.java:586)
...

-

PR: https://git.openjdk.java.net/jdk/pull/6282


RFR: JDK-8277003 - JumpableGenerator.rngs() documentation refers to wrong method

2021-11-11 Thread Jim Laskey
Documentation in `RandomGenerator.rngs()` refers to `JumpableGenerator.jump()` 
when it should be `JumpableGenerator.jumps()`

-

Commit messages:
 - 8273792 - JumpableGenerator.rngs() documentation refers to wrong method

Changes: https://git.openjdk.java.net/jdk/pull/6352/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=6352=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8277003
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6352.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6352/head:pull/6352

PR: https://git.openjdk.java.net/jdk/pull/6352


RFR: JDK-8274685 - Documentation suggests there are ArbitrarilyJumpableGenerator when none

2021-11-11 Thread Jim Laskey
"There is also an interface RandomGenerator.ArbitrarilyJumpableGenerator for 
algorithms that allow jumping along the state cycle by any user-specified 
distance. In this package, implementations of these interfaces include 
"Xoroshiro128PlusPlus", and "Xoshiro256PlusPlus" is incorrect. 
"Xoroshiro128PlusPlus", and "Xoshiro256PlusPlus" are actually 
RandomGenerator.JumpableGenerator.

-

Commit messages:
 - 8274685: Documentation suggests there are ArbitrarilyJumpableGenerator when 
none

Changes: https://git.openjdk.java.net/jdk/pull/6349/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=6349=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8274685
  Stats: 18 lines in 1 file changed: 7 ins; 2 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6349.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6349/head:pull/6349

PR: https://git.openjdk.java.net/jdk/pull/6349


Re: RFR: 8275063: Implementation of Foreign Function & Memory API (Second incubator) [v23]

2021-11-11 Thread Maurizio Cimadamore
> This PR contains the API and implementation changes for JEP-419 [1]. A more 
> detailed description of such changes, to avoid repetitions during the review 
> process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/419

Maurizio Cimadamore has updated the pull request with a new target base due to 
a merge or a rebase. The pull request now contains 32 commits:

 - Merge branch 'master' into JEP-419
 - Revert removal of upcall MH customization
   (This change caused spurious VM crashes, so reverting to baseline)
 - Further tweak upcall safety considerations
 - Clarify safety considerations for upcalls
 - Rename MemorySegment::ofAddressNative to MemorySegment::ofAddress
   (which is consistent with other restricted factories in VaList and 
NativeSymbol)
 - Streamline javadoc for package-info
 - * Add two new CLinker static methods to compute upcall/downcall method types
   * Clarify section on CLinker downcall type
   * Add section on CLinker safety guarantees
 - Fix TestUpcall
   * reverse() has a bug, as it doesn't tweak parameter types
   * reverse() is applied to the wrong MH
 - Make ArenaAllocator impl more flexible in the face of OOME
   An ArenaAllocator should remain open for business, even if OOME is thrown in 
case other allocations can fit the arena size.
 - Simplify ArenaAllocator impl.
   The arena should respect its boundaries and never allocate more memory than 
its size specifies.
 - ... and 22 more: https://git.openjdk.java.net/jdk/compare/aea09677...8c3860f8

-

Changes: https://git.openjdk.java.net/jdk/pull/5907/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=5907=22
  Stats: 14686 lines in 193 files changed: 6956 ins; 5120 del; 2610 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5907.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5907/head:pull/5907

PR: https://git.openjdk.java.net/jdk/pull/5907


Re: RFR: 8276123: ZipFile::getEntry will not return a file entry when there is a directory entry of the same name within a Zip File

2021-11-11 Thread Claes Redestad
On Thu, 11 Nov 2021 12:25:38 GMT, Jaikiran Pai  wrote:

>> Hi Jaikiran,
>> 
>> The comment is correct
>
> Thank you for that clarification.  The "addSlash" param being "false" in the 
> call below that comment is what made me think that the comment had a typo. I 
> read that code in a bit more detail now and I see what that comment means. It 
> essentially says that it's now issuing a call to find a entry position (if it 
> exists) for the name ending with a "/" character.

The comment is a bit too fuzzy. What's happening here is we searched for `foo` 
and found a match for `foo/` - but we can't be sure there's no exact entry 
`foo` later on in the hash bucket, so we (somewhat inefficiently) redo the 
search for `foo` without the trailing slash parameter.

I suggest clarifying to something like this:
```  // name + "/" entry found, keep looking for and prefer an entry which 
exactly matches name```

-

PR: https://git.openjdk.java.net/jdk/pull/6342


Re: RFR: 8276123: ZipFile::getEntry will not return a file entry when there is a directory entry of the same name within a Zip File

2021-11-11 Thread Jaikiran Pai
On Thu, 11 Nov 2021 11:51:31 GMT, Lance Andersen  wrote:

>> src/java.base/share/classes/java/util/zip/ZipFile.java line 1642:
>> 
>>> 1640: && entry.startsWith(name) &&
>>> 1641: entry.charAt(entryLen - 1) == '/') {
>>> 1642: // Now check for a match with a trailing 
>>> slash
>> 
>> Hello Lance,
>> Is this a typo in that comment? Should it instead say "... without a 
>> trailing slash"?
>
> Hi Jaikiran,
> 
> The comment is correct

Thank you for that clarification.  The "addSlash" param being "false" in the 
call below that comment is what made me think that the comment had a typo. I 
read that code in a bit more detail now and I see what that comment means. It 
essentially says that it's now issuing a call to find a entry position (if it 
exists) for the name ending with a "/" character.

-

PR: https://git.openjdk.java.net/jdk/pull/6342


Withdrawn: 8275728: Add simple Producer/Consumer microbenchmark for Thread.onSpinWait

2021-11-11 Thread Evgeny Astigeevich
On Wed, 10 Nov 2021 18:07:47 GMT, Evgeny Astigeevich  
wrote:

> This is a microbenchmarks to demonstrate `Thread.onSpinWait` can be used to 
> avoid heavy locks.
> The microbenchmark differs from [Gil's original 
> benchmark](https://github.com/giltene/GilExamples/tree/master/SpinWaitTest) 
> and [Dmitry's 
> variations](http://cr.openjdk.java.net/~dchuyko/8186670/yield/spinwait.html). 
> Those benchmarks produce/consume data by incrementing a volatile counter. The 
> latency of such operations is almost zero. They also don't use heavy locks. 
> According to [Gil's 
> SpinWaitTest.java](https://github.com/giltene/GilExamples/blob/master/SpinWaitTest/src/main/java/SpinWaitTest.java):
>> This test can be used to measure and document the impact of 
>> Runtime.onSpinWait() behavior
>>  on thread-to-thread communication latencies. E.g. when the two threads are 
>> pinned to
>> the two hardware threads of a shared x86 core (with a shared L1), this test 
>> will
>> demonstrate an estimate the best case thread-to-thread latencies possible on 
>> the
>> platform
> 
> Gil's microbenchmark targets SMT cases (x86 hyperthreading). As not all CPUs 
> support SMT, the microbenchmarks cannot demonstrate benefits of 
> `Thread.onSpinWait`. It is actually opposite. They show `Thread.onSpinWait`  
> has negative impact on performance.
> 
> The microbenchmark from PR uses `BigInteger` to have 100 - 200 ns latencies 
> for producing/consuming data. These latencies can cause either a producer or 
> a consumer to wait each another. Waiting is implemented with 
> `Object.wait`/`Object.notify` which are heavy. `Thread.onSpinWait` can be 
> used in a spin loop to avoid them.
> 
> **ARM64 results**:
> - No spin loop
> 
> Benchmark   (maxNum)  (spinNum)  Mode  Cnt 
> ScoreError  Units
> ThreadOnSpinWaitProducerConsumer.trial   100  0  avgt   75  
> 1520.448 ± 40.507  us/op
> 
> - No `Thread.onSpinWait` intrinsic
> 
> Benchmark   (maxNum)  (spinNum)  Mode  Cnt 
> ScoreError  Units
> ThreadOnSpinWaitProducerConsumer.trial   100125  avgt   75  
> 1580.756 ± 47.501  us/op
> 
> - `ISB`-based `Thread.onSpinWait` intrinsic
> 
> Benchmark   (maxNum)  (spinNum)  Mode  Cnt
> Score Error  Units
> ThreadOnSpinWaitProducerConsumer.trial   100125  avgt   75  
> 617.454 ± 174.431  us/op
> 
> 
> **X86_64 results**:
> - No spin loop
> 
> Benchmark   (maxNum)  (spinNum)  Mode  Cnt
> Score Error  Units
> ThreadOnSpinWaitProducerConsumer.trial  100125  avgt   75  
> 1417.944 ± 1.691  us/op
> 
> - No `Thread.onSpinWait` intrinsic
> 
> Benchmark   (maxNum)  (spinNum)  Mode  Cnt
> Score Error  Units
> ThreadOnSpinWaitProducerConsumer.trial  100125  avgt   75  
> 1410.987 ± 2.093  us/op
> 
> - `PAUSE`-based `Thread.onSpinWait` intrinsic
> 
> Benchmark   (maxNum)  (spinNum)  Mode  Cnt
> Score Error  Units
> ThreadOnSpinWaitProducerConsumer.trial  100125  avgt   75  
> 217.054 ± 1.283  us/op

This pull request has been closed without being integrated.

-

PR: https://git.openjdk.java.net/jdk/pull/6338


Re: RFR: 8276123: ZipFile::getEntry will not return a file entry when there is a directory entry of the same name within a Zip File

2021-11-11 Thread Alan Bateman
On Wed, 10 Nov 2021 20:51:20 GMT, Lance Andersen  wrote:

> Hi all,
> 
> This patch addresses a regression introduced in JDK 15 via JDK-8242959 where 
> you can no longer access a file entry contained within a Zip file when there 
> is also a directory entry with the same name via ZipFile:getEntry(). 
> 
>  Once fixed, the behavior will be consistent with earlier JDK releases. 
> 
> Mach5 tiers 1-3 have been run without failure
> 
> Best
> Lance

test/jdk/java/util/zip/ZipFile/ZipFileDuplicateEntryTest.java line 176:

> 174: zos.closeEntry();
> 175: } catch (IOException e) {
> 176: e.printStackTrace();

Did you mean to catch IOException here? If the setup fails then the test will 
still run.

-

PR: https://git.openjdk.java.net/jdk/pull/6342


Re: RFR: 8276123: ZipFile::getEntry will not return a file entry when there is a directory entry of the same name within a Zip File

2021-11-11 Thread Lance Andersen
On Thu, 11 Nov 2021 02:14:50 GMT, Jaikiran Pai  wrote:

>> Hi all,
>> 
>> This patch addresses a regression introduced in JDK 15 via JDK-8242959 where 
>> you can no longer access a file entry contained within a Zip file when there 
>> is also a directory entry with the same name via ZipFile:getEntry(). 
>> 
>>  Once fixed, the behavior will be consistent with earlier JDK releases. 
>> 
>> Mach5 tiers 1-3 have been run without failure
>> 
>> Best
>> Lance
>
> src/java.base/share/classes/java/util/zip/ZipFile.java line 1642:
> 
>> 1640: && entry.startsWith(name) &&
>> 1641: entry.charAt(entryLen - 1) == '/') {
>> 1642: // Now check for a match with a trailing 
>> slash
> 
> Hello Lance,
> Is this a typo in that comment? Should it instead say "... without a trailing 
> slash"?

Hi Jaikiran,

The comment is correct

-

PR: https://git.openjdk.java.net/jdk/pull/6342


Re: RFR: 8275007: Java fails to start with null charset if LC_ALL is set to certain locales [v2]

2021-11-11 Thread Ichiroh Takiguchi
On Tue, 9 Nov 2021 19:38:01 GMT, Naoto Sato  wrote:

>> Please review the subject fix. In light of JEP400, Java runtime can/should 
>> start in UTF-8 charset if the underlying native encoding is not supported.
>
> Naoto Sato has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Emit a warning on unsupported jnu encoding

I could see following output on my CentOS7.

$ env LC_ALL=kk_KZ.pt154 ~/jdk-17.0.1/bin/java -showversion Hello.java 
Error occurred during initialization of VM
java.lang.NullPointerException
at java.lang.System.getProperty(java.base/System.java:918)
at 
sun.security.action.GetPropertyAction.privilegedGetProperty(java.base/GetPropertyAction.java:106)
at java.nio.charset.Charset.defaultCharset(java.base/Charset.java:607)
at java.lang.String.(java.base/String.java:1412)
at java.lang.String.(java.base/String.java:1432)
at 
jdk.internal.util.SystemProps$Raw.platformProperties(java.base/Native Method)
at 
jdk.internal.util.SystemProps$Raw.(java.base/SystemProps.java:234)
at 
jdk.internal.util.SystemProps.initProperties(java.base/SystemProps.java:54)
at java.lang.System.initPhase1(java.base/System.java:2089)

$ env LC_ALL=kk_KZ.pt154 ~/jdk-18-b22/bin/java -showversion Hello.java 
Error occurred during initialization of VM
java.lang.NullPointerException
at java.lang.System.getProperty(java.base/System.java:929)
at 
sun.security.action.GetPropertyAction.privilegedGetProperty(java.base/GetPropertyAction.java:106)
at java.nio.charset.Charset.defaultCharset(java.base/Charset.java:646)
at java.lang.String.(java.base/String.java:1411)
at java.lang.String.(java.base/String.java:1431)
at 
jdk.internal.util.SystemProps$Raw.platformProperties(java.base/Native Method)
at 
jdk.internal.util.SystemProps$Raw.(java.base/SystemProps.java:240)
at 
jdk.internal.util.SystemProps.initProperties(java.base/SystemProps.java:54)
at java.lang.System.initPhase1(java.base/System.java:2100)

-

PR: https://git.openjdk.java.net/jdk/pull/6282


Re: RFR: 8275007: Java fails to start with null charset if LC_ALL is set to certain locales [v2]

2021-11-11 Thread Alan Bateman
On Thu, 11 Nov 2021 09:40:14 GMT, Ichiroh Takiguchi  
wrote:

> I don't have Oracle Linux... I tried to find out unsupported locales by using 
> following commands. I used RHEL7.9.

In your previous post you used env LC_ALL=kk_KZ.pt154 java Hello.java. Would it 
be possible to repeat that with JDK 17 and the main-line (latest JDK 18 EA 
build is okay). I'm wondering if you see the NPE.

In any case, our next step here will be to have fallback saved during early 
startup so that file system and other places don't do the lookup. This seems 
the sanest way to avoid the recursive initialisation issue.

-

PR: https://git.openjdk.java.net/jdk/pull/6282


Re: RFR: 8244202: Implementation of JEP 418: Internet-Address Resolution SPI [v13]

2021-11-11 Thread Aleksei Efimov
> This change implements a new service provider interface for host name and 
> address resolution, so that java.net.InetAddress API can make use of 
> resolvers other than the platform's built-in resolver.
> 
> The following API classes are added to `java.net.spi` package to facilitate 
> this:
> - `InetAddressResolverProvider` -  abstract class defining a service, and is, 
> essentially, a factory for `InetAddressResolver` resolvers.
> - `InetAddressResolverProvider.Configuration ` - an interface describing the 
> platform's built-in configuration for resolution operations that could be 
> used to bootstrap a resolver construction, or to implement partial delegation 
> of lookup operations.
> - `InetAddressResolver` - an interface that defines methods for the 
> fundamental forward and reverse lookup operations.
> - `InetAddressResolver.LookupPolicy` - a class whose instances describe the 
> characteristics of one forward lookup operation.  
> 
> More details in [JEP-418](https://openjdk.java.net/jeps/418).
> 
> Testing: new and existing `tier1:tier3` tests

Aleksei Efimov has updated the pull request with a new target base due to a 
merge or a rebase. The pull request now contains 19 commits:

 - Merge branch 'master' into JDK-8244202_JEP418_impl
 - Merge branch 'master' into JDK-8244202_JEP418_impl
 - Merge branch 'master' into JDK-8244202_JEP418_impl
 - Replace 'system' with 'the system-wide', move comment section
 - Add @ throws NPE to hosts file resolver javadoc
 - Changes to address review comments
 - Update tests to address SM deprecation
 - Merge branch 'master' into JDK-8244202_JEP418_impl
 - More javadoc updates to API classes
 - Review updates + move resolver docs to the provider class (CSR update to 
follow)
 - ... and 9 more: https://git.openjdk.java.net/jdk/compare/f561d3c1...a2498d2b

-

Changes: https://git.openjdk.java.net/jdk/pull/5822/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=5822=12
  Stats: 3141 lines in 56 files changed: 2848 ins; 155 del; 138 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5822.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5822/head:pull/5822

PR: https://git.openjdk.java.net/jdk/pull/5822


Re: RFR: 8275007: Java fails to start with null charset if LC_ALL is set to certain locales [v2]

2021-11-11 Thread Ichiroh Takiguchi
On Tue, 9 Nov 2021 19:38:01 GMT, Naoto Sato  wrote:

>> Please review the subject fix. In light of JEP400, Java runtime can/should 
>> start in UTF-8 charset if the underlying native encoding is not supported.
>
> Naoto Sato has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Emit a warning on unsupported jnu encoding

I don't have Oracle Linux...
I tried to find out unsupported locales by using following commands.
I used RHEL7.9.

$ cat CharsetIsSupported.java 
import java.nio.charset.Charset;

public class CharsetIsSupported {
public static void main(String[] args) throws Exception {
for(String s : args) {
if (!Charset.isSupported(s))
System.out.println(s);
}
}
}
$ locale -a | while read LOC; do env LANG=$LOC locale charmap; done | sort -u | 
xargs ~/jdk-17.0.1/bin/java CharsetIsSupported.java > encoding.lst
$ locale -a | while read LOC; do echo -e "$LOC\t\c"; env LANG=$LOC locale 
charmap; done | grep -f encoding.lst
cy_GB   ISO-8859-14
cy_GB.iso885914 ISO-8859-14
hy_AM.armscii8  ARMSCII-8
ka_GE   GEORGIAN-PS
ka_GE.georgianpsGEORGIAN-PS
kk_KZ   PT154
kk_KZ.pt154 PT154
lg_UG   ISO-8859-10
lg_UG.iso885910 ISO-8859-10
tg_TJ   KOI8-T
tg_TJ.koi8t KOI8-T


I tried following command, "sun.jnu.encoding" system property was referred 
following source code.
We may need to care about these files.

$ find src -type f | xargs grep '"sun.jnu.encoding"'
src/java.base/share/classes/java/lang/System.java:var jnuEncoding = 
props.getProperty("sun.jnu.encoding");
src/java.base/share/classes/java/lang/System.java:
props.getProperty("sun.jnu.encoding"));
src/java.base/share/classes/jdk/internal/util/SystemProps.java:
put(props, "sun.jnu.encoding", raw.propDefault(Raw._sun_jnu_encoding_NDX));
src/java.base/share/classes/sun/launcher/LauncherHelper.java:private static 
final String encprop = "sun.jnu.encoding";
src/java.base/share/classes/sun/nio/fs/Util.java:
GetPropertyAction.privilegedGetProperty("sun.jnu.encoding"),
src/java.base/share/native/libjava/jni_util.h:NO_ENCODING_YET = 0,
/* "sun.jnu.encoding" not yet set */
src/java.desktop/share/classes/sun/font/SunFontManager.java:
String sysEncoding = System.getProperty("sun.jnu.encoding");

-

PR: https://git.openjdk.java.net/jdk/pull/6282


Re: RFR: 8244202: Implementation of JEP 418: Internet-Address Resolution SPI [v12]

2021-11-11 Thread Chris Hegarty
On Wed, 3 Nov 2021 13:23:36 GMT, Aleksei Efimov  wrote:

>> This change implements a new service provider interface for host name and 
>> address resolution, so that java.net.InetAddress API can make use of 
>> resolvers other than the platform's built-in resolver.
>> 
>> The following API classes are added to `java.net.spi` package to facilitate 
>> this:
>> - `InetAddressResolverProvider` -  abstract class defining a service, and 
>> is, essentially, a factory for `InetAddressResolver` resolvers.
>> - `InetAddressResolverProvider.Configuration ` - an interface describing the 
>> platform's built-in configuration for resolution operations that could be 
>> used to bootstrap a resolver construction, or to implement partial 
>> delegation of lookup operations.
>> - `InetAddressResolver` - an interface that defines methods for the 
>> fundamental forward and reverse lookup operations.
>> - `InetAddressResolver.LookupPolicy` - a class whose instances describe the 
>> characteristics of one forward lookup operation.  
>> 
>> More details in [JEP-418](https://openjdk.java.net/jeps/418).
>> 
>> Testing: new and existing `tier1:tier3` tests
>
> Aleksei Efimov has updated the pull request with a new target base due to a 
> merge or a rebase. The pull request now contains 18 commits:
> 
>  - Merge branch 'master' into JDK-8244202_JEP418_impl
>  - Merge branch 'master' into JDK-8244202_JEP418_impl
>  - Replace 'system' with 'the system-wide', move comment section
>  - Add @ throws NPE to hosts file resolver javadoc
>  - Changes to address review comments
>  - Update tests to address SM deprecation
>  - Merge branch 'master' into JDK-8244202_JEP418_impl
>  - More javadoc updates to API classes
>  - Review updates + move resolver docs to the provider class (CSR update to 
> follow)
>  - Change InetAddressResolver method names
>  - ... and 8 more: 
> https://git.openjdk.java.net/jdk/compare/a316c06e...0542df51

LGTM.

-

Marked as reviewed by chegar (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5822


Re: JEP 416: Missing throws IllegalArgumentException declaration for Method::invoke?

2021-11-11 Thread Alan Bateman

On 11/11/2021 08:21, Marc Hoffmann wrote:

Hi,

with the implementation of JEP 416 
(https://github.com/openjdk/jdk/commit/c6339cb8a255d387bb182ad20dd69f3d460cf1ed 
)
 the throws declaration for IllegalArgumentException on Method::invoke was removed — 
while it is still described in JavaDoc. Was this on purpose?

Sorry if this was discussed before, but I was not able to find a review 
discussion around this commit. Also I’m not sure what the policy is whether 
unchecked exceptions should be declared if mentioned in JavaDoc.


Usually the method throws clause just lists the checked exceptions but 
there cases where the source code (esp. older code) does declare that it 
throws IllegalArgumentException, SecurityException or other unchecked 
exceptions. All exceptions should of course be @throws documented in the 
method description. In this case, I think it's just cleanup, the method 
continues to document that it may throw IllegalArgumentException.


Are you running into an issue or is this just showing up with API 
diffs?  There shouldn't be a compatibility issue but maybe there is 
something looking at the method Exceptions table that expects to see 
unchecked exceptions?


-Alan





JEP 416: Missing throws IllegalArgumentException declaration for Method::invoke?

2021-11-11 Thread Marc Hoffmann
Hi,

with the implementation of JEP 416 
(https://github.com/openjdk/jdk/commit/c6339cb8a255d387bb182ad20dd69f3d460cf1ed 
)
 the throws declaration for IllegalArgumentException on Method::invoke was 
removed — while it is still described in JavaDoc. Was this on purpose?

Sorry if this was discussed before, but I was not able to find a review 
discussion around this commit. Also I’m not sure what the policy is whether 
unchecked exceptions should be declared if mentioned in JavaDoc.

Best regards,
-marc