Java for the Rising 5s
The language:
The implementation:
Plato's theory of forms suggests that what we experience with our senses are reflections of ideas, or forms, that are eternal. All the horses we see are just world are recogniseable, but imperfect, reflections of the form "horse", and the "horse" form is a pre-requisite for any "horse" existing.
On the other hand, Aristotle said that we only come up with classification such as "horse" after we have seen many horses, and have decided what the common features between horses are.
OO programming uses Aristotlean philosophy in the design stage, but becomes platonic at run time.
OO design:
It can be very difficult to get this right first time, and often requires multiple iterations.
Java has OO designed in from the start, it is fundamental to the language, so you can't avoid using it when programming in Java. Here are some of the terms that Java uses to refer to OO concepts:
Java language has 9 "primitive" types, including "int", "float", "void" etc.. All other types are classes (over 2700 public classes in JDK1.4).
Defining a class in Java requires you to provide:
Object is the root class and so all other classes are ultimately derived from it.
A simple example of polymorphism is that the Object class has a "toString()" method which returns a String describing the object. Typically when you define a class you override this function. For example, the Cat class might return the cat's name. Any code which calls "toString" on your object automatically gets the result from your class-specific function.
Java designed to provide resilience by default. Compile-time errors easily caught.
Strategy for handling run-time errors: exceptions. Conventionally errors handled by return codes, but this approach is flawed - users don't check return codes; how does an int function return an error, different standards of error return (see UNIX API).
Various environments do offer exception handling, but this is often tied to underlying OS, so not easy to do in a generic way, e.g. VAX calling standard, UNIX signals. Java language isn't concerned with underlying OS.
C++ has exception facility built into language but wasn't there initially, and they're not able to make it as robust as Java partly because that would break existing code.
Define exception: "I take exception to that" - generated when a problem occurs that you don't know how to deal with. Instead, you give up control to a higher context (e.g. the routine that called you). If that context doesn't know, it will hand it back to someone else, and so on. Like LIB$SIGNAL.
Coding LIB$ESTABLISH or sigaction() can be fiddly. Java syntax (which looks like C++) is very straightforward, e.g.
try {
doSomething();
}
catch (Exception e) {
// deal with error
}
// carry on
Unlike C++, Java knows what kind of exceptions may be thrown by operations. The compiler therefore requires that you either bracket such operations with an appropriate try..catch, or declare the exception in your own heading, e.g.
void doSomething() throws SomeException
Exception is a Java class. So it has a "toString()" method which typically returns the exception name. A RuntimeException is a subclass of Exception which itself has subclasses including ArithmeticException, NullPointerException. Java treats these differently: you don't have to catch RuntimeExceptions, because:
You can define your own Exception (or RuntimeException) subclasses and put any functionality into them you want. Typically they'll just contain info about what went wrong, and methods to extract that info. The Exception class has "getMessage()" and "printStackTrace()".
A very large part of JFC is devoted to Swing, which is the GUI library for Java programs.
The original Java GUI implementation was called AWT (abstract window toolkit). AWT functionality is built into the JVM - being platform specific, it "knows" how to get the platform to display buttons, text, windows, etc.. However, although this had the advantage of producing a UI that had the flavour of the underlying platform, it meant that AWT had to represent the lowest common denominator of all platforms.
Sun did produce AWT 1.1, but that was followed by Swing, which is written in 100% Java but uses the underlying AWT to communicate with the screen. When you ask AWT to create a button, it will call the platform "button" function. When you ask Swing to create a button, it tells AWT what lines and pixels to draw.
Because Swing is completely written in Java:
A GUI library is very amenable to being modelled in OO way. E.g. (made up):
DrawableObject->Rectangle->Window->Button->RadioButton
Motif API and the Win32 API both have very OO "feel" to them although they are implemented in non OO languages. MFC puts an OO interface to Win32 which shares many concepts with Swing. (notice that MFC also provides a CObject class which is the root of all MFC classes.)
Swing is written in Java and so it's a lot easier to implement as an OO design.
AWT supported a range of components which were common to a range of platforms. Swing supports many more, doesn't depend on platform support.
Swing provides "layout managers". Similar to Motif Forms. (don't know if Win32 has anything like this?)
Swing uses MVC model-view-controller. Should be familiar to anyone who's used MFC
In Swing (and most other MVC implementations), V&C are typically merged. E.g. the controller for turning on/off a light is probably the same check box which is showing the state of the light. So documents tend to refer to "MVC", but easier to think of as "MV".
while a view is typically attached to a model, a model doesn't need to know about a view. Multiple views can be attached to the same model. E.g. two edit windows open on the same file
The same model can be represented by different types of view e.g. tree/list pane in smithers
The design of the model can be independent of the design of the view(s)
Model can be changed, or subclassed, and view will still work. E.g. Swing has JList component which is the view of a list. JFC provides a class which is a ListModel but you are free to create your own : so long as you are a ListModel, a JList can be attached to you.
One big Problem with Swing is that it's very complex and intimidating. E.g.JList class has about 70 methods of its own, and inherits over 100 from ancestor classes. Models are usually easier - minimal ListModel has only 4 methods.
But, in contrast to MFC, the design means that once you've been using Swing for a while it's fairly easy to guess what function you should be looking for. "javadoc" comes into its own here.