I can echo a lot of what Rafael said.
JRebel is also a heavy user of the mentioned APIs here, especially
Unsafe.defineClass and Unsafe.allocateInstance -- we actually use all 4 ways
mentioned for creating an instance without calling the constructor (depending
on Java version and vendor).
Like testing frameworks, JRebel is also something minded for a development
environment, and not a production environment.
Yes, JRebel can be quite invasive with how we instrument things, and if no
official API exists for doing these things, we generally dig in the private
APIs until we find it; but an official supported API would always be preferable
and to me the Instrumentation API does seems like a good fit for this kind of
API.
One of the main things about Unsafe.defineClass is that it can define classes
in the boot (null) classloader (and in any package). We use this since we
sometimes need to define companion classes in the same package as an existing
on, including classes defined in the boot classloader.
/Michael
From: jigsaw-dev <jigsaw-dev-boun...@openjdk.java.net> on behalf of Jochen
Theodorou <blackd...@gmx.org>
Sent: 04 April 2018 01:24
To: jigsaw-dev@openjdk.java.net
Subject: Re: Avoiding sun.misc.Unsafe and embracing modules in Java libraries:
missing links
On 03.04.2018 21:26, Henri Tremblay wrote:
[...]
> For completeness, there are 4 ways to create a class without calling a
> constructor right now that I'm aware of:
>
> - Unsafe.allocateInstance
which is supposed to go away at some point
> - sun.reflect.ReflectionFactory.newConstructorForSerialization (my
> favorite because it's the fastest one)
which afaik works in java9 but is also one of those critical doomed APIs
> - Generate an extending class forgetting to call the super constructor
> (so it's not exactly that same class that is instantiated). It requires
> -Xverify:none
Is this really an option for a production environment?
> - Generate a class extending MagicAccessorImpl that will then
> instantiates the wanted class but calling the wrong constructor
Is jdk.internal.reflect.MagicAccessorImpl still usable in Java9+? I
thought this is no longer exported
Under the premise that all critical API usages will be removed in the
future and replacement APIs will be created I think we might indeed
still miss something here
bye Jochen
