[prev in list] [next in list] [prev in thread] [next in thread]
List: openjdk-2d-dev
Subject: Re: [OpenJDK 2D-Dev] Fwd: Re: JDK 9 pre-review of JDK-6850612: Deprecate Class.newInstance since it
From: Philip Race <philip.race () oracle ! com>
Date: 2016-04-27 16:55:29
Message-ID: 5720EF01.3070902 () oracle ! com
[Download RAW message or body]
Rather than adding all these annotations I would prefer that you do
what Stuart did with the boxed primitive constructor deprecation
where he disabled the deprecation checking on the desktop module
until we can clean it up. That one was done within about a week and
should be in dev in a few days ..
-phil
On 4/26/16, 9:45 AM, joe darcy wrote:
>
> Phil and other client reviewers,
>
> Please review this change from core libs which impacts client libs
> implementations. In brief, deprecating a method in core reflection
> requires uses of that method to have a
> @SuppressWarnings("deprecation") annotation. The typical way to
> minimize the scope of the deprecation is to declare a temporary
> variable which can host the @SuppressWarnings annotation. The
> alternative would have been to suppress the warning on the entire
> method, which would allow addition use of deprecated methods to sneak in.
>
> http://cr.openjdk.java.net/~darcy/6850612.0/
>
> Thanks,
>
> -Joe
>
>
> -------- Forwarded Message --------
> Subject: Re: JDK 9 pre-review of JDK-6850612: Deprecate
> Class.newInstance since it violates the checked exception language
> contract
> Date: Thu, 21 Apr 2016 09:25:27 -0700
> From: joe darcy <joe.darcy@oracle.com>
> Organization: Oracle Corporation
> To: core-libs-dev <core-libs-dev@openjdk.java.net>
>
>
>
> 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
>
[Attachment #3 (text/html)]
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Rather than adding all these annotations I would prefer that you do<br>
what Stuart did with the boxed primitive constructor deprecation<br>
where he disabled the deprecation checking on the desktop module<br>
until we can clean it up. That one was done within about a week and<br>
should be in dev in a few days ..<br>
<br>
-phil<br>
<br>
On 4/26/16, 9:45 AM, joe darcy wrote:
<blockquote
cite="mid:57f52e95-9485-1114-5314-cbdf1680709b@oracle.com"
type="cite">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<p>Phil and other client reviewers,</p>
<p>Please review this change from core libs which impacts client
libs implementations. In brief, deprecating a method in core
reflection requires uses of that method to have a
@SuppressWarnings("deprecation") annotation. The typical way to
minimize the scope of the deprecation is to declare a temporary
variable which can host the @SuppressWarnings annotation. The
alternative would have been to suppress the warning on the
entire method, which would allow addition use of deprecated
methods to sneak in.</p>
<p> <a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://cr.openjdk.java.net/%7Edarcy/6850612.0/">http://cr.openjdk.java.net/~darcy/6850612.0/</a><br>
</p>
<p>Thanks,<br>
</p>
<p>-Joe<br>
</p>
<div class="moz-forward-container"><br>
-------- Forwarded Message --------
<table class="moz-email-headers-table" border="0"
cellpadding="0" cellspacing="0">
<tbody>
<tr>
<th align="RIGHT" nowrap="nowrap" valign="BASELINE">Subject:
</th>
<td>Re: JDK 9 pre-review of JDK-6850612: Deprecate
Class.newInstance since it violates the checked
exception language contract</td>
</tr>
<tr>
<th align="RIGHT" nowrap="nowrap" valign="BASELINE">Date:
</th>
<td>Thu, 21 Apr 2016 09:25:27 -0700</td>
</tr>
<tr>
<th align="RIGHT" nowrap="nowrap" valign="BASELINE">From:
</th>
<td>joe darcy <a moz-do-not-send="true"
class="moz-txt-link-rfc2396E"
href="mailto:joe.darcy@oracle.com"><joe.darcy@oracle.com></a></td>
</tr>
<tr>
<th align="RIGHT" nowrap="nowrap" valign="BASELINE">Organization:
</th>
<td>Oracle Corporation</td>
</tr>
<tr>
<th align="RIGHT" nowrap="nowrap" valign="BASELINE">To: </th>
<td>core-libs-dev <a moz-do-not-send="true"
class="moz-txt-link-rfc2396E"
href="mailto:core-libs-dev@openjdk.java.net"><core-libs-dev@openjdk.java.net></a></td>
</tr>
</tbody>
</table>
<br>
<br>
<pre>Hello,
After a generally positive reception, please review the webrev to
implement the deprecation of Class.newInstance and the suppression of
the resulting warnings:
<a moz-do-not-send="true" class="moz-txt-link-freetext" \
href="http://cr.openjdk.java.net/%7Edarcy/6850612.0/">http://cr.openjdk.java.net/~darcy/6850612.0/</a>
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]
> <a moz-do-not-send="true" class="moz-txt-link-freetext" \
href="http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-April/040192.html">http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-April/040192.html</a>
</pre>
</div>
</blockquote>
</body>
</html>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic