I wanted to reply that if you have a perf sensitive code that uses newInstance you should use a MethodHandle instead to avoid to do the security checks multiple times but i remember that they was an issue with MethodHandle attached to a constructor and i don't know if it was resolved.
Rémi Le 19 avril 2016 12:41:00 CEST, Peter Levart <peter.lev...@gmail.com> a écrit : >Hi, > >On 04/19/2016 01:05 AM, Stuart Marks wrote: >> >> >> On 4/17/16 10:31 AM, joe darcy wrote: >>> With talk of deprecation in the air [1], I thought it would be a >fine >>> time to >> >> "In the Spring a young man's fancy lightly turns to thoughts of >> deprecation." >> -- apologies to Tennyson >> >>> examine one of the bugs on my list >>> >>> JDK-6850612: Deprecate Class.newInstance since it violates the >>> checked >>> exception language contract >>> >>> As the title of the bug implies, The Class.newInstance method >>> knowingly violates >>> the checking exception contract. This has long been documented in >its >>> specification: [...] >>> >>> Comments on the bug have suggested that besides deprecating the >>> method, a new >>> method on Class could be introduced, >>> newInstanceWithProperExceptionBehavior, >>> that had the same signature but wrapped exceptions thrown by the >>> constructor >>> call in the same way Constructor.newInstance does. >> >> Deprecating Class.newInstance() seems reasonable to me, for the >> reasons you've stated. >> >> It's not clear to me that a replacement method adds much value. I >> believe it's possible to replace a call >> >> clazz.newInstance() // 1 >> >> with the call >> >> clazz.getConstructor().newInstance() // 2 >> >> which is only a bit longer. Both snippets are declared to throw >> InstantiationException and IllegalAccessException. But snippet 2 also > >> is declared to throw InvocationTargetException and >NoSuchMethodException. >> >> This would seem to be an inconvenience, but *all* of these exceptions > >> are subtypes of ReflectiveOperationException. It seems pretty likely >> to me that most code handles these different exception types the same > >> way. So it's fairly low cost to replace snippet 1 with snippet 2, and > >> to adjust the exception handling to deal with >> ReflectiveOperationException. Thus I don't see much value in adding a > >> new method such as Class.newInstanceWithProperExceptionBehavior(). > >...except for performance. The Class.newInstance() does special >constructor and caller caching so that access checks don't have to be >performed at every invocation. > >Performance sensitive user code using Class.newInstance() should then >probably be modified to obtain Constructor only once and then re-use it > >for multiple invocations. > >Regards, Peter > >> >> s'marks
