July 2021 - core-libs-dev

[jdk17] Integrated: 8270916: Update java.lang.annotation.Target for changes in JLS 9.6.4.1
by Joe Darcy 22 Jul '21

22 Jul '21

On Mon, 19 Jul 2021 21:18:42 GMT, Joe Darcy <darcy(a)openjdk.org> wrote: > Given changes in JLS 9.6.4.1, JDK-8261610 in Java SE 17, the statements about annotation applicability made in java.lang.annotation.Target need to be updated to match. > > Please also review the corresponding CSR: https://bugs.openjdk.java.net/browse/JDK-8270917 This pull request has now been integrated. Changeset: ecc37b06 Author: Joe Darcy <darcy(a)openjdk.org> URL: https://git.openjdk.java.net/jdk17/commit/ecc37b06f283c18ab4aa2b23562843bca… Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod 8270916: Update java.lang.annotation.Target for changes in JLS 9.6.4.1 Reviewed-by: bpb, naoto ------------- PR: https://git.openjdk.java.net/jdk17/pull/256

1 0

Re: [jdk17] RFR: 8270916: Update java.lang.annotation.Target for changes in JLS 9.6.4.1
by Naoto Sato 22 Jul '21

22 Jul '21

On Mon, 19 Jul 2021 21:18:42 GMT, Joe Darcy <darcy(a)openjdk.org> wrote: > Given changes in JLS 9.6.4.1, JDK-8261610 in Java SE 17, the statements about annotation applicability made in java.lang.annotation.Target need to be updated to match. > > Please also review the corresponding CSR: https://bugs.openjdk.java.net/browse/JDK-8270917 Marked as reviewed by naoto (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk17/pull/256

1 0

Re: [jdk17] RFR: 8270916: Update java.lang.annotation.Target for changes in JLS 9.6.4.1
by Brian Burkhalter 22 Jul '21

22 Jul '21

On Mon, 19 Jul 2021 21:18:42 GMT, Joe Darcy <darcy(a)openjdk.org> wrote: > Given changes in JLS 9.6.4.1, JDK-8261610 in Java SE 17, the statements about annotation applicability made in java.lang.annotation.Target need to be updated to match. > > Please also review the corresponding CSR: https://bugs.openjdk.java.net/browse/JDK-8270917 Marked as reviewed by bpb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk17/pull/256

1 0

RFR: 8268974: jpackage fails to handle --dest option containing "bin" folder
by Alexey Semenyuk 22 Jul '21

22 Jul '21

GetApplicationHomeFromDll() fails if the path to libjli.so contains "bin" component (/tmp/bin/HelloWorld/lib/runtime/lib/libjli.so). TruncatePath() looks for "/bin/" first in "/tmp/bin/HelloWorld/lib/runtime/lib/libjli.so" string and then it looks for "/lib/". But this is wrong order as it should look for "/lib/" first. I.e. TruncatePath() should look for "/bin/" and then for "/lib/" if called from GetApplicationHome() and for "/lib/" first and then for "/bin/" if called from GetApplicationHomeFromDll(). ------------- Commit messages: - 8268974: jpackage fails to handle --dest option containing "bin" folder Changes: https://git.openjdk.java.net/jdk/pull/4534/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4534&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268974 Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/4534.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4534/head:pull/4534 PR: https://git.openjdk.java.net/jdk/pull/4534

4 12

jpackage OS/X JDK-8263157 fix regressed out
by Michael Hall 22 Jul '21

22 Jul '21

JDK-8263157 <https://bugs.openjdk.java.net/browse/JDK-8263157> [macos]: java.library.path is being set incorrectly The fix for this seems to be gone in both current jdk17 and jdk18 releases. There is no ‘app’ directory included in java.library.path. outputdir/HalfPipe.app/Contents/runtime/Contents/Home/bin/java -version openjdk version "18-ea" 2022-03-15 OpenJDK Runtime Environment (build 18-ea+6-237) OpenJDK 64-Bit Server VM (build 18-ea+6-237, mixed mode) outputdir/HalfPipe.app/Contents/MacOS/HalfPipe Exception in thread "main" java.lang.UnsatisfiedLinkError: no hp in java.library.path: /opt/ooRexx/lib/ooRexx;/Users/mjh/HalfPipe/HalfPipe_jpkg/outputdir/HalfPipe.app/Contents/app:/Users/mjh/Library/Java/Extensions:/Library/Java/Extensions:/Network/Library/Java/Extensions:/System/Library/Java/Extensions:/usr/lib/java:. at java.base/java.lang.ClassLoader.loadLibrary(Unknown Source) at java.base/java.lang.Runtime.loadLibrary0(Unknown Source) at java.base/java.lang.System.loadLibrary(Unknown Source) at us.hall.hp.common.LoaderLaunchStub.<clinit>(LoaderLaunchStub.java:35) Failed to launch JVM

3 6

JNI WeakGlobalRefs
by Hans Boehm 22 Jul '21

22 Jul '21

Is this an appropriate list to discuss JNI? I'm concerned that the current semantics of JNI WeakGlobalRefs are still dangerous in a very subtle way that is hidden in the spec. The current (14+) spec says: “Weak global references are related to Java phantom references (java.lang.ref.PhantomReference). A weak global reference to a specific object is treated as a phantom reference referring to that object when determining whether the object is phantom reachable (see java.lang.ref). ---> Such a weak global reference will become functionally equivalent to NULL at the same time as a PhantomReference referring to that same object would be cleared by the garbage collector. <---” (This was the result of JDK-8220617, and is IMO a large improvement over the prior version, but ...) Consider what happens if I have a WeakGlobalRef W that refers to a Java object A which, possibly indirectly, relies on an object F, where F is finalizable, i.e. W - - -> A -----> ... -----> F Assume that F becomes invalid once it is finalized, e.g. because the finalizer deallocates a native object that F relies on. This seems to be a very common case. We are then exposed to the following scenario: 0) At some point, there are no longer any other references to A or F. 1) F is enqueued for finalization. 2) W is dereferenced by Thread 1, yielding a strong reference to A and transitively to F. 3) F is finalized. 4) Thread 1 uses A and F, accessing F, which is no longer valid. 5) Crash, or possibly memory corruption followed by a later crash elsewhere. (3) and (4) actually race, so there is some synchronization effort and cost required to prevent F from corrupting memory. Commonly the implementer of W will have no idea that F even exists. I believe that typically there is no way to prevent this scenario, unless the developer adding W actually knows how every class that A could possibly rely on, including those in the Java standard library, are implemented. This is reminiscent of finalizer ordering issues. But it seems to be worse, in that there isn't even a semi-plausible workaround. I believe all of this is exactly the reason PhantomReference.get() always returns null, while WeakReference provides significantly different semantics, and WeakReferences are enqueued when an object is enqueued for finalization. The situation improves, but the problem doesn't fully disappear, in a hypothetical world without finalizers. It's still possible to use WeakGlobalRef to get a strong reference to A after a WeakReference to A has been cleared and enqueued. I think the problem does go away if all cleanup code were to use PhantomReference-based Cleaners. AFAICT, backward-compatibility aside, the obvious solution here is to have WeakGlobalRefs behave like WeakReferences. My impression is that this would fix significantly more broken clients than it would break correct ones, so it is arguably still a viable option. There is a case in which the current semantics are actually the desired ones, namely when implementing, say, a String intern table. In this case it's important the reference not be cleared even if the referent is, at some point, only reachable via a finalizer. But this use case again relies on the programmer knowing that no part of the referent is invalidated by a finalizer. That's a reasonable assumption for the Java-implementation-provided String intern table. But I'm not sure it's reasonable for any user-written code. There seem to be two ways forward here: 1) Make WeakGlobalRefs behave like WeakReferences instead of PhantomReferences, or 2) Add strong warnings to the spec that basically suggest using a strong GlobalRef to a WeakReference instead. Has there been prior discussion of this? Are there reasonable use cases for the current semantics? Is there something else that I'm overlooking? If not, what's the best way forward here? (I found some discussion from JDK-8220617, including a message I posted. Unfortunately, it seems to me that all of us overlooked this issue?) Hans

3 2

Re: RFR: 8190753: (zipfs): Accessing a large entry (> 2^31 bytes) leads to a negative initial size for ByteArrayOutputStream [v8]
by Jaikiran Pai 22 Jul '21

22 Jul '21

On Wed, 21 Jul 2021 04:09:23 GMT, Jaikiran Pai <jpai(a)openjdk.org> wrote: > > > For some context - the new `FileRolloverOutputStream` extends `ByteArrayOutputStream` and hence cannot have a `throws IOException` in its overridden `write` methods. > > > > > > Have you tried wrapping a BAOS rather than extending, that might allow the exception wrapping/unwapping to go away. > > Hello Alan, > > I did experiment with it earlier, before going with the current approach in this PR. The disadvantage, as I see it, with wrapping a `ByteArrayOutputStream` instead of extending it is that when trying to rollover the contents to a file, you don't have access to the (inner protected) byte array of the ByteArrayOutputStream. > > The rollover code would then look something like: > > ``` > private void transferToFile() throws IOException { > // create a tempfile > entry.file = getTempPathForEntry(null); > // transfer the already written data from the byte array buffer into this tempfile > try (OutputStream os = new BufferedOutputStream(Files.newOutputStream(entry.file))) { > new ByteArrayInputStream(baos.toByteArray(), 0, baos.size()).transferTo(os); > } > // release the underlying byte array > baos = null; > // append any further data to the file with buffering enabled > tmpFileOS = new BufferedOutputStream(Files.newOutputStream(entry.file, APPEND)); > } > ``` > > So although you can transfer the contents to the file without requiring the access to the byte array, you end up creating a new copy of that array (through the use of `baos.toByteArray()`), which can be at most 10MB in size. I thought avoiding a new copy of that (potentially 10MB) array during this transfer would be a good save and hence decided to settle on extending `ByteArrayOutputStream` instead of wrapping it. > > The use of `extends` of course now means dealing with the `UncheckedIOException` as done in this PR. But if you think that the array copy isn't a concern and wrapping the `ByteArrayOutputStream` is a better way, then I'll go ahead and update this PR accordingly. Now that the mailing lists integration seems to be back to normal, just adding this dummy comment to bring to attention the latest comments in this PR. ------------- PR: https://git.openjdk.java.net/jdk/pull/4607

3 2

Re: RFR: 8260265: UTF-8 by Default [v6]
by Alan Bateman 22 Jul '21

22 Jul '21

On Wed, 21 Jul 2021 17:34:15 GMT, Naoto Sato <naoto(a)openjdk.org> wrote: >> This is an implementation for the `JEP 400: UTF-8 by Default`. The gist of the changes is `Charset.defaultCharset()` returning `UTF-8` and `file.encoding` system property being added in the spec, but another notable modification is in `java.io.PrintStream` where it continues to use the `Console` encoding as the default charset instead of `UTF-8`. Other changes are mostly clarification of the term "default charset" and their links. Corresponding CSR has also been drafted. >> >> JEP 400: https://bugs.openjdk.java.net/browse/JDK-8187041 >> CSR: https://bugs.openjdk.java.net/browse/JDK-8260266 > > Naoto Sato has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains ten additional commits since the last revision: > > - Merge branch 'master' into JDK-8260265 > - Refined `file.encoding` description > - Merge branch 'master' into JDK-8260265 > - Reflects comments > - Removed leftover `console` references in `PrintStream` > - Reflects comments > - Reflects review comments > - Merge branch 'master' into JDK-8260265 > - 8260265: UTF-8 by Default Thanks for incorporating the suggestion for the getProperties text. I think it looks good now. ------------- Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4733

1 0

RFR: Merge jdk17
by Jesper Wilhelmsson 22 Jul '21

22 Jul '21

Forwardport JDK 17 -> JDK 18 ------------- Commit messages: - Merge - 8266347: assert(Dependencies::is_concrete_root_method(fm, ctxk) == Dependencies::is_concrete_method(m, ctxk)) failed: mismatch - 8264066: Enhance compiler validation - 8265201: JarFile.getInputStream not validating invalid signed jars - 8258432: Improve File Transfers - 8264079: Improve abstractions - 8262380: Enhance XML processing passes - 8262967: Improve Zip file support - 8264460: Improve NTLM support - 8256491: Better HTTP transport - ... and 10 more: https://git.openjdk.java.net/jdk/compare/0790f04d...025eaefb The webrevs contain the adjustments done while merging with regards to each parent branch: - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=4863&range=00.0 - jdk17: https://webrevs.openjdk.java.net/?repo=jdk&pr=4863&range=00.1 Changes: https://git.openjdk.java.net/jdk/pull/4863/files Stats: 517 lines in 33 files changed: 403 ins; 34 del; 80 mod Patch: https://git.openjdk.java.net/jdk/pull/4863.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4863/head:pull/4863 PR: https://git.openjdk.java.net/jdk/pull/4863

1 2

jpackage on MacOS - ./Contents/Contents/app/myapp.cfg file not found
by Bruno Borges 21 Jul '21

21 Jul '21

Hi all, Been trying to use Java 16.0.1 to produce a PKG for the fx2048 [1] game, and the generated app-image comes with a binary launcher that tries to load the .cfg file from the wrong directory. Anyone seen this problem? fx2048.app/Contents/MacOS master -> origin/master ✔ 1h59m java:16.0.1 $ tree ../../../ -L 4 ../../../ └── fx2048.app └── Contents ├── Info.plist ├── MacOS │ └── fx2048 ├── PkgInfo ├── Resources │ └── fx2048.icns ├── app │ └── fx2048.cfg └── runtime └── Contents 7 directories, 5 files $ ./fx2048 Error opening "/Users/bruno/myprojects/fx2048/build/installers/fx2048.app/Contents/Contents/app/fx2048.cfg" file: No such file or directory [1] http://github.com/brunoborges/fx2048

3 3