> On 20 Dec 2015, at 19:46, Joel Borggrén-Franck > <joel.borggren.fra...@gmail.com> wrote: > > Do you know if it is only newConstructorForSerialization?
That is our understanding. > Is it worth > keeping a minimal ReflectionFactory in sun.reflect that only exposes > that? That is the current plan. -Chris. > 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 >>> >>
