Why does the android Color class have a public constructor when all its members are static? Is it just a mistake?
-
You'd probably have to track down the Google engineer who wrote the `Color` class all those years ago, and ask. – CommonsWare Aug 27 '14 at 19:34
2 Answers
Probably consistency and potential future use are reasons for the engineer to write a constructor even if it does nothing. But, the engineer may not have written the constructor. A default public constructor is created by the compiler if no constructor is given.
See the answer given here. It links to this.
The documentation, which is probably auto-generated to some extent, might inform you of the default constructors' existence, even if the engineer did not create it.
The source code for the Color.java file shows that no Google engineer explicitly wrote a public constructor for the Color class.
The API documentation for the Color class does list a public constructor, but Java has an implicit default constructor, and that is the constructor listed in the documentation.
The real possible questions here are either/or,
- Why does the Google Android documentation list implicit default constructors in the constructor section of class documentation?
- Why does Java have an implicit default constructor when I could possibly make a class that only has static members?
For the first point I don't think that is any mistake or a bad design decision of Google to decide to list the implicit default constructor. They could define a constructor in the class to restrict access to any constructors, but that would just require extra code, and uselessly creating a default constructor for a class that only has static members does not cause any misuse of the class.
For the second point it might make sense to have a compiler optimization to prevent any implicit default constructors in classes that have only static members, but that's a question for another thread.
tl;dr Nope, not a mistake.

- 995
- 1
- 12
- 27
-
@dragon66 I would still argue that this is not an individual developers problem to be solved, but rather a language feature that you may or may not like. Other languages approach it differently. If you really don't like it, you can go make a pull request, Android is open source. – yiati Nov 23 '15 at 15:58
-
Nope, even with a private constructor you can still instantiate it with reflection. The only way for an individual developer to solve this problem is to both implement a private constructor, and throw an exception in the private constructor. This is not a problem for an individual developer to solve. As I discussed around the second point there could be a compiler optimization around this, but that is still not a problem for an individual developer to solve. – yiati Nov 24 '15 at 04:40
-