Proposal: Replace foreach loop with Iterable.forEach in String.join(CharSequence, Iterable)
The following code:
for (CharSequence cs: elements) {
joiner.add(cs);
}
Can be replaced with:
elements.forEach(joiner::add);
This would have the minor benefit of making it safe to use String.join with
synchronized collections without requiring a client side lock. There are likely
other opportunities like this in the JDK.
Also, with the addition of forEach on Iterable, and Predicate in Java 8, the
following design FAQ is outdated.
https://docs.oracle.com/en/java/javase/16/docs/api/java.base/java/util/doc-files/coll-designfaq.html#a6
Thanks,
Don
Re: RFR: 8272137: Make Collection and Optional classes streamable
On Mon, 9 Aug 2021 12:28:23 GMT, CC007 wrote: > create Streamable and ParallelStreamable interface and use them in Collection > and Optional The List and Collection interface was almost directly taken from java.util (apart from the small feature interfaces, that I extracted from them), so it would make sense that those classes use an older design. Are you suggesting that there are deeper architectural issues with the hierarchy-heavy collection stack? Would it be better if a list contained a collection, rather than inheriting from it? If that is the case, anything that is proposed in this PR is merely aiming at symptoms of a possibility much larger underlying problem, which might require going back to the drawing board for all collection related features. - PR: https://git.openjdk.java.net/jdk/pull/5050
Re: RFR: 8272137: Make Collection and Optional classes streamable
On Mon, 9 Aug 2021 12:28:23 GMT, CC007 wrote: > create Streamable and ParallelStreamable interface and use them in Collection > and Optional You can view the mailing lists at https://mail.openjdk.java.net/mailman/listinfo and subscribe there. If you want to send a mail, just send one to say `jdk-dev` at `openjdk.java.net` (and carbon copy if you reply to a specific person so the list can see a copy) On a separate note, @CC007 your model falls back to the fairly-old inheritance vs embodiment (extending a class vs using it as a field) debate. Nowadays, I think Java has evolved to reduce excessive reliances on inheritances, as there can be clashes (for example, a class cannot implement a comparator for two different type arguments). Also due to these potential of clashing, in a lot of java code, interface implementation classes avoid implementing multiple interfaces at once. - PR: https://git.openjdk.java.net/jdk/pull/5050
Re: RFR: 8272137: Make Collection and Optional classes streamable
On Mon, 9 Aug 2021 12:28:23 GMT, CC007 wrote: > create Streamable and ParallelStreamable interface and use them in Collection > and Optional Also, sorry for my Millennial lack of knowledge of older communication methods, but if I wanted to reply to a specific thread in a mailing list, how would I do that? Does it require certain content in the subject and/or quoted text in the message body? It does feel way less intuitive than just clicking the comment box or clicking `... -> Quote reply` on a comment in this PR - PR: https://git.openjdk.java.net/jdk/pull/5050
Re: RFR: 8272137: Make Collection and Optional classes streamable
On Mon, 16 Aug 2021 03:39:02 GMT, Tagir F. Valeev wrote: >> create Streamable and ParallelStreamable interface and use them in >> Collection and Optional > > Mostly agreed with Brian. Judging from 7 years of using Stream API, I can say > that this abstraction would not solve any real problem. If you need a way to > create many identical streams on demand, just accept `Supplier>`. > This allows more flexibility for clients. They can not only supply > `myCollection::stream` or `myOptional::stream` but also `() -> > Arrays.stream(myArray)`, `() -> IntStream.range(...).boxed()`, `() -> > myCollection.stream().filter(something)` or whatever else. A dedicated > `Streamable` interface is too limited and will require adapters in many cases > but you can already adapt anything to `Supplier>`. People already > use `Supplier>` idiom pretty often, so creating a new `Streamable` > interface would add an API mess: some people would stick with `Supplier` and > others would migrate to `Streamable`. So I vote to reject this PR. > > I said "mostly" because I think that PR is a good starting point for > discussion. It's much easier to explain which enhancement you are proposing > if you already present some code. And we are already at corelibs-dev, as PR > comments are mirrored there, and for some people, it's more comfortable to > discuss via GitHub interface, as you don't have to subscribe and get tons of > unrelated e-mails, you can concentrate on a single discussion only. So in my > opinion, it's completely ok to write code and create a PR before the > discussion, even if it's likely to be thrown away. It is fine that the pull request is closed for now, but I agree with @amaembo that if this conversation is indeed mirrored there, then it shouldn't be a problem to discuss the proposal here, along with the proposed changes. I actually worked out a usecase (See: https://github.com/CC007/InterfaceSegregationDemo), where I partially reimagined the Collection interface stack and its neighboring interfaces/classes. I also added a `Demo` class to show how I imagined to use these interfaces and to show how the granularity of these interfaces can be useful. The fact that I have to create copies of interfaces and delegates for implementations makes me feel like something is lacking in the collection stack and that for this usecase `Supplier` wouldn't cut it, but feel free to fork and refactor my code to prove me wrong. PS: while creating the Demo class, I noticed that it couldn't be analyzed if the return value of a method with type ` & Addable & Iterable & RandomAccess>` could be safely cast to a new local variable with type ` & Addable` and that you can't declare variables of type ` & Addable` (it won't let you use the `&` when using the `?`), but I digress. - PR: https://git.openjdk.java.net/jdk/pull/5050
RFR: 8272369: java/io/File/GetXSpace.java failed with "RuntimeException: java.nio.file.NoSuchFileException: /run/user/0"
This change proposes to exclude `/run/user` mounts from the test when run on Linux as they can "disappear" while the test is running. - Commit messages: - 8272369: java/io/File/GetXSpace.java failed with "RuntimeException: java.nio.file.NoSuchFileException: /run/user/0" Changes: https://git.openjdk.java.net/jdk/pull/5136/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=5136=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8272369 Stats: 15 lines in 1 file changed: 7 ins; 4 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/5136.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5136/head:pull/5136 PR: https://git.openjdk.java.net/jdk/pull/5136
Re: RFR: 8272398: Update DockerTestUtils.buildJdkDockerImage()
On Mon, 16 Aug 2021 23:48:46 GMT, Igor Ignatyev wrote:
>> Please review this change that updates the buildJdkDockerImage() test
>> library API.
>>
>> This work originated while working on "8195809: [TESTBUG] jps and jcmd -l
>> support for containers is not tested".
>> The initial intent was to extend the buildJdkDockerImage() API of
>> DockerTestUtils to accept custom Dockerfile content.
>> As I analyzed the usage of buildJdkDockerImage() I realized that:
>> - 2nd argument "dockerfile" is always the same: "Dockerfile-BasicTest"
>> its use has been obsolete for some time, in favor of Dockerfile
>> generated by DockerTestUtils
>> - 3rd argument "buildDirName" is also always the same: "jdk-docker"
>>
>> Hence I thought it would be a good idea to simplify this API and make it
>> up-to-date.
>>
>> Also, since the method signature is being updated, I thought it would be a
>> good idea to also change the name to use more generic container terminology:
>> buildJdkDockerImage() --> buildJdkContainerImage()
>
> test/lib/jdk/test/lib/containers/docker/DockerTestUtils.java line 179:
>
>> 177: * @throws Exception
>> 178: */
>> 179: public static void buildImage(String imageName, Path buildDir)
>> throws Exception {
>
> it seems there are no users of this method, do we need to keep it public?
Sounds good. Will do.
-
PR: https://git.openjdk.java.net/jdk/pull/5134
Re: RFR: 8272124: Cgroup v1 initialization causes NullPointerException when path contains colon
On Mon, 16 Aug 2021 17:25:57 GMT, Harold Seigel wrote: > Please review this small fix for JDK-8272124. The fix puts a limit of 3 when > splitting self cgroup lines by ':' so that Cgroup paths won't get truncated > if they contain embedded ':'s. For example, an entry of > "11:memory:/user.sli:ce" in a /proc/self/cgroup file will now result in a > Cgroup path of "/user.sli:ce" instead of "/user.sli". > > The fix was tested with Mach5 tiers 1 and 2, and Mach5 tiers 3-5 on Linux x64 > and Linux aarch64. > > Thanks, Harold Changes look good to me. - Marked as reviewed by mseledtsov (Committer). PR: https://git.openjdk.java.net/jdk/pull/5127
Re: RFR: 8272398: Update DockerTestUtils.buildJdkDockerImage()
On Mon, 16 Aug 2021 23:31:41 GMT, Mikhailo Seledtsov
wrote:
> Please review this change that updates the buildJdkDockerImage() test library
> API.
>
> This work originated while working on "8195809: [TESTBUG] jps and jcmd -l
> support for containers is not tested".
> The initial intent was to extend the buildJdkDockerImage() API of
> DockerTestUtils to accept custom Dockerfile content.
> As I analyzed the usage of buildJdkDockerImage() I realized that:
> - 2nd argument "dockerfile" is always the same: "Dockerfile-BasicTest"
> its use has been obsolete for some time, in favor of Dockerfile
> generated by DockerTestUtils
> - 3rd argument "buildDirName" is also always the same: "jdk-docker"
>
> Hence I thought it would be a good idea to simplify this API and make it
> up-to-date.
>
> Also, since the method signature is being updated, I thought it would be a
> good idea to also change the name to use more generic container terminology:
> buildJdkDockerImage() --> buildJdkContainerImage()
Changes requested by iignatyev (Reviewer).
test/lib/jdk/test/lib/containers/docker/DockerTestUtils.java line 145:
> 143:
> 144: // Create an image build/staging directory
> 145: Path buildDir = Paths.get(".", "image-build");
to make it more robust and possible to have more than one container within a
test, I'd use `imagName` + "image-build" as build dir name.
test/lib/jdk/test/lib/containers/docker/DockerTestUtils.java line 179:
> 177: * @throws Exception
> 178: */
> 179: public static void buildImage(String imageName, Path buildDir)
> throws Exception {
it seems there are no users of this method, do we need to keep it public?
-
PR: https://git.openjdk.java.net/jdk/pull/5134
Re: RFR: 8272398: Update DockerTestUtils.buildJdkDockerImage()
On Mon, 16 Aug 2021 23:47:04 GMT, Igor Ignatyev wrote:
>> Please review this change that updates the buildJdkDockerImage() test
>> library API.
>>
>> This work originated while working on "8195809: [TESTBUG] jps and jcmd -l
>> support for containers is not tested".
>> The initial intent was to extend the buildJdkDockerImage() API of
>> DockerTestUtils to accept custom Dockerfile content.
>> As I analyzed the usage of buildJdkDockerImage() I realized that:
>> - 2nd argument "dockerfile" is always the same: "Dockerfile-BasicTest"
>> its use has been obsolete for some time, in favor of Dockerfile
>> generated by DockerTestUtils
>> - 3rd argument "buildDirName" is also always the same: "jdk-docker"
>>
>> Hence I thought it would be a good idea to simplify this API and make it
>> up-to-date.
>>
>> Also, since the method signature is being updated, I thought it would be a
>> good idea to also change the name to use more generic container terminology:
>> buildJdkDockerImage() --> buildJdkContainerImage()
>
> test/lib/jdk/test/lib/containers/docker/DockerTestUtils.java line 145:
>
>> 143:
>> 144: // Create an image build/staging directory
>> 145: Path buildDir = Paths.get(".", "image-build");
>
> to make it more robust and possible to have more than one container within a
> test, I'd use `imagName` + "image-build" as build dir name.
you also don't need to have `.` as a first argument, `Paths.get("x")` returns
you a path to "x" in current directory.
-
PR: https://git.openjdk.java.net/jdk/pull/5134
Withdrawn: 8272137: Make Collection and Optional classes streamable
On Mon, 9 Aug 2021 12:28:23 GMT, CC007 wrote: > create Streamable and ParallelStreamable interface and use them in Collection > and Optional This pull request has been closed without being integrated. - PR: https://git.openjdk.java.net/jdk/pull/5050
Re: RFR: 8272398: Update DockerTestUtils.buildJdkDockerImage()
On Mon, 16 Aug 2021 23:31:41 GMT, Mikhailo Seledtsov wrote: > Please review this change that updates the buildJdkDockerImage() test library > API. > > This work originated while working on "8195809: [TESTBUG] jps and jcmd -l > support for containers is not tested". > The initial intent was to extend the buildJdkDockerImage() API of > DockerTestUtils to accept custom Dockerfile content. > As I analyzed the usage of buildJdkDockerImage() I realized that: > - 2nd argument "dockerfile" is always the same: "Dockerfile-BasicTest" > its use has been obsolete for some time, in favor of Dockerfile > generated by DockerTestUtils > - 3rd argument "buildDirName" is also always the same: "jdk-docker" > > Hence I thought it would be a good idea to simplify this API and make it > up-to-date. > > Also, since the method signature is being updated, I thought it would be a > good idea to also change the name to use more generic container terminology: > buildJdkDockerImage() --> buildJdkContainerImage() @hseigel Could you please review when you have a chance ? Testing: - ran jdk/containers and hotspot/containers tests on - OL 7.9 with Docker - OL 8.3 with Podman - OL 8.3 aarch64 with Podman All PASS - PR: https://git.openjdk.java.net/jdk/pull/5134
JPackage and ask for microphone permissions broken on OSX...
Hi Core-libs-dev, I’m trying to report an issue with JPackage on recent versions of OSX. Problem is, the microphone permissions aren’t granted to applications created by jpackage. The resulting recorded 16 bit PCM line in samples files are the correct duration, but don’t have any sound (samples all set to 0). System Preferences -> Security & Privacy -> Privacy -> Microphone (application never asks for permissions) Otherwise, the only workaround I can figure out is to have the app launch then bootstrap itself using Runtime and grant applications to the Terminal.app (when it calls itself from `java Application.app/MacOS/Resources/Application`) There are various reports of this on the Internet - but I’m wondering if the JPackage team is aware of the issue. https://stackoverflow.com/questions/55727488/application-doesnt-ask-for-permission-to-access-microphone-in-macos-10-14-mojav This pretty much shows the solution - needs a bit of Objective C though. Reproducing the problem: JPackage any java sound recording app on latest OSX, run it... will be unable to capture sound. Run the same code from the command line, via classpath or modules... it will record audio after asking the user to grant microphone permissions to Terminal.app. It would be great if this is fixed in JDK 17. Many Thanks, Ben S
RFR: 8272398: Update DockerTestUtils.buildJdkDockerImage()
Please review this change that updates the buildJdkDockerImage() test library API. This work originated while working on "8195809: [TESTBUG] jps and jcmd -l support for containers is not tested". The initial intent was to extend the buildJdkDockerImage() API of DockerTestUtils to accept custom Dockerfile content. As I analyzed the usage of buildJdkDockerImage() I realized that: - 2nd argument "dockerfile" is always the same: "Dockerfile-BasicTest" its use has been obsolete for some time, in favor of Dockerfile generated by DockerTestUtils - 3rd argument "buildDirName" is also always the same: "jdk-docker" Hence I thought it would be a good idea to simplify this API and make it up-to-date. Also, since the method signature is being updated, I thought it would be a good idea to also change the name to use more generic container terminology: buildJdkDockerImage() --> buildJdkContainerImage() - Commit messages: - Updated buildJdkDockerImage, changed signature and renamed to buildJdkContainerImage - Proposed docker build API updates Changes: https://git.openjdk.java.net/jdk/pull/5134/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=5134=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8272398 Stats: 68 lines in 17 files changed: 20 ins; 15 del; 33 mod Patch: https://git.openjdk.java.net/jdk/pull/5134.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5134/head:pull/5134 PR: https://git.openjdk.java.net/jdk/pull/5134
RFR: 8269559: AArch64: Implement string_compare intrinsic in SVE
This patch implements string_compare intrinsic in SVE. It supports all LL, LU, UL and UU comparisons. As we haven't found an existing benchmark to measure performance impact, we created a benchmark derived from the test [1] for this evaluation. This benchmark is attached to this patch. Besides, remove the unused temporary register `vtmp3` from the existing match rules for StrCmp. The result below shows all varients can be benefited largely. Command: make exploded-test TEST="micro:StringCompareToDifferentLength" Benchmark(size) Mode Cnt Score Speedup Units compareToLL 24 avgt 10 1.0x ms/op compareToLL 36 avgt 10 1.0x ms/op compareToLL 72 avgt 10 1.0x ms/op compareToLL 128 avgt 10 1.4x ms/op compareToLL 256 avgt 10 1.8x ms/op compareToLL 512 avgt 10 2.7x ms/op compareToLU 24 avgt 10 1.6x ms/op compareToLU 36 avgt 10 1.8x ms/op compareToLU 72 avgt 10 2.3x ms/op compareToLU 128 avgt 10 3.8x ms/op compareToLU 256 avgt 10 4.7x ms/op compareToLU 512 avgt 10 6.3x ms/op compareToUL 24 avgt 10 1.6x ms/op compareToUL 36 avgt 10 1.7x ms/op compareToUL 72 avgt 10 2.2x ms/op compareToUL 128 avgt 10 3.3x ms/op compareToUL 256 avgt 10 4.4x ms/op compareToUL 512 avgt 10 6.1x ms/op compareToUU 24 avgt 10 1.0x ms/op compareToUU 36 avgt 10 1.0x ms/op compareToUU 72 avgt 10 1.4x ms/op compareToUU 128 avgt 10 2.2x ms/op compareToUU 256 avgt 10 2.6x ms/op compareToUU 512 avgt 10 3.7x ms/op [1] https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/compiler/intrinsics/string/TestStringCompareToDifferentLength.java - Commit messages: - 8269559: AArch64: Implement string_compare intrinsic in SVE Changes: https://git.openjdk.java.net/jdk/pull/5129/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=5129=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8269559 Stats: 550 lines in 12 files changed: 447 ins; 12 del; 91 mod Patch: https://git.openjdk.java.net/jdk/pull/5129.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5129/head:pull/5129 PR: https://git.openjdk.java.net/jdk/pull/5129
RFR: 8272541: Incorrect overflow test in Toom-Cook branch of BigInteger multiplication
Please consider this change which would modify a conditional `a + b > c` where the left side variables are `int`s and the right side is `(long)Integer.MAX_VALUE + 1`. The change is to cast the left side variables to `long`s. - Commit messages: - 8272541: Incorrect overflow test in Toom-Cook branch of BigInteger multiplication Changes: https://git.openjdk.java.net/jdk/pull/5130/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=5130=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8272541 Stats: 30 lines in 2 files changed: 18 ins; 3 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/5130.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5130/head:pull/5130 PR: https://git.openjdk.java.net/jdk/pull/5130
Re: 'Condition is always false' in 'BigInteger#multiply(BigInteger, boolean)'
Hello Andrey,
Indeed that appears to be incorrect. I filed [1] to track it.
Thanks,
Brian
[1] https://bugs.openjdk.java.net/browse/JDK-8272541
On Aug 15, 2021, at 2:12 AM, Andrey Turbanov
mailto:turban...@gmail.com>> wrote:
I found suspicious condition in method
"java.math.BigInteger#multiply(java.math.BigInteger, boolean)"
It's detected by IntelliJ IDEA inspection 'Constant conditions & exceptions'
```
if (bitLength(mag, mag.length) +
bitLength(val.mag, val.mag.length) >
32L*MAX_MAG_LENGTH) {
reportOverflow();
}
```
Method bitLength returns 'int', hence the left operand of '>'
comparison is 'int' too.
But the right operand of '>' comparison is 'long' with value ==
Integer.MAX_VALUE + 1.
It means this condition is always false.
Reproducer:
BigInteger a = new BigInteger(1073742825, ThreadLocalRandom.current());
BigInteger b = new BigInteger(1073742825, ThreadLocalRandom.current());
BigInteger c = a.multiply(b);
Re: RFR: 8153490: Cannot setBytes() if incoming buffer's length is bigger than number of elements we want to insert. [v4]
On Mon, 24 May 2021 11:18:57 GMT, Mitsuru Kariya wrote: >> Fix `SerialBlob.setBytes(long pos, byte[] bytes, int offset, int length)` in >> the following cases: >> >> 1. `pos - 1 + bytes.length - offset > this.length() && pos - 1 + length <= >> this.length()` >>The original implementation throws `ArrayIndexOutOfBoundsException` but >> this case should end successfully. >>(test31) >> >> 2. `pos - 1 + length > this.length()` >>The original implementation throws `ArrayIndexOutOfBoundsException` but >> this case should end successfully. *1 >>(test32) >> >> 3. `pos == this.length() + 1` >>The original implementation throws `SerialException` but this case should >> end successfully. *2 >>(test33) >> >> 4. `length < 0` >>The original implementation throws `ArrayIndexOutOfBoundsException` but >> this case should throw `SerialException`. >>(test34) >> >> 5. `offset + length > Integer.MAX_VALUE` >>The original implementation throws `ArrayIndexOutOfBoundsException` (or >> `OutOfMemoryError` in most cases) but this case should throw >> `SerialException`. >>(test35) >> >> Additionally, fix `SerialClob.setString(long pos, String str, int offset, >> int length)` in the following cases: >> >> 1. `offset > str.length()` >>The original implementaion throws `StringIndexOutOfBoundsException` but >> this case should throw `SerialException`. >>(test39) >> >> 2. `pos - 1 + str.length() - offset > this.length() && pos - 1 + length <= >> this.length()` >>The original implementation throws `ArrayIndexOutOfBoundsException` but >> this case should end successfully. >>(test32) >> >> 3. `pos - 1 + length > this.length()` >>The original implementaion throws `SerialException` but this case should >> end successfully. *3 >>(test40) >> >> 4. `pos == this.length() + 1` >>The original implementaion throws `SerialException` but this case should >> end successfully. *4 >>(test41) >> >> 5. `length < 0` >>The original implementation throws `StringIndexOutOfBoundsException` but >> this case should throw `SerialException`. >>(test42) >> >> 6. `offset + length > Integer.MAX_VALUE` >>The original implementation throws `ArrayIndexOutOfBoundsException` (or >> `OutOfMemoryError` in most cases) but this case should throw >> `SerialException`. >>(test43) >> >> >> The javadoc has also been modified according to the above. >> >> *1 The documentation of `Blob.setBytes()` says, "If the end of the Blob >> value is reached while writing the array of bytes, then the length of the >> Blob value will be increased to accommodate the extra bytes." >> >> *2 The documentation of `Blob.setBytes()` says, "If the value specified for >> pos is greater than the length+1 of the BLOB value then the behavior is >> undefined." >>So, it should work correctly when pos == length+1 of the BLOB value. >> >> *3 The documentation of `Clob.setString()` says, "If the end of the Clob >> value is eached while writing the given string, then the length of the Clob >> value will be increased to accommodate the extra characters." >> >> *4 The documentation of `Clob.setString()` says, "If the value specified for >> pos is greater than the length+1 of the CLOB value then the behavior is >> undefined." >>So, it should work correctly when pos == length+1 of the CLOB value. > > Mitsuru Kariya has updated the pull request incrementally with one additional > commit since the last revision: > > Modify javadoc for consistency In process - PR: https://git.openjdk.java.net/jdk/pull/4001
RFR: 8272124: Cgroup v1 initialization causes NullPointerException when path contains colon
Please review this small fix for JDK-8272124. The fix puts a limit of 3 when splitting self cgroup lines by ':' so that Cgroup paths won't get truncated if they contain embedded ':'s. For example, an entry of "11:memory:/user.sli:ce" in a /proc/self/cgroup file will now result in a Cgroup path of "/user.sli:ce" instead of "/user.sli". The fix was tested with Mach5 tiers 1 and 2, and Mach5 tiers 3-5 on Linux x64 and Linux aarch64. Thanks, Harold - Commit messages: - 8272124: Cgroup v1 initialization causes NullPointerException when path contains colon Changes: https://git.openjdk.java.net/jdk/pull/5127/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=5127=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8272124 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/5127.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5127/head:pull/5127 PR: https://git.openjdk.java.net/jdk/pull/5127
Re: RFR: 8268788: Annotations with lambda expressions can still cause AnnotationFormatError [v3]
On Mon, 16 Aug 2021 13:56:44 GMT, Sergei Ustimenko wrote: >> Change #3294 helps to avoid `AnnotaionFormatException` in >> `sun.reflect.annotation.AnnotationInvocationHandler.validateAnnotationMethods`. >> While it fixes the case with e.g. `Runnable` that generates the synthetic >> method without parameters, validation still fails on synthetic methods that >> have parameters e.g. `Function`, `BiFunction`, etc. >> >> This change removes the restriction on parameters count to be zero i.e. >> lambdas with parameters >> would be skipped from validation. > > Sergei Ustimenko has updated the pull request with a new target base due to a > merge or a rebase. The pull request now contains one commit: > > 8268788: Annotations with lambda expressions can still cause > AnnotationFormatError Hi, that would be great if anyone would have time to take a quick look on this pull request. I hope this change is still relevant and I am happy to have any feedback from you. Thanks! - PR: https://git.openjdk.java.net/jdk/pull/4642
Integrated: 8272297: FileInputStream should override transferTo() for better performance
On Thu, 12 Aug 2021 01:16:04 GMT, Brian Burkhalter wrote: > Please consider this request to add an override > `java.io.FileInputStream.transferTo(OutputStream)` with improved performance > if the parameter is a `FileOutputStream`. This pull request has now been integrated. Changeset: 82688258 Author:Brian Burkhalter URL: https://git.openjdk.java.net/jdk/commit/82688258f676e6be8a603f6ab744d52728e3478b Stats: 148 lines in 2 files changed: 148 ins; 0 del; 0 mod 8272297: FileInputStream should override transferTo() for better performance Reviewed-by: alanb - PR: https://git.openjdk.java.net/jdk/pull/5097
Re: RFR: 8272137: Make Collection and Optional classes streamable
On Sun, 15 Aug 2021 01:43:32 GMT, Brian Goetz wrote: > To reiterate: These issues were explored in the JSR 335 EG and it was agreed > that this abstraction did not carry its weight. Yes, we explored this when the Stream API was being designed. It's hard, if not impossible, to capture all decisions for posterity. In the passing years I don't think anything significantly new has arisen for us to revisit that decision. - PR: https://git.openjdk.java.net/jdk/pull/5050
Re: RFR: 8268788: Annotations with lambda expressions can still cause AnnotationFormatError [v3]
> Change #3294 helps to avoid `AnnotaionFormatException` in > `sun.reflect.annotation.AnnotationInvocationHandler.validateAnnotationMethods`. > While it fixes the case with e.g. `Runnable` that generates the synthetic > method without parameters, validation still fails on synthetic methods that > have parameters e.g. `Function`, `BiFunction`, etc. > > This change removes the restriction on parameters count to be zero i.e. > lambdas with parameters > would be skipped from validation. Sergei Ustimenko has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: 8268788: Annotations with lambda expressions can still cause AnnotationFormatError - Changes: https://git.openjdk.java.net/jdk/pull/4642/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=4642=02 Stats: 8 lines in 2 files changed: 5 ins; 1 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/4642.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4642/head:pull/4642 PR: https://git.openjdk.java.net/jdk/pull/4642
RFR: JDK-8272326 java/util/Random/RandomTestMoments.java had two Gaussian fails
RandomTestMoments.java and RandomTestChiSquared.java expect successive calls to nextLong to reproduce the same sequence of values. SecureRandom, by its nature, does not follow this requirement. The patch filters out SecureRandom from these tests. - Commit messages: - Filter out SecureRandom Changes: https://git.openjdk.java.net/jdk/pull/5124/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=5124=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8272326 Stats: 5 lines in 2 files changed: 3 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/5124.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5124/head:pull/5124 PR: https://git.openjdk.java.net/jdk/pull/5124
Re: RFR: 8272137: Make Collection and Optional classes streamable
On Sun, 15 Aug 2021 02:45:17 GMT, CC007 wrote: >> create Streamable and ParallelStreamable interface and use them in >> Collection and Optional > > I read through [these > posts](http://mail.openjdk.java.net/pipermail/lambda-libs-spec-experts/2013-June/thread.html#1910) > and while I did see good reasons for not moving stream to Iterable, I didn't > see any mention of a separate Streamable-like interface, so could you > elaborate on that it "did not carry its weight"? @CC007 Please follow the course of action that @briangoetz has requested. This needs to be discussed on the appropriate mailing list (core-libs-dev in this case) prior to submitting a pull request. It is premature to review this PR. I invite you to refer to the [OpenJDK Developers' Guide](https://openjdk.java.net/guide/), specifically the [Socialize your change](https://openjdk.java.net/guide/#socialize-your-change) section. - PR: https://git.openjdk.java.net/jdk/pull/5050
Re: RFR: 8272297: FileInputStream should override transferTo() for better performance [v2]
On Sun, 15 Aug 2021 16:51:59 GMT, Roman Kennke wrote: > Having followed both #4263 and this PR from the sidelines, may I ask why for > #4263 much more rigorous testing is asked but not here? E.g. test for NPE, > random-sized files/buffers, random position, return value, comprehensive JMH > tests to show performance, etc? I'm all for high quality standards and good > test coverage, but why are we seemingly measuring with double standards? I don't think your comment is fair. The FIS PR is modest, covering one scenario, it's easy to review. The serious bugs that we pointed out have been addressed and test coverage has been added. The Channels PR is much more ambitious and is trying to cover a matrix of scenarios involving file channel and selectable channels, lots of corner cases and potential issues, and will require a lot of review cycles. None of the scenarios had any test coverage initially. This has been partially addressed but the proposal is still unwieldy, hence the discussion on reducing the scope to something manageable. - PR: https://git.openjdk.java.net/jdk/pull/5097
