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 "type" is central to the definition of package: "A package is a grouping of related types ... ". And as an afterthought to the afterthought, a sort of apology for a definition is appended: "Note that types refers to classes, interfaces, enumerations, and annotation types." It's a pity the author doesn't know how to conjugate verbs, and its odd that the definition seems to be recursive, but it's better than nothing, and the author could, with grace, have stopped there. But perhaps a sixth sense told him (or her) that what had been written so far was grammatical and logical gibberish, so he (or she) fumbled on, still in the insert intended for a short crunchy definition, but now on the tangential path of a long and rambling essay: "Enumerations and annotation types are special kinds of classes and interfaces, respectively, so types are often referred to in this lesson simply as classes and interfaces".

Why not say that in the first place? Why not open the lesson with a simple definition, such as: a package is a group of related classes and interfaces? That would be too simple I suppose; not highfalutin enough.

The gibberish continues: "The types that are part of the Java platform are members of various packages that bundle classes by function: fundamental classes are in java.lang, classes for reading and writing (input and output) are in java.io, and so on. You can put your types in packages too." Well thank you very much. But besides making our code files look pretty, why should we want to?

The text continues with the silliest example imaginable. The world is awash with graphics software, and has been for twenty years or more. This may be new and exciting for the boffins at Sun, who never properly weaned themselves from the command line, but why would anyone in the real world want to write code for creating plane geometrical graphics. And none of the reasons for bundling these files into a package struck me as particularly compelling.