Contents Home Page
E provides several tools and utilities:
E compiler (ecomp)
E Java Interpreter (javaec)
Distributed Garbage Collector
ThreadWatcher utility
Class Blesser
E provides its own compiler, called ecomp. ecomp compiles code directly to Java bytecodes (.class files). The ecomp compiler can compile Java code as well as E code.
Files generated by ecomp
Like other Java compilers, ecomp generates one .class file for every Java class defined in the source file.
For every E-class defined in the source files passed to ecomp, the compiler generates the following.class files:
- classname.class
- classnameObject_$_Intf.class
- classnameObject.class
- classnameObject_$_Proxy.class
- classnameObject_$_Channel.class
- classnameObject_$_Sealer.class
- classnameObject_$_Impl$closure.class
- classnameObject_$_Unsealer.class
- classnameObject_$_Impl.class
ecomp
ecomp [-verbose][-obfuscate][-classpath path] {[-d directory] filename(s) }The ecomp command compiles E and Java source code into Java bytecodes. You then use the E Java interpreter, javaec, to interpret the Java bytecodes. The javaec command is similar to Java's java command, but adds E functionality such as the Trust Manager and Distributed Garbage Collector.
Options
- -verbose
Writes out information about loaded source and class files and compilation times.
- -obfuscate
Scrambles the names of all private methods and fields in the generated .class file.
- -classpath path
Prefixes the value of path to the value of the CLASSPATH environment variable. Note that this is different behavior from javaec, which actually overrides CLASSPATH when you use this same option.
- -d directory name
Specifies the root directory of the class hierarchy. For example, entering the following line:
ecomp -d <my_dir> MyProgram.esaves the .class files for the classes in the MyProgram.e source file to the directory my_dir.The directory must already exist. See the following section Where ecomp outputs class files for more information.
-g Generates local variable information for debuggers.
filename(s)
The file or files to be compiled. By convention, files containing E-classes should have a .e extension, while files containing only Java classes should have a .java extension. However, this is not required.
You can specify multiple files.
Note that if there are cyclic dependencies between classes defined in different files, all of the containing files must be compiled together.
Where ecomp outputs class files
E follows Java rules on packages and file hierarchy, and the compiler generates Java bytecode in a location based on your package name.
Where ecomp outputs the generated .class files depends on whether you specify a directory with the -d option, and if you specify a package in your source file. The basic rule is that if you specify a package in your source file, you should either be in that directory when you compile, or specify it with the -d option (and it must exist).
Without the -d option
If you do not specify a directory, or if you specify a directory that does not exist, ecomp create the class file(s) in the directory where the source file is.
Note that if you specify a package in your source file, but do not specify a directory when you compile, ecomp still outputs the generated class file(s) in the source file's directory, regardless of the path indicated by the package line. Unless you compile in the directory specified by the package, javaec will not be able to find these files later on when you try to run the program, since the package and the file directory do not match.
With the -d option
No package statement
ecomp creates the .class file(s) in the directory specified by the indicated path. For example, if you run the following line:
ecomp -d /var/tmp filenameecomp creates the class file(s) in /var/tmp.
With a package statement
With a corresponding directory path. If there is a directory path under the specified directory corresponding to the package statement, ecomp creates the .class files in that directory path, below the current directory specified by the package name. For example, if your source file contains the following line:
package ec.misc.foo;and you run
ecomp -d /var/tmp filenameecomp creates the class file(s) in the directory /var/tmp/ec/misc/foo (providing /ec/misc/foo exists under/var/tmp).
Without a corresponding directory path. ecomp creates the .class file(s) in the current directory, where the source file exists. Be sure that in this situation you are already in the correct directory (specified by the package line in the source file) when you compile.
E provides its own Java interpreter, javaec, to interpret and execute Java bytecodes generated by the compiler. The javaec interpreter is based on Java's interpreter, java, but includes E features such as the Class Blesser, distributed garbage collector, and Trust Manager.
Note that to fully implement the distributed garbage collector, you must run javaec with the E system argument -ECenableDgc (described in the following section):
javaec classname -ECenableDgcTo turn on the Class Loader, you must also include the following code in your main object:
RtLauncher.setupClassLoader(int Security_Level);This call turns on the E class loader. Add this line before any RtLauncher.launch calls. See the documentation on RtEEnvironment and also the section Creating access-controlled objects in the E Runtime chapter for more information.
The -EC* standard command-line arguments
E provides the -EC* system arguments that you can enter at the command line when you run an E program. These arguments are stripped out of the standard arguments array when you launch an object. This lets you run a program with E-provided system facilities, but not have these arguments passed in turn to any objects you launch in your program.
Currently, E provides the -ECenableDgc argument, which turns on distributed garbage collection.
Running javaec
To execute a Java or E program that has no package, you must be in the directory that contains the class file(s). To execute a packaged program, the following conditions apply:
- The .class file must be in a directory path matching the package name.
- This directory path must be rooted in one of the entries in your $CLASSPATH.
- You do not need to be in the same directory as the .class file when you run javaec.
To run javaec, its directory must be included in your PATH variable. E will specify a default directory during installation, but you must update your PATH if you change this directory.
javaec
javaec [-classpath path] [-ms n ] [-noasyncgc] [-ss x ][-oss x ][-v, -verbose ][-verify ] [-verifyremote][-noverify][-verbosegc] classname.class program argumentsOptions
- -classpath path
Specifies the path E uses to look up classes. If you have set a default for CLASSPATH, using this option overrides that default (note that this is different behavior than ecomp's classpath option). Enter the path using the following format:
directory1:directory2:directory nwith directories separated by colons. Use a single period (.) to indicate the current directory. For example:
.:/home/lani/classes:/usr/local/e/classes-ms n Sets the size of the memory allocation pool (the garbage collected heap) to n, which must be greater than 1000 bytes. The default units for n are bytes, but you can change this. Append either the letter "k" to set the default unit to kilobytes, or the letter "m" for to change it to megabytes. The default is -ms3m, for 3 megabytes of memory.
-noasyncgc Turns off asynchronous garbage collection. When passed as an option, no garbage collection takes place unless it is explicitly called or the program runs out of memory. Normally garbage collection runs as an asynchronous thread in parallel with other threads.
-ss n Each Java thread has two stacks: one for Java code and one for C code. The -ss option sets the maximum stack size that can be used by C code in a thread to n. Every thread that is spawned during the execution of the program passed to java has n as its C stack size.
The default unit for n is bytes, and n must be greater than 1000 bytes. You can change the default unit by appending either the letter "k" for kilobytes or the letter "m" for megabytes. The default stack size is 64 kilobytes (-ss 64k).
-oss n Each Java thread has two stacks: one for Java code and one for C code. The -oss option sets the maximum stack size that can be used by Java code in a thread to n. Every thread that is spawned during the execution of the program passed to java has n as its Java stack size.
The default unit for n is bytes, and n must be greater than 1000 bytes. You can change the default unit by appending either the letter "k" for kilobytes or the letter "m" for megabytes. The default stack size is 400 kilobytes (-ss400k).
-v, -verbose Prints a message to stdout each time a class file is loaded.
-verify Runs the verifier on all code.
-verifyremote Runs the verifier on all code that is loaded into the system via a classloader. verifyremote is the default for the interpreter.
-noverify Turns verification off.
-verbosegc Causes the garbage collector to print out messages whenever it frees memory.
classname.class program arguments The name of the compiled E or Java class to run. See the following section on Class names for information on using class names.
Program arguments. You can pass in either E-provided system arguments or any arguments pertinent to your program. Currently, E provides the -ECenableDgc argument to turn on distributed garbage collection. See The EC* standard command line arguments at the beginning of this section for more information.
Command line arguments with a key=value syntax should use the syntax x=y. For example, host=localhost.
E lets you pass command line arguments to an object you launch to create restricted environments. For example, if you run javaec with the following arguments:
javaec myfile host=localhostyou can pass this to objects you launch in the application (with RtLauncher.launch), and then create a restricted file system environment using this path. See the documentation on Creating access controlled objects (in the E Runtime chapter), RtLauncher, and RtEEnvironment (in the E Class Library chapter) for more information.
Class names
When you run javaec, you must fully qualify the class file name like you do in Java. This means that if you specified a package in the original source file, you must include the package hierarchy in the javaec command line. For example, if your source file myexampleclass has the line:
package ec.e.examples:you must run javaec with the package hierarchy:
javaec ec.e.examples.myexampleclassjavaec passes any arguments following classname to the program.
The bytecodes for the E or Java class are in a file classname.class. ecomp generates this file when you compile the corresponding class source file. ecomp automatically adds this extension to the bytecode file when the class is compiled.
classname must contain a main() method, which E executes and then exits, unless main() creates one or more threads. If any threads are created by main(), then E doesn't exit until the last thread exits. The main() method is defined as follows:
class Aclass {public static void main(String argv[]){ < main code > } }As in Java, when you define your own E or Java classes, you need to specify their location using CLASSPATH. See the Java documentation on CLASSPATH for more details. Note that the system always appends the location of the system classes onto the end of the class path unless you use the -classpath option to specify a path.
The E product provides a distributed garbage collector. Unlike Java's garbage collector, which performs garbage collection only within the scope of your local machine, E's distributed garbage collector performs garbage collection over the net for your distributed objects.
To use the distributed garbage collector, pass the -ECenableDgc argument on the command line when you run javaec. For example:
javaec Myfile -ECenableDgc
import ec.util.ThreadWatcher;
ThreadWatcher is a Java class which creates a daemon thread to monitor all of the threads in the system and periodically print out what threads are running. You can set the periodicity, and start and stop the monitor. This utility is useful when you have a Java application that hangs, and you want to know what is running.
You can only have one ThreadWatcher instance active at one time.
Creation
You can not explicitly create a ThreadWatcher. The system does it for you through class methods which start watching.
Public variables
public static int waitTime = 5000
This is the wait interval, and can be changed while the ThreadWatcher is running. If it is changed, the former waitTime will still be used for the current "watch" slice, but it will then start using the new waitTime. waitTime is specified in milliseconds.
Methods
public static void startWatching()
Starts up the unique ThreadWatcher (if it is not already running), which will print out what threads are running every 5 seconds. Returns immediately, as the ThreadWatcher runs in it's own thread.
public static void startWatching(int timeToWait)
Starts up the unique ThreadWatcher (if it is not already running), which will print out what threads are running every "timeToWait" seconds. Returns immediately, as the ThreadWatcher runs in it's own thread. TimeToWait is specified in milliseconds.
public static void stopWatching()
Stops the unique ThreadWatcher (if it is not running)
public static void showThreads()
Shows all the threads (this is the same method that is called periodically by the ThreadWatcher itself). Note that the ThreadWatcher doesn't have to be started to call this, you can manually keep track of all the threads by calling this whenever you want.
Interfaces
None
Example
import ec.util.ThreadWatcher; public class ThreadVoyeur { public static void main(String args[]) { // Watch the threads every minute ThreadWatcher.startWatching(60000); SomeOtherFancyClass.doSomethingSpawningLotsOfThreads(); } public userInvokedToSpewThreads () { ThreadWatcher.showThreads(); } public userWantsToStopWatching () { ThreadWatcher.stopWatching(); } public userWantsToWatchWithThisInterval(int newInterval) { ThreadWatcher.waitTime = newInterval; // Although probably better to just do this... ThreadWatcher.stopWatching(); ThreadWatcher.startWatching(newInterval); } }
The E environment provides a user interface called the Class Blesser to manage the TBF, keys, certificates, and E's trust relationships in general. (See the Authentication section in the E Runtime chapter for a discussion of these topics.) You can invoke the Class Blesser either through an interactive graphical user interface, or a command-line interface. When invoking from the command-line, an input file of commands may be specified for the Class Blesser to execute as a batch.
The Interactive Interface
To invoke the graphical user interface for the Class Blesser, run the E Java interpreter (javaec) with the Class Blesser argument, with no command-line options:
javaec ec.clbless.ClBlessThe graphical interface has several menus, which are explained in the following paragraphs:
File Menu
- Open
- Save
- Save As
These commands bring up standard file dialog boxes for opening and saving TBF, key, and certificate files.
- Quit
The Quit command exits the Class Blesser.
Certificate Menu
The commands in the Certificate menu are used for manipulation and management of E trust certificates, and are largely self-explanatory.
- Generate Certificate
The Generate Certificate command brings up a dialog for interactive generation of new E trust certificates. The controls in this dialog box allow interactive generation of variable bindings and source claim statements. The top pane of the window lists currently defined local variables and their values, as established with the Assign button. The lower pane contains the text of the certificate under construction. (The text of an existing TBF or certificate file can be pasted into this pane for modification.)
- PkgBelong
The PkgBelong button in the Create Certificate dialog brings up the PkgBelong dialog box. The PkgBelong predicate of a source claim statement grants authority to a key to make claims about membership in a particular E package; this dialog allows you to specify the name and location of the package.
- LoadOkay
Similarly, the LoadOkay button brings up a dialog for entering the names of the loading and loaded classes specified in a LoadOkayCert claim statement. (The loaded_hash and loading_hash parameters for the classes are calculated and supplied by the Class Blesser.
- View Certificates
- Remove Certificates
- Import Certificates
- Export Certificates
These commands bring up additional dialog boxes for displaying and managing certificates.
Keys Menu
The Keys menu is similar to the Certificate menu; it is used for generation and manipulation of keys.
- Unlock Keyring...
Unlocks the keyring
- Generate Key
The Generate Key command presents a dialog for generating a new public-key/private-key pair. The user specifies the desired bit length of the key (longer keys provide greater security against cryptographic attack), and a text string by which the key can be looked up later, as its key_ID.
- View Public Keys
- View Private Keys
- Remove Public Keys
- Remove Private Keys
- Import Public Keys
- Import Private Keys
- Export Public Keys
- Export Private Keys
These commands are similar to their counterparts in the Certificate menu. If an operation is being attempted on a private key, the Class Blesser displays a Passphrase field. Use this field to verify your ownership of the private key by entering a secret passphrase known only the creator of the key.
Help Menu
- Help
The Help command in the Help menu brings up a window full of explanatory text about the various commands and dialogs available through the Class Blesser interface.
- About
The About command displays version and copyright information for the Class Blesser itself.
The Command-Line Interface
You can also invoke the Class Blesser from the command line by using options:
javaec ec.clbless.ClBless optionswhere options are chosen from among:
-log <LogFile> -verbose -help [<cmd>] -infile <InputFile> -cmd NAME <arg1> [<arg2> .. <argn>] -tbf <input file>Command-Line Options
- -log <LogFile>
Route diagnostic messages and other output to the specified LogFile. Requests for passwords and other secure input will still be routed to the terminal. If a file with the same name already exists, it will be overwritten.
- -verbose
Provide detailed feedback. This is routed to the active terminal (or to a log file if specified).
- -help [<cmd>]
Display a brief text description of the named command. If no command is specified, the Class Blesser displays a list of the available commands.
- -infile <InputFile>
Invokes the Class Blesser in batch mode to execute the list of commands contained in InputFile. Any required passwords or other input will be requested from the terminal at the start of execution.
- -cmd NAME <arg1> [<arg2> .. <argn>]
Invokes the Class Blesser to execute a single key command or certificate command. The named command may be any of the batch-mode key or certificate commands.
- - tbf <InputFile>
Builds a trust boot file from a text input file. The input file cannot have the same name as an existing trust boot file; this option does not overwrite any file of the same name. You can then copy this new trust boot file to your ~/e/tbf directory, where the trust boot file resides.
Key Commands
- -cmd KADD -key <KeyInfo> -keylen <KeyLen>
(Key Add) Generate a public/private key pair with the label KeyInfo, of length KeyLen.
- -cmd KDEL -keyring <public/secret> -key <KeyInfo>
(Key Delete) Remove the key corresponding to KeyInfo from your public or secret keyring.
- -cmd KOUT -keyring <public/secret> -file <FileName>
(Keys Out) Export the keys in your public or secret keyring to the file FileName in ASCII form.
- -cmd KIN -keyring <public/secret> -file <FileName>
(Keys In) Import all keys in file FileName to your public or secret keyring.
- -cmd KLIST -keyring <public/secret>
(Key List) Display the key info and key ID for all keys in your public or secret keyring.
Certificate Commands
- -cmd CADD -sigKey <SigKeyInfo> [-keylen <KeyLen>] -claim <Claim>
(Certificate Add) Create a certificate database that makes a claim and signs it with the key corresponding to SigKeyInfo. If such a key doesn't exist yet, create it (with key length KeyLen if provided). Claim is a claim string, in the form described in Source Claim Statements in the E Runtime chapter.Claim must be surrounded by single quotes because claim statements can contain double-quotes.
- -cmd CMC -sigKey <SigKeyInfo> -claim <Claim>
(CanMakeClaim) Create a CanMakeClaim certificate asserting Claim, signed by the key corresponding to KeyInfo, and add it to the certificate database.
- -cmd CMC -sigKey <SigKeyInfo> -key <KeyInfo> [-keylen <KeyLen>] -pkg <PkgName>
(CanMakeClaim) Create and add to the database a CanMakeClaim certificate, signed by the key corresponding to SigKeyInfo, asserting that the key corresponding to KeyInfo can make any PkgBelongCert claim about the package PkgName. The generated certificate is of the form:
SigKeyInfo states { KeyInfo CanMakeClaim where { delegate = "yes|no" and claim == "PkgBelongCert where (pkg == 'PkgName')" } }-cmd CMC -sigKey <SigKeyInfo> -key <KeyInfo> [-keylen <KeyLen>] -pkg <PkgName> -file <FileName>
(CanMakeClaim) Create and add to the database a CanMakeClaim certificate, signed by SigKeyInfo, asserting that key KeyInfo can make LoadOkayCert claims loading the class in file FileName, which belongs to the package PkgName. The generated certificate is of the form:
SigKeyInfo states { KeyInfo CanMakeClaim where { delegate = "yes|no" and claim == "LoadOkayCert where ( loaded_class == 'FileName' and pkg == 'PkgName' )" } }-cmd PBC -sigKey <SigKeyInfo> [-keylen <KeyLen>] -pkg <PkgName> -file <FileName> (PkgBelongCert) Create and add to the database a signed certificate asserting that the class in file FileName belongs to the package PkgName.
-cmd PBC -sigKey <SigKeyInfo> [-keylen <KeyLen>] -pkg <PkgName> -path <Path> (PkgBelongCert) Create and add to the database a signed certificate asserting that all of the classes in the directory specified by Path belong to package PkgName.
-cmd LOC -sigKey <SigKeyInfo> -loaded <PkgName> -path <Path> -loading <PkgName> -path <Path> (LoadOkayCert) Create and add to the database a signed certificate asserting a LoadOkayCert claim about the specified -loaded and -loading packages.
-cmd CDEL -sigKey <SigKeyInfo> -class <Classname> (Certificate Delete) Delete all claims in the certificate database about class ClassName. ClassName must be fully-qualified (no wildcards).
-cmd COUT -file <FileName> (Certificate Out) Export the certificate database to FileName.
-cmd CIN -file <FileName> (Certificate In) Add to the certificate database the certificates contained in FileName.
-cmd CGRP -sigKey <SigKeyInfo> (Certificate Group) Consolidate all certificates in the database signed by the key corresponding to SigKeyInfo into a single signed certificate.
-cmd ALOC -sigkey <SigKeyInfo> -pkg <PkgName> -path <Path> [-keylen <KeyLen> -classkeys <key/package>] (Autogenerate LoadOkayCert) Generate keys corresponding to SigKeyInfo for each class or package loaded from classes within the indicated package. This command creates CanMakeClaim certificates for the generated keys. It then also generates the LoadOkayCerts for each class loaded, signing them with the appropriate generated key.
You can use the classkeys option to create one key/loaded class instead of one key/loaded package. Keylen is the length of the generated keys, if different from the length of the signing key. Path is the location of the classes on disk.
Command File Syntax
A command is interpreted as everything between a -cmd and either the next -cmd or the end of the file. The command file may contain comment lines; any line beginning with # or // is ignored.
The order of arguments in a single command is ignored. If the same argument (such as -sigKey) appears more than once in a command, the last argument given will be used.
If multiple -cmds are specified on the shell command line invoking the Class Blesser, only the first one will be processed.