There are two behavioral changes. First, this change may affect the timing on when a native library is being unloaded because it is now handled by the system cleaner thread rather than the finalizer thread that is subject to the thread scheduling. Note that it is unspecified when a native library is unloaded. This behavior is solely implementation-dependent. The native library will be unloaded when a class loader becomes phantom reachable and the cleaner thread is in action to invoke the cleaning method. Previously, the native library will be unloaded when a class loader becomes finalizable and the finalizer thread is in action to invoke the finalizer. It is expected that this behavioral change should not be noticeable except the native library is being reloaded immediately when the class loader is GC'ed before the system cleaner thread gets a chance to handle the unloading of that class loader. Second, JNI_OnUnload calling JNI_FindClass can only find classes visible to the system class loader or its ancestor. Existing native library expects to find classes defined to this unloaded class loader or its ancestors that is not a built-in class loader will no longer work. It is specified in the spec for JNI_OnUnload that the programmer should be conservative on using Java VM services, and refrain from arbitrary Java call-backs. It is believed that the compatibility risk should be low but marked as medium because it is uncertain how existing applications depend on these behaviors.