Browse DevX
Sign up for e-mail newsletters from DevX


Java History 101: Once Upon an Oak : Page 2

Delve into the early days of Java's development and you'll discover the answers to some age-old Java questions.




Building the Right Environment to Support AI, Machine Learning and Deep Learning

Unsigned Integer Values (Section 3.1)
The specification says "the four integer types of widths of 8, 16, 32, and 64 bitsare signed unless prefixed by the unsigned modifier.

The margin explains further: "unsigned isn't implemented yet; it might never be." How right the author was.

Storage of Integer Values (Section 3.1)
In my newsletter on Determining Memory Usage in Java, I noted that when you have a data member of byte or short, it still uses at least 4 bytes of memory. This changed in JDK 1.4. The Oak spec provides the historical reason why this was done:

"A variable's type does not directly affect its storage allocation. Type only determines the variable's properties and legal range of values. If a value is assigned to a variable that is outside the legal range of the variable, the value is reduced modulo the range."

I wish I had known that when I wrote my first Java program. I spent a lot of time deliberating which data types I wanted to use in order to save memory, but I was actually wasting my time. Since this changed as of JDK 1.4, now using bytes and shorts does help to reduce the memory footprint.

Arrays (Section 3.5)
In Oak, you were able to declare arrays as follows:

int a[10]; a[5] = 1;

However, you were also able to declare an array in the current Java fashion with new. Because having two ways of doing the same thing causes confusion, I am very pleased that the old way was removed.

Const vs. Final (Sections 4.6 and 4.9)
Apparently, programmers initially were meant to use final only for classes and methods and const for making fields constant.

Private Did Not Exist (Sections 4.10)
This was to me the most surprising part of Oak 0.2. It had only three access levels (public, protected, and private) as opposed to the current four. Private did not require a keyword and equated to the current "package private" or "friendly" or "package access" type of access level. All classes in a particular package could use all variables and methods declared in the classes in that package, regardless of public, protected, and private declarations. I am very glad that they introduced a more private version of private, one that was accessible only within the class.

The lack of private as you know it today explains why when a member is protected, it is also accessible from within the same package. When Oak was written, protected was obviously accessible within the package because its private (Java's "package access") was the most restrictive access level. I seem to remember that in JDK 1.0 you had a fifth access level called "private protected", which meant that only subclasses could access the member.

This piece of surprising history also explains why fields are not private by default—they actually were "private" originally, when private meant something different. Needless to say, I am quite pleased to have the more restrictive "private" modifier. Without it, the industry would be in even more trouble.

Comment and Contribute






(Maximum characters: 1200). You have 1200 characters left.



Thanks for your registration, follow us on our social networks to keep up-to-date