Learning Java

Since 1995, when Microsoft replaced the old 16 bit Win3x with it's 32 bit operating systems, WinNT and Win9x onwards, Windows users have not really had to think about defining paths as environment variables, unless they have had the misfortune still to be running a 16 bit application from the command prompt. So when lessons in the Java Tutorial make references to setting path variables, I feel as if I have been time warped back 15 years. The subject of my last blog talks about setting the class path, and the "Hello World" for Windows lesson in the very first trail obliquely embeds instructions about path settings. And when I say oblique, I mean very oblique. First they set you up to hit an error. Then they provide a link to a troubleshooting page. And from there there is another link to instructions on writing a path to javac in the user environment settings. Considering the level of detail given on simpleton tasks, like saving a text file, or basic navigation ...

This lesson obliquely answers a question not answered in the earlier lesson on creating packages . Quoting from the lesson: "Many implementations of the Java platform rely on hierarchical file systems to manage source and class files, although The Java Language Specification does not require this". So in theory, it seems, you can put package members anywhere you like, but in practice it seems advisable to file them in an orderly way. If you use NetBeans, it will do the filing for you, with each project in a directory or folder and class files and source files in subdirectories or subfolders. If you program by hand, this lesson recommends that you put package members in a folder which corresponds to the package name. It also suggests that (like NetBeans) you put your source files and compiled files into separate subfolders. This all seems very reasonable and sensible, but I still can't fathom why the information was not put up front in the lesson on ...

This is an important lesson. Notwithstanding my comments on the linguistic style of the previous few lessons, java packages are central to the java model for sharing code. Microsoft uses what they call dynamic link libraries (dll's) to store code shared by many applications. When you, the ordinary programmer, create an application which uses an object defined in a dll, VB, or whatever other programming application is being used, makes a note of it, and when you distribute the application, that, and any other dll you have used, gets included in the cab files. In contrast with the Java model, your own code is stored (after compiling) in an executable, and is not readily usable by other programmers or applications. In the java model, it seems that even the most humble programmer, has the option of making the classes, which they create, usable by others. And because they have the option of doing so, they are encouraged to organise their work in the same manner which...

After a singularly unconvincing lesson on the theory behind packages, there follows one on how to make them. And the opening is not auspicious: "To create a package, you choose a name for the package ... ". Gosh I'd never have guessed that. Never having created a file before, or a folder, or zip file, I'd never have guessed that you have to "choose a name" for java packages. The level of these tutorials is not consistent. One minute they use undefined terms, and just assume you can work out what they mean. And the next go down to a level which can only be described as inane. Is it Sun, is it Java, or is it Americans who just can't express themselves in writing. It can't be Americans. I had my doctoral thesis proof read by an American whose English was impeccable. It must be mainstream programmers, who just aren't used to writing in English. The bottom line is that it makes the learning process long, slow and hard. After readin...

Here is a trail which should apply to everyone. Let us hope it is useful and easy to understand. Let us hope it is written in English. Let us hope in vain. Even the opening sentence of the opening lesson includes an undefined term. "To make types easier to find and use ... programmers bundle groups of related types into packages." From all the preceding lessons I hardly recollect the term type being used, let alone defined. A quick search through the lessons revealed one the more esoteric lessons: " Enum Types ", using the term in the same context, but again with no definition. It is just assumed that you can read the authors mind, or can work it out for yourself. This is a bad assumption in a tutorial. But then, as if as an afterthought, there has been inserted into the text a definition. Is it a definition of "type"? No; it is a definition of package, which is fair enough since that is the title of the thread. But the ...

When I read the trail on Generics the first time I fogged out. And when I read it a second time I fogged out again. For me, key phrases include: // Imagine this is one part of a large application // modified by one programmer. // ... and this is another, perhaps written // by a different programmer These phrases are a let out for me because I am a sole programmer working from home on a non-collaborative project. So the situation described with not apply. Another key phrase is: "In any nontrivial software project, bugs are simply a fact of life". This tells me the trail has something to do with error trapping. This in turn raises two questions in my mind. First, why is there nothing about error trapping or bug avoidance in the trail heading? Second, why is the first lesson which even mentions errors and bugs so incredibly esoteric? Why not have a basic lesson on bugs first, and then put the weird one in an appendix somew...

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...