Wouldn't it be nice if constructors could be inherited and overridden just like methods?

[Anil Philip]

I was looking at the definition of RuntimeException

RuntimeException()
Constructs a new runtime exception with null as its detail message.

RuntimeException(String message)
Constructs a new runtime exception with the specified detail message.

RuntimeException(String message, Throwable cause)
Constructs a new runtime exception with the specified detail message and cause.

Then I looked at the definition of Exception which it inherits from:

Exception()
Constructs a new exception with null as its detail message.

Exception(String message)
Constructs a new exception with the specified detail message.

Exception(String message, Throwable cause)
Constructs a new exception with the specified detail message and cause.

Any derived class could not just latch onto the constructor of the base class and reuse the constructors.
It must define these all over again.
So I wondered; Wouldn't it be nice if constructors could be inherited and overridden just like methods?

[Stephan van Hulst]

And what syntax would you propose for that?

[Anil Philip]

Stephan van Hulst wrote:And what syntax would you propose for that?

Instead of defining those 3 constructors in RuntimeException, they would not be defined,
but would be invoked (in the case of the 3rd one)

throw new RuntimeException("my message", cause);

but Java would search for the constructor closest and up the hierarchy that matched and was defined.
In this case,

Exception(String message, Throwable cause)

[Stephan van Hulst]

That would be a really bad idea.

In essence, that means that I can no longer control whether and how a caller makes an instance of my class, and it also means that I can create instances of classes without providing the bare minimum of information they need for initialization.

Consider the following example:

var i = new Integer();

First of all, you're not supposed to instantiate an Integer directly. You're supposed to use a literal or one of the valueOf() factory methods. Secondly, if you DID instantiate an Integer directly, then what would it even mean to instantiate one without a value?

Remember, according to your proposal, Integer should inherit the parameterless constructor from the Number class.

[Anil Philip]

Stephan van Hulst wrote:
Remember, according to your proposal, Integer should inherit the parameterless constructor from the Number class.

Good point. Thanks.

[Tim Holloway]

Stephan van Hulst wrote:
First of all, you're not supposed to instantiate an Integer directly. You're supposed to use a literal or one of the valueOf() factory methods. Secondly, if you DID instantiate an Integer directly, then what would it even mean to instantiate one without a value?

"Not supposed to" in this case means that it's inefficient to instantiate Integers via construtors as opposed to Integer.valueOf(), especially for popular values like 0, 1, and so forth,

Incidentally, Integer.valueOf(null) should, I think invoke the valueOf(String) version as only unambiguous match. And it it does, it won't throw a NullPointerException, it will throw a NumberFormatException.

[Paul Clapham]

Tim Holloway wrote:Incidentally, Integer.valueOf(null) should, I think invoke the valueOf(String) version as only unambiguous match. And it it does, it won't throw a NullPointerException, it will throw a NumberFormatException.

No, it invokes Integer.valueOf(Integer), but yes, it does throw NumberFormatException:

java.lang.NumberFormatException: Cannot parse null string
at java.base/java.lang.Integer.parseInt(Integer.java:623)
at java.base/java.lang.Integer.valueOf(Integer.java:988)

EDIT: However line 988 in my JRE source code is inside a method whose declaration is

public static Integer valueOf(String s) throws NumberFormatException

so I must be misunderstanding how a stack trace is formatted.

[Mike Simmons]

When it says

at java.base/java.lang.Integer.valueOf(Integer.java:988)

this confusing notation does not mean valueOf(Integer) - it means a valueOf(<unspecified args>) method in the Integer.java file, line 988.  They leave out the argument types, which is extra annoying.  But at least the line number allows you to work out what they mean - as long as you are looking at the right source code.

[Rob Spoor]

Stephan van Hulst wrote:That would be a really bad idea.

In essence, that means that I can no longer control whether and how a caller makes an instance of my class, and it also means that I can create instances of classes without providing the bare minimum of information they need for initialization.

Consider the following example:

var i = new Integer();

First of all, you're not supposed to instantiate an Integer directly. You're supposed to use a literal or one of the valueOf() factory methods. Secondly, if you DID instantiate an Integer directly, then what would it even mean to instantiate one without a value?

Remember, according to your proposal, Integer should inherit the parameterless constructor from the Number class.

This could be circumvented by only automatically creating constructors if no explicit constructors exists. If you create just one constructor manually, no more automatically created constructors. That's already done right now with the no-argument constructor, but this would actually change what the compiler does - a single no-argument constructor might not be added anymore, but several others.

I don't think Oracle will implement this, and I won't miss it. Within seconds my IDE can create these constructors just as easily (and those seconds are me find the right context menu item).