I have been working with Java since the mid nineties, and in that time, Java has gone from being a “fad”, the next “big thing”, etc, to becoming a widely accepted and deployed programming language in the business world. Being involved with Java for a long time has its share of ups and downs. On the plus side, you know and understand the very basic foundations of the language and its evolution, on the negative side you sometimes talk about stuff no one else has a clue about. So many people have given me a strange look whenever I have mentioned any one of the four items in the title that I have decided to write a blog post about it just so that I can declare “go read it up on my blog” :).
Oak
Oak is the name that Java was known by internally at Sun before a committee of lawyers gave their approval for it to be called Java. The other potential names were “Silk” and “Lyric”. From Jonathan’s blog that gives an account of James Gosling “…So, who named Java? Marketing organized the meeting, the consultant ran it, and a whole pile of us did a lot of yelling out of random words. I’m honestly not real sure who said “Java” first, but I’m pretty sure it was Mark Opperman.” So what about Oak ? Where did this come from?
Java was created by a secret “Green team” put together at Sun microsystems to prepare for the next big thing in computing. James Gosling one of the key members, basically named it after an Oak tree in front of his office. Short answer – Oak is the precursor of Java.
0xCAFEBABE
The first four bytes of every Java class file are specified to be 0xCAFEBABE, a magic number that can help tools quickly differentiate likely class files from non class files. It is surprising how few people, even people who have been working on Java for a long time actually know of this. To check this out, open any .class file generated by the Java Compiler in a binary mode HEX editor, the first four bytes are CA FE BA BE . Sometimes, when I am in the (inevitable) position of interviewing a job applicant with deep knowledge of Java, I toss this question out casually. To my disappointment, not one single person out of the dozen or so “senior Java people” that I have asked it to has been able to give me the right answer – (not that this matters, being ignorant of trivia about Java is not a show stopper by any means).
There was much speculation about the origin of word when it was initially introduced. Take a look at this[artima.com] discussion for instance. The strange thing is that, it seems to have been decided even before the name “Java” was officially chosen to represent the language. There is also some discussion about Kim Polese and how she might have been the origin of the “babe” term for the original Java team.
The answer as provided by James Gosling himself here “We used to go to lunch at a place called St Michael’s Alley. According to local legend, in the deep dark past, the Grateful Dead used to perform there …<snip>, we referred to the place as Cafe Dead. Somewhere along the line it was noticed that this was a HEX number. I was re-vamping some file format code and needed a couple of magic numbers: one for the persistent object file, and one for classes. I used CAFEDEAD for the object file format, and in grepping for 4 character hex words that fit after “CAFE” (it seemed to be a good theme) I hit on BABE and decided to use it. At that time, it didn’t seem terribly important or destined to go anywhere but the trash-can of history. So CAFEBABE became the class file format, and CAFEDEAD was the persistent object format. But the persistent object facility went away, and along with it went the use of CAFEDEAD – it was eventually replaced by RMI.”
Green Threads
Green threads, the threads provided by the JVM, run at the user level, meaning that the JVM creates and schedules the threads itself. Therefore, the operating system kernel doesn’t create or schedule them. Instead, the underlying OS sees the JVM only as one thread. The latest JVMs all use native threads and not green threads but when Java was very young (JDK 1.1), only green threads were supported.
The reason for this has to do with the original intent of Java’s creators – that it should be an OS that would run “set-top-boxes” for television. These were to be simple low-computing-power devices and hence Java used to abstract out all the thread creation into the user space rather than at the OS space.
Unfortunately as Java become popular in the enterprise, green threads proved inefficient for a number of reasons. Foremost, green threads could not take advantage of a multiprocessor system. Since the JVM runs from within one thread, the threads that the JVM created are not threads at the OS level. Instead, the JVM splits its timeslice among the various threads that it spawns internally. Thus, the JVM threads are bound to run within that single JVM thread that runs inside a single processor. In contrast, native threads were created and scheduled by the underlying operating system. Rather than creating and scheduling threads itself, the JVM created the threads by calling OS-level APIs. As a result, the native threading model can benefit from multiple processors. Performance can improve because an IO-blocked thread will no longer block the entire JVM. The block will only block the thread waiting for the IO resource.
However Green threads (or their equivalents) are still in use in some languages – Smalltalk and Ruby (as of 1.9) for instance. One benefit of using them is that the underlying OS does not have to support a threading implementation. They are also much lighter weight and faster to start.
I actually remember having to debug a Java program that was calling some multi-threaded C++ routine wrapped by JNI calls using a different Java version and encountering a hard-to-reproduce problem. After some very late nights spent going round in circles, I eventually figured out that the root of the problem was one version of Java was using green threads while the other was not.
RuntimeException
Perhaps the most hotly debated aspect of Java when it was initially released was its Exception handling mechanism. Java has what are called as “checked exceptions” and “unchecked exceptions” – checked exceptions need to be declared as a part of the method signature (or caught). This results in fewer unpleasant surprises at run time but causes syntactic clutter and implementation leaks to seep into Interfaces. The class “RuntimeException” in the Java API and its children are examples of unchecked exceptions. Now comes the subtle and interesting part.
What is the meaning of the name “RuntimeException” ? Why is the class so named? Think about this for a minute.
Whenever I ask this question of a Java professional, the inevitable answer I get is “It is so named because these are exceptions thrown at runtime”. However ALL exceptions are thrown at runtime right? The real answer is so much simpler.
Recall that Java has a class called as the “Runtime” class – an abstracted representation of the underlying Java Virtual Machine that allows us to add hooks and get information. So the simple answer to “What is the meaning of the name RuntimeException” is
“It is an exception thrown by the Runtime itself” rather than any particular piece of code.
Suprgeek's Blog 