Community
Participate
Working Groups
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.
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
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 ?
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.
Discussed with David at the conf, and he agreed we are doing the right thing.