Technical reason for no default parameters in Java

问题:

I've been looking around to try to find what the reasoning is behind not including default parameters for functions in Java.

I'm aware that it's possible to simulate the behavior, either with varargs or else by creating several overloaded functions that accept fewer parameters, and call the real function that takes all parameters. However, neither of these options match the clarity and ease-of-use of, e.g. C++'s syntax.

Does anyone know if there's a solid technical reason that would make something like

void myFunc(int a=1, int b=2) {...}

undesirable or undo-able in a new version of Java?

回答1:

I am not aware of a technical reason, apart from it being complicated which values are being omitted and which ones are not.

For example, in your sample, if only one integer was passed through then is it a or b that should be defaulted? Most probably a but it does add that level of ambiguity.

A simple solution would be to

void myFunc(Integer a, Integer b) {
  if (a == null) a = 1;
  if (b == null) b = 2;

}

Yes it is more long winded, and yes it hides the defaulting within the code, rather than the method signature (which could then be shown in JavaDoc), but it does enforce the consistency.

回答2:

To Avoid Ambiguity. Java Support Method Override.

We assume the code below:

public int add(int a) {
    // do something
}

public int add(int a, int b = 0) {
    // do something
}

When we call add(12), Can you tell me which function is invoked?

回答3:

It was not in the initial version of Java because they decided they did not need it, probably to keep things simple.

Adding it now would be tricky, because it needs to be done in a backwards-compatible fashion. Adding varargs, autoboxing and generics in Java5 was a major undertaking, and it could only be done with limited functionality (such as type erasure) and at the cost of increased complexity (the new method resolution rules make for good exam trick questions).

Your best shot would be with a non-Java language on the JVM. Maybe one of them already has this.

回答4:

I agree that optional arguments would add huge clarity and save the huge work of defining loads of overloaded methods (called telescoping), which do nothing than call each other. However, the enabler for this neat feature is passing arguments by name.

Named association is self-documenting. In contrast, positional argument association is concise but it makes you to refer the definition of method all the time to check which argument is expected in nth position at every invocation. This is ridiculous and motivates us to search for solutions like Builder pattern. The Builder actually solves both problems at once because named association is a synonym for optional arguments. But Builder is useful only for user. API designer still must waste space/time to create the Builder class. Pattern bigots might disagree but it is an overkill to create a Builder class for every method with named/optional arguments. Language design should obviate this stupid pattern. But, I do not know how compatible they are with the variable argument list.