Posts

Showing posts from October, 2008

Managing Source and Class Files

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

Using Package Members

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

How to Make a Java Package

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

Package Theory

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 "

Generics

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