Do you know if it is only newConstructorForSerialization? Is it worth keeping a minimal ReflectionFactory in sun.reflect that only exposes that?
On Wed, Dec 16, 2015 at 1:22 PM, Chris Hegarty <chris.hega...@oracle.com> wrote: > On 15/12/15 18:56, Joel Borggrén-Franck wrote: >> >> Hi Chris, >> >> I'm somewhat surprised to see ReflectionFactory on that list. Can you >> share more details around its external use? > > > ReflectionFactory.newConstructorForSerialization is used by several > popular third party serialization, mocking, proxying, libraries to > construct objects in a non-standard way. > > -Chris. > >> cheers >> /Joel >> >> On Tue, 15 Dec 2015 at 16:15 Chris Hegarty <chris.hega...@oracle.com >> <mailto:chris.hega...@oracle.com>> wrote: >> >> Paul, >> >> I cannot address your general question, but I guess it might be >> motivated >> by some of my recent preparatory work for JEP 260 [1]. This JEP >> proposes >> to expose a small number of critical API’s that are in the sun.misc >> and >> sun.reflect namespace. Anything not deemed critical should be removed >> from these packages, since it should not be exposed. There is also a >> significant amount of technical debt in these packages. >> >> -Chris. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8132928 >> >> On 15 Dec 2015, at 15:09, Paul Benedict <pbened...@apache.org >> <mailto:pbened...@apache.org>> wrote: >> >> > I have a general question prompted by the many classes moved from >> sun.* to >> > jdk.*. Once JDK 9 delivers on the Module System and internals are >> no longer >> > exposed, is it planned to eventually migrate away from the sun.* >> legacy >> > namespace in later JDK versions? >> > >> > Cheers, >> > Paul >> >
