This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 135982 - [Change Parameters] Implicit call of default constructor is not updated
Summary: [Change Parameters] Implicit call of default constructor is not updated
Alias: None
Product: java
Classification: Unclassified
Component: Refactoring (show other bugs)
Version: 6.x
Hardware: All All
: P3 blocker with 2 votes (vote)
Assignee: Jan Pokorsky
: 160957 (view as bug list)
Depends on:
Reported: 2008-05-28 11:46 UTC by Jiri Prox
Modified: 2009-05-19 15:37 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Note You need to log in before you can comment on or make changes to this bug.
Description Jiri Prox 2008-05-28 11:46:39 UTC
Product Version: NetBeans IDE Dev (Build 20080525200304)
Java: 1.6.0_10-beta; Java HotSpot(TM) Client VM 11.0-b11
System: Linux version 2.6.22-14-generic running on i386; UTF-8; en_US (nb)
Userdir: /home/jp159440/.netbeans/dev

When changing parameter of default constructor, the implicit calls in constructors of subclasses  are not updated. This
results in uncompilable code.
Comment 1 Jan Pokorsky 2009-03-24 22:45:16 UTC
*** Issue 160957 has been marked as a duplicate of this issue. ***
Comment 2 misterm 2009-04-28 16:10:08 UTC
In issue # 160957, it is suggested this is not an index problem, but should be worked around on refactoring side. 
However, this means not only Change parameters will have to contain a workaround, but also Find Usages, Safely delete 
and any other refactoring provided by third parties.

Are you sure it wouldn't be better to add those synthetic members to the index?
Comment 3 Jan Pokorsky 2009-04-29 15:25:24 UTC
Could you describe in more details why Safely Delete, Find Usages and any other refactoring provided by third parties
should contain a workaround please?
Comment 4 misterm 2009-04-29 15:32:50 UTC
If you have:

public class A {
   public A() {
      //do something

   public A(String s) {
      //do something else

Trying to safely delete A() needs to check whether there are subclasses whose constructors call super() implicitly.
Find usages on A() should find the same subclasses.

The same principle applies to any other refactoring.
Comment 5 misterm 2009-05-06 21:11:59 UTC
Any feedback on whether this is a refactoring issue or indexing issue?
Comment 6 Jan Pokorsky 2009-05-11 16:12:34 UTC
Sorry for delay, I has not been on-line for a while. Here is the update:

I have been investigating the class index a bit and it seems to contain references of implicit constructors. Thus there
is nothing to fix in the index. Instead of querying for subclasses it is possible to query for constructor references
directly so your use case with safely delete will work.

For the Change Parameters refactoring nothing changes. The subclasses query should be usually faster since it skips "new
Foo()" references.
Comment 7 Jan Pokorsky 2009-05-13 16:10:55 UTC
Comment 8 misterm 2009-05-19 15:36:53 UTC
Only the main issue got fixed. The other ones mentioned in the discussion are still broken. For instance, given:

public class SuperClass {
   public SuperClass() {}
   public SuperClass(Object o) {}


public class SubClass extends SuperClass {

Trying to safely delete SuperClass() should fail, but works now, leaving SubClass uncompilable. Find Usages on 
SuperClass() returns zero results, when it should point to the default constructor in SubClass. Third party 
refactorings applicable to SuperClass() will probably fail as well.

So I will mark this issue as VERIFIED, but will file two new ones.
Comment 9 misterm 2009-05-19 15:37:39 UTC
Filed issue # 166511 (Safely delete) and issue # 165512 (Find Usages)