August 2021 - core-libs-dev

RFR: 8273098: Unnecessary Vector usage in java.naming
by Andrey Turbanov 30 Aug '21

30 Aug '21

Usage of thread-safe collection Vector is unnecessary. It's recommended to use ArrayList/array if a thread-safe implementation is not needed. In post-BiasedLocking times, this is gets worse, as every access is synchronized. I checked only places where Vector was used as local variable. ------------- Commit messages: - [PATCH] Unnecessary Vector usage in java.naming Changes: https://git.openjdk.java.net/jdk/pull/5262/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5262&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273098 Stats: 30 lines in 3 files changed: 1 ins; 2 del; 27 mod Patch: https://git.openjdk.java.net/jdk/pull/5262.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5262/head:pull/5262 PR: https://git.openjdk.java.net/jdk/pull/5262

3 3

Re: JPackage and ask for microphone permissions broken on OSX...
by Ben S 29 Aug '21

29 Aug '21

Putting the information how to do this together. Trying to get an existing jpackaged app, that is not signed and is not distributed in the app store, to ask for mike permissions. Does not ever ask for permissions. Not sure how this differs from IntelliJ (which does successfully ask for permissions). Is the problem in Macos or Java or Info.plist? /Applications/SomeAppFolder/SomeApp.app/Contents/Info.plist <plist version="1.0"> <dict> <key>CFBundleIdentifier</key> <string>com.someorg.someapp.somepackage.random12345</string> <key>NSMicrophoneUsageDescription</key> <string>Someapp requests access to the device's microphone.</string> </dict> </plist> You can remove all the microphone permissions and start again - tccutil reset Microphone Could there be some other settings controlling this? Is there a way of getting a debug log? Thanks, Ben S. > On Aug 25, 2021, at 8:40 AM, Alan Snyder <javalists(a)cbfiddle.com> wrote: > On Aug 24, 2021, at 6:52 AM, Andy Herrick <andy.herrick(a)oracle.com> wrote: > > One final thing to note, MacOS keeps track of what you have ever previously granted microphone permission to (and will never ask again) based on the mac package identifier (which defaults to the main class name), so I explicitly set this using a shell script with jpackage option "--mac-package-identifier audio-$1" option, so I can pass in different values and create a unique one each time. > > I?ve been wondering what you mean here. > > Are you saying that you routinely generate random package identifiers or is this a workaround that you use in special circumstances? > > Alan > > I believe the permission is granted to a bundle idenditifer. I think tccutil can be used to reset > > https://apple.stackexchange.com/questions/384317/how-do-i-reset-camera-and-…

1 0

RFR: 8273091: Doc of [Strict]Math.floorDiv(long, int) erroneously documents int in @return tag
by Raffaello Giulietti 27 Aug '21

27 Aug '21

This PR corrects a typo in the JavaDoc of `[Strict]Math.floorDiv(long,int)`. ------------- Commit messages: - 8273091: Doc of [Strict]Math.floorDiv(long,int) erroneously documents int in @return tag Changes: https://git.openjdk.java.net/jdk/pull/5287/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5287&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273091 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/5287.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5287/head:pull/5287 PR: https://git.openjdk.java.net/jdk/pull/5287

3 3

RFR: JDK-8272866 java.util.random package summary contains incorrect mixing function in table
by Jim Laskey 27 Aug '21

27 Aug '21

The table 'LXM Multipliers' at the end of the javadoc for the java.util.random package states that the mixing function is mixLea32 for all the 64/128-bit LCG based generators. This should be updated to mixLea64 for the 64/128-bit LCG generators. Only the L32X64MixRandom which uses a 32-bit LCG will use the mixLea32 mixing function. ------------- Commit messages: - Correct table entries Changes: https://git.openjdk.java.net/jdk/pull/5279/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5279&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8272866 Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/5279.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5279/head:pull/5279 PR: https://git.openjdk.java.net/jdk/pull/5279

2 2

Replace StringBuffers to StringBuilders in tests
by Sergei Ustimenko 27 Aug '21

27 Aug '21

Hi all, Some tests use StringBuffers instead of StringBuilders where additional thread-safety is not required as e.g. in test/jdk/sun/util/resources/TimeZone/Bug4640234.java:82 : ... StringBuffer errors = new StringBuffer( "" ); StringBuffer warnings = new StringBuffer( "" ); ... There were some efforts to clean up core libs (e.g. java.base module in https://github.com/openjdk/jdk/pull/2922) and I've noticed some tests that could be improved as well. Now there are about 300 tests for different modules that in general use StringBuffers (most probably some of them not without a reason) so is it something worth looking into? What you think about it? Regards, Sergei

3 3

RFR: 8272541: Incorrect overflow test in Toom-Cook branch of BigInteger multiplication
by Brian Burkhalter 27 Aug '21

27 Aug '21

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&pr=5130&range=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

2 2

what does the spec say about file paths that are too long?
by Alan Snyder 27 Aug '21

27 Aug '21

I’ve been looking for some specification of what happens when a file request is made using a path that is too long (whatever that means to the underlying system). I have not found one. Is there one? My opinion is that silent truncation should not happen. Instead, an exception should be thrown. I have had the misfortunate of using an application (not Java) that did not check path lengths and the OS truncated the paths. The result was a kind of corruption to an implied schema causing incorrect search results and potentially data loss. Writing defensively to protect against silent path truncation is probably quite challenging, as well as tedious, especially when working with a system-independent API. If it is not already covered, I would like to see the specification mandate exceptions instead of silent truncation.

3 8

Proposal: JDK-8231640 - (prop) Canonical property storage
by Jaikiran Pai 27 Aug '21

27 Aug '21

The java.util.Properties class allows the properties to be written out to a stream or through a writer. In its current form, the specification of these APIs state that a comment comprising of the current date is always written out. The spec doesn't make any guarantees about the order of the properties when they are written out. There have been requests asking to make these APIs more deterministic. These requests, from what I have seen, mainly ask for: - A way to disable writing out the date comment - A way to write out the properties in a deterministic and reproducible way There have been discussions in the mailing list in the past which have been captured in JDK-8231640[1]. In these discussions, there has been an inclination to not touch the current existing API implementations and instead introduce new API(s) to achieve the proposed use cases. Before starting off with an implementation, I wanted to try and get some inputs on what the new API(s) would look like and what the scope of such a work should be. Right now, the Properties class has 2 "store" APIs: public void store(Writer writer, String comments) throws IOException public void store(OutputStream out, String comments) throws IOException For the sake of this discussion we won't be talking about the "save" API, in that same class, which has been deprecated. As part of this enhancement, one of the proposed API name is "storeCanonical". As a start, I plan to use this name for the new API. Is there any different suggestion for the name? As for the API signature, I plan to introduce 2 new APIs: public void storeCanonical(Writer writer, String comments) throws IOException public void storeCanonical(OutputStream out, String comments) throws IOException to match what the "store" variants currently provide. The first difference between these "storeCanonical" and the "store" will be the trivial part where these new "storeCanonical" implementations will no longer write out the date comment. Users are allowed to pass optional comments to these new APIs. If any comment is passed to these APIs, these will continue to be written out first, before the actual properties are written out. Speaking of optional comments, should the APIs accept an instance of java.util.Optional for the comments parameter. Perhaps: public void storeCanonical(Writer writer, Optional<String> comments) throws IOException public void storeCanonical(OutputStream out, Optional<String> comments) throws IOException Coming to the part where we write out the properties, these APIs will write out the properties in the lexicographical order of the property keys. An additional enhancement perhaps could be to allow users to pass in an optional java.util.Comparator instance to provide for application specific ordering of the property keys while being written out by these APIs. I am not too sure if we should introduce that. Any inputs? If we do introduce it, we would end up with 4 new APIs: public void storeCanonical(Writer writer, Optional<String> comments) throws IOException public void storeCanonical(OutputStream out, Optional<String> comments) throws IOException public void storeCanonical(Writer writer, Optional<String> comments, Comparator<String> keyOrderer) throws IOException public void storeCanonical(OutputStream out, Optional<String> comments, Comparator<String> keyOrderer) throws IOException Is that worth it? Finally, the other semantics, like the property key value separators, how/where newlines are inserted, what character encoding is used etc... will continue to match with the current semantics of the "store" APIs. [1] https://bugs.openjdk.java.net/browse/JDK-8231640 -Jaikiran

5 18

Re: StringBuilder OOMs earlier with JRE 11 compared to JRE 8
by David Holmes 27 Aug '21

27 Aug '21

Hi Simeon, Redirecting this to core-libs-dev as it is not a serviceability issue. (bcc serviceabillity-dev) Thanks, David On 27/08/2021 8:53 pm, S A wrote: > Hi all, > > while working on https://bugs.eclipse.org/bugs/show_bug.cgi?id=575641 > <https://bugs.eclipse.org/bugs/show_bug.cgi?id=575641>, I noticed that > StringBuilder throws an OOM "half as early" in OpenJDK 11 (and 17 early > access), when compared to OpenJDK 8. > > In particular, I ran the following snippet to see where the limit of > appending to a StringBuilder is: > > StringBuilder sb = new StringBuilder(); > long n = 8L * 1024L * 1024L; > for (long i = 0; i < n; ++i) { > int m = 1024; > for (int j = 0; j < m; ++j) { > int length = sb.length(); > try { > sb.append((char) j); > } catch (Error e) { > System.out.println("Error occurred at length=" + length + " [i=" + i + > ", j=" + j + "]"); > throw e; > } > > } > } > > JRE 8: > > Error occurred at length=2147483645 [i=2097151, j=1021] > Exception in thread "main" java.lang.OutOfMemoryError: Requested array > size exceeds VM limit > at java.util.Arrays.copyOf(Arrays.java:3332) > at > java.lang.AbstractStringBuilder.ensureCapacityInternal(AbstractStringBuilder.java:124) > at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:649) > at java.lang.StringBuilder.append(StringBuilder.java:202) > at > test.stringbuilder.TestStringbuilderOOM.main(TestStringbuilderOOM.java:13) > > JRE 11: > > Error occurred at length=1073741822 [i=1048575, j=1022] > Exception in thread "main" java.lang.OutOfMemoryError: Requested array > size exceeds VM limit > at java.base/java.util.Arrays.copyOf(Arrays.java:3745) > at > java.base/java.lang.AbstractStringBuilder.ensureCapacityInternal(AbstractStringBuilder.java:172) > at > java.base/java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:748) > at java.base/java.lang.StringBuilder.append(StringBuilder.java:241) > at > TestJava11/test.stringbuilder.TestStringbuilderOOM.main(TestStringbuilderOOM.java:13) > > While StringBuilder is not a good choice for holding GBs of text, I > wonder that no effort is made to clamp the capacity to its limit when (I > assume) it is being doubled upon array expansion. > > Is this something that should be looked into or it can be safely ignored > (from JDK users POV)? > > Best regards, > Simeon

3 2

RFR: 8272863: Replace usages of Collections.sort with List.sort call in public java modules
by Andrey Turbanov 26 Aug '21

26 Aug '21

Collections.sort is just a wrapper, so it is better to use an instance method directly. ------------- Commit messages: - [PATCH] Replace usages of Collections.sort with List.sort call in public java modules Changes: https://git.openjdk.java.net/jdk/pull/5229/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5229&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8272863 Stats: 27 lines in 10 files changed: 0 ins; 8 del; 19 mod Patch: https://git.openjdk.java.net/jdk/pull/5229.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5229/head:pull/5229 PR: https://git.openjdk.java.net/jdk/pull/5229

5 11