Browse DevX
Sign up for e-mail newsletters from DevX


Java History 101: Once Upon an Oak : Page 3

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

Abstract Methods (Section 5)
As in C++, abstract methods were defined like so:

public interface Storing { void freezeDry(Stream s) = 0; }

Assertions and Pre/Postconditions (Sections 7, 7.1, and 7.2)
Unfortunately, the assertions in Oak 0.2 were not implemented in time, so they were thrown out to satisfy the release deadline. If you think that assertions are back in JDK 1.4, have a look at the power that the Oak 0.2 assertions would have given you:

class Calender { static int lastDay[12]= {31,29,31,30,31,30,31,31,30,31,30,31}; int month assert(month>=1 && month<=12); int date assert(date>=1 && date<=lastDay[month]); }

Although objects are not required to obey the legality constraints within methods, the constraints are enforced at the entry and exit of every public and protected method. I wish James Gosling had worked a few more weekends (if that were possible) to finish the implementation of assert as it appeared in the original Oak spec. In addition, the spec also loosely defined preconditions and postconditions, but they also were given the boot due to time pressure. What a pity.

Post-incrementing Strings (Section 8.1.4)
In Oak, you were able to post-increment a String. You could literally say s1++;, which was equivalent to s1 = s1 + 1;. The post-increment statement is often (if not always) implemented as +=1, so it seems that this also was true for Strings. Fortunately, Java does not allow this anymore.

Goto ... (Section 9.3)
Of course, being based on C, Oak included the infamous goto statement. Fortunately, Java does not.

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