Java Beyond Classes

It can often be heard that everything in Java is a class, and that using such a universal framework is a great advantage of Java before the other programming languages. This common prejudice lies at least twice: first, not all Java is classes, and second, reducing everything to classes is no advantage at all.

Every programming language is designed to represent a range of typical operations involving physical interaction of numerous electric circuits inside the computer (or several computers, in a distributed system), which result in a change of the computer's logical state. It is these objective states of the computer (or a computer network) that are of interest for the user, and not the way they are physically implemented or encoded in the programming language. Java class is one of the possible models of a logical state of computer, so that every such state is considered to represent a specific class, to instantiate it. Object properties defined for the class are the properties of a particular instantiation. Methods of the class also apply to its instantiation, representing various processes that can be initiated on an instance of the class.

However, properties and methods of Java classes are not classes themselves (though they can be instances of some classes), and they do not apply to classes. The introduction of such classes as java.lang.Class, java.lang.reflect.Method or java.lang.reflect.Member is no more that mere metaphorical description of the basic Java constructs. They cannot be used to create and develop classes, to dynamically produce Java from inside Java. Most classes in the java.lang.* package are, in fact, fake classes, they are essentially static and can as well be replaced by reserved words, similar to "if", "for", or "switch". This would closer reflect their true role in Java, as well as relieve the programmer from silly repetion of unnecessary prefixes (like Math.) for static functions and constants, and of unjustified separation of "primitive types" and java.lang classes. What is built in cannot be a class.

Yet another example of a non-class object in Java is Java Virtual Machine, the interpreter of Java code. JVM implementation significantly influences the range of classes available, and the outcome of any operation. Each Java code instantiates a specific JVM, and it may be not runnable on another JVM. In a universal JVM, code interpretation would depend on the explicit attribution to a particular Java version, and particular JVM type. This is somewhat like modern Intel processors emulating the operation sets of all the older processors, down to 8086.

Well, one could try to "improve" Java and make everything a class, including classes themselves. Personally, I doubt that this can be achieved, since any such attempt is bound to get stuck in the old "liar paradox" of classical logic. Probably, this could be a useful experience, and a way to many interesting discoveries, but in a field other than applied programming. A programmer needs a language that can express anything within a specific application area with minimum effort. Of two programming languages that ensure the same functionality, that which is more compact and logically transparent will be preferred. Object oriented programming appeared in response to such a demand, promising to reduce the computation process to a simple sequence of intuitively understandable operations.

However, as usual, too much good is no good. Trying to construct classes for every purpose leads to cumbrous and inefficient programming, where any change requires a delicate work of adjusting the interaction of numerous classes, rather than a simple replacement of a piece of code. The existence of various tools for managing classes and structural optimization, does not help much in really difficult cases.

For any method, or approach, its merits become its faults if used wherever needed or not. Exaggerated consistency means inadequacy. Certainly, one could use a code set of only two characters for the English language, but will that make it more readable? Most human readers would prefer the traditional Roman alphabet. Moreover, in writing, many people stick to their favorite shortcuts instead of spelling frequent words in full; this effectively extends the alphabet. Such compound characters do not much differ from Chinese or Japanese ideograms, since the latter are as well composed of simpler components, though not necessarily phonemic. Obviously, the usage of shortcuts/ideograms can become inefficient when there are too many of them, and search for a proper character takes more time than phonemic spelling. For each application, there must be an optimal alphabet for efficient coding. The length of this alphabet depends on the parameters of the activities to be described: for rigid activities, with a fixed operation set, the alphabet tends to expand until it includes characters for each possible operation, while fast development suggests a relatively compact universal character set.

Similarly, in programming, there is no need to stick to a single design system, or a single approach. Using a preferred development environment is like programming always in machine codes, neglecting the existence of high-level languages. This ideology is gaining strength in data management (at least on the level of basic XML), while, in programming, there is still an obsession of finding the only "true" way to efficient design.