Browse DevX
Sign up for e-mail newsletters from DevX


Java History 101: Once Upon an Oak : Page 4

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

Exceptions (Section 9.4)
Where does the name RuntimeException come from? Aren't all exceptions thrown at runtime? Of course they are, but these exceptions are called runtime because they are thrown by the runtime system.

In Oak 0.2, all exceptions were unchecked, meaning that no throws clause existed. My guess is that checked exceptions were added only after the whole exception hierarchy was already set in wet concrete. I would have preferred a separate branch for checked exceptions, something like:

public class Throwable { } /** Serious errors in the virtual machine */ public class Error extends Throwable { } public class CheckedException extends Throwable { } public class IOException extends CheckedException { } public class UncheckedException extends Throwable { } public class NullPointerException extends UncheckedException { }

This way you would avoid catching unchecked exceptions when you catch CheckedException. However, the exception class hierarchy appears to have been developed before the idea of checked vs. unchecked exceptions, so we are stuck with an exception mechanism that will cause headaches for generations to come.

Asynchronous Exceptions (Section 9.4.2)
If your program gets an asynchronous exception, you are dead. A few weeks ago I was looking at a program that was throwing OutOfMemoryError. This hiccup can happen at any time really, which is why it is called an asynchronous exception. Another scenario in which this can happen is with Thread.stop(). As you can imagine, this is inherently dangerous (which is why it is deprecated).

In Oak, life was even more precarious. You could cause an asynchronous exception in another thread using Thread's postException() method. Now that was dangerous! Imagine if other threads could cause asynchronous exceptions at any place in your code!

In order to safeguard your code, you could "protect" it. If you wanted to indicate that you had some critical code, which could not handle asynchronous exceptions, you did the following:

protect { /* critical section goes here */ }

And code that was quite happy with asynchronous exceptions did the following:

unprotect { /* code that can afford asynchronous exceptions */ }

A note in the margin said that the default would probably be changed to not allow asynchronous exceptions except in explicitly unprotected sections of code. I'm very glad that this feature was tossed. I cannot imagine how complex the Java programs would have become with it in place.

The End
That's it. The rest of the manual was filled with a Glossary and an Index, which pushed the final page count to 38 pages—probably to satisfy some manager who wanted a manual that wouldn't blow away in the wind when he showed it to the marketing guys on the golf course.

Even though this manual was written way back in 1994, it provided for fascinating reading, even late at night.

Editor's Note: This article first appeared in Dr. Kabutz's The Java(tm) Specialists' Newsletter under the title Once upon an Oak .... To subscribe, send an email to subscribe@javaspecialists.co.za.

Dr. Heinz Kabutz owns Maximum Solutions, a Cape Town-based consulting firm that specializes in Java technology. He spends the majority of his time programming Java OO applications and also advises companies that wish to embrace Java as a technology. He has been a lead programmer in one of the first big Java developments in South Africa, now consisting of almost 600,000 lines of Java code. He has been programming in Java since 1997. He can be reached at heinz@javaspecialists.co.za.
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