Please use the Apache issue tracking system for new NetBeans issues (https://issues.apache.org/jira/projects/NETBEANS0/issues) !!
Bug 68123 - Find Usages on a public default constructor should report deser usage as one hit, if Externalizable
Find Usages on a public default constructor should report deser usage as one ...
Status: RESOLVED WONTFIX
Product: editor
Classification: Unclassified
Component: Refactoring
5.x
All All
: P3 with 1 vote (vote)
: 6.x
Assigned To: Jan Becicka
issues@java
enhanced_checks
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-11-04 20:27 UTC by Jesse Glick
Modified: 2016-07-07 07:31 UTC (History)
0 users

See Also:
Issue Type: ENHANCEMENT
:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2005-11-04 20:27:36 UTC
If you have a class which (directly or indirectly) implements
java.io.Externalizable, it must have a public no-argument constructor. This
constructor is called during deserialization. Therefore it ought to be reported
if you perform Find Usages on the constructor. Similarly, Delete Safely should
prevent you from accidentally deleting this constructor, and Change Method
Parameters should prevent you from adding arguments or changing its visibility
to something other than public.

Ideally, refactoring features should also understand that for
java.io.Serializable classes, matching readResolve, writeReplace, readObject,
and writeObject methods are special, and so something like "<used during
(de)serialization>" should appear as a special search hit in Find Usages, and
Change Method Parameters should not permit changing arguments or return type
(though changing visibility is OK and deleting these methods is also OK).

Somewhat related is that code completion in the main class body for Serializable
classes should offer those four special methods as possible "overrides" so you
do not have to remember the exact method signature.
Comment 1 Jan Becicka 2005-11-07 09:16:19 UTC
Currently refactoring module works only on language level. This type of checks
are library dependent and requires some semantic level of insight.
Comment 2 Jesse Glick 2005-11-08 01:01:28 UTC
Serialization is more a core part of the language than an arbitrary library,
even more so than most of the Java platform. Consider that deserializing an
object can bypass all its constructors, which is something you cannot otherwise
do outside JNI even using reflection.
Comment 3 Martin Balin 2016-07-07 07:31:18 UTC
This old bug may not be relevant anymore. If you can still reproduce it in 8.2 development builds please reopen this issue.

Thanks for your cooperation,
NetBeans IDE 8.2 Release Boss


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo