Getters and Setters

Main references:

1. Tom Swan, "Programmer's guide to the 1802", Hayden Book Company Inc., Hayden Park, New Yersey, 1989 (9th printing)
2. Patrick Niemeyer & Jonathan Knudsen, "Learning Java", O'Reilly & Associates, Inc. (2000)

It's interesting to compare the true content of these two books with each other. I think a real programmer will agree with me that Tom Swan's book is concise, readable and to-the-point. In contrast herewith, "Learning Java" is a bulky and messy writeup, full of irrelevant an irritating blatherings, in short: a bad specimen of commercialization in Information Technology. It will be shown in the sequel that very much the same is true for the culture which has grown around Java itself. It's not so much that I hate programming in this language. On the contrary: you can write quite decent programs in it. Current practice, though, seems to discourage using Java a great deal, rather than promoting the platform. This is mainly caused by what I am calling

The Cultivation of Inefficiency

This paragraph will be concerned with an common programming issue, namely: how to load a data-item from a memory location with (variable-)name B and store it into a memory location with (variable-)name A. Everybody who has done some BASIC programming in the old days, may be aware of a rather concise solution to this problem:
      A=B
Not so in modern times. In Java, to begin with, you have to define quite a number of things before you can make a real start. To begin with editing a file 'ff.java', which must contain a "class". They say that any variable 'a' or 'b' must belong to such a class. OK, let's do so. In the end, 'ff.java' has the following content:
class ff
{
  private byte a;
 
  public byte getA()
  {
    return this.a;
  }
  public void setA(byte a)
  {
    this.a = a;
  }
  private byte b;
 
  public byte getB()
  {
    return this.b;
  }
  public void setB(byte b)
  {
    this.b = b;
  }
}
In order to arrange now for the transfer of just one byte from B to A, one has to create yet another class and write something like this:
import java.io.*;

class HH
{
  public static void main(String[] args)
  {
    ff f = new ff();

    f.setB((byte)10);
    f.setA(f.getB());

    PrintWriter uit = new PrintWriter(System.out,true);
    uit.println(f.getA() + "=" + f.getB());
    uit.close();
  }
}
In good old BASIC, this would have been simply as follows:
    B=10
    A=B
    PRINT A,B
In order to make a fair comparison between Java, BASIC and Assembly Language (yes!), one has to learn here, quickly, a couple of 1802 machine instructions:
  4N : load via N, advance N   D <- M(R(N)) , R(N) <- R(N)+1
  5N : store via N             D -> M(R(N))
  8N : get Low Register N      D <- R(N).0
  9N : get High Register N     D <- R(N).1
  AN : put Low Register N      D -> R(N).0
  BN : put High Register N     D -> R(N).1
  F8 : load immediate          D <- M(R(P)) , R(P) <- R(P)+1
Now assume that we have two variables, called A and B, whose adresses have been compiled (by some high-level compiler), as follows:
         adress A = $3208
         adress B = $1926
Then, in 1802 machine language, we do the following:
  F8 32 B7 F8 08 A7  : R(7) contains adress of A (4)
  F8 19 B8 F8 26 A8  : R(8) contains adress of B (4)
  F8 10 58           : store 10 via D in B (2)
  48 57              : load contents of B and store in A (2)
If we make a reasonable count of the statements needed, then the result may be summarized in the following table:
  BASIC: B=10 : A=B  giving 2 statements
  1802 : 4 + 4 + 2 + 2
  Java : 11 in 'ff.java' + 4 in 'HH.java'
This makes BASIC the winner with 2 statements, 1802 machine language is second with 12 instructions (= statements in assembly language). Java is third with 15 high-level language statements. The situation is even worse, however, since the "low level" Java statements will, in turn, be translated into bytes, which are feeded into a "Java Virtual Machine". The JVM, in turn, translates the bytes into machine instructions which will perform a Load and a Store, for each of the statements:
    return this.a;
    this.a = a;
The point here is that a programmer is forced to costruct a second layer which does a "get" and a "set", built upon a primary layer which already does a "get" and a "set" !!
He is forced to do so, because the Java community has adopted the ridiculous idea that variables in a class are always "private" and can be accessed only by "public" methods. Here the notions "private" and "public" can only emerge in environments which are ruled by Administrative Personnel, as these people are overly preoccupied with their "safety" requirements. Essentially, nothing really happens to the content of variables in an administrative environment, except that data are moved back and forth, say from one database to another. Since there is hardly any number crunching involved with these operations, cosiderations of efficiency are seldom an issue. This explains why Java, with its obvious cultivation of "safety" though inefficient "getters" and "setters", nevertheless has gained a certain acceptance within these communities. (Apart from the fact that their programs, and books, seem quite impressive nowadays, as far as the volume is measured, at least ...)

Oh yeah .. , and talking about inefficiency, the Struts "framework" certainly is the Cultivation of Inefficiency par excellence ! This product has been developed originally by someone skilled in the Programming Business for less than five years at that time: Craig McClanahan. Sure, and we all can see that: Struts is a pig to learn and clumsy to use. Quite in concordance with the basic philosophy in Business Administration: how to make everything unnecessarily complicated. Business Administration is NO Rocket Science. How would come that systems of coupled non-linear inhomogeneous partial differential equations can be solved efficiently? But they - the bean counters - tell us that an interdisciplinary approach (sic!) is needed to generate a simple postcode item. No surprise, if you only take a look at the standard Struts directory structure. What would be simpler than to have everything in one map: say Postcode. But no! They put JSP files in the top directory: Postcode. Now look where they put the Java classes (i.e. the executable code):

Postcode\WEB-INF\classes\nl\tudelft\dto\postcode
Unbelievable, huh? No wonder that you also need files for "configuration" of that inefficiency. You will find them in WEB-INF. There exist quite a number of file types as well: jsp , xml , properties , tld , xml , class , java , jar . And they put these files in different directories, as if the suffix alone can not be trusted. You have to edit many of those files, and keep track of them, in all those different places, with all those different formats, in order to keep the "framework" consistent. I wish you good luck!