Javastates ( offers constructs that implement the widely used state chart semantics.

  • states can be embedded so as to form composite states
  • sub regions within one state allow for the concurrency

Javastates extends state charts by allowing to bind resource triples (object - resource - value) to states.

  • the triples (also called requirements) are inherited by sub states
  • requirements can be overridden in sub states

Javastates offers an api for transitions. Changing state occurs by calling the function setState.

  • regions are namespaces : state names are unique within a region, but may collide accross regions. This protects applications from newly introduced modules.
  • the root state of a region has a default name of "root".

Javastates offers no support for events. Applications offer many different ways of triggering events (the most basic being the call of a function). In Java Swing, there is a rich collection of Listeners of various kinds for many event types.

  • Event handlers in GUI apis like Java Swing are dealt with by setting callbacks, that occur as specific kinds of resources
  • Javastates lets the user decide for his events by setting event related resources
  • being resources, callbacks are inherited and can be overloaded in sub states
  • Javastates hence cannot compare with QuatumLeap's statechart implementation Qp ( ), that interfaces low level kernel, device and driver events

Javastates is very flexible

  • states can be introduced dynamically
  • regions can be added dynamically (hence it is not required as in Qt for instance ( ) to declare concurrent states.
  • dynamically adding regions is useful when dealing with multiple document interfaces. Each document may be bound with a single subregion of a given state.
  • requirements too can be added dynamically