period, during which time Sun will accept public comments on the specification and possibly rerelease modified versions of the draft as it incorporates worthwhile comments.
PersonalJava's targets are personal consumer devices that make heavy use of communications. The specification suggests set-top boxes and intelligent telephones as potential candidate applications. Of necessity then, an implementation of the PersonalJava API will occupy a smaller footprint than an implementation of the full Java Development Kit (JDK) 1.1. (JavaSoft estimates that the PersonalJava virtual machine and supporting class libraries will fit in 2 MB of ROM and approximately 1 to 2 MB of RAM.)
The PersonalJava API is sort of a subset of the full JDK 1.1 API. I say "sort of" because, though most of
the PersonalJava API is indeed a simple reduction of the JDK 1.1 API, you won't find some new elements of PersonalJava in JDK 1.1.
For example, PersonalJava defines new Timer and TimerSpec APIs, which let PersonalJava applications create objects that provide what amounts to a millisecond-resolution alarm clock. You can attach a kind of "interrupt handler" to a timer, in much the same way that you attach a listener object to an event source in the JDK 1.1's event handler.
In addition, PersonalJava extends the Abstract Windowing Toolkit (AWT) with new APIs for handling such things as display output double buffering and mouseless input. (Double-buffered systems provide an external buffer memory into which all the drawing is done. The updated display is shown on-screen by copying buffer memory to the actual screen's memory. This reduces unsightly side effects that can occur while the application and display hardware are battling for screen-memory access.)
Most interesting are the goals of the Pe
rsonalJava API. Specifically, that products "...based on PersonalJava should be usable by people with no computer experience." We'll see.