<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<pre><span class="new">+ @SuppressWarnings("serial") // Not statically typed as Serializable
So is the comment being used to distinguish this overloading of what "serial" means ?
Why not introduce a new warning category ?
</span></pre>
Randomly looking at <br>
====<br>
src/java.desktop/share/classes/java/awt/Container.java<br>
<br>
@@ -3849,10 +3849,11 @@<br>
<br>
/**<br>
* The handler to fire {@code PropertyChange}<br>
* when children are added or removed<br>
*/<br>
+ @SuppressWarnings("serial") // Not statically typed as
Serializable<br>
protected ContainerListener accessibleContainerHandler =
null;<br>
===<br>
<br>
I see that Container has a writeObject method which doesn't write
this field, so it is effectively transient.<br>
<br>
I recognise that it is difficult for the compiler to figure this
out, so perhaps there should just be a policy<br>
not to check classes that have writeObject methods ?<br>
<br>
Also in such a case, would it be an effectively compatible change to
add transient to the field, so that<br>
it presumably would no longer need this warning.<br>
<br>
I haven't looked but presumably there could be other such cases.<br>
<br>
Will you be filing bugs for all the fixable cases ?<br>
<br>
-phil<br>
<br>
On 9/21/19, 12:48 PM, Joe Darcy wrote:
<blockquote
cite="mid:ed084e59-bebd-714e-d8af-893115f0e6b3@oracle.com"
type="cite">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<p>Hello,</p>
<p>Quick background, I'm working on expanding the compile-time
serialization checks of javac's -Xlint:serial option. Ahead of
that work going back, I'm analyzing the JDK sources and plan to
pre-suppress the coming-soon new warnings, fixing or at least
filing follow-up bugs for any problems that are found.
Corresponding suppression bugs are already out for review
against core libs (JDK-8231202) and security libs (JDK-8231262).</p>
<p>The new check in development is if a serializable class has an
instance field that is not declared to be a serializable type.
This might actually be fine in practice, such as if the field in
question always points to a serializable object at runtime, but
it is arguably worth noting as an item of potential concern.
This check is skipped if the class using the
serialPersistentFields mechanism.</p>
<p>For the client libs, the webrev with the new
@SuppressedWarnings annotations is:<br>
</p>
<p> JDK-8231334: Suppress warnings on non-serializable instance
fields in client libs serializable classes <br>
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://cr.openjdk.java.net/%7Edarcy/8231334.0/">http://cr.openjdk.java.net/~darcy/8231334.0/</a></p>
<p>The changes are mostly in awt, but also some in beans, a few in
printing, and one in sound.<br>
</p>
<p>As discussed with Phil off-line, the new checks also found an
existing known issue, the auxiliary class <span
class="c-message__body" dir="auto" data-qa="message-text">java.awt.ImageMediaEntry
declared in </span><span class="c-message__body" dir="auto"
data-qa="message-text"><span class="c-message__body"
dir="auto" data-qa="message-text">MediaTracker.java is not
serializable/deserializable in practice (JDK-4397681).</span></span></p>
<p><span class="c-message__body" dir="auto" data-qa="message-text"><span
class="c-message__body" dir="auto" data-qa="message-text">Thanks,</span></span></p>
<p><span class="c-message__body" dir="auto" data-qa="message-text"><span
class="c-message__body" dir="auto" data-qa="message-text">-Joe<br>
</span></span></p>
</blockquote>
</body>
</html>