- 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 ( http://www.state-machine.com/ ), 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 (http://qt.nokia.com/doc/4.6/statemachine-api.html ) 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