The BISS java framework is a framework of about 150 Java classes for building graphical applications with state-of-the-art user interfaces. Instead of following the OS-native look-and-feel (like java.awt), it implements its own Java-native look-and-feel. The framework can be extended without the need to write native libraries and uses a more powerful mechanism for event processing than the standard, low-level approach of the JDK 1.0.x.
It also forms a suitable base to implement a stand-alone Java AWT because it requires much less support by native libraries. This is due to the fact that BISS AWT just uses the generic components of java.awt (like Graphics, Frame, Canvas and Panel) and rebuilds all high level widgets (like Lists, TextAreas etc.) on top of this. To prove this, BISS AWT comes with a native library build for the publicly available kaffevirtual machine.
The structure of BISS AWT even makes it possible to use it as a replacement for the non-generic, high-level java.awt.peer classes (ListPeer etc.). It therefor also is a good platform for ``clean-room'' java.awt compliant AWT implementations.
By October 1995, we began to look for a programming platform that should enable us to port our large C++ framework for OS/2 (called BSA) to Unix and Windows. The BSA, which currently consists of about 500+ classes, covers all aspects of OS/2 application programming, but definitely has its strengths in creating large-scale applications with sophisticated user-interfaces (beyond usual presentation manager capabilities). It is mainly used by some European insurance companies and also contains powerful tools to ease source programming (called CThrough) and to graphically specify static and dynamic behavior of apps without the need to program sources at all (called the ObjectDesigner).
After some validation tests, we decided to go with Java by end of 1995. We did this mainly because of the inherent technical strengths of Java as an application programming system. But by then, less was known about how the available Java implementations behaved outside of small, Web centric applets.
Soon after, we realized that the standard java.awt implementation from the Sun JDK could not be used for our purposes because of several reasons:
Most of this was caused by the JDK implementation of java.awt, which provides a platform native look-and-feel and therefor heavily utilizes native libraries. These libraries in turn require a large support infrastructure of peer classes and are the single most important source of problems for bug fixing as well as porting Java to other platforms.
We found Randy Chapmans Linux port working in most cases, but it was crucial for us to proof Javas capabilities on at least Linux, OS/2, NT and Windows 95.
Therefor, by February of 1996 we started to write replacements of the existing java.awt widgets. These replacements were not meant to be a complete substitute of the java.awt, they were designed so that they could live in coexistence. But from the beginning it was clear that all of this work had to be done solely in Java (because of portability and extendability).
Besides deriving all classes from the generic parts of the standard java.awt (Canvas, Panel etc.), we also decided to use a more powerful mechanism to connect widgets to non-visible parts of the application (AKA models). Rather than using a non Java-native approach like methodRefs, we have chosen the standard Observer/Observable pattern. It is more powerful than the chained handleEvent() mechanism and (in a slightly more generalized form) is not constrained to a single class-subtree.
A useful side effect of this design is the fact that widget implementations use the same type domain like the rest of the Java app (e.g. Text widgets work on common Java String objects rather than on C-string buffers, Lists work with Vectors containing arbitrary objects instead of using separate, platform specific representations of string lists).
The first real test case for this framework was a package called biss.jde which implements a source programming toolset that will be expanded to the size of the CThrough system.
By middle of 1996, with the release of JDK 1.0.2, Sun started to tighten their license policy (at least they seemed to do so). As a logical consequence, many people began to think about free Java implementations. At this time, there already was a usable, yet not matured, free virtual machine available called kaffe (built by Tim Wilkinson). But there was no java.awt. Clause Lecommandeur soon after started his sawt project. Its goals are to create an X-based native library / peer layer without Motif (the toolkit used by the JDK). Otherwise it follows the same design patterns, and that means there is a lot of work to do because it basically has to implement its own toolkit to build widgets like TextAreas, Lists etc. It is targeted just on the X environment.
At first, it was just a silly idea. But then we began to realize that it was feasible to use the existing biss.awt class hierarchy to implement the java.awt.peer interfaces for the non-generic widgets like Lists, TextAreas, TextFields, Buttons etc. This opened up some great opportunities:
By August 1996, we started to talk about these opportunities with some of the main Linux-Java contributors, namely Randy Chapman, Karl Asha and Miguel de Icaza. We got very encouraging responses, which convinced me to try to make BISS AWT the GUI base for the upcoming Free Java (Jolt).
Even with the attitude to make BISS AWT a platform for free Java programming, there was the question of how compatible to be with respect to the standard JDK, i.e. if we should build something that was able to run unmodified Java code written for the plain JDK. Given the fact that BISS AWT can perfectly run on top of the standard JDK (is downward compatible), I was somewhat reluctant to spend too much effort on this. Now that we have two, more or less compatible/coexisting, standard JDK event handling mechanisms (JDK 1.1 and 1.0.2), my second thoughts seem to be justified. However, after some discussions, we decided to modify the biss.awt so that it could get a platform for java.awt implementations. To prove its suitability, we also started to implement a native layer based upon the kaffe VM and Xlib.
Given the history above, it is easy to deduce the list of goals BISS AWT should meet. They are (with decreasing importance):
The bottom line is: BISS AWT is not meant to be a global replacement of the standard java.awt, nor is it primarily a public java.awt implementation. Its main purpose is to give Java developers, who are challenged to build complex GUI applications, a library / toolset combination with a high degree of freedom and independence (with respect to Java platforms, operating systems and even shrink wrapped systems). And we are dedicated to extend this up to a complete, stand-alone AWT implementation. To say it with other words: we want autarky, and we want it in the most portable way.
This goal is motivated by a vision. Given the excellent runtime modularization and robustness of Java, it should be feasible to use it as some kind of a high-level shell on top of various operating systems. Classes would act as modules, main() methods would be the external commands of these modules. It would be some kind of a programming system positioned between Tcl and Oberon. It would be both portable and coexisting with other applications. It would be a dream becoming true.