JDK9 : Usage of JDK private API sun.misc.Unsafe by xstream

[pmouawad]

Hello,
Within Apache JMeter project, we ran jdeps on jmeter and found xstream was using internal libraries from jdk:
xstream-1.4.8.jar ->
/Library/Java/JavaVirtualMachines/jdk1.8.0_45.jdk/Contents/Home/jre/lib/rt.jar
(Full JRE)
com.thoughtworks.xstream.converters.reflection.SunLimitedUnsafeReflectionProvider
(xstream-1.4.8.jar)
-> sun.misc.Unsafe JDK
internal API (rt.jar)
com.thoughtworks.xstream.converters.reflection.SunUnsafeReflectionProvider
(xstream-1.4.8.jar)
-> sun.misc.Unsafe JDK
internal API (rt.jar)

Looking at code, it seems to handle correctly the potential missing class by defaulting to SunUnsafeReflectionProvider , but it appears usage is not recommended by Oracle JDK Team :
https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+Analysis+Tool

So if Unsafe is removed , it would introduce some limitation:

• Cannot newInstance: classes without public visibility, non-static inner classes, classes without default constructors.

Maybe this need should be reported to Oracle (if not already done) within their work to provide alternative to Unsafe through APIs.
Regards
Philippe M.

[joehni]

XStream cannot properly work without sun.misc.Unsafe, but it's reported already (actually years ago). AFAICS they will provide an alternative for Java 9, but I have not looked into it.

[joehni]

Java 9 does not contain a replacement for this functionality, so it will stay for now.

[Snake1999]

Use VarHandle instead. Didn't you guys know that?
We've been troubled for long with tons of WARNING: Illegal reflective access by com.thoughtworks.xstream.core.util.Fields (file:/Users/lmlstarqaq/.m2/repository/com/thoughtworks/xstream/xstream/1.3.1/xstream-1.3.1.jar) to field java.util.Properties.defaults because mysql depends on your project.
You are too lazy to make this change. It's Java 9 now. Wait for another Java 10? 11? infinity?

[joehni]

... complains the guy using himself a version that's nearly a decade old and has known security issues.

If it is so easy, provide patches. My time is limited.

[pmouawad]

@joehni , don't bother about such comments, you project is great , thanks for all your work on it !

[ArthurBorsboom]

Hi Jorg,

First of all, thanks for the library.
To me, your library is a sweet solution for a common challenge. :)

While implementing v1.4.11.1 in my application, I also noticed the "illegal reflective access operation" using Java 13.

Do you believe Java 13 offers the necessities to workaround the reflective access?

If not, I'm using another library org.json.JSONObject which kind of does the same as your library.
It translate Java objects to Json. I haven't looked at the implementation, however, maybe this gives some inspiration for a possible solution.

Does this help in a way?

[joehni]

While implementing v1.4.11.1 in my application, I also noticed the "illegal reflective access operation" using Java 13.

This issue is about the usage of sun.misc.Unsafe and has nothing to do with "illegal reflecting access". And no, there is still no replacement for the allocateInstance call.

[raymond-jgler]

Hi, I would be glad for some confirmation.
for the unsafe package issue, my project also heavily depends on Xstream,

Also, to work around, I wrote small code to recursively add a default constructor to classes without it, to use PureJavaReflectionProvider, which employs pure relfection to initialize objects, with a default constructor, or ObjectStreamClass.lookup(type) if without.
#line74
For that, I do:
xstream = new XStream(new PureJavaReflectionProvider(), driver, new ClassLoaderReference(new CustomClassLoader()), null)
to replace SunLimitedUnsafeReflectionProvider,

My question is that if still having the unsafe package code will crash the system when Java restricts unsafe package or not, I think it won't right ? , because the try-catch block when initializing ("sun.misc.Unsafe") will fail and the canUseSunUnsafeReflectionProvider flag will be false.

Thank you in advance for any practical and useful answers/inputs.

[joehni]

The main point for using Unsafe is the initialization of classes without initializing them. That is was Java serialization does. If you control the marshalled classes, you may do as you've described, but your default constructors (or the general class initializer) should not do overcomplicated stuff. E.g. if the class initializer locks resources it can get problematic. Also without Unsafe it won't be possible to unmarshal object graphs that build rings or unmarshal non-static inner classes. But if you get your application already running with the PureJavaReflectionProvider, you don't have such cases ans you're safe.