Use JNI's class-loading and unloading hooks to cache the Java class and method fields (rather than a static method)
Ensure the data to be copied back to Java will fit in arrays
References
18
Description
We no longer use global variables to avoid allocations between consecutive calls to encode messages using MessageEncoder.
Unfortunately, this results in about a ~20% performance penalty. If we want to resolve this in the future, we can add native state to every instance of the MessageEncoder, but the user will need to explicitly clean it up since there's no reliable way to hook into JVM's GC mechanisms.
In MessageEncoder, rather than using a static initialization method, we can use JNI's class loading/unloading hooks to init/deinit thread-safe global variables.
Added some extra checks to ensure that the data we're copying back to the JVM will fit in arrays. Previously, it could cause an integer overflow of Java's size variables.
Validation performed
Followed the reproduction instructions in #18 and ensured the problem no longer occurred.
References
18
Description
MessageEncoder.MessageEncoder, but the user will need to explicitly clean it up since there's no reliable way to hook into JVM's GC mechanisms.MessageEncoder, rather than using a static initialization method, we can use JNI's class loading/unloading hooks to init/deinit thread-safe global variables.Validation performed