Posts

Showing posts from 2008

Learning Swing with the NetBeans IDE

This is where the tutorial begins to get interesting, and for me it was the launch pad to my own first Java applet. I even like the form of the example. It not only contains the essential components of a GUI, but also a tiny bit of mathematics, and it performs a calculation which many of us perform in our head from time to time (if we come from an Anglo-Saxon culture with continental European influences). The lesson Setting up the Celsius Converter Project is important to read very slowly. Stuff this up and you stuff up your whole project. I think there might be a mistake in it. Certainly I made a mistake on my first run through, and it did stuff me right up. In Step 1: Create a New Project, the instructions are just fine. Step 2 is fine. Step 3 is also fine in so far as it goes. Obviously if you are using the lesson as a guide for your own custom project you will choose a name which suits you, but that is not the main issue. The main issue here is that nothi

Getting Started with Swing

Getting Started with Swing is the first lesson in the so-called Swing Tutorial . The lesson has two parts: About the JFC and Swing and Compiling and Running Swing Programs . The first is as dull as it sounds, albeit of theoretical importance. It is essentially a reminder of the transparency of Java - a reminder that the power of Java lies in the huge collection of classes, already written by someone else, but made available for everyone. So while you can use a development environment like NetBeans, you can also access the functionality of the classes with hand written code. This is important. If you want to program in VB (to create a Windows app) but you don't like the development environment, you are pretty well buggered. But if you want to create a GUI with Java, and you don't like NetBeans, you can either use another development environment, or you can do the whole thing with a text editor, provided you follow the rules very carefully. The second par

Swing

Since my last post I have been musing on the question of where to go next. Should I plough through more turgid lessons on the language or should I have some fun with the Swing thread. After some deliberation I have decided to go with A Brief Introduction to Swing . The first branch of this trail is a philosophical piece entitled What is Swing? It is best to ignore this as the tutorial tends to get muddled when it tries to be philosophical. The second branch, A Swing Demo , is much more fun. It talks you through a real applet, and it inspires enthusiasm because it is so neat, and it works so well. The Swing Features trail is pretty much a reference document with illustrations of what VB would call GUI objects, but which here are called Swing components. There is in my opinion rather too much space devotes to the so called "Look and Feel", and then there are the usual sections on internationalisation and accessibility, which in a politically correct world

Setting Path as an Environment Variable

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

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

Numbers and Strings

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

Interfaces and Inheritance

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

Nested Classes

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 .

More than a beginner might need on classes

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

Classes and Objects

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

Constructors revisited

"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

Declaring Classes and Defining Methods

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

The Constructor

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

Java Language Basics

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

Inheritance, Interfaces and Packages

Image
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

Object-Oriented Programming Concepts

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

Hello World

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

Where to start?

Image
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