Replacement for sun.misc.Unsafe.allocateInstance(Class<?>) ?
Hello guys, there's a lot of talk about making sun.misc.Unsafe unaccessible in JDK 9 ... however, there seems no replacement for the allocateInstance method. XStream is relying heavily on this functionality and without it the library will no longer be able to deserialize a lot of objects from XML. What are the long-term options? Cheers, jörg
Hey Jörg, It will not yet be unaccessible, you just have to force JDK 9 to export the sun.misc package to be visible to user code. There will be a command line flag for that purpose, however I agree eventually we’ll need a replacement, whatever it looks like. Chris
Am 31.07.2015 um 20:33 schrieb Jörg Schaible <joerg.schaible@gmx.de>:
Hello guys,
there's a lot of talk about making sun.misc.Unsafe unaccessible in JDK 9 ... however, there seems no replacement for the allocateInstance method.
XStream is relying heavily on this functionality and without it the library will no longer be able to deserialize a lot of objects from XML. What are the long-term options?
Cheers, jörg
On 31/07/15 18:33, Jörg Schaible wrote:
there's a lot of talk about making sun.misc.Unsafe unaccessible in JDK 9 ... however, there seems no replacement for the allocateInstance method.
XStream is relying heavily on this functionality and without it the library will no longer be able to deserialize a lot of objects from XML. What are the long-term options?
In the long term we're going to need a more official way for non-core serialization to create uninitialized objects. I suspect it's more likely to look like sun.reflect.ReflectionFactory than Unsafe.allocateInstance. However, the security problems are great. I haven't heard any suggestion about how to expose this feature to user-created libraries without breaking Java security, and I suspect there may be none. Andrew.
On 08/01/2015 10:57 AM, Andrew Haley wrote:
However, the security problems are great. I haven't heard any suggestion about how to expose this feature to user-created libraries without breaking Java security, and I suspect there may be none.
Are the problems greater than those of general reflection after setAccessible(true)? I don't think so. I think the main objection would be philosophical (against adding yet more trapdoors). I respect that—but at the same time, there does not seem to be a core technical requirement why a suitable API with a proper permission check could not be added to the JDK. -- Florian Weimer / Red Hat Product Security
On 01/08/15 23:38, Florian Weimer wrote:
On 08/01/2015 10:57 AM, Andrew Haley wrote:
However, the security problems are great. I haven't heard any suggestion about how to expose this feature to user-created libraries without breaking Java security, and I suspect there may be none.
Are the problems greater than those of general reflection after setAccessible(true)?
No. Either blows a huge hole on the usual guarantees.
I don't think so. I think the main objection would be philosophical (against adding yet more trapdoors).
"philosophical" doesn't mean "unimportant" or "fussy", though: it goes to the very core of the way that Java is used and is intended to be used.
I respect that—but at the same time, there does not seem to be a core technical requirement why a suitable API with a proper permission check could not be added to the JDK.
We have ReflectionFactory already, and I suppose as long as there are security checks there's no strong security-related reason not to move that class into, say, java.lang.reflect. Having said that, there are real problems where parts of the VM "know" something about the structure of an object. For example, String instances always have a char[] attached, and HotSpot makes use of that fact. Violating such invariants may cause the VM to crash. I don't know that a list of such invariants exists. Perhaps that's not exactly a security worry, but it's surely a problem. Andrew.
On 1/08/2015 3:33 AM, Jörg Schaible wrote:
Hello guys,
there's a lot of talk about making sun.misc.Unsafe unaccessible in JDK 9 ... however, there seems no replacement for the allocateInstance method.
XStream is relying heavily on this functionality and without it the library will no longer be able to deserialize a lot of objects from XML. What are the long-term options?
See: http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-June/002342.html for existing discussion. David
Cheers, jörg
participants (5)
-
Andrew Haley
-
Christoph Engelbert
-
David Holmes
-
Florian Weimer
-
Jörg Schaible