Bug 173806 - Warning for private constructors are semantically incorrect
Summary: Warning for private constructors are semantically incorrect
Status: RESOLVED WONTFIX
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.3   Edit
Hardware: PC Windows XP
: P3 major (vote)
Target Milestone: 3.3 M6   Edit
Assignee: Philipe Mulet CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-02-11 16:50 EST by David Williams CLA
Modified: 2007-03-08 21:53 EST (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description David Williams CLA 2007-02-11 16:50:05 EST
I suspect this is some result of "fixing" bug 163443, but in M5 we started to get some warnings about "the constructor Foo() is  never used locally" if the constructor was private. 

From what I can tell, this is only for classes which do have a public constructor, which takes arguments. 

Case 1: which technically we could "fix" in our code. 

private Foo() {
  super();
}
public Foo(String s) {
   super();
   this.s=s;
}

This is a common pattern, and I think should not be flagged as a "not used" case. 
But, technically we could "fix" it (make the error go away) if we changed the second public constructor to use this() instead of super(). 

Case 2: which we can not fix in our code, and interacts with super class hierarchy. 

private Foo() {
  super();
}
public Foo(String s) {
  super(s);
}

In this case, the private constructor is (still) the valid way to denote that no instance can be constructed without a string, but we still get the red x. 

I put as "major" since I think this does qualify as a missing function. 
It pretty much requires developers to turn off the warning about private member functions.
Comment 1 Olivier Thomann CLA 2007-02-16 15:03:07 EST
This is reported in Eclipse code as warnings during the build.
Here are the plugins that are using this pattern:
org.eclipse.ant.ui
org.eclipse.equinox.preferences
org.eclipse.jdt.compiler.apt
org.eclipse.jdt.debug.ui
org.eclipse.update.core
Comment 2 Philipe Mulet CLA 2007-03-04 09:45:57 EST
David - a default constructor is ONLY added by the compiler if not other constructor is defined. Therefore, I don't see what the addition of extra private constructors is buying you; which is what the compiler is trying to tell you.

Basically in both examples you gave, I don't see why discarding the unused private constructor would not be the right move... maybe missing something ?
Comment 3 Olivier Thomann CLA 2007-03-08 13:14:27 EST
You might need the default constructor to be able to use the reflection and newInstance() to create a new instance, but you want to ensure that no users are instanciating this class that way.
I wonder if using a constructor with package visibility would not do the same thing since in most cases, users are working outside of the current package.
Comment 4 Philipe Mulet CLA 2007-03-08 21:53:43 EST
Discussed with David at the conf, and he agreed we are doing the right thing.