Replacement for sun.misc.Unsafe.allocateInstance(Class<?>) ?
aph at redhat.com
Sun Aug 2 10:20:48 UTC 2015
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
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
> 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.
More information about the core-libs-dev