May 2021 - core-libs-dev

DataInputStream readUTF related field initialization
by Robert Marcano 05 May '21

05 May '21

Greetings. DataInputStream has some fields with the comment "working arrays initialized on demand by readUTF" but these fields are being initialized at object instantiation. On the other hand DataOutputStream has one field with a likewise comment initialized to null. I think DataInputStream could be optimized the same way as DataOutputStream and help in the memoty footprint of DataInputStream when used for other reads not related to readUTF. Sounds reasonable?

2 1

Re: RFR: 8244146: javac changes for JEP 306
by Srikanth Adayapalam 05 May '21

05 May '21

On Sat, 1 May 2021 23:00:05 GMT, Joe Darcy <darcy(a)openjdk.org> wrote: > 8244146: javac changes for JEP 306 src/jdk.compiler/share/classes/com/sun/tools/javac/code/Source.java line 228: > 226: SEALED_CLASSES(JDK17, Fragments.FeatureSealedClasses, DiagKind.PLURAL), > 227: // todo: will need to supplement/replace with target feature for writing out classes > 228: REDUNDANT_STRICTFP(JDK17), Is the todo still relevant ?? test/langtools/tools/javac/annotations/typeAnnotations/classfile/NestedLambdasCastedTest.java line 34: > 32: * @build toolbox.ToolBox toolbox.JavapTask > 33: * @run compile -source 16 -g NestedLambdasCastedTest.java > 34: * @run main NestedLambdasCastedTest To massage the existing tests at some places you are passing -source 16 and at others -release 16. Is there some nuance behind it ? ------------- PR: https://git.openjdk.java.net/jdk/pull/3831

2 1

Accessing stream in random order
by Tiramisu Mokka 05 May '21

05 May '21

Hi all, The Stream API makes a great job to work with various collections. However some simple operations are quite hard to achieve, for example collect the result into a random order list. The best solution I came with is: Arrays.asList("a", "b", "c", "d").stream() .collect(collectingAndThen(toList(), l -> { Collections.shuffle(l); return l;})); If Collections#shuffle would return the shuffled list, then this can be written even more elegant: Arrays.asList("a", "b", "c", "d").stream() .collect(collectingAndThen(toList(), Collections::shuffle)); Thus two questions: 1) why stream has a way to sort, but not to shuffle 2) why Collections#shuffle doesn't returns the suffld list Are there objectives to address those cases? Thanks in advance, -kofemann /** caffeinated mutations of the core personality */

1 0

Expected behavior for annotation property with duplicate value definition
by Rafael Winterhalter 05 May '21

05 May '21

Hello, I was wondering if the current OpenJDK behavior should yield an exception or if it is accidental and if so, if it should be altered to avoid surprising behavior. If an annotation: @interface Sample { String v(); } is added to a member where the property 'v' is assigned a value twice, the last added value is returned by the reflection API and no error is raised. I recently observed this for ASM-generated code where a value was added twice and it led to a longer bug search, but technically this could of course also happen when javac or other language compilers generate code. I wonder therefore if this should rather yield an error or if this behavior should be documented somewhere in case that the change would be possibly too disruptive for existing code. I am happy to provide a patch to OpenJDK but wonder what exception should be thrown when reading the property. Best regards, Rafael

2 3

Re: RFR: 8244146: javac changes for JEP 306
by Jan Lahoda 05 May '21

05 May '21

On Sat, 1 May 2021 23:00:05 GMT, Joe Darcy <darcy(a)openjdk.org> wrote: > 8244146: javac changes for JEP 306 src/jdk.jshell/share/classes/jdk/jshell/TaskFactory.java line 170: > 168: > 169: allOptions.add("--should-stop=at=FLOW"); > 170: allOptions.add("-Xlint:unchecked,-strictfp"); I wonder if JShell should also print the `strictfp` warnings, so that the users would learn about this change. If needed, it should be possible to disable this, I think, possibly like: diff --git a/test/langtools/jdk/jshell/ClassesTest.java b/test/langtools/jdk/jshell/ClassesTest.java index 082d757b02f..b0b8156e359 100644 --- a/test/langtools/jdk/jshell/ClassesTest.java +++ b/test/langtools/jdk/jshell/ClassesTest.java @@ -342,4 +342,9 @@ public class ClassesTest extends KullaTesting { assertEval("new A()"); } + @Override + public void setUp() { + setUp(bc -> bc.compilerOptions("-Xlint:-strictfp")); + } + } ------------- PR: https://git.openjdk.java.net/jdk/pull/3831

1 0

RFR: 8260621: (jrtfs) ThreadLocal memory leak in ImageBufferCache when using jrtfs
by Athijegannathan Sundararajan 05 May '21

05 May '21

Instead of BufferReference class, Map.Entry is used as pair implementation. This avoids the metaspace leak seen via thread local. ------------- Commit messages: - added comment. generics cleanup. - 8260621: (jrtfs) ThreadLocal memory leak in ImageBufferCache when using jrtfs Changes: https://git.openjdk.java.net/jdk/pull/3849/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3849&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260621 Stats: 57 lines in 1 file changed: 30 ins; 7 del; 20 mod Patch: https://git.openjdk.java.net/jdk/pull/3849.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3849/head:pull/3849 PR: https://git.openjdk.java.net/jdk/pull/3849

4 4

Re: RFR: 8244146: javac changes for JEP 306
by Srikanth Adayapalam 05 May '21

05 May '21

On Sat, 1 May 2021 23:00:05 GMT, Joe Darcy <darcy(a)openjdk.org> wrote: > 8244146: javac changes for JEP 306 Overall, looks good other than the various minor issues called out. I wonder if the tests would have turned out to be a good bit simpler if we simply checked diagnostics against a golden file and skipped the toolbox approach. Is there a strong benefit to using the toolbox approach for the present need ?? Also, another model for tests could have been test/langtools/tools/javac//7166455/CheckACC_STRICTFlagOnclinitTest.java rather than using an annotation processor. (Not asking for a change, just an academic question/observation) ------------- PR: https://git.openjdk.java.net/jdk/pull/3831

1 0

Re: RFR: 8244146: javac changes for JEP 306
by Srikanth Adayapalam 05 May '21

05 May '21

On Sat, 1 May 2021 23:00:05 GMT, Joe Darcy <darcy(a)openjdk.org> wrote: > 8244146: javac changes for JEP 306 src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 1326: > 1324: private void warnOnExplicitStrictfp(DiagnosticPosition pos, JCTree tree) { > 1325: DiagnosticPosition prevLintPos = deferredLintHandler.setPos(tree.pos()); > 1326: try { Do we need tree passed as a parameter at all ? Why can't we use just pos instead of tree.pos() Looking at the 3 call sites of checkFlags it seems guaranteed that pos is same as tree.pos() ? ------------- PR: https://git.openjdk.java.net/jdk/pull/3831

1 0

RFR: 8266179: [macos] jpackage should specify architecture for produced pkg files
by Alexander Matveev 04 May '21

04 May '21

jpackage should specify architecture for produced PKG files via hostArchitectures="x86_x64 or arm64". aarch64 installer will be installable on x64 without specifying hostArchitectures which is not correct and if install on arm Mac it will request Rosetta 2. With proposed fix by setting hostArchitectures="x86_x64" if installer contains x64 binaries, it will be installable on x64 Mac and will require Rosetta 2 on arm Mac. hostArchitectures will be set to arm64 if installer contain aarch64 binaries and will gave error when run on x64 Mac and will be installable on arm Mac without triggering installation of Rosetta 2. ------------- Commit messages: - 8266179: [macos] jpackage should specify architecture for produced pkg files Changes: https://git.openjdk.java.net/jdk/pull/3807/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3807&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266179 Stats: 7 lines in 2 files changed: 6 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3807.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3807/head:pull/3807 PR: https://git.openjdk.java.net/jdk/pull/3807

4 20

Re: RFR: 8244146: javac changes for JEP 306
by Joe Darcy 04 May '21

04 May '21

On Sat, 1 May 2021 23:00:05 GMT, Joe Darcy <darcy(a)openjdk.org> wrote: > 8244146: javac changes for JEP 306 For core-libs, under JEP 306 strictfp would be a no-op under 17. Therefore, the few uses of the strictfp modifier in the base module can be removed. ------------- PR: https://git.openjdk.java.net/jdk/pull/3831

1 0