This is only conjecture but it's possibly the safest design for PODs if the language doesn't force initialization at the point of definition for the compiler to be able to detect uninitialized variables and post errors.
A compile-time error is preferable to a surprise at runtime, and initializing these to default values like
false for a
boolean could end up being something the programmer did not actually want -- although initializing variables with default values is still preferable to garbage as in C since it at least provides deterministic behavior.
Anyway, that would be my best guess -- it's done to prevent accidents from occurring where a programmer might have intended to set a
true, e.g., but forgot to initialize it. The language designers decided to make that an error instead of making it default to
false. The designers decided to explicitly require programmers to spell things out instead of having implicit default behavior which might not match what they intended.
Furthermoore, why was it not changed in later, more modern java
versions ? (7,8,9) ?
If it started out this way and the rationale above matches the designers of the language, then it's not a safe change to turn what was formerly an error into passable runtime behavior. Suddenly what would have been former errors in old code now pass without error in ways that could go from code that doesn't build where the compiler can point out what it's doing wrong to code which can suddenly run but only in ways that cause runtime behavior which was different from what the programmer originally intended. From a language design standpoint, if it started out this way, then you want to keep it this way indefinitely.
But isn't it the other way round? If a program was never legal (i.e.
resulted in compiler error, or invoked unspecified behaviour), then it
is safe for the language designers to assign some meaning to this
I wanted to add this question into the comment since it's such a good one that really made me think a lot about it. I would suggest a strong "no" but need some careful explanation. The gist of it is that you cannot confidently introduce implicit functionality into a language or a library that formerly considered the original behavior where the programmer failed to specify his intentions a mistake, because we cannot assume the implicit behavior we're inserting in place of the former mistake was in line with his original unspecified intentions. A language that was originally built with the specification that
boolean x will have a default value of
false is fine, but lacking such a specification so late in the game, we can't suddenly decide we can read people's minds.
These build errors are not the result of limitations, they are the result of the language designers intentionally considering the failure for the programmer to specify intent a real human error. It's not the type of case where you can go back on such a firm design decision in the language with a historical design rationale behind it in ways that can guarantee no horrific side effects in all possible cases. To provide default implicit behavior is not expanding the language capabilities in this case, it's reverting a fundamental design decision at the heart of the type system, and reverting fundamental design decisions in a mature language or library is generally something to strongly err against doing.
I might come off like I'm being paranoid and too strict/dogmatic, but such is often the requirement to maintain a mature language or library with countless lines of code produced by people across the world for years written against it. We can't suddenly decide to go back on fundamental design decisions in ways that alters the behavior of all code ever written for said language/library far removed from our control, even if it's just turning a formerly decided error into a non-error. That's not an expansion of the language, that's a fundamental design change and a no-no in the majority of cases unless absolutely required, and providing implicit default values for PODs was practically never a requirement for Java devs to get on with their day.
For example, if former code had
boolean x and tried to use it, you can't suddenly go from the language treating that like a mistake to then being able to assume that the programmer intended
x to be
false, since the former design he wrote the code against never specified that behavior. He might have wanted
x to be
true, and now instead of code which just fails to run, the code might now run and cause sporadic bugs that are hard to ever trace down to this cause (far, far worse than code that simply fails to run).
As an analogical example which will more clearly highlight the problem, right now Java does not allow arrays to be indexed with negative numbers (some languages provide this and allow circular indexing). To do so is considered a programmer mistake and error, and the system will throw an out of bounds exception. However, if the language designers suddenly change their mind and decide negative indexing of plain old arrays should now be allowed and that it should be fine to introduce because former code that negatively indexed arrays were never working in the first place, well now you might have turned horrible programmer mistakes which could have been caught on execution into non-mistakes with an assumption that this is now okay. The practical end result could be that we've now obscured and hidden some very, very deadly bugs introduced in code written against prior Java versions before it supported negative indexing.