JDK 9 pre-review of JDK-6850612: Deprecate Class.newInstance since it violates the checked exception language contract

[Peter Levart]

Hi Joe,


On 04/22/2016 07:47 PM, joe darcy wrote:
> Hi Roger,
>
> Per other discussion in the thread, no new method will be introduced.
>
> The area owners will need to cleanup this usage of this method since 
> it may involve restructuring of catch blocks, etc., since the 
> recommended approach has different exception behavior.

The functionality of Class.newInstance() might have a logical 
replacement in existing API (getConstructor().newInstance()) but this 
replacement is not equivalent performance-wise.

As mentioned, Class.newInstance() has a special cache for constructor 
and caller that speeds up repeated invocations from the same caller by 
skipping access checks. Suppose there exist a public API like the following:

public <T extends SomeType> T instantiateAndSetup(Class<T> clazz) { ... }

...that uses clazz.newInstance() inside the implementation to construct 
new instances of passed-in classes. Suppose such API is widely used and 
is performance sensitive. What is the maintainer of that API supposed to 
do when Class.newInstance() is deprecated and later removed with no 
replacement? He has the following choices:

- deprecate his API and provide a replacement taking a Constructor 
object instead of a Class object and leave the responsibility of 
Constructor(s) caching to the user of the API.
- maintain an internal cache of Class -> Constructor in his 
implementation of the API. Such cache is not trivial as it must weakly 
reference Class and Constructor objects or ClassLoader leaks are 
possible and it has its own overhead.

Wouldn't it be possible to just change the specification of the method 
to wrap checked exceptions with an unchecked exception (such as 
UdeclaredThrowableException)? I think this would have a minimal impact 
on existing code as constructors usually don't throw checked exceptions 
- in particular the no-argument constructors.

Is there any evidence that such no-argument constructors exist at all, 
let alone that they are invoked via Class.newInstance() ?

Regards, Peter


>
> Thanks,
>
> -Joe
>
> On 4/22/2016 8:33 AM, Roger Riggs wrote:
>> Hi Joe,
>>
>> Wouldn't it be less make work to introduce the new method, replace 
>> the current one where appropriate
>> and then deprecate the existing method?  As it is, you/someone is 
>> going to make a second pass
>> over all the same files.
>>
>> Roger
>>
>>
>> On 4/21/2016 12:25 PM, joe darcy wrote:
>>> Hello,
>>>
>>> After a generally positive reception, please review the webrev to 
>>> implement the deprecation of Class.newInstance and the suppression 
>>> of the resulting warnings:
>>>
>>> http://cr.openjdk.java.net/~darcy/6850612.0/
>>>
>>> There are also some changes in the langtools repo; I'll send a 
>>> separate review request for those changes to compiler-dev.
>>>
>>> I'll also forward this review request to other areas with affected 
>>> code.
>>>
>>> Thanks,
>>>
>>> -Joe
>>>
>>> On 4/17/2016 10:31 AM, joe darcy wrote:
>>>> Hello,
>>>>
>>>> With talk of deprecation in the air [1], I thought it would be a 
>>>> fine time to 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:
>>>>
>>>>> Note that this method propagates any exception thrown by the 
>>>>> nullary constructor, including a checked exception. Use of this 
>>>>> method effectively bypasses the compile-time exception checking 
>>>>> that would otherwise be performed by the compiler. The 
>>>>> Constructor.newInstance method avoids this problem by wrapping any 
>>>>> exception thrown by the constructor in a (checked) 
>>>>> InvocationTargetException.
>>>>
>>>> Roughly, the fix would be to turn the text of this note into the 
>>>> @deprecated text and to add a @Deprecated(since="9") annotation to 
>>>> the method. There are a few dozen uses of the method in the JDK 
>>>> that would have to be @SuppressWarning-ed or otherwise updated.
>>>>
>>>> Thoughts on the appropriateness of deprecating this method at this 
>>>> time?
>>>>
>>>> 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.
>>>>
>>>> Thanks,
>>>>
>>>> -Joe
>>>>
>>>> [1] 
>>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-April/040192.html
>>>
>>
>