E started out adapting AWT and Swing for use as its GUI Toolkit library. In order to allow locally untrusted code, such as caplets, to have a user interface, we would have to tame these libraries to follow capability discipline. As part of the DarpaBrowser exercise, we attempted a first draft taming of AWT/Swing. The section "Taming the Java Interface" of the Darpa Security Review explains taming as well as many of the problems we ran into. Although we have fixed essentially all of the particular problems this document enumerates, the sheer size of the AWT/Swing APIs presents a huge hurdle for the taming process, and makes it implausible we will ever have confidence in the result.
We examined several alternatives, but nothing seemed very attractive until we came across the Standard Widget Toolkit, or SWT, of IBM's Eclipse project. As of 0.8.20 we now have support for SWT integrated into E. SWT is already largely tamed, and we already have an experimental rewrite of eBrowser (our code editor for E) using SWT rather than AWT/Swing.
Besides uniquely meeting our requirements, SWT gives us several other advantages:
See MarcS' message E and SWT for further pros and cons of Swing vs SWT for use by E.
Integrating support for SWT into E presented several interesting issues...
New E Command Line
You can get help on command line of the 'e' driver script (a bash script) by typing
$ e --help
As of 0.8.20, the resulting help text is now:
e [-options] [script [args...]] where options are: -cpa <afterpath> Adds to end of classpath. -cpb <beforepath> Adds to beginning of classpath. -D<name>=<value> Defines Property. Passed to java. -J<java-option> java-option passed to java. For example, "e -J-version" shows the Java version. --help Prints this out and exits. --show Shows the java command line, rather than executing it. --start=<runnerKind> Determines the initial runner's kind. Where <runnerKind> is one of awt Initial vat runs in the AWT event loop and thread swt Initial vat runs in the SWT event loop and thread headless Initial vat runs in its own event loop and thread and script is one of <filename>.<ext> The E script file to execute. If --start=<...> is not provided, <ext> determines the runnerKind, and must be one of 'e', 'e-awt', 'e-swt', or 'e-headless'. ('e' is deprecated and currently defaults to 'e-awt'. It will default to 'e-swt', at which point it will be undeprecated.) - Use stdin as script file. runnerKind is determined as if <ext> is 'e'. --interact An interactive command line. runnerKind is determined as if <ext> is 'e'. no script & args is equivalent to "--interact"
The important changes are shown in bold above -- the two ways of specifying what kind of Runner is used to run the initial vat, and therefore the E script being specified. These two ways are via the new "--start=..." option, and via newly recognized extensions: ".e-awt", ".e-swt", and ".e-headless". On platforms where E's installation causes extensions to be recognized for launching (currently only MSWindows platforms), 0.8.20 causes these new extensions to be recognized as well.
To get the effect of the old "--headless" option, no longer supported as of 0.8.20, use "--start=headless" instead. Except for this change, the new e driver command line is upwards compatible from the old.
A Runner is an event-loop together with the thread servicing the event-loop. AWT and SWT each have their own event-loop mechanism, and in order for E objects (whether written in ELib or the E language) to access and be accessed from AWT or SWT widgets respectively, their vats need to run within the Runners built to run within these event loops. The third kind of Runner, headless, is an event-loop and thread built just for running E objects.
Because we must choose a kind of Runner before we can execute E code within that Runner, it would have been awkward to place the runner-kind directive within the startup E script, such as with a pragma statement. We would have liked to add the above "--start=..." command-line option to the e driver invocation on the "#!" line, such as
#!/usr/bin/env rune --start=swt # broken, since #! only allows one option
but the "#!" mechanism, for some stupifying reason, only supports one option, and we've already used up that budget by using the /usr/bin/env program to avoid pinning the location of the e driver. We could have decided to create wrapping shell scripts, e-awt, e-swt, and e-headless to be used after /usr/bin/env, where these would pass all their arguments to the e driver in addition to a "--start=..." argument. But on platforms like MSWindows, that do extension-based launching and ignore the #! line, we'd also have to enhance the E interpreter to read and process the #! line. What a mess. In the end it seemed simpler to encode the choice in the extension. (Both these choices seem ugly. If you know of a better alternative, please let us know.)
Unless stated otherwise, all text on this page which is either unattributed or by Mark S. Miller is hereby placed in the public domain.