On Fri, 9 Apr 2021 20:45:33 GMT, Matthias Bläsing <github.com+2179736+matthiasblaes...@openjdk.org> wrote:
>>> I pushed an update, that addresses the comments and updated the issue with >>> the final issue id. >> >> You also need to adjust the PR title to match the bug title exactly. >> >>> I did not touch the comments on the original commits, so that history is >>> kept intact (I understand, that skara bot will use the PR message as base >>> for the final squashed commit and ignores the individual commits) >> >> Yes, this is correct. And we prefer contributors to do just what you did for >> incremental changes. Thanks. > > I'm currently rerunning tests and preparing and update - further analysis > showed, that thread attachment is handled in > `WebCore::StorageThread::threadEntryPoint()`: > > https://github.com/openjdk/jfx/blob/808b1078f762a923bd5e74298daffeb88ed108c2/modules/javafx.web/src/main/native/Source/WebKitLegacy/Storage/StorageThread.cpp#L76-L87 > > The analysis was triggered by a request from @neilcsmith-net on the netbeans > mailing list. He pointed out, that the fault should have happened earlier if > the the thread indeed was not attached. In that case `GetEnv` is required to > return `NULL`. From the > [doc](https://docs.oracle.com/en/java/javase/11/docs/specs/jni/invocation.html#getenv): > >> If the current thread is not attached to the VM, sets *env to NULL, and >> returns JNI_EDETACHED. If the specified version is not supported, sets *env >> to NULL, and returns JNI_EVERSION. Otherwise, sets *env to the appropriate >> interface, and returns JNI_OK. That's good since it will simplify the fix to the root cause, which is that looking up the class fails depending on the ClassLoader used to load the JavaFX modules. ------------- PR: https://git.openjdk.java.net/jfx/pull/458
