Thinking in Java

After having read the first 100 pages of 'Java in easy steps', the steps got more and more difficult. Apparently, there are just 50 odd easy steps in Java. Lucky for me, my new book arrived: 'Java, the good parts'.
But that book seemed to be written for a rather specific audience. If you haven't been a professional baseball player with 15 years hands-on experience of Java, do not even consider buying this book.

For some reason my luck was not running out this week. Some weeks ago I ordered a used copy of 'Thinking in Java' by Bruce Eckel and it arrived the other day. 1200 pages of text scared me off at first. But after having read a few pages things started to look brighter. Yes, this is a heavy book (in weight).
Still, the information Bruce is relaying to me is dense enough to keep awake. Which could not be said from the Head First book(s). There's also no rivalry with other languages. Bruce does a great job explaining about Java. And on his website http://www.mindviewinc.com/Books/downloads.html you can find the full book in HTML format and full sourcecode of the examples. OK, I bought mine, but if I would have printed it, it would have been more expensive.

This webpage is about the things I tried and learned while reading this book.

HelloDate.java

On page 123 the first real java example starts. It's a hello-world-ish style program. With a twist. Here's the source:

// HelloDate.java

// import java.util.*;

public class HelloDate {
   public static void main (String args []) {
      System.out.println ("Hello it's now ");
      System.out.println (new java.util.Date () );
   }
}
   

jan@Beryllium:~/develop/java$ javac HelloDate.java
jan@Beryllium:~/develop/java$ java HelloDate
Hello it's now
Sun Jun 13 01:58:43 CEST 2010
jan@Beryllium:~/develop/java$
   

Progress

I've covered 220 pages now in this book. In a matter of days. The reading tempo is comparable with that in the Head First book. With the differnece that now I'm gaining knowledge. This book contains facts, explains things, makes comparisons and seems to 'talk' to me. It's as if you listen to a lecture of a professional.

Similarities with Modula-2

Java is an OOP language. Modula-2 is a systems programming language. That makes the tow distinct. Still, Sun (the inventor of Java) were internally working on and using a Modula-2+ compiler. And I see similarities between Modula-2 and Java. Of course, Java had to maintain most similarities with C++, Smaltalk and other OOP languages. Yet it added structure that were features of Modula-2 (and also Oberon features). The features were not copied. They were interpreted and Java versions were developed. Some of these are:

• Garbage collector (Oberon)
• Import statement (Modula-2)
• Qualified imports (Modula-2)
• Array bounds checks in runtime (Modula-2)

Doubts again

I reached Chapter 5: code re-usal. For a Modula-2 programmer this ought to be the feast of recognition. In Modula-2 I make groups of procedures that share a common goal and put them in one (implementation) module. When done, I make a second (definition) module (with the file extension .def) in which the public data and procedures aree listed. The implementation module stays hidden; the client programmer just has access to the definition module. How I did things is not important. I had hoped that things were similar in Java.

But that hope was in vain. Java definitely wants to be as close to C and C++ as possible. Java makes some diversions but for code re-usal they lean towards the curly braces languages. That's a pity. The mechanism of code re-usal libraries is so complex, with private, public, friendly and protected members. Some of them cn also be static. It's important WHERE the libraries are. In the CLASSPATH? In the current directory?

Add to this the ambiguities for imports. A statement like 'import java.util.*' may be powerful but it is also dangerous. God knows whats inside the java utillities. And all of it is immediately imported. I would have appreciated the Modula-2 approach. Either a generic import of a library, followed by continuous qualified imports for every used keyword. Or a long import list in which specific parts of a library are imported.

Another thing that is bothering me right now is the fact that I reached page 300 of a 1200 page manual. And we haven't even touched the nitty gritty parts. How about the Wirth books for Modula-2 and Oberon? These were less than 50 pages describing the full language in detail. Oberon is an OOP language as well. So how come a superb writer needs 1200 pages to describe a language?
It looks like Java is to wea to be described in few pages. Instead it needs huge books (an many of them) to describe all the topics and the exceptions (on the exceptions) that are part of the language. I have a minor experience with building a compiler (see the M4M section) and I know how hard it was to build one for a simple and structured language like Plov. A language like Java, that deals with facts, keywords and with 'feelings' must have been a monster to create. Let alone to maintain. So many options for each aspect. Things that can be done multiple ways. Every line must be scanned left/right/left and perhaps multiple times. Java tries to be a simple language. It isn't....

This page http://www.encyclopedia4u.com/o/oberon-programming-language.html sums it all up, better than I ever could do. As things look now, I am considering ditching Java (now final) in favor of Oberon-2 that compiles to either C or Java Bytecode.

Page created on 13 June 2010 and

Page equipped with FroogleBuster technology