Replacing Unsafe.allocateInstance

[Henri Tremblay]

We currently have two valid ways to do it. It has been possible since the
first version of Java. Both can be blocked by a security manager.

So I really don't see why we should now limit the practice in scope.

Creating a bogus class in Java is already quite easy. I can just hack
around using reflection. This presentation (and variation of it) is one of
my personal favorite:
http://fr.slideshare.net/JAXLondon2014/reflection-madness-dr-heinz-kabutz

My conclusion is that user should have two choices:

   - Use a security manager to prevent dangerous behavior. Knowingly
   disallow some performance hack and forcing to add unnecessary default
   constructor. This is the approach taken by Google App Engine for instance
   - Do not use a security manager and trust the code. This is the approach
   I must say I've seen everywhere for the last 15 years. I've worked for
   banks and some limited military stuff. I still need to check at nuclear
   power plant, fighter jets or space shuttles. I do hope they use a security
   manager ;-)


On 30 June 2015 at 11:58, Brian Goetz <brian.goetz at oracle.com> wrote:

> Mocking should be allowed for any class since any class can be mocked. Even
>> the JDK ones
>>
>
> An understandable user perspective :)
>
> Unfortunately, many serious security bugs can stem from being able to
> create a bogus instance of a JDK class that is loaded off the
> bootclasspath, and the existence of vectors for creating these exploits is
> a negative for the entire ecosystem.  So, we may need to make some
> tradeoffs between security and convenience.
>
> (Many JDK APIs primarily expose interfaces anyway; these are easily mocked
> without magic.)
>
>