RFR: 8282608: RawNativeLibraryImpl can't be passed to NativeLibraries::findEntry0
Maurizio Cimadamore
mcimadamore at openjdk.java.net
Thu Mar 3 22:18:00 UTC 2022
On Thu, 3 Mar 2022 21:57:19 GMT, Mandy Chung <mchung at 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.
Fix looks good - sorry I missed it yesterday. I left a minor, optional, cosmetic comment.
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?
-------------
Marked as reviewed by mcimadamore (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/7684
More information about the core-libs-dev
mailing list