Re: RFR: 8254231: Implementation of Foreign Linker API (Incubator) [v15]

[Nick Gasson]

On Thu, 5 Nov 2020 21:26:16 GMT, Maurizio Cimadamore  
wrote:

>> This patch contains the changes associated with the first incubation round 
>> of the foreign linker access API incubation
>> (see JEP 389 [1]). This work is meant to sit on top of the foreign memory 
>> access support (see JEP 393 [2] and associated pull request [3]).
>> 
>> The main goal of this API is to provide a way to call native functions from 
>> Java code without the need of intermediate JNI glue code. In order to do 
>> this, native calls are modeled through the MethodHandle API. I suggest 
>> reading the writeup [4] I put together few weeks ago, which illustrates what 
>> the foreign linker support is, and how it should be used by clients.
>> 
>> Disclaimer: the pull request mechanism isn't great at managing *dependent* 
>> reviews. For this reasons, I'm attaching a webrev which contains only the 
>> differences between this PR and the memory access PR. I will be periodically 
>> uploading new webrevs, as new iterations come out, to try and make the life 
>> of reviewers as simple as possible.
>> 
>> A big thank to Jorn Vernee and Vladimir Ivanov - they are the main 
>> architects of all the hotspot changes you see here, and without their help, 
>> the foreign linker support wouldn't be what it is today. As usual, a big 
>> thank to Paul Sandoz, who provided many insights (often by trying the bits 
>> first hand).
>> 
>> Thanks
>> Maurizio
>> 
>> Webrev:
>> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/webrev
>> 
>> Javadoc:
>> 
>> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/javadoc/jdk/incubator/foreign/package-summary.html
>> 
>> Specdiff (relative to [3]):
>> 
>> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/specdiff_delta/overview-summary.html
>> 
>> CSR:
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8254232
>> 
>> 
>> 
>> ### API Changes
>> 
>> The API changes are actually rather slim:
>> 
>> * `LibraryLookup`
>>   * This class allows clients to lookup symbols in native libraries; the 
>> interface is fairly simple; you can load a library by name, or absolute 
>> path, and then lookup symbols on that library.
>> * `FunctionDescriptor`
>>   * This is an abstraction that is very similar, in spirit, to `MethodType`; 
>> it is, at its core, an aggregate of memory layouts for the function 
>> arguments/return type. A function descriptor is used to describe the 
>> signature of a native function.
>> * `CLinker`
>>   * This is the real star of the show. A `CLinker` has two main methods: 
>> `downcallHandle` and `upcallStub`; the first takes a native symbol (as 
>> obtained from `LibraryLookup`), a `MethodType` and a `FunctionDescriptor` 
>> and returns a `MethodHandle` instance which can be used to call the target 
>> native symbol. The second takes an existing method handle, and a 
>> `FunctionDescriptor` and returns a new `MemorySegment` corresponding to a 
>> code stub allocated by the VM which acts as a trampoline from native code to 
>> the user-provided method handle. This is very useful for implementing 
>> upcalls.
>>* This class also contains the various layout constants that should be 
>> used by clients when describing native signatures (e.g. `C_LONG` and 
>> friends); these layouts contain additional ABI classfication information (in 
>> the form of layout attributes) which is used by the runtime to *infer* how 
>> Java arguments should be shuffled for the native call to take place.
>>   * Finally, this class provides some helper functions e.g. so that clients 
>> can convert Java strings into C strings and back.
>> * `NativeScope`
>>   * This is an helper class which allows clients to group together logically 
>> related allocations; that is, rather than allocating separate memory 
>> segments using separate *try-with-resource* constructs, a `NativeScope` 
>> allows clients to use a _single_ block, and allocate all the required 
>> segments there. This is not only an usability boost, but also a performance 
>> boost, since not all allocation requests will be turned into `malloc` calls.
>> * `MemorySegment`
>>   * Only one method added here - namely `handoff(NativeScope)` which allows 
>> a segment to be transferred onto an existing native scope.
>> 
>> ### Safety
>> 
>> The foreign linker API is intrinsically unsafe; many things can go wrong 
>> when requesting a native method handle. For instance, the description of the 
>> native signature might be wrong (e.g. have too many arguments) - and the 
>> runtime has, in the general case, no way to detect such mismatches. For 
>> these reasons, obtaining a `CLinker` instance is a *restricted* operation, 
>> which can be enabled by specifying the usual JDK property 
>> `-Dforeign.restricted=permit` (as it's the case for other restricted method 
>> in the foreign memory API).
>> 
>> ### Implementation changes
>> 
>> The Java changes associated with `LibraryLookup` are relative 
>> straightforward; the only interesting thing to note here is that library 

Re: RFR: 8254231: Implementation of Foreign Linker API (Incubator) [v15]

[David Holmes]

On Fri, 6 Nov 2020 21:42:41 GMT, Coleen Phillimore  wrote:

>> Maurizio Cimadamore has updated the pull request with a new target base due 
>> to a merge or a rebase. The pull request now contains 64 commits:
>> 
>>  - Merge branch '8254162' into 8254231_linker
>>  - Fix post-merge issues caused by 8219014
>>  - Merge branch 'master' into 8254162
>>  - Addess remaining feedback from @AlanBateman and @mrserb
>>  - Address comments from @AlanBateman
>>  - Fix typo in upcall helper for aarch64
>>  - Merge branch '8254162' into 8254231_linker
>>  - Merge branch 'master' into 8254162
>>  - Fix issues with derived buffers and IO operations
>>  - More 32-bit fixes for TestLayouts
>>  - ... and 54 more: 
>> https://git.openjdk.java.net/jdk/compare/a50fdd54...b38afb3f
>
> src/hotspot/cpu/aarch64/universalUpcallHandler_aarch64.cpp line 55:
> 
>> 53: 
>> 54: // FIXME: This should be initialized explicitly instead of lazily/racily
>> 55: static void upcall_init() {
> 
> The FIXME is right this should be initialized as a well known class and 
> referred to here as SystemDictionary::ProgrammableUpcallHandler_klass().  
> This really doesn't belong here.

I agree with Coleen.

-

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

Re: RFR: 8254231: Implementation of Foreign Linker API (Incubator) [v14]

[David Holmes]

On Fri, 30 Oct 2020 12:16:02 GMT, Maurizio Cimadamore  
wrote:

>> This patch contains the changes associated with the first incubation round 
>> of the foreign linker access API incubation
>> (see JEP 389 [1]). This work is meant to sit on top of the foreign memory 
>> access support (see JEP 393 [2] and associated pull request [3]).
>> 
>> The main goal of this API is to provide a way to call native functions from 
>> Java code without the need of intermediate JNI glue code. In order to do 
>> this, native calls are modeled through the MethodHandle API. I suggest 
>> reading the writeup [4] I put together few weeks ago, which illustrates what 
>> the foreign linker support is, and how it should be used by clients.
>> 
>> Disclaimer: the pull request mechanism isn't great at managing *dependent* 
>> reviews. For this reasons, I'm attaching a webrev which contains only the 
>> differences between this PR and the memory access PR. I will be periodically 
>> uploading new webrevs, as new iterations come out, to try and make the life 
>> of reviewers as simple as possible.
>> 
>> A big thank to Jorn Vernee and Vladimir Ivanov - they are the main 
>> architects of all the hotspot changes you see here, and without their help, 
>> the foreign linker support wouldn't be what it is today. As usual, a big 
>> thank to Paul Sandoz, who provided many insights (often by trying the bits 
>> first hand).
>> 
>> Thanks
>> Maurizio
>> 
>> Webrev:
>> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/webrev
>> 
>> Javadoc:
>> 
>> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/javadoc/jdk/incubator/foreign/package-summary.html
>> 
>> Specdiff (relative to [3]):
>> 
>> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/specdiff_delta/overview-summary.html
>> 
>> CSR:
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8254232
>> 
>> 
>> 
>> ### API Changes
>> 
>> The API changes are actually rather slim:
>> 
>> * `LibraryLookup`
>>   * This class allows clients to lookup symbols in native libraries; the 
>> interface is fairly simple; you can load a library by name, or absolute 
>> path, and then lookup symbols on that library.
>> * `FunctionDescriptor`
>>   * This is an abstraction that is very similar, in spirit, to `MethodType`; 
>> it is, at its core, an aggregate of memory layouts for the function 
>> arguments/return type. A function descriptor is used to describe the 
>> signature of a native function.
>> * `CLinker`
>>   * This is the real star of the show. A `CLinker` has two main methods: 
>> `downcallHandle` and `upcallStub`; the first takes a native symbol (as 
>> obtained from `LibraryLookup`), a `MethodType` and a `FunctionDescriptor` 
>> and returns a `MethodHandle` instance which can be used to call the target 
>> native symbol. The second takes an existing method handle, and a 
>> `FunctionDescriptor` and returns a new `MemorySegment` corresponding to a 
>> code stub allocated by the VM which acts as a trampoline from native code to 
>> the user-provided method handle. This is very useful for implementing 
>> upcalls.
>>* This class also contains the various layout constants that should be 
>> used by clients when describing native signatures (e.g. `C_LONG` and 
>> friends); these layouts contain additional ABI classfication information (in 
>> the form of layout attributes) which is used by the runtime to *infer* how 
>> Java arguments should be shuffled for the native call to take place.
>>   * Finally, this class provides some helper functions e.g. so that clients 
>> can convert Java strings into C strings and back.
>> * `NativeScope`
>>   * This is an helper class which allows clients to group together logically 
>> related allocations; that is, rather than allocating separate memory 
>> segments using separate *try-with-resource* constructs, a `NativeScope` 
>> allows clients to use a _single_ block, and allocate all the required 
>> segments there. This is not only an usability boost, but also a performance 
>> boost, since not all allocation requests will be turned into `malloc` calls.
>> * `MemorySegment`
>>   * Only one method added here - namely `handoff(NativeScope)` which allows 
>> a segment to be transferred onto an existing native scope.
>> 
>> ### Safety
>> 
>> The foreign linker API is intrinsically unsafe; many things can go wrong 
>> when requesting a native method handle. For instance, the description of the 
>> native signature might be wrong (e.g. have too many arguments) - and the 
>> runtime has, in the general case, no way to detect such mismatches. For 
>> these reasons, obtaining a `CLinker` instance is a *restricted* operation, 
>> which can be enabled by specifying the usual JDK property 
>> `-Dforeign.restricted=permit` (as it's the case for other restricted method 
>> in the foreign memory API).
>> 
>> ### Implementation changes
>> 
>> The Java changes associated with `LibraryLookup` are relative 
>> straightforward; the only interesting thing to note here is that library 

Re: RFR: 8254231: Implementation of Foreign Linker API (Incubator) [v15]

[David Holmes]

On Thu, 5 Nov 2020 21:26:16 GMT, Maurizio Cimadamore  
wrote:

>> This patch contains the changes associated with the first incubation round 
>> of the foreign linker access API incubation
>> (see JEP 389 [1]). This work is meant to sit on top of the foreign memory 
>> access support (see JEP 393 [2] and associated pull request [3]).
>> 
>> The main goal of this API is to provide a way to call native functions from 
>> Java code without the need of intermediate JNI glue code. In order to do 
>> this, native calls are modeled through the MethodHandle API. I suggest 
>> reading the writeup [4] I put together few weeks ago, which illustrates what 
>> the foreign linker support is, and how it should be used by clients.
>> 
>> Disclaimer: the pull request mechanism isn't great at managing *dependent* 
>> reviews. For this reasons, I'm attaching a webrev which contains only the 
>> differences between this PR and the memory access PR. I will be periodically 
>> uploading new webrevs, as new iterations come out, to try and make the life 
>> of reviewers as simple as possible.
>> 
>> A big thank to Jorn Vernee and Vladimir Ivanov - they are the main 
>> architects of all the hotspot changes you see here, and without their help, 
>> the foreign linker support wouldn't be what it is today. As usual, a big 
>> thank to Paul Sandoz, who provided many insights (often by trying the bits 
>> first hand).
>> 
>> Thanks
>> Maurizio
>> 
>> Webrev:
>> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/webrev
>> 
>> Javadoc:
>> 
>> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/javadoc/jdk/incubator/foreign/package-summary.html
>> 
>> Specdiff (relative to [3]):
>> 
>> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/specdiff_delta/overview-summary.html
>> 
>> CSR:
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8254232
>> 
>> 
>> 
>> ### API Changes
>> 
>> The API changes are actually rather slim:
>> 
>> * `LibraryLookup`
>>   * This class allows clients to lookup symbols in native libraries; the 
>> interface is fairly simple; you can load a library by name, or absolute 
>> path, and then lookup symbols on that library.
>> * `FunctionDescriptor`
>>   * This is an abstraction that is very similar, in spirit, to `MethodType`; 
>> it is, at its core, an aggregate of memory layouts for the function 
>> arguments/return type. A function descriptor is used to describe the 
>> signature of a native function.
>> * `CLinker`
>>   * This is the real star of the show. A `CLinker` has two main methods: 
>> `downcallHandle` and `upcallStub`; the first takes a native symbol (as 
>> obtained from `LibraryLookup`), a `MethodType` and a `FunctionDescriptor` 
>> and returns a `MethodHandle` instance which can be used to call the target 
>> native symbol. The second takes an existing method handle, and a 
>> `FunctionDescriptor` and returns a new `MemorySegment` corresponding to a 
>> code stub allocated by the VM which acts as a trampoline from native code to 
>> the user-provided method handle. This is very useful for implementing 
>> upcalls.
>>* This class also contains the various layout constants that should be 
>> used by clients when describing native signatures (e.g. `C_LONG` and 
>> friends); these layouts contain additional ABI classfication information (in 
>> the form of layout attributes) which is used by the runtime to *infer* how 
>> Java arguments should be shuffled for the native call to take place.
>>   * Finally, this class provides some helper functions e.g. so that clients 
>> can convert Java strings into C strings and back.
>> * `NativeScope`
>>   * This is an helper class which allows clients to group together logically 
>> related allocations; that is, rather than allocating separate memory 
>> segments using separate *try-with-resource* constructs, a `NativeScope` 
>> allows clients to use a _single_ block, and allocate all the required 
>> segments there. This is not only an usability boost, but also a performance 
>> boost, since not all allocation requests will be turned into `malloc` calls.
>> * `MemorySegment`
>>   * Only one method added here - namely `handoff(NativeScope)` which allows 
>> a segment to be transferred onto an existing native scope.
>> 
>> ### Safety
>> 
>> The foreign linker API is intrinsically unsafe; many things can go wrong 
>> when requesting a native method handle. For instance, the description of the 
>> native signature might be wrong (e.g. have too many arguments) - and the 
>> runtime has, in the general case, no way to detect such mismatches. For 
>> these reasons, obtaining a `CLinker` instance is a *restricted* operation, 
>> which can be enabled by specifying the usual JDK property 
>> `-Dforeign.restricted=permit` (as it's the case for other restricted method 
>> in the foreign memory API).
>> 
>> ### Implementation changes
>> 
>> The Java changes associated with `LibraryLookup` are relative 
>> straightforward; the only interesting thing to note here is that library 

Re: RFR: 8254231: Implementation of Foreign Linker API (Incubator) [v15]

[David Holmes]

On Thu, 5 Nov 2020 21:26:16 GMT, Maurizio Cimadamore  
wrote:

>> This patch contains the changes associated with the first incubation round 
>> of the foreign linker access API incubation
>> (see JEP 389 [1]). This work is meant to sit on top of the foreign memory 
>> access support (see JEP 393 [2] and associated pull request [3]).
>> 
>> The main goal of this API is to provide a way to call native functions from 
>> Java code without the need of intermediate JNI glue code. In order to do 
>> this, native calls are modeled through the MethodHandle API. I suggest 
>> reading the writeup [4] I put together few weeks ago, which illustrates what 
>> the foreign linker support is, and how it should be used by clients.
>> 
>> Disclaimer: the pull request mechanism isn't great at managing *dependent* 
>> reviews. For this reasons, I'm attaching a webrev which contains only the 
>> differences between this PR and the memory access PR. I will be periodically 
>> uploading new webrevs, as new iterations come out, to try and make the life 
>> of reviewers as simple as possible.
>> 
>> A big thank to Jorn Vernee and Vladimir Ivanov - they are the main 
>> architects of all the hotspot changes you see here, and without their help, 
>> the foreign linker support wouldn't be what it is today. As usual, a big 
>> thank to Paul Sandoz, who provided many insights (often by trying the bits 
>> first hand).
>> 
>> Thanks
>> Maurizio
>> 
>> Webrev:
>> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/webrev
>> 
>> Javadoc:
>> 
>> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/javadoc/jdk/incubator/foreign/package-summary.html
>> 
>> Specdiff (relative to [3]):
>> 
>> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/specdiff_delta/overview-summary.html
>> 
>> CSR:
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8254232
>> 
>> 
>> 
>> ### API Changes
>> 
>> The API changes are actually rather slim:
>> 
>> * `LibraryLookup`
>>   * This class allows clients to lookup symbols in native libraries; the 
>> interface is fairly simple; you can load a library by name, or absolute 
>> path, and then lookup symbols on that library.
>> * `FunctionDescriptor`
>>   * This is an abstraction that is very similar, in spirit, to `MethodType`; 
>> it is, at its core, an aggregate of memory layouts for the function 
>> arguments/return type. A function descriptor is used to describe the 
>> signature of a native function.
>> * `CLinker`
>>   * This is the real star of the show. A `CLinker` has two main methods: 
>> `downcallHandle` and `upcallStub`; the first takes a native symbol (as 
>> obtained from `LibraryLookup`), a `MethodType` and a `FunctionDescriptor` 
>> and returns a `MethodHandle` instance which can be used to call the target 
>> native symbol. The second takes an existing method handle, and a 
>> `FunctionDescriptor` and returns a new `MemorySegment` corresponding to a 
>> code stub allocated by the VM which acts as a trampoline from native code to 
>> the user-provided method handle. This is very useful for implementing 
>> upcalls.
>>* This class also contains the various layout constants that should be 
>> used by clients when describing native signatures (e.g. `C_LONG` and 
>> friends); these layouts contain additional ABI classfication information (in 
>> the form of layout attributes) which is used by the runtime to *infer* how 
>> Java arguments should be shuffled for the native call to take place.
>>   * Finally, this class provides some helper functions e.g. so that clients 
>> can convert Java strings into C strings and back.
>> * `NativeScope`
>>   * This is an helper class which allows clients to group together logically 
>> related allocations; that is, rather than allocating separate memory 
>> segments using separate *try-with-resource* constructs, a `NativeScope` 
>> allows clients to use a _single_ block, and allocate all the required 
>> segments there. This is not only an usability boost, but also a performance 
>> boost, since not all allocation requests will be turned into `malloc` calls.
>> * `MemorySegment`
>>   * Only one method added here - namely `handoff(NativeScope)` which allows 
>> a segment to be transferred onto an existing native scope.
>> 
>> ### Safety
>> 
>> The foreign linker API is intrinsically unsafe; many things can go wrong 
>> when requesting a native method handle. For instance, the description of the 
>> native signature might be wrong (e.g. have too many arguments) - and the 
>> runtime has, in the general case, no way to detect such mismatches. For 
>> these reasons, obtaining a `CLinker` instance is a *restricted* operation, 
>> which can be enabled by specifying the usual JDK property 
>> `-Dforeign.restricted=permit` (as it's the case for other restricted method 
>> in the foreign memory API).
>> 
>> ### Implementation changes
>> 
>> The Java changes associated with `LibraryLookup` are relative 
>> straightforward; the only interesting thing to note here is that library 

Re: RFR: 8255883: Avoid multiple GeneratedMethodAccessor for same NativeMethod… [v2]

[Hui Shi]

On Fri, 6 Nov 2020 08:58:13 GMT, Joel Borggrén-Franck  
wrote:

> Are there any benchmarks to compare this accessor with the previous version 
> in the presumably common case where there is no or very little contention? 
> Edit to clarify: it is stated as "trivial" is this also measured somewhere?

@jbf  in presumably common case,  one extra CAS is added when invocation reach 
threshold.
MethodInvoke in jdk repo micro benchmark test shows no regression with this 
patch.

**Before patch**
Benchmark  Mode  Cnt   Score   Error  Units
MethodInvoke.invokeWithSixObjectParams avgt   25   5.443 ? 0.008  ns/op
MethodInvoke.invokeWithSixPrimitiveParams  avgt   25  10.195 ? 0.020  ns/op
MethodInvoke.invokeWithoutParams   avgt   25   3.919 ? 0.011  ns/op

Benchmark  Mode  Cnt   Score   Error  Units
MethodInvoke.invokeWithSixObjectParams avgt   25   5.440 ? 0.012  ns/op
MethodInvoke.invokeWithSixPrimitiveParams  avgt   25  10.197 ? 0.028  ns/op
MethodInvoke.invokeWithoutParams   avgt   25   3.923 ? 0.010  ns/op

**After patch**
Benchmark  Mode  Cnt   Score   Error  Units
MethodInvoke.invokeWithSixObjectParams avgt   25   5.438 ? 0.005  ns/op
MethodInvoke.invokeWithSixPrimitiveParams  avgt   25  10.190 ? 0.038  ns/op
MethodInvoke.invokeWithoutParams   avgt   25   3.930 ? 0.010  ns/op
Finished running test 'micro:java.lang.reflect.MethodInvoke'

Benchmark  Mode  Cnt   Score   Error  Units
MethodInvoke.invokeWithSixObjectParams avgt   25   5.442 ? 0.009  ns/op
MethodInvoke.invokeWithSixPrimitiveParams  avgt   25  10.205 ? 0.034  ns/op
MethodInvoke.invokeWithoutParams   avgt   25   3.916 ? 0.005  ns/op

-

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

Re: RFR: 8247781: Day periods support [v10]

[Naoto Sato]

> Hi,
> 
> Please review the changes for the subject issue. This is to enhance the 
> java.time package to support day periods, such as "in the morning", defined 
> in CLDR. It will add a new pattern character 'B' and its supporting builder 
> method. The motivation and its spec are in this CSR:
> 
> https://bugs.openjdk.java.net/browse/JDK-8254629
> 
> Naoto

Naoto Sato has updated the pull request incrementally with one additional 
commit since the last revision:

  Addressing https://github.com/openjdk/jdk/pull/938#discussion_r519061476

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/938/files
  - new: https://git.openjdk.java.net/jdk/pull/938/files/3a9ea64a..7140ae27

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

  Stats: 90 lines in 3 files changed: 56 ins; 34 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/938.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/938/head:pull/938

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

Re: RFR: 8247781: Day periods support [v10]

[Naoto Sato]

On Fri, 6 Nov 2020 23:59:36 GMT, Stephen Colebourne  
wrote:

>> I find the whole "half way between the start and end" behaviour of day 
>> periods odd anyway, but if it is to be supported then it should be 
>> consistent as you've implemented. 
>> 
>> Another option I should have thought of earlier would be to simply not 
>> support the "half way between the start and end" behaviour of LDML in either 
>> dayPeriod or AM/PM. But since LDML defines it, you've implemented it, and it 
>> isn't overly harmful I think its OK to leave it in.
>> 
>> Would it be possible for STRICT mode to not have the "half way between the 
>> start and end" behaviour?
>
> I've had a look tonight, but found two more problems!
> 
> The comments at the start of `resolveTimeLenient()` indicate that setting the 
> midpoint in `resolveTimeFields()` is a bad idea - it needs to be done inside 
> `resolveTimeLenient()`. (This ensures user-defined fields can resolve to 
> ChronoFields IIRC). Thus, the day period resolving would have to be split 
> between the two methods. How important is the midpoint logic? Could it just 
> be dropped?
> 
> Secondly, we need to ensure that "24:00 midnight" (using HOUR_OF_DAY only) 
> correctly parses to the end of day midnight, not the start of day or an 
> exception. This is related to the problem above. 
> 
> I _think_ (but haven't confirmed everything yet) that the only thing that 
> should be in `resolveTimeFields()` is the resolution of HOUR_OF_AMPM + 
> dayPeriod to HOUR_OF_DAY (with `dayPeriod` then being set to `null`). 
> Everything else should go in `resolveTimeLenient()` - the midpoint logic in 
> the first if block (where time fields are defaulted), and the validation 
> logic at the end of the method.

Thanks for the insights. I believe I fixed both of the issues with the new 
commit.

-

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

Re: RFR: 8180352: Add Stream.toList() method

[Alan Snyder]

> On Nov 8, 2020, at 3:32 AM, fo...@univ-mlv.fr wrote:
> 
> It's a strawman but the effect is real, the more interfaces you have the less 
> you can reuse code because the code is written with the wrong interface for 
> your use case. 

There are points of compromise. If someone can accept misbehavior, they can use 
interfaces that are pure access interfaces, such as Iterator and Stream.

> Following the same reasoning, you can say that having interfaces saying that 
> collections are null hostile is even more important because it alleviate the 
> issue with NullPointerException. 

My own immutable collection classes are also null-intolerant. No explosion 
there. Use Optional instead.

> Array vs List is not something we can be very proud of, by example in 
> java.lang.invoke, we have several methods that are duplicated only because of 
> this dichotomy. 
> File vs Path is less an issue because it's between implementation classes, 
> not interfaces, anyway, you still have a number of methods inside 
> java.io/java.nio  that are duplicated.

Progress with backwards compatibility requires some duplication. It is nothing 
to be ashamed about.

I’m more ashamed that Type<> notation cannot be used with arrays and [] 
notation cannot be used with Lists.

  Alan

Re: RFR: 8066622 8066637: remove deprecated using java.io.File.toURL() in internal classes

[Phil Race]

On Sat, 7 Nov 2020 07:55:03 GMT, Sebastian Ritter 
 wrote:

> In result of Javadoc to do not use java.io.File.toURL()
> Change use  java.io.File.toURL().toURI() instead.

You reference a desktop bug that discusses many, many deprecations
and skara has identified https://bugs.openjdk.java.net/browse/JDK-8066622
as the issue being fixed.
Yet you propose to fix precisely one of these.
But when this is integrated that bug will be closed out as resolved.
I think you need a new bug about JUST the changes you are making.
So I don't think you should use that bug id any where in this PR.
And I'd like to hear whether you actually *tested* splashscreen with your 
change ? I see no sign that you did.

-

Changes requested by prr (Reviewer).

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

Re: RFR: 8254162: Implementation of Foreign-Memory Access API (Third Incubator) [v22]

[Alan Bateman]

On Thu, 5 Nov 2020 17:14:16 GMT, Maurizio Cimadamore  
wrote:

>> This patch contains the changes associated with the third incubation round 
>> of the foreign memory access API incubation  (see JEP 393 [1]). This 
>> iteration focus on improving the usability of the API in 3 main ways:
>> 
>> * first, by providing a way to obtain truly *shared* segments, which can be 
>> accessed and closed concurrently from multiple threads
>> * second, by providing a way to register a memory segment against a 
>> `Cleaner`, so as to have some (optional) guarantee that the memory will be 
>> deallocated, eventually
>> * third, by not requiring users to dive deep into var handles when they 
>> first pick up the API; a new `MemoryAccess` class has been added, which 
>> defines several useful dereference routines; these are really just thin 
>> wrappers around memory access var handles, but they make the barrier of 
>> entry for using this API somewhat lower.
>> 
>> A big conceptual shift that comes with this API refresh is that the role of 
>> `MemorySegment` and `MemoryAddress` is not the same as it used to be; it 
>> used to be the case that a memory address could (sometimes, not always) have 
>> a back link to the memory segment which originated it; additionally, memory 
>> access var handles used `MemoryAddress` as a basic unit of dereference.
>> 
>> This has all changed as per this API refresh;  now a `MemoryAddress` is just 
>> a dumb carrier which wraps a pair of object/long addressing coordinates; 
>> `MemorySegment` has become the star of the show, as far as dereferencing 
>> memory is concerned. You cannot dereference memory if you don't have a 
>> segment. This improves usability in a number of ways - first, it is a lot 
>> easier to wrap native addresses (`long`, essentially) into a 
>> `MemoryAddress`; secondly, it is crystal clear what a client has to do in 
>> order to dereference memory: if a client has a segment, it can use that; 
>> otherwise, if the client only has an address, it will have to create a 
>> segment *unsafely* (this can be done by calling 
>> `MemoryAddress::asSegmentRestricted`).
>> 
>> A list of the API, implementation and test changes is provided below. If  
>> you have any questions, or need more detailed explanations, I (and the  rest 
>> of the Panama team) will be happy to point at existing discussions,  and/or 
>> to provide the feedback required. 
>> 
>> A big thank to Erik Osterlund, Vladimir Ivanov and David Holmes, without 
>> whom the work on shared memory segment would not have been possible; also 
>> I'd like to thank Paul Sandoz, whose insights on API design have been very 
>> helpful in this journey.
>> 
>> Thanks 
>> Maurizio 
>> 
>> Javadoc: 
>> 
>> http://cr.openjdk.java.net/~mcimadamore/8254162_v1/javadoc/jdk/incubator/foreign/package-summary.html
>> 
>> Specdiff: 
>> 
>> http://cr.openjdk.java.net/~mcimadamore/8254162_v1/specdiff/jdk/incubator/foreign/package-summary.html
>> 
>> CSR: 
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8254163
>> 
>> 
>> 
>> ### API Changes
>> 
>> * `MemorySegment`
>>   * drop factory for restricted segment (this has been moved to 
>> `MemoryAddress`, see below)
>>   * added a no-arg factory for a native restricted segment representing 
>> entire native heap
>>   * rename `withOwnerThread` to `handoff`
>>   * add new `share` method, to create shared segments
>>   * add new `registerCleaner` method, to register a segment against a cleaner
>>   * add more helpers to create arrays from a segment e.g. `toIntArray`
>>   * add some `asSlice` overloads (to make up for the fact that now segments 
>> are more frequently used as cursors)
>>   * rename `baseAddress` to `address` (so that `MemorySegment` can implement 
>> `Addressable`)
>> * `MemoryAddress`
>>   * drop `segment` accessor
>>   * drop `rebase` method and replace it with `segmentOffset` which returns 
>> the offset (a `long`) of this address relative to a given segment
>> * `MemoryAccess`
>>   * New class supporting several static dereference helpers; the helpers are 
>> organized by carrier and access mode, where a carrier is one of the usual 
>> suspect (a Java primitive, minus `boolean`); the access mode can be simple 
>> (e.g. access base address of given segment), or indexed, in which case the 
>> accessor takes a segment and either a low-level byte offset,or a high level 
>> logical index. The classification is reflected in the naming scheme (e.g. 
>> `getByte` vs. `getByteAtOffset` vs `getByteAtIndex`).
>> * `MemoryHandles`
>>   * drop `withOffset` combinator
>>   * drop `withStride` combinator
>>   * the basic memory access handle factory now returns a var handle which 
>> takes a `MemorySegment` and a `long` - from which it is easy to derive all 
>> the other handles using plain var handle combinators.
>> * `Addressable`
>>   * This is a new interface which is attached to entities which can be 
>> projected to a `MemoryAddress`. For now, both `MemoryAddress` and 
>> 

Re: RFR: 8180352: Add Stream.toList() method [v2]

[Peter Levart]

On Sun, 8 Nov 2020 10:47:08 GMT, Peter Levart  wrote:

>>> Simon Roberts wrote:
>> 
>>> This discussion of unmodifiable lists brings me back to the thought that
>>> there would be good client-side reasons for inserting an UnmodifiableList
>>> interface as a parent of LIst, not least because all our unmodifiable
>>> variants from the Collections.unmodifiableList proxy onward fail the Liskov
>>> substitution test for actually "being contract-fulfilling Lists".
>> 
>> At some point there probably will need to be a long article explaining all 
>> the issues here, but at the moment the best writeup I have is this one:
>> 
>> https://stackoverflow.com/a/57926310/1441122
>> 
>> TL;DR there are a few different ways to approach retrofitting something like 
>> this, but they all have enough compromises that the net benefits are unclear.
>
> Hi Stuart,
> 
> I would like to discuss the serialization. You introduce new 
> CollSer.IMM_LIST_NULLS type of immutable collection. This means that if this 
> change goes into JDK16 for example, JDK15 and before will not be able to 
> deserialize such list as they know nothing about IMM_LIST_NULLS even if such 
> lists don't contain nulls. The reason you say to chose new type of 
> serialization format is the following:
> 
>> "Suppose I had an application that created a data structure that used lists 
>> from List.of(), and I had a global assertion over that structure that it 
>> contained no nulls. Further suppose that I serialized and deserizalized this 
>> structure. I'd want that assertion to be preserved after deserialization. If 
>> another app (or a future version of this app) created the structure using 
>> Stream.to
>>  List(), this would allow nulls to leak into that structure and violate that 
>> assertion. Therefore, the result of Stream.toList() should not be 
>> serialization-compatible with List.of() et. al. That's why there's the new 
>> IMM_LIST_NULLS tag in the serial format"
> 
> I don't quite get this reasoning. Let's try to decompose the reasoning giving 
> an example. Suppose we had the following data structure:
> 
> public class Names implements Serializable {
>   private final List names;
>   Names(List names) {
> this.names = names;
>   }
>   public List names() { return names; }
> }
> 
> App v1 creates such structures using new Names(List.of(...)) and 
> serializes/deserializes them. They keep the invariant that no nulls are 
> present. Now comes App v2 that starts using new Names(stream.toList()) which 
> allows nulls to be present. When such Names instance from app v2 is 
> serialized and then deserialized in app v1, nulls "leak" into data structure 
> of app v1 that does not expect them.
> 
> But the question is how does having a separate CollSer.IMM_LIST_NULLS type 
> prevent that from happening?

I can see that having a separate IMM_LIST_NULLS type might be necessary to 
preserve the allows-null/disallows-null behaviour of indexOf and lastIndexOf 
methods...

NOTE ALSO that while ListN.equals(o) method is using Objects.equals(o1, o2) to 
compare elements, hashCode is inherited from AbstractImmutableList:

public int hashCode() {
int hash = 1;
for (int i = 0, s = size(); i < s; i++) {
hash = 31 * hash + get(i).hashCode();
}
return hash;
}

...which means it will throw NPE when the list contains null. The same goes for 
SubList.

-

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

Re: Class TreeMap | Lower and Upper Count Support

[forax]

> De: "mayank bansal" 
> À: "Remi Forax" 
> Cc: "core-libs-dev" 
> Envoyé: Dimanche 8 Novembre 2020 12:55:09
> Objet: Re: Class TreeMap | Lower and Upper Count Support

> Hi Remi,
> Thank you for pointing that out. This is providing the same feature but it is
> not the optimal approach for calculating the size.

> AscendingSubMap().size() is actually iterating each and every element using
> Iterator to calculate the size resulting in the O(N) time complexity which can
> be reduced to O(logN) and this will be a huge improvement. Code snippet for 
> the
> reference - [
> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/TreeMap.java#L1937-L1950
> |
> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/TreeMap.java#L1937-L1950
> ]

> I am coming from the fact that I was trying to solve one coding problem, I 
> tried
> using own [ https://leetcode.com/submissions/detail/418028305/ | Balanced BST 
> ]
> (AVL tree) and it executed in ~180ms and when I tried using [
> https://leetcode.com/submissions/detail/418070375/ | TreeSet headSet().size() 
> ]
> , it resulted in a TLE - Time Limit Exceeded.

Interesting, I've always though that all collections of java.util had a size() 
implementation in O(1). 
It may be worth fixing this if there is a simple fix. 

One issue with TreeMap is that unlike most of the other implementations, 
TreeMap is not used a lot so we are still discovering issues. 

Rémi 

> On Sun, Nov 8, 2020 at 4:09 PM Remi Forax < [ mailto:fo...@univ-mlv.fr |
> fo...@univ-mlv.fr ] > wrote:

>> Is it different from
>> headMap(key, true).size() / tailMap(key, true).size() ?

>> [
>> https://docs.oracle.com/en/java/javase/15/docs/api/java.base/java/util/NavigableMap.html#headMap(K,boolean)
>> |
>> https://docs.oracle.com/en/java/javase/15/docs/api/java.base/java/util/NavigableMap.html#headMap(K,boolean)
>> ]
>> [
>> https://docs.oracle.com/en/java/javase/15/docs/api/java.base/java/util/NavigableMap.html#tailMap(K,boolean)
>> |
>> https://docs.oracle.com/en/java/javase/15/docs/api/java.base/java/util/NavigableMap.html#tailMap(K,boolean)
>> ]

>> cheers,
>> Rémi

>> - Mail original -
>>> De: "mayank bansal" < [ mailto:mayankbansal...@gmail.com |
>> > mayankbansal...@gmail.com ] >
>>> À: "core-libs-dev" < [ mailto:core-libs-dev@openjdk.java.net |
>> > core-libs-dev@openjdk.java.net ] >
>> > Envoyé: Dimanche 8 Novembre 2020 11:22:01
>> > Objet: Class TreeMap | Lower and Upper Count Support

>> > Hi Everyone,

>> > I would like to propose and work on a feature request of supporting the
>> > lower and higher count in java class TreeMap.
>> > "lower count" is the number of elements that are strictly less than the
>> > given value.
>> > "upper count" is the number of elements that are strictly greater than the
>> > given value.

>> > *Method definitions-*
>> > int getLowerCount(K key);
>> > int getHigherCount(K key);

>> > *Follow-up feature -*
>> > Class TreeSet constructor initializes the TreeMap in the TreeSet
>> > constructor.
>> > It puts the dummy value as *new Object()* whenever we add the entry in
>> > TreeSet.
>> > I would like to work on the feature to provide the *Duplicate count* in
>> > case of the same Key and the same Value.

>> > I will be happy to work on both and raise a PR. I need some guidance if the
>> > proposed feature looks good and I can start working on it and also would
>> > like to know about the process whether I can directly raise the PR.

>> > Thanks
>> > --
>> > Regards,
>> > Mayank Bansal

> --
> Regards,
> Mayank Bansal

Re: Class TreeMap | Lower and Upper Count Support

[mayank bansal]

Hi Remi,

Thank you for pointing that out. This is providing the same feature but it
is not the optimal approach for calculating the size.

AscendingSubMap().size() is actually iterating each and every element using
Iterator to calculate the size resulting in the O(N) time complexity which
can be reduced to O(logN) and this will be a huge improvement. Code snippet
for the reference -
https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/TreeMap.java#L1937-L1950

I am coming from the fact that I was trying to solve one coding problem, I
tried using own Balanced BST
 (AVL tree) and it
executed in ~180ms and when I tried using TreeSet headSet().size()
, it resulted in a TLE
- Time Limit Exceeded.



On Sun, Nov 8, 2020 at 4:09 PM Remi Forax  wrote:

> Is it different from
>  headMap(key, true).size() / tailMap(key, true).size() ?
>
>
> https://docs.oracle.com/en/java/javase/15/docs/api/java.base/java/util/NavigableMap.html#headMap(K,boolean)
>
> https://docs.oracle.com/en/java/javase/15/docs/api/java.base/java/util/NavigableMap.html#tailMap(K,boolean)
>
> cheers,
> Rémi
>
> - Mail original -
> > De: "mayank bansal" 
> > À: "core-libs-dev" 
> > Envoyé: Dimanche 8 Novembre 2020 11:22:01
> > Objet: Class TreeMap | Lower and Upper Count Support
>
> > Hi Everyone,
> >
> > I would like to propose and work on a feature request of supporting the
> > lower and higher count in java class TreeMap.
> > "lower count" is the number of elements that are strictly less than the
> > given value.
> > "upper count" is the number of elements that are strictly greater than
> the
> > given value.
> >
> > *Method definitions-*
> > int getLowerCount(K key);
> > int getHigherCount(K key);
> >
> > *Follow-up feature -*
> > Class TreeSet constructor initializes the TreeMap in the TreeSet
> > constructor.
> > It puts the dummy value as *new Object()* whenever we add the entry in
> > TreeSet.
> > I would like to work on the feature to provide the *Duplicate count* in
> > case of the same Key and the same Value.
> >
> > I will be happy to work on both and raise a PR. I need some guidance if
> the
> > proposed feature looks good and I can start working on it and also would
> > like to know about the process whether I can directly raise the PR.
> >
> > Thanks
> > --
> > Regards,
> > Mayank Bansal
>


-- 
Regards,
Mayank Bansal

Re: Filtered XMLStreamReader Exceptions (java.xml)

[Michael Edgar]

Hi Joe,

This is the first issue I have worked on with openjdk so I assume I will
need a sponsor (I do not have a JBS account). Regarding the PR, I am not
familiar with the Skara process. Is there anything I need to know beyond
the typical GitHub PR process?

Thanks,
Mike


On Thu, Nov 5, 2020 at 8:22 PM Joe Wang  wrote:

> Hi Mike,
>
> I saw that you are on the OCA list but not census
> , I therefore assumed you'd need a
> sponsor, or would you?  Let me know if I'm mistaken. If you're an openjdk
> author/committer and have a JBS account, please go ahead take over the bug
> and create a CSR. Creating a CSR is straight-forward: from the JBS bug,
> click more -> create CSR and follow the template.
>
> You mentioned you're going to submit a PR. Are you familiar with the Skara
> process or have you already done it?
>
> Thanks,
> Joe
>
> On 11/5/20 1:35 PM, Michael Edgar wrote:
>
> The bug for this issue was accepted: JDK-8255918. I have made the change
> that I suggested in my original email and tested, but have not yet opened a
> pull request. Please let me know what (if anything) needs to occur for the
> CSR process due to the method signature change (added `throws`).
>
> Thank you,
> Mike
>
>
> On Wed, Oct 28, 2020 at 12:52 PM Joe Wang  wrote:
>
>> Hi Mike,
>>
>> As you said, creating a bug report would be a good start. If it involves
>> a signature change, it'd need to go through a proper review (CSR) process.
>>
>> When you are ready to submit a bug report, please make sure to add a
>> test case to illustrate the use case scenario.
>>
>> Thanks,
>> Joe
>>
>> On 10/28/20 5:14 AM, Michael Edgar wrote:
>> > Hi everyone,
>> > I'm working on a project that makes use of the StAX API and an issue I
>> have
>> > encountered is that when wrapping an `XMLStreamReader` with a
>> > `StreamFilter`, errors encountered in the setup are not thrown to the
>> > caller. The source of the error could be any stream error that is
>> triggered
>> > as the `XMLStreamFilterImpl` advances to the next acceptable event.
>> > Ultimately, when attempting to utilize the filtered reader, some
>> secondary
>> > exception will occur, but the original `Exception` is lost.
>> >
>> > I have not seen any other issues related specifically to this problem,
>> so I
>> > would like to propose removal of the try/catch in the constructor of
>> > `com.sun.org.apache.xerces.internal.impl.XMLStreamFilterImpl` and the
>> > method signature changed to declare that `XMLStreamException` is thrown.
>> > The constructor is used by
>> >
>> `com.sun.xml.internal.stream.XMLInputFactoryImpl.createFilteredReader(XMLStreamReader,
>> > StreamFilter)` which itself already declares the same exception and is
>> an
>> > implementation of the public `XMLInputFactory` interface.
>> >
>> > Further, the `nextTag` method of the same class has a bug where it
>> checks
>> > for `START_ELEMENT` events twice.
>> >
>> > I have an OCA in place and I am happy to submit a PR, but I believe
>> that a
>> > bug record needs to be opened in order to proceed.
>> >
>> > Thank you,
>> > Mike
>>
>>
>

Re: RFR: 8180352: Add Stream.toList() method

[forax]

> De: "Alan Snyder" 
> À: "Remi Forax" 
> Cc: "Simon Roberts" , "core-libs-dev"
> 
> Envoyé: Vendredi 6 Novembre 2020 18:55:40
> Objet: Re: RFR: 8180352: Add Stream.toList() method
Hi Alan, 

>>> This discussion of unmodifiable lists brings me back to the thought that
>>> there would be good client-side reasons for inserting an UnmodifiableList
>>> interface as a parent of LIst
>> On Nov 6, 2020, at 1:14 AM, Remi Forax < [ mailto:fo...@univ-mlv.fr |
>> fo...@univ-mlv.fr ] > wrote:

>> This question is asked at least every six months since 1998
>> [
>> https://docs.oracle.com/javase/8/docs/technotes/guides/collections/designfaq.html#a1
>> |
>> https://docs.oracle.com/javase/8/docs/technotes/guides/collections/designfaq.html#a1
>> ]

> The question that Simon asked is not exactly the question that is answered in
> this link.

> The question of whether List should be a subtype of (some kind of) 
> ImmutableList
> is answered in
> Stuart’s stack overflow answer ( [ 
> https://stackoverflow.com/a/57926310/1441122
> | https://stackoverflow.com/a/57926310/1441122 ] ). The answer
> is that it should not.

> The question answered in the link is basically a straw man: why not capture
> every conceivable
> semantic distinction in the collections type system. And the answer is, not
> surprisingly, that
> there would be way too many types.

It's a strawman but the effect is real, the more interfaces you have the less 
you can reuse code because the code is written with the wrong interface for 
your use case. 

> But a question that deserves ongoing review is whether Java should support
> immutable collections
> using a separate type hierarchy. In other words, Immutable List would not be a
> subtype of List
> and List would not be a subtype of Immutable List. The linked answer says:
> " Adding this support to the type hierarchy requires four more interfaces.” 
> Four
> additional
> interfaces sounds like a small cost for a significant benefit. As Java evolves
> to better support
> functional programming styles, immutable collections seems like an obvious 
> next
> step.

> Much could be written, and probably has been, about the disadvantages of 
> basing
> the
> collections framework on mutable collections. Let me just remark that in
> addition to the
> already mentioned UnsupportedOperationException, there is also the more subtle
> ConcurrentModificationException, both of which would be absent in fully
> immutable collections.

Following the same reasoning, you can say that having interfaces saying that 
collections are null hostile is even more important because it alleviate the 
issue with NullPointerException. 

> The lack of subtyping between List and ImmutableList is not terrible. Arrays
> coexist with
> Lists with no subtyping relationship. java.io.File coexists with
> java.nio.filePath with no
> subtyping relationship. It means that explicit conversions are required 
> between
> List and
> ImmutableList. Extra copying may be needed, but there are tricks for reducing
> copying, and the
> need for defensive copying is removed.

Array vs List is not something we can be very proud of, by example in 
java.lang.invoke, we have several methods that are duplicated only because of 
this dichotomy. 
File vs Path is less an issue because it's between implementation classes, not 
interfaces, anyway, you still have a number of methods inside java.io/java.nio 
that are duplicated. 

Anyway, I don't think we can *all* agree about how a collection API should be 
implemented because it is equivalent to answering to the question what you want 
to be part of the type system and what you want to be runtime exceptions. 
With that in minde, Java is in the middle between Clojure and Scala. 

> Alan

Rémi 

Re: RFR: 8180352: Add Stream.toList() method [v2]

[Peter Levart]

On Fri, 6 Nov 2020 03:05:45 GMT, Stuart Marks  wrote:

>> @ePaul wrote:
>> 
>>> The Stream API works just as well with [third party] collection libraries 
>>> instead of the java.util ones, just using different collectors. Adding a 
>>> method which directly returns a java.util.List somewhat couples it to the 
>>> Java Collection API.
>>> 
>>> Now this was mentioned two and a half year ago. Did something change which 
>>> made this consideration irrelevant? I would expect at least some mention of 
>>> it in the discussion here.
>> 
>> The separation between streams and the java.util Collections Framework is a 
>> good design principle, but it isn't an ironclad rule. It's still easy to 
>> have streams create instances of other collections libraries using the 
>> Collector interface. What's different here is that the Collections Framework 
>> has "leaked into" streams a little bit more, so that they're now more 
>> interdependent. This doesn't seem to have any disadvantages; it seems 
>> unlikely that the Collections Framework will ever be unplugged from the JDK. 
>> However, the benefits are that a List is the closest thing we have to an 
>> unmodifiable array that also plays well with generics and that can be 
>> value-based; these benefits are considerable.
>
>> Simon Roberts wrote:
> 
>> This discussion of unmodifiable lists brings me back to the thought that
>> there would be good client-side reasons for inserting an UnmodifiableList
>> interface as a parent of LIst, not least because all our unmodifiable
>> variants from the Collections.unmodifiableList proxy onward fail the Liskov
>> substitution test for actually "being contract-fulfilling Lists".
> 
> At some point there probably will need to be a long article explaining all 
> the issues here, but at the moment the best writeup I have is this one:
> 
> https://stackoverflow.com/a/57926310/1441122
> 
> TL;DR there are a few different ways to approach retrofitting something like 
> this, but they all have enough compromises that the net benefits are unclear.

Hi Stuart,

I would like to discuss the serialization. You introduce new 
CollSer.IMM_LIST_NULLS type of immutable collection. This means that if this 
change goes into JDK16 for example, JDK15 and before will not be able to 
deserialize such list as they know nothing about IMM_LIST_NULLS even if such 
lists don't contain nulls. The reason you say to chose new type of 
serialization format is the following:

> "Suppose I had an application that created a data structure that used lists 
> from List.of(), and I had a global assertion over that structure that it 
> contained no nulls. Further suppose that I serialized and deserizalized this 
> structure. I'd want that assertion to be preserved after deserialization. If 
> another app (or a future version of this app) created the structure using 
> Stream.to
>  List(), this would allow nulls to leak into that structure and violate that 
> assertion. Therefore, the result of Stream.toList() should not be 
> serialization-compatible with List.of() et. al. That's why there's the new 
> IMM_LIST_NULLS tag in the serial format"

I don't quite get this reasoning. Let's try to decompose the reasoning giving 
an example. Suppose we had the following data structure:

public class Names implements Serializable {
  private final List names;
  Names(List names) {
this.names = names;
  }
  public List names() { return names; }
}

App v1 creates such structures using new Names(List.of(...)) and 
serializes/deserializes them. They keep the invariant that no nulls are 
present. Now comes App v2 that starts using new Names(stream.toList()) which 
allows nulls to be present. When such Names instance from app v2 is serialized 
and then deserialized in app v1, nulls "leak" into data structure of app v1 
that does not expect them.

But the question is how does having a separate CollSer.IMM_LIST_NULLS type 
prevent that from happening?

-

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

Re: Class TreeMap | Lower and Upper Count Support

[Remi Forax]

Is it different from
 headMap(key, true).size() / tailMap(key, true).size() ?

https://docs.oracle.com/en/java/javase/15/docs/api/java.base/java/util/NavigableMap.html#headMap(K,boolean)
https://docs.oracle.com/en/java/javase/15/docs/api/java.base/java/util/NavigableMap.html#tailMap(K,boolean)

cheers,
Rémi

- Mail original -
> De: "mayank bansal" 
> À: "core-libs-dev" 
> Envoyé: Dimanche 8 Novembre 2020 11:22:01
> Objet: Class TreeMap | Lower and Upper Count Support

> Hi Everyone,
> 
> I would like to propose and work on a feature request of supporting the
> lower and higher count in java class TreeMap.
> "lower count" is the number of elements that are strictly less than the
> given value.
> "upper count" is the number of elements that are strictly greater than the
> given value.
> 
> *Method definitions-*
> int getLowerCount(K key);
> int getHigherCount(K key);
> 
> *Follow-up feature -*
> Class TreeSet constructor initializes the TreeMap in the TreeSet
> constructor.
> It puts the dummy value as *new Object()* whenever we add the entry in
> TreeSet.
> I would like to work on the feature to provide the *Duplicate count* in
> case of the same Key and the same Value.
> 
> I will be happy to work on both and raise a PR. I need some guidance if the
> proposed feature looks good and I can start working on it and also would
> like to know about the process whether I can directly raise the PR.
> 
> Thanks
> --
> Regards,
> Mayank Bansal

Class TreeMap | Lower and Upper Count Support

[mayank bansal]

Hi Everyone,

I would like to propose and work on a feature request of supporting the
lower and higher count in java class TreeMap.
"lower count" is the number of elements that are strictly less than the
given value.
"upper count" is the number of elements that are strictly greater than the
given value.

*Method definitions-*
int getLowerCount(K key);
int getHigherCount(K key);

*Follow-up feature -*
Class TreeSet constructor initializes the TreeMap in the TreeSet
constructor.
It puts the dummy value as *new Object()* whenever we add the entry in
TreeSet.
I would like to work on the feature to provide the *Duplicate count* in
case of the same Key and the same Value.

I will be happy to work on both and raise a PR. I need some guidance if the
proposed feature looks good and I can start working on it and also would
like to know about the process whether I can directly raise the PR.

Thanks
-- 
Regards,
Mayank Bansal

Re: RFR: 8254162: Implementation of Foreign-Memory Access API (Third Incubator)

[Alan Bateman]

On Wed, 4 Nov 2020 07:45:09 GMT, Alan Bateman  wrote:

>>> The javadoc for copyFrom isn't changed in this update but I notice it 
>>> specifies IndexOutOfBoundException when the source segment is larger than 
>>> the receiver, have other exceptions been examined?
>> 
>> This exception is consistent with other uses of this exception throughout 
>> this API (e.g. when writing a segment out of bounds).
>
> I assume the CSR needs to be updated so that it's in sync with the API 
> changes in the latest round.

I see the xxxByteAtIndex methods that took a ByteOrder have been removed from 
MemoryAccess. Should the xxxByte and xxxByteAtOffset that take a ByteOrder be 
removed too?

-

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