JDK 14 RFR of JDK-8233940: Preview API tests for String methods should use ${jdk.version} as -source arg

Hello, To remove the need to modify tests when the JDK version is updated, the tests of the preview API in String should use "${jdk.version}" as an argument to -source rather than a fixed version string:     JDK-8233940: Preview API tests for String methods should use ${jdk.version} as

[JDK 14] RFR 8233961: Problem list tools/jlink/JLinkReproducibleTest.java for windows-all

tools/jlink/JLinkReproducibleTest.java This test has been seen to fail frequently due to JDK-8217166. Please review the patch to problem list it  until issue is addressed. bug: https://bugs.openjdk.java.net/browse/JDK-8233961 Thanks, Amy diff --git a/test/jdk/ProblemList.txt

Jpackage bug: Failed to find runtime/bin/jli.dll

Hello everybody, I used the latest jpackage to create an installer for windows. The installed (console) application does not start and complains about "Failed to find library" with "$ROOTDIR\runtime\bin\jli.dll". If I change the line "app.runtime=$ROOTDIR\runtime" to "app.runtime=$APPDIR\runtime"

Collections.synchronized* Javadoc could use see-also links

When I was fresh out of college, I ended up reinventing the ConcurrentHashMap wheel because I wasn't aware of it. I knew about Collections.synchronizedMap(), but knew that locking the entire map for a get or put (rather than just the hash bucket it hit) would prevent my program from benefiting

RFR JDK-8233527: Update Lookup::hasPrivateAccess and Lookup::defineClass spec w.r.t. full power lookup

This is a follow-up of JDK-8226916. Lookup::hasPrivateAccess intends to test if this lookup is a full-power lookup; that is created by the original caller class calling MethodHandles::lookup. The current specification for Lookup::hasPrivateAccess returns true if the lookup modes contain

Re: RFR: 8231863: Crash if classpath is read from @argument file and the main gets option argument

On 11/11/19 8:53 AM, Henry Jen wrote: Thanks Alan and Mandy for the review. I am guessing the Alan’s preference to use Files.write(aFilePath, lines) is to avoid extra String.join operation, which I would too. The current version with byte[] is more flexible but we most likely won't need it

Re: RandomAccess Interface and List Heirarchy

Thanks for the thoughtful responses. I think my issue with Runtime annotation is that it's just that -- Runtime. Compiletime is highly preferable. I also understand the challenges listed by Peter, and the original intended use of RandomAccess as explained by Remi. I'd like to propose another

Re: RFR: 8231863: Crash if classpath is read from @argument file and the main gets option argument

Thanks for the feedback, it's been a great learning experience and I'll make sure to incorporate these considerations in future contributions Cheers Mat Sent from Outlook From: Alan Bateman Sent: Monday, November 11, 2019 10:24 AM

Re: RFR: 8231863: Crash if classpath is read from @argument file and the main gets option argument

On 11/11/2019 16:53, Henry Jen wrote: Thanks Alan and Mandy for the review. I am guessing the Alan’s preference to use Files.write(aFilePath, lines) is to avoid extra String.join operation, which I would too. The current version with byte[] is more flexible but we most likely won't need it in

Re: RFR: 8231863: Crash if classpath is read from @argument file and the main gets option argument

Thanks Alan and Mandy for the review. I am guessing the Alan’s preference to use Files.write(aFilePath, lines) is to avoid extra String.join operation, which I would too. The current version with byte[] is more flexible but we most likely won't need it in launcher. Anyway, I don’t think the

_IEEE_LIBM targets and __kernel_standard

__kernel_standard in src/java.base/share/native/libfdlibm/k_standard.c is built for _IEEE_LIBM targets as well, but it appears superfluous there. In noticed this because GCC 10 flags an uninitialized variable in this code: …/src/java.base/share/native/libfdlibm/k_standard.c: In function

Re: RFR: JDK-8233591: Reorder jpackage help text to focus on package

OK. -- Kevin On 11/9/2019 11:46 AM, Alexey Semenyuk wrote: Kevin, My point was to add consistency. We used to have class names in camel case and pascal case (className, ClassName) and this didn't look right for me. I agree ClassName, `mypkg` is more appropriate. I'm neutral about