easymock/objenesis

Objenesis Java 11 compatibility issues

Opened this issue ยท 8 comments

Running a jdeps scan from a JDK 11 like:

<java_home>\bin\jdeps -jdkinternals objenesis-2.6.jar

, shows some references to sun.misc.Unsafe:

org.objenesis.instantiator.sun.UnsafeFactoryInstantiator -> sun.misc.Unsafe JDK internal API (jdk.unsupported)
org.objenesis.instantiator.util.ClassDefinitionUtils -> sun.misc.Unsafe JDK internal API (jdk.unsupported)
org.objenesis.instantiator.util.UnsafeUtils -> sun.misc.Unsafe

Which are present even in the newest version of the library - 3.0.1. Are there any plans for these to be removed/replaced in a newer version?

Thanks,
Ivo

Replace by what?

Well, if the latest version of the library is aiming to support Java 8-11, and there is no real alternative of the sun.misc.Unsafe, could this class be accessed via reflection? Similar to org.objenesis.instantiator.util.DefineClassHelper$Java11?

But what is the problem with sun.misc.Unsafe? It is available in Java 11

@henri-tremblay

But what is the problem with sun.misc.Unsafe? It is available in Java 11

This kind of answer is not useful at all. I think that's natural that using a class named "Unsafe", from a module named "unsupported" raises some concerns.

A different question is if that class can be replaced. I would recommend reading https://blogs.oracle.com/javamagazine/the-unsafe-class-unsafe-at-any-speed, where Unsafe is explained, mentioning the specific case of Objenesis.

Explaining that it can't be replaced at the moment is much more useful than just saying "but it is available".

@renatosilvarosa Do you realize that I maintain Objenesis and coined most of the content of this article? Compatibility issues means something is not working. From as far as I know, Objenesis is working perfectly in Java 11. If @ivo-atanasov has found something wrong, I am highly interested in knowing what it is in order to fix it. Objenesis is doing shady stuff. Which is why it's using shady classes like Unsafe. There is no other way for now. To the best of my knowledge.

There is no other way for now. To the best of my knowledge.

@henri-tremblay That is a perfectly valid reason.
I still think that the question made by @ivo-atanasov makes sense. But it's your choice if you don't want to explain or help who comes here searching for answers.

I thought I had answered. There is no plan to remove it since there is no replacement as per Java 17. Unsafe is widely used. That's why it has a special status in the module system. It is still available to use. Most low-level frameworks will have the same issue when using jdeps.

I don't know too much about this topic. But maybe the Java 10 the MethodHandles API could be capable of "introducing" empty constructors at runtime?