Replacing Unsafe.allocateInstance

[Henri Tremblay]

Hi,

You summarized the 3 usages well.

Mocking should be allowed for any class since any class can be mocked. Even
the JDK ones
Mocking is mainly used for testing but can also be used for stubbing at
runtime. Not in production but during development or QA. For instance, you
can use a mock from EasyMock and inject it through dependency injection

Proxying is indeed another use case. Of course, it is used in production
code

About serialization, there is one special feature. The Java serialization
is in fact calling the default constructor of the first non-serializable
parent class. So Objenesis has two kinds of instantiator:
1) Mocking and Proxying: No constructor called (or, to be accurate, only
Object default constructor is called)
2) The default constructor of the first non-serializable parent class is
called

We should support both if we when to help alternate serialization
frameworks I think. Unsafe.allocateInstance can't help us for that.

Then, I want to make sure I got the security problem right. Right now, the
ReflectionFactory isn't protected by anything apart the fact the it is in a
sun.* package. So if we move it in a java.* package, we will need to
provide a way to add security to it. Am I getting it?

Being still pragmatic, I agree with the security side of it, however, I
don't think we should put more security on it than what we already have.
But I'm not an expert in that domain so I don't know exactly what security
features are currently preventing using ReflectionFactory and Unsafe.


On 30 June 2015 at 05:22, Paul Sandoz <paul.sandoz at oracle.com> wrote:

> Hi Henri,
>
> Thanks for raising this discussion.
>
> Just to augment what Chris says here.
>
> We cannot directly expose Unsafe.allocateInstance in a public API and try
> and place in a little known corner and hope only the people who are meant
> to use it will and will do so responsibly :-)
>
> There are a bunch of general use-cases:
>
>   1) Mocking;
>   2) Proxying; and
>   3) Serialization.
>
> It should be possible to corral 3 (and possibly 2) in some safe mechanism.
> I dunno how to do that for 1.
>
> Constructing an object without calling its constructor is inherently
> integrity busting (unless somehow hidden or contained) and IIUC mocking by
> design is a form of semi-controlled integrity busting.
>
> Would i be correct in assuming that mocking is primarily used for testing
> and that if used in production would raise some eye brows?
>
> One approach we could consider for 1, trying to be pragmatic and
> recognising the reality here, is a method that constructs an object without
> calling it's constructor under the following conditions:
>
> 1) a security check is performed if a security manager is present; and
>
> 2) it would not be possible to construct any JDK class (e.g. classes
> loaded by the boot loader).
>
> That is not a definite proposal but i would be really interested in your
> feedback given your experience with Objenesis and mocking.
>
> Paul.
>