Learning Java

The Numbers and Strings trail is also pretty much a reference trail, but there is a catch, to catch out the unwary beginner. Some of the lessons need to be read very carefully, before you begin programming. In the languages I've used previously, a number is a number and a string is a string, and that's all you really need to know, besides how to convert one to the other. Not so in Java. Java is the language where all objects have to belong to classes, classes belong to superclasses, and superclasses belong to an object. So to expect a number simply to be a number and a string simply to be a string in Java would be naive. No, in Java, numbers belong to a number class (with subclasses for the number types), strings belong to a string class, and even formatting belongs to a formatting class. The implications for programming with numbers don't seem to be too great because "most of the time" you are allowed to use the "primitive types". So when you d...

The next trail is headed " Interfaces and Inheritance ". I have already suggested that real beginners can manage without this stuff, and I think they could safely skip this trail. I shall plough on, because my last project used a lot of code, and if I am starting again in a new language, I might as well familiarise myself with any techniques which might make my coding more efficient. Reading the blurb on Interfaces it seems these might be used in large collaborative projects, where different, possible competing entities write code, but they agree to operate within a common structure; and that's where the interface comes in. The vendors of programming software might also use them. Inheritance has already been explained quite well with the bicycle analogy, and these lessons just seem to flesh that out a bit further. Placing an object at the top of the superclass hierarchy seems typically contrary, but at the end of the day, if it works, who gives a shi...

The lesson on Nested Classes is another which could be skipped in its entirety by the beginner, without loss of continuity. And while the tutorial argues enthusiastically that: "There are several compelling reasons for using nested classes", I can't see myself using them for some time, if ever. I read the sample page with an open mind, prepared to be persuaded otherwise, but the example was so trivial, it did the opposite. I remain convinced that the home programmer can live without nested classes. And the Summary page wasn't really a summary, and could have been appended to the opening page , thereby reducing bloat in the table of contents. And if you ignore the questions and exercises, this concludes the trail on classes and objects .

In an earlier blog I suggested that this tutorial might sometimes offer forks, with career programmers following one path and real beginners following another. And the More on Classes lesson perhaps represents the point on the current trail when the two paths might part. With what we've been told already, an enthusiastic beginner could create classes and objects and write some useful code. For the sake of completeness, I'll continue on the trail, and perhaps make the occasional snide remark on the way. Lets begin with Returning a Value from a Method. If I entitled a lesson thus, I'd open it with a statement about returning values from methods. And if I wanted to open a lesson with the sentence: "A method returns to the code that invoked it when ... ", then I'd entitle the lesson something like "Code Execution Paths". Heading a lesson "Returning a Value" and then talking about paths through code is at best confusing. Metho...

There follow two lessons, which are straightforward and easy to follow, so there is no need to say much about them. The Passing Information lesson gives a nice illustration with code to compute monthly payments on a home loan. The rest of the lesson is fine, except that a paragraph on circles refers to another lesson without giving a hyper-link. It's not the end of the world, but it is annoying. I'll provide one . And the top page of the Objects group is nicely explained, with links to the code for the classes behind the objects it uses. This is thoughtful, and certainly aids understanding. Then it all falls apart with the lesson on Creating Objects . I'm not quite sure why we need this page. We've already seen objects created in the first lesson on classes , and we've seen them created in a different way in the second lesson on classes (with constructors). When I first read this lesson I wondered whether it was written deliberately to conf...

"A class contains constructors that are invoked to create objects from the class blueprint.", says the lesson entitled Providing Constructors . So where is the constructor in Hello World? Where is the constructor in the first bicycle ? For clarity, let's set out the code for the first bicycle (Version 1): class Bicycle { int cadence = 0; int speed = 0; int gear = 1; void changeCadence(int newValue) { cadence = newValue; } void changeGear(int newValue) { gear = newValue; } void speedUp(int increment) { speed = speed + increment; } void applyBrakes(int decrement) { speed = speed - decrement; } void printStates() { System.out.println("cadence:"+cadence+ " speed:"+speed+" gear:"+gear); } } and lets compare this with the bicycle with constructor (Version 2): public class Bicycle { // the...

The Declaring Classes page obliquely refers to Inheritance and Interfaces, but just as the previous page on this topic said very little on why you would use an Interface, and when you would use one instead of or as well as a superclass, this page also assumes you would know when and why you would use either or both constructs. To be fair there is a promise to talk about them later: "The lesson on interfaces and inheritance will explain how and why you would use the extends and implements keywords", but there are two things wrong with the promise. First there is no hyperlink, so the reader is left to scurry around looking for lessons "on interfaces and inheritance". Second, we have already lessons on interfaces and inheritance , which say very little about how and why when you would use one rather than the other. My general observation of these tutorials is that the language mechanics are better described than the more abstract ideas. This app...

This takes us to the third lesson in the language trail , Classes and Objects , and the first lesson is a closer look at classes . The lesson subtly introduces a new concept: That of a "constructor". This term appears neither in the closer look at hello world , nor in the first lesson on classes . But it is not formerly introduced, nor is it explained. We are just told that there is one of them in the bicycle class. Which fact is interesting in itself, because if there is one in the bicycle class, why wasn't it mentioned the last time the bicycle class was set out before us. It wasn't mentioned because it wasn't there. It wasn't there on the page, and nor was it in the sample class available on a hyperlink . Now I know these are all just illustrative examples, but I really think the learning process for the beginner would be made easier if the sample code for examples given a name, like bicycle, were kept consistent. As to what the const...

I was a bit down on the Concepts trail . Not so language basics . This one read just fine. I guess the nuts and bolts of all programming languages have to have aspects in common, because at the end of the day they all have to perform similar tasks. If I have a criticism it is not of what is there so much as what I feel is missing from the page on variables . When learning VB there are whole chapters on the life of variables, but these Java tutorials don't seem to mention the concept explicitly. I posted a question on the subject in the tutorial discussion forum , but I was not really happy with the replies. I'll set out the problem again here. Essentially I had used NetBeans to create what in VB is called a form but here seems to be called a JFrame. The Jframe had a button a text field and labels. I coded the button to put a string in one of the labels. So far so good. But I wanted the button to remember what it had done after the event code had finish...

As I ploughed on through the trail , I began to feel there might be merit in a Java Tutorial for ninnies, such as myself. Such a tutorial would include the sections Objects and Classes , and then it would stop for a breather, and perhaps provide simple (but not too simple) practical examples on how it all works. Perhaps later in this blog I might record how I applied the previous two lessons, but for now I'll plough on, because that's what I did when I first followed the trail . I thought the bicycle analogy worked really well to explain the concept of inheritance , but I couldn't help racking my brains and wondering when I would ever apply the knowledge myself. And after struggling to absorb the rul es on Objects and Classes, when I read the page on interfaces , I asked the questions: Why? What is this for? How does this help me to write good code? When would I or when should I use an interface? I'd wager that 90% of grass roots programmers, by which I p...

After the irritation of "Hello World!" is was a pleasure to start a thread with some substance. I liked the description of objects , and analogy between the state and behaviour of real world objects and the fields and methods of software objects. The diagram was a bit weird. At first I thought there were 3 methods and 3 fields with methods on the left and objects on the right. But I guess displaying an abstract idea with a diagram is always tricky, and if you asked a hundred illustrators to do this they'd come up with a hundred ideas. I might have drawn it differently, but it focussed my thoughts and was still an asset to the thread. I liked the bicycle analogy, especially when it was extended to the description of classes . But when the idea was converted to code, I found the methods disappointing. I guess because I like physics, in the apply brakes method, I was looking for something about forces, masses and coefficients of friction. I know it has to be kept s...

The next lesson is entitled " A Closer Look at the "Hello World!" Application ", and it opens with the phrase "Here again is its code". If I opened a lesson thus, I think I would quote the entire content of the source file. It is after all only 8 lines. But in the actual lesson, the non-comment section of the code is quoted, and guess what the lesson talks about first: comments. Perhaps it is a trivial point. Perhaps no one else has noticed. But for me, the non-java programmer, it caused me to stop, to read it twice, to work harder to understand what it all meant and where it all fitted in. I guess the rest of the lesson flows OK, but if I were feeling picky, and I am, I'd make two comments. The first is the Hello World is a really feeble tool to illustrate programming concepts. I grant that some of the important components are in there, but it's so dull, and it is not thorough.. A practical programmer want a method to do a little more th...

Editorial Note: This blog was written three years ago, since when Sun has been acquired by Oracle. Pretty much all of the links to the Java tutorial have therefore become wrong. I shall attempt to correct as many as possible, but if I miss any, please use the link given below to get to the main page, and navigate manually from there. The documentation that came with JDK6 led me to “The Java Tutorials” at: http://download.oracle.com/javase/tutorial/index.html Full of optimism I hit the link to the “ Getting Started ” trail. The first link in this trail is entitled “ The Java Technology Phenomenon ”, and without any hard feelings intended, I have to describe it as pretty boring. If I might generalise from a very small sample, I think a possible criticism of the whole tutorial is that it is written by some of the leading experts in the field – people who have been working for so long with this stuff that they have spinal reflexes for many tasks, which the new user m...