Replacing Unsafe.allocateInstance

[charlie hunt]

Hi Chris,

You mentioned you have “Seen serialization frameworks that create String instances and “injecting” a char[] afterwards however I prefer calling the package private constructor to just prevent copying of the char[] (in cases where it won’t break the immutability contract like deserialization).”

Could you possibly point me to such serialization frameworks, and you also mentioned you prefer calling the package private constructor (I’m assuming this is on java.lang.String) ?

I do not need to see the entire code base, a segment of code that shows how java.lang.String is being constructed would be sufficient, (in the case you described and the aforementioned serialization frameworks).

thanks,

charlie

> On Aug 2, 2015, at 2:52 AM, Christoph Engelbert <chris at hazelcast.com> wrote:
> 
> Hey Paul,
> 
> The assumption of non creating JDK classes without calling constructors is not completely right.
> Seen serialization frameworks that create String instances and “injecting” a char[] afterwards however I prefer calling the package private constructor to just prevent copying of the char[] (in cases where it won’t break the immutability contract like deserialization).
> 
> Chris
> 
>> Am 30.06.2015 um 12:22 schrieb Paul Sandoz <paul.sandoz at oracle.com>:
>> 
>> 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.
>