Fix AbstractLdapNamingEnumeration next to throw NoSuchElementException instead of NullPointerException

I have a small PR to fix a bug in AbstractLdapNamingEnumeration - details are in the PR: https://github.com/openjdk/jdk/pull/6095 (Note: I'm already an OpenJDK contributor and have signed an OCA but don't have an author account to be able to create bugs) Thanks, -Andrew

RE: [PATCH] Add const to input parameter for JNU_IsInstanceOfByName

T jint JNICALL -JNU_IsInstanceOfByName(JNIEnv *env, jobject object, char *classname); +JNU_IsInstanceOfByName(JNIEnv *env, jobject object, const char *classname); /* Get or set class and instance fields. -Original Message- From: Alan Bateman Sent: Friday, July 19, 2019 4:03 AM To: Andr

[PATCH] Add const to input parameter for JNU_IsInstanceOfByName

Hi Everyone, I'm making some const-correctness fixes to some downstream libraries that use JNU_* functions, and noticed that JNU_IsInstanceOfByName takes in the class name by char* instead of const char* when it does not need to modify the string. It would be useful to change this so that we

RE: latest changes in java.lang.Class

Stream.of should not be used with null. https://docs.oracle.com/javase/9/docs/api/java/util/stream/Stream.html#of-T- I think you'd be right if it were Stream.ofNullable, and there does appear to be a bug in that code (never appended to sb) - thanks for pointing that out... Thanks, -Andrew

[PATCH] Remove unused variables in io_util_md.c handleLseek

While looking through this code debugging another issue I noticed there were some extra unused local variables. Patch is inline below. Thanks, -Andrew diff --git a/src/java.base/windows/native/libjava/io_util_md.c b/src/java.base/windows/native/libjava/io_util_md.c ---

RE: Adding Path-based constructors to various classes

NIO.2 APIs that supersede RandomAccessFile either, but I could be wrong. Thanks, -Andrew From: Brian Burkhalter Sent: Monday, December 17, 2018 4:47 PM To: Andrew Luo ; nio-dev Cc: Core-Libs-Dev Subject: Re: Adding Path-based constructors to various classes (looping in nio-dev) Hi Andrew

Adding Path-based constructors to various classes

Many classes such as: https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/io/RandomAccessFile.html https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/zip/ZipFile.html have constructors that use the File API or String but no constructor that takes Path. Is

RE: JDK 13 RFR of core libs portions of JDK-8205626: Start of release updates for JDK 13

Not a reviewer - looks good anyways - however, I would if some of those constants be refactored to fewer locations? For example, I see many copies of: @SupportedSourceVersion(SourceVersion.RELEASE_13) Perhaps if you declare SourceVersion as: RELEASE_12, RELEASE_13, CURRENT_RELEASE =

RE: RFR(s): JDK-8214687 Optimize Collections.nCopies().hashCode()

CopiesList is private anyways, so are you suggesting that someone might call nCopies(0) in a previous version of the JDK, serialize the return value, and then unserialize in a later version of the JRE? Is this even a supported use case (serialization/deserialization of JRE classes across

RE: [PATCH] Windows 32-bit DLL name decoration

By the way, in hotspot we are generating a .def file dynamically while keeping the JNICALL calling convention (for symbols such as JNI_CreateJavaVM) I believe (just by looking through the code in http://hg.openjdk.java.net/jdk/jdk/file/44fe5fab538a/make/hotspot/lib/JvmMapfile.gmk, unless this

RE: JDK-8212780: JEP 343: Packaging Tool Implementation

I noticed in WindowsRegistry.java we're actually making calls to reg(.exe) and parsing the output/result. Is this preferred over making direct calls to the WINAPI functions via JNI? (Also, would this be a security concern if another reg.exe is in the PATH before the Windows system one?)

RE: RFR 4947890 : Minimize JNI upcalls in system-properties initialization

I'm not a reviewer, but aren't names that begin with _ in the global namespace (_awt_headless_NDX for example) reserved for the C/C++ library? Thanks, Andrew -Original Message- From: core-libs-dev On Behalf Of Roger Riggs Sent: Tuesday, November 13, 2018 8:00 AM To: Core-Libs-Dev ;

RE: From JDK12 it is not possible to drop 'final' modifier

Also, you might want to take a look at JLS 13.4.9 "final Fields and Constants". Primitive static final constants can be folded at compile time, so even if you were able to change it at runtime, it wouldn't have any effect... Thanks, Andrew -Original Message- From: core-libs-dev On

RE: RFR(JDK 12/NIO) 8202285: (fs) Add a method to Files for comparing file contents

I'm not a reviewer, but just wanted to point out that the fully qualified Files.BUFFER_SIZE can be simplified to just BUFFER_SIZE. Searching through the code in Files.java I don't see many other instances of using Files.* (although I do see a few). Thanks Andrew -Original Message-

RE: RFR 8213031: Enhance jdk.nio.zipfs to support Posix File Permissions

I'm not a committer/reviewer but noticed something: In ZipUtils.java: private static final Map> permCache = new WeakHashMap<>(); This is static, and is concurrently modified, so will it cause issues if multiple threads are operating on ZIP filesystems (even if they are different objects/ZIP

RE: RFR(s): 8210549: Runtime.exec: in closeDescriptors(), use FD_CLOEXEC instead of close()

Sorry, I meant to say: "Unfortunately, that is only for files... sockets in Linux are file descriptors as well, but OpenJDK is (currently) not opening them with CLOEXEC." -Original Message- From: core-libs-dev On Behalf Of Andrew Luo Sent: Wednesday, October 24, 20

RE: RFR(s): 8210549: Runtime.exec: in closeDescriptors(), use FD_CLOEXEC instead of close()

By the way, there is some related work on CLOEXEC for networking that I had done. It seems like this work is somewhat similar (although my work addresses a different use case - when JNI code calls exec on its own and doesn't go through and close its inherited FDs):

RE: 6516099: InputStream.skipFully(int k) to skip exactly k bytes

I'm not a reviewer/committer but just a suggestion: You can use assert to ensure "document" that skip(long) should never return negative (and also provide useful debugging when assertions are enabled), for example: 586 long ns = skip(n); assert ns >= 0 : "skip(long) returned

[PATCH] Fix typo in javadoc for java.lang.ref.Cleaner

Noticed a typo in the Javadoc for Cleaner... Patch attached below: diff --git a/src/java.base/share/classes/java/lang/ref/Cleaner.java b/src/java.base/share/classes/java/lang/ref/Cleaner.java --- a/src/java.base/share/classes/java/lang/ref/Cleaner.java +++