Browse DevX
Sign up for e-mail newsletters from DevX


Java History 101: Once Upon an Oak

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

few weeks ago I was talking to someone about the origins of Java when I realized that I had big gaps in my knowledge of Java's history. Trying to fill these gaps, I started digging around on Sun's Web site, and I eventually stumbled across the Oak Language Specification. Oak was the original name of what is now commonly known as Java, and this specification is the oldest manual available for Oak (i.e. Java). (For more on the origins of Java, have a look at The Green Project and Java(TM) Technology: An Early History.)

I printed the manual and kept it next to my bed in case of insomnia (so I thought). However, to my pleasant surprise, when I started reading it not only did it keep me awake, but I also discovered answers to age-old Java questions:

  • Why can you have only one public class per .java file?
  • Why are protected members also accessible from the same package?
  • Why do short fields use as much memory as int fields (at least pre-JDK 1.4)?
  • In this article, I highlight the differences between Java 0.2 (i.e., Oak 0.2) and the Java we have now. For reference, I include the section numbers in the Oak 0.2 specification.

    Why Is Each Public Class in a Separate File? (Section 1)
    I have been asked this question frequently while teaching my Java courses. Until now I have not had a good answer. Section 1 states: "Although each Oak compilation unit can contain multiple classes or interfaces, at most one class or interface per compilation unit can be public."

    The margin explains why: "This restriction is not yet enforced by the compiler, although it's necessary for efficient package importation."

    The compiler would have to make an additional pass through all the compilation units (.java files) to figure out which classes were where, which would make the compilation even slower.

    One-line Javadoc Comments (Section 2.1)
    Oak had the ability to write a one-line JavaDoc comment, like so:

    public class OneLineJavaDoc { //* The number of lines allowed in a document. public int numberOfLines; }

    Fortunately, Java does not support this confusing construct.

    Additional Keywords (Section 2.3)
    Oak had some additional keywords that are not available in Java:

  • clone, const and goto were keywords, and ushort, string, Cstring and unsynchronized were obsolete by version 0.2. Isn't it amazing how quickly things become obsolete in this industry?
  • protect and unprotect were nasty keywords for writing terrible exception code (more about that later).
  • enum was a keyword, but the sidebar stated that enum isn't implemented yet. So, the answer to the question why does Java not have enum is not a heavy philosophical one about object-oriented polymorphism and strategy patterns. It is simply that James Gosling didn't implement it in time, and his management forced him to push the language out the door before he could finish the feature. ;-)

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