In order to make transition to the notations and terminology of language easier, we present the concepts from the preceding section in a more formal way. Speaking more formally, SystemJ introduces three types of high-level entities, and two types of objects used within those entities on which new SystemJ control flow statements operate. Those entities are:

1. Program or system. It is the top level entity through which SystemJ program sees its environment and vice versa. Within the declaration part of this entity program interface with the environment and channels through which clock domains will communicate is declared. Also, clock domains are also declared in the body of this entity. The SystemJ program will start by executing its body and starting clock domain execution in any order because clock domains are asynchronous.
2. Clock domain. Clock domain is the entity which groups all reactions that will execute synchronously. Clock domain itself is nothing but another reaction which may have children, grandchildren and so on, but is executed asynchronously with those reactions that are instantiated as clock domains.
3. Reaction. It is probably most important entity because within reaction all computation and communication with its surrounding is defined. Reaction uses sequential and concurrent statements to specify its operation and those statements are from both SystemJ and Java repertoire. Reactions execute synchronously and fully comply with perfect synchronous reactive execution paradigm. The difference between reactions and programs in imperative programming languages like Java and C/C++ is that reactions perform and use time. The time is in this case explicitly introduced through new SystemJ statements, although it does not have absolute explicit value. It is logical time expressed in ticks. When any of the time consuming statements is executed by a reaction, it consumes one tick of its time. It stops its own execution and waits until other synchronous reactions in the same clock domain consume their own tick. All other statements, being SystemJ or Java statements, are executed instantaneously from the point of view of logical time (lock-step execution).

SystemJ reactions use SystemJ flow control statements to operate on two types of SystemJ objects, which are used for communication and synchronization purposes:

1. Signals. Signal is an object that has special meaning. They are emitted by reactions and broadcasted to other reactions and the environment. Other reactions may use the signals to change the flow of their own computation. However, the life of signal validity is time limited. Once emitted, we say the signal is present only for one tick of time (in which it is emitted) and then it becomes absent. The third possible value is unresolved and we will leave the in-depth treatment of this topic to ‘The system Primer’. Signal as an object consists of two elements: the status and the value. Signal values are abstractions and can be any object of any Java type (primitive or user defined). Signal status is used to indicate whether signal is present, absent or undecided. The value of the signal is the current value assigned to the Java object associated with the signal. Obviously, signal can be very simple and have just its status. In that case we talk of pure signals, which are similar to usual signals used in digital electronics or description of hardware. As signals are used to exchange information with the environment, the environment itself has to be able to understand what to do with the signal emitted from a reaction and also be able to supply reactions with meaningful signals. Operations on signals are fully supported by SystemJ compilation technology.
2. Channels. Channels are the object used to provide communication between reactions in different clock domains. SystemJ allows using channels to transfer a message of any Java type from a sending to a receiving reaction. However, as reactions in different clock domains are executing at different clocks, in order to provide safe transfer of the messages, synchronization between these communicating reactions is required. The synchronization is implemented by using rendezvous mechanism (full handshaking) and is enforced by SystemJ compilation of SystemJ program. Thus, the system designer does not need to take care of any aspect of synchronization. The sending reaction is blocked until confirmation from the receiving reaction is received that the transfer was successful. This way channels become safe way of ensuring that information is transferred or will be informed why the transfer was unsuccessful. As channels are very abstract objects, the underlying mechanism of actual data exchange (e.g. via shared memory, operating systems sockets and communication protocol like TCP/IP or operating system IPC) is not visible to the programmer. SystemJ provides the ways to connect the channels with different actual data exchange mechanisms. While those which use shared memory in SystemJ programs that executes on single processor are automatically implemented, some of the others (like socket-based TCP/IP) are selectable options; the others can be added as needed for concrete target execution platforms.

The detials how the system designers use these objects through SystemJ statements can be found here or with more elaborate examples in the SystemJ Manual.