On Thu, 3 Mar 2022 22:14:15 GMT, Maurizio Cimadamore <mcimadam...@openjdk.org> wrote:
>> This fixes a bug in JDK-8282515 that `NativeLibraries::findEntry0` reads the >> handle from the given native library instance with the field ID for >> `NativeLibraryImpl::handle` which is wrong for `RawNativeLibraryImpl`. The >> `NativeLibraries::findEntry0` now takes the handle of the library instead >> and that can be used to look up symbols in the native library loaded by >> System::loadLibrary and also RawNativeLibraries. >> >> Tier 1-4 testing is in progress. > > src/java.base/share/classes/jdk/internal/loader/RawNativeLibraries.java line > 38: > >> 36: import java.util.concurrent.ConcurrentHashMap; >> 37: >> 38: import static jdk.internal.loader.NativeLibraries.findEntry0; > > We have `NativeLibraries` and `RawNativeLibraries` which are unrelated > classes. Then we have `NativeLibraryImpl` and `RawNativeLibraryImpl` which > shared a common super type (`NativeLibrary`). I find it mildly asymmetric to > put the `find0` native method in `NativeLibraries` since that's not the > supertype of `RawNativeLibraries`. Is there common code between the two > XYZLibraries classes that can be shared? If so, maybe `find0` can go in that > common supertype - if not, maybe it's better to put `find0` in > `NativeLibrary` itself? I agree it's asymmetric to put the native method in `NativeLibraries`. `NativeLibrary` would be a better place for `findEntry0`. I will also turn `NativeLibrary` to an abstract class to make `findEntry0` is package-private static method. ------------- PR: https://git.openjdk.java.net/jdk/pull/7684
