JSH (Java SHell) is a shell written in Java which features advanced
parallel processing capabilities. The main driving components of JSH
are; ModuleManagement, LogManager, ConnectionManager, JSHProcesses, EventManager, and Terminal. All of these classes will be outlined later in this README. Note that
JSH was built to be a modular system, designed to operate as either a
low level CLI or a higher level GUI based system. It can be run on all
platforms that support Java, and either as superuser or as a standard
user. It needs no extra libraries by default, and is higly configurable
through the use of a built-in configuration system.

Abstract serialization takes objects at a higher level, and separates them into
two parts; their class structure, and their serialized information. By
doing this, any process run within JSH can be broken down into these two
parts, sent over to another Node running JSH and realized as a direct
duplicate. All objects that are to be “run” within JSH must extend the
JProcess class, which is a serializable class. The main use of this is
in ConnectionManager.

Modules in JSH are extensions of JSH that can be loaded during JSH launch.
These modules are essentially independent of JSH, however they can
access internals of JSH, as well as call methods from other modules. In
this way, modules can have dependencies on other modules. A module is
loaded from the “modules” directory within JSH’s main directory, and a
list of modules to load is kept in the same directory under the file
name “module.lst.” All modules listed within this file are loaded,
enabled, and executed. Within a Module’s main directory, a dependency
list labeled “res.lst” can be kept linking to either individual class
files, or JAR files which contain necessary code. These JAR files can
also contain Native Libraries to be loaded.
The ModuleManagement class is responsible for loading these modules, and
managing/monitoring them. In order to load a module after
initialization, the method “hotLoad()” must be called. The “hotLoad()”
method should be used sparingly however, as it is buggy, and if a module
is incorrectly implemented it could crash JSH, this will be fixed in a
future update.

JSH uses Logger objcets to organize process output. All JProcesses have
unique Logger objects that they use to print output, these Logger
objects are also used to assist in output redirection of any process, as
any Logger object can print to any OutputStream ambiguously.
The LogManager class is responsible for managing these Logger objects.
All Logger objects which are created notify the LogManager class of
their creation, and on creation are stored in a structure within
LogManager to maintain and monitor them. LogManager itself is not a
JProcess, and as such does not contain a Logger object, it instead
writes directly to the default OutputStream. LogManager and Launch are
the only classes with direct access to the default OutputStream.

JSH contains a system which implements a clustering capability based on Abstract Serialization.
In this, a JProcess can be serialized, and sent to another JSH
instance which will de-serialize and execute the JProcess object
ambiguously. This means that any form of JProcess can be sent, be it a
Command, or a Module, or an independently coded form of JProcess. These
JProcesses can be sent at varying points within their lifecycle as well.
ConnectionManager allows Nodes to find one another, and then distribute
JProcesses queued to them around the general Node system. Each
instance of JSH contains an independent ConnectionManager, meaning that
no instance is truly a host, and no instance is truly a client. Instead
all instances of JSH act as transceivers, relatively independent of all
other instances surrounding them. As such, instances can be added or
removed without affecting other instances as long as all JProcesses that
originated from that instance are completed and the proper information
is returned to the sender. A second feature of this is, JSH being a
crossplatform program, can send or receive processes from any system
that can run Java. So a JProcess that is created on a Windows machine
can be cleanly and efficiently run on a Linux or Mac machine with little
to no interpretation.

Throughout this README, the class “JProcess” has been mentioned several times. As mentioned in Abstract Serialization, all processes to be run in JSH must extend the JProcess class. Upon a
JProcess objects instantiation, it registers itself with JSHProcesses
whose responsibility is managing and monitoring all JProcess objects
currently active, and inactive, within a JSH Node.

EventManager is used for internal event management, and most commonly handles
ModuleEvents, which are fired in order to trigger a Module wihout
needing to depend on that module. This allows processes within JSH to
“softdepend” on modules, in other words a JProcess could support a
module, however if that module is not installed the JProcess will still
load and run successfully. The EventManager class can also be used to
handle native events, and has built-in “evdev” support.

The Terminal class implements a text-based Terminal that takes user input,
and provides output from JSH itself. The Terminal class is used to
execute Commands, which are JProcess objects, that similarly to modules
are loaded upon launch. Commands are stored in the “bin” directory of
JSH’s main directory. All Command files stored within that directory are
loaded. Several important commands that provide low-level access to
files, and the JSH system itself are built into the JSH system, and
loaded automatically upon Launch. These can be disabled in the “system”
configuration file which is located in the “conf” directory within
JSH’s main directory. Commands can also be loaded from a remote
repository, configurable on first launch.