Encapsulation is one of the first things a neophyte learns about object oriented programming. Defined here as “the concept that an object should totally separate its interface from its implementation,” it is one of the three pillars of object oriented programming, inheritance and polymorphism being the other two. Encapsulation freshly imprinted in his mind, the neophyte is then assigned to write a Java program, with the minimum possible number of lines, which prints “Hello World.” A quick search on the Internet and he finds several examples he can use. For the sake of completeness, I provide another one here:
public class HelloWorld {
public static void main(String[] args) {
System.out.println("Hello World.");
}
}
The neophyte, possessing an inordinate curiosity, endeavors to actually understand this code. Knowing that methods always end with a set of parentheses, he is confused about the syntax of the particular line of code that does all the work. What is System? Doesn’t convention dictate that object names start with a small letter? Shouldn’t it be system? And what is out? It’s not a method because it lacks the mandatory parentheses. Ah, something finally familiar: println() is a method and “Hello World.” is its parameter. Feeling a bit ignorant, he sheepishly asks his instructor to elaborate.
The instructor explains, “Focus on the one important line, System.out.println(“Hello World.”). System is a special class that contains useful class fields and methods and can’t be instantiated. Further, out is a static PrintStream variable that is set by calling nullPrintStream(), which returns either null or throws a NullPointerException.”
Pressed by the student for more explanation, the flustered instructor invariably says, “That’s the beauty of encapsulation: you don’t have to know how it works, just that it works. We’ll get into it more later on, but for now, let’s move on to polymorphism.” 
Our neophyte, put off by the apparent complexity of Java, considers a different career path, but hearing a lot of buzz about Ruby, he decides to have a look-see. Imagine his pleasant surprise when he finds this snippet:
puts “Hello World.”
Wait, that’s not a snippet, that’s the whole code. Simple, clean, intuitive. He doesn’t give a whit whether or not the comparisons between Java and Ruby are fair or valid, he sees that he can accomplish the same result with less code. For him, Java’s weakness is its complexity; Ruby’s strength is its concise productivity. He’ll later learn Ruby’s limitations but well after he’s invested time to get his brain around it and adopted it as his language of choice.
How can Java answer this challenge? Comparisons break down here because Ruby is scripted and Java is compiled (at least to byte code). Java (arguably) needs all the public static void main business so it can’t simplify to Ruby’s extent, but life should be a little easier in the Java stack. In this case, incorporate encapsulation and provide a println() method on Object:
public class Object {
//
public void println(String s) {
System.out.println(s);
}
}
Now our neophyte’s Hello World program looks a little better:
public class HelloWorld {
public static void main(String[] args) {
println("Hello World.");
}
}
It’s not quite as clean as the Ruby version, but it demonstrates a not-so-subtle but profound idea: embrace the concepts of object oriented programming and encapsulate the language’s implementation. (Why is Object so sparce?)
Iterators are another example. Iterators are internal to a Ruby collection and the programmer merely provides the block of code executed by the collection’s method.
The neophyte’s next assignment: Create and print an array of strings. Here it is in Ruby:
name = %w[Last First MI]
name.each {|name| puts name}
Looping through the array is the responsibility of the each method. In Java, even with Tiger, it’s cumbersome (admittedly a relative term) because a for construct is still required:
List<String> list = new ArrayList<String>();
list.add("Last");
list.add("First");
list.add("MI");
for (String name:list) {
System.out.println(name);
}
It’s amazing that Java still necessitates typing the declaration (String name) even though the expression (list) is parameterized. The so-called “advantage” of Generics is that casting from Object to String is unnecessary in the code block.
The Java Empire has a huge code base and is not soon to crumble. But there are cracks in the foundation and the barbarians are at the gate. Unless (maybe regardless if) repairs are made, collapse is inevitable. Consider this: eventually, our neophyte becomes a journeyman or even a master. If he can convince his boss or client that his language of choice (be it Ruby or any other) is faster, sleeker, sexier than Java, which will be selected for that grand new project?
