Process Monitor

The JUNK Text Console
Activating this function will produce the text console terminal for JUNK. The JUNK text console is used for user debugging, exception tracing and message passing in JUNK's Jvm process. All of the JD4X module output or message dumps either to the standard system output or error pipes are redirected to this terminal. This will allow the user to inspect and analyze any abnormally terminated module, or any other debugging user messages sent by the module. Refer to the text console section for the detail facilities available.

The Run Dialog


It allows an application to be executed like on a Xterm. An application program is also referred to as a process in our documentation. In short, a process is merely an execution path within the computer with an isolated execution environment.  All processes activated from the run dialog are under the direct management of JUNK. If a process is under the management of JUNK, then JUNK can terminate it at anytime as it deems fit. The process is also made available to the user's direct manipulation from JUNK's process monitor. This is the recommended way of creating native process in the JD4X system.

The User Manual Help Launcher
Activating this function will launch the current user manual in either mozilla or netscape respectively. If none of these two browsers can be found, an error dialog will appear telling the user where the actual user manual is located. The user can then use their own favourite web browser to view the files accordingly. This feature is only temperary and will be replaced by a more standard help manual in future releases.

Logout Of The Desktop
Activating this function ends the desktop session. Before the JD4X system actually ends the desktop session, it will double confirm with the user by asking for a confirmation to exit the system. This feature shuts down the whole JD4X system including JUNK that is running in the background. Shutdown will proceed if "yes" was selected. The other options merely cancel the command to shutdown. All current desktop configuration changes are automatically saved so that the new configuration can be restored on the next desktop session.

Text Console
Text consoles are used for user debugging, exception tracing and message passing in a Jvm process. All of the Java program hosted in a particular shared Jvm will have their output or message dumps either to the standard system output or error pipes redirected to this console terminal. This will allow the user to inspect and analyze any abnormally terminated Java application, a faulty program or any other debugging user messages sent by the Jvm or Java application.


Each of the text consoles has an area that host all the messages and a function panel that offers three main facilities to its user:


JBin Support For The JD4X Shared Jvm
JD4X has a shared Jvm feature that allows a user to directly manipulate the Jvm that they create. This feature requires that the user places all the desire Java applications into the jbin directory located in the JD4X home directory. Each shared Jvm parses the jbin directory where the JD4X system is installed and creates a link to any jar or class file that it is able to execute. This feature allows an easy execution environment for Java application programs commonly used on the desktop to share the common memory space of a Jvm. The advantage of this feature is that the user can track the loading process, avoid the process startup time, reduce the reloading time of an already loaded class byte code and is very useful for debugging and for using undocumented Java programs. The user only needs to copy the desired Java program into the jbin directory and the JD4X system will automatically link it into its execution domain. The main Java program must reside directly in the top level of the jbin directory whether it is a class file or Jar file because the parsing is not recursive. If the main Java program is hidden in another subdirectory in jbin, the shared Jvm will assume that the class or Jar file is a plugin and will not load them. Applications that are non-compliant to the JD4X system may result in poor performance (but performance will not be slower than any normal Java process startup time). This is because of the use of the System.exit() call instead of disposing their resources and allowing the JD4X Jvm to handle the Jvm shutdown. Any JD4X compliant application will never terminate the existing Jvm and therefore reduces the time taken for the Jvm process startup and setup. Class loading efficiency is more or less the same as normal Jvm class loading unless custom loading is used but the improvement if any at all are really minor and makes no difference to the user. Custom loading and system loading helps to define insecure and secure Java applications respectively within the user's Java desktop system. In so doing users can define for themselves which application they trust and which they do not. However, as of current release, this feature will be done automatically for the user. System loading occurs when the user places the Java program into the jbin directory. The shared Jvm will delegate the loading of any jbin application to the system class loader. Custom class loading occurs when the Java application is loaded from anywhere other than the jbin directory. In this case, the shared Jvm will delegate the loading to the JD4X network class loader which has a set of more limited permissions.

JD4X Jvm GUI Interface

Note: The shared Jvm facility may be pending deprecation or perhaps future updates.

In summary, all executable Java classes has to be loaded into a Jvm's memory and its byte code has to be interpreted into native functionalities (provided by the native Jvm libraries) before a class can be run on the computer. In most of the Java toolkits, the java program does just that but it keeps all the details of class loading and class invokation transparent to the Java user. This is where the JD4X Jvm differs. The JD4X Jvm is an interactive Jvm that allow its clients to decide what, when and how each Java class or Java jar file is to be loaded and executed.

Classloader Monitor
Creating a shared Jvm will produce a dialog box that allows the user to access six main Jvm facilities. The classloader monitor keeps track of the currently loaded classloaders in the Jvm. This dialog currently has six functions available to the user:

(a) Execute classloader: (1st icon from left)
Selecting 1 or more of the currently loaded classloaders in the monitor list and activating this function will execute them in one go. If the selected classloader contains a class, that class will be executed. However, if the selected classloader contains a compressed jar file, then the main class defined in its manifest file will be executed. In addition, before each of the selected classloader is executed, the user will be asked on how to create the class object.

Invokation Options

 

There are three options available to the user:

(i) Default: This option is to create the class object using the default constructor of the class if any. If no default constructor or constructor that takes no arguments is found within the class definition, then an exception will be thrown.

(ii) Main: This option is to use the public static void main(String[] args) to create the class object if any. If no such method is found within the class definition, then an exception will be thrown.

(iii) Applet: This option is to be used if the class file is an Applet or JApplet and needs to be loaded into an applet viewer. If the class selected is not an applet, then an exception will be thrown. The JD4X Jvm will automatically provide the needed applet viewer for the applet class and display the applet in it.

Applet Viewer

 

Once the user has decided on how the class object is to be created, the user will be asked again if any parameters are to be passed into the class object to be created, however this is only if (ii) Main was selected.

Paramter Option

A text entry dialog will be displayed for the user to enter the desired parameter options. If no parameters are desired to be passed to the class object, the user can simply click on the Ok button without entering anything. Finally, the class object is created in the Jvm.

(b) Class Monitor: (2nd icon from left)

Class Monitor

Selecting only one of the currently loaded classloader in the monitor list and activating this function will produce a dialog box that allows the user to access two main class facilities. If more than 1 classloader is selected, only the last selected classloader will be used. The class monitor keeps track of the currently loaded classes in the selected classloader. This dialog currently has two functions available to the user:

(i) Execute class: (1st icon from left)
This function's procedure is similar to that of the classloader execution function except that instead of a classloader, each of the currently loaded classes can be individually selected for execution. Multiple classes can be selected in one go. However, subclasses cannot be executed. This facility allows users to individually test run specific loaded classes without having to test run the entire Java application program.

(ii) Reflect class: (2nd icon from left)

Reflector Dialog

 

Selecting 1 or more of the currently loaded classes in the monitor list and activating this function will produce a listing of all the details of the class definition. This option allows the user to inspect a loaded class or their subclasses for analysis purposes. It is often useful for investigating on undocumented classes before executing or using them.

(c) Unload classloader: (3rd icon from left)
Selecting 1 or more of the currently loaded classloaders in the monitor list and activating this function will unload them in one go. Unloading a classloader will remove all the class objects belonging to that classloader and if any of the class object at that moment is still under active use then an exception will be thrown whenever that class object is being referenced. This function does not remove the loaded class definition from the Jvm but instead it removes the objects created from it such that more memory can be made available in the Jvm at the user's command. This feature depends on the Jvm garbage collector implementation and the amount of memory released is not guaranteed.

(d) Class Loading: (4th icon from left)

Jvm File Chooser

 

Activating this function displays a file chooser that allows the user to select the desired Java class or compressed jar file to be loaded from the local file system. Click on any of the files to select the desired class or jar file to load into the Jvm. Once the desired file has been selected, click on the Load button to initiate the loading process. Each classloader is maintained by a manager that list the paths where the class or jar was loaded from so that they can be referenced later by the user. If the selected file is a compressed Java jar file, then the main class defined in the manifest file and its needed subclasses will be automatically loaded by the JD4X Jvm. If the selected file is a class file, then the user will be asked to enter the package to which the class is declared to belong to.

Package Option

 

The package information is then used to find and load the selected class file. Class loading is a function that allows the user to load files from arbitary locations on the file system including the trusted system loading directory, jbin. Any class or jar file found inside the jbin directory is considered secure for system loading and custom loading will deny any loading access from it, however, if system loading is required, this same function will automatically re-direct the loading to the system classloader. Therefore current users no longer need to worry about the two different kinds of class loading because the JD4X Jvm will handle it for them. JD4X separates the jbin directory loading from the rest of the file system because classes and jars loaded using system class loading is directly loaded by the system or bootstrip classloader which has more privilleges than the custom classloader. Classes and jars loaded using system class loading cannot be tracked except for the initial loaded class, which is needed for execution. Users should make full use of the jbin directory by placing commonly used Java desktop applications into that directory to allow easy and secure loading. The JBin support functionality uses this form of class loading.

(e) Text console of the Jvm: (5th icon from left)
The Jvm text console is used for user debugging, exception tracing and message passing in the Jvm. All of the Java program output or message dumps either to the standard system output or error pipes are redirected to this terminal. This will allow the user to inspect and analyze any abnormally terminate Java program, a faulty program or any other debugging user messages sent by the Jvm or Java program. Refer to the text console section for the detail facilities available on each text console.

(f) Kill Jvm: (6th icon from left)
This feature is to kill the Jvm and terminate all classes running in its memory space, resulting in a normal process termination. Any Java application programs currently hosted by the Jvm will be terminated and their memory released. The JD4X Jvm will reconfirm with the user before proceeding to shutdown.

Jvm Termination Dialog

(g) Jvm Memory: (progression bar at the top)
This is merely an indicator of the total memory used by the Jvm at any particular time. The values are calculated in 1Kbytes or 1024 byte. Activating any of the JD4X Jvm features will produce the most updated memory usage within the Jvm.