[e-lang] [Fwd: [Waterken-server] ref_send: eventual reference operations in Java]

Mark S. Miller markm at cs.jhu.edu
Sun Mar 4 20:47:54 CST 2007

In case there's anyone on e-lang who hasn't seen this on cap-talk or 
waterken-server, I thought I'd repost it here. Discussion has started at 
waterken-server: <https://lists.sourceforge.net/lists/listinfo/waterken-server>.

-------- Original Message --------
Subject: [Waterken-server] ref_send: eventual reference operations in Java
Date: Sun, 4 Mar 2007 10:10:38 -0800
From: Tyler Close <tyler.close at gmail.com>
Reply-To: Implementation and use of web-calculus technology 
<waterken-server at lists.sourceforge.net>
To: General discussions concerning capability systems. 
<cap-talk at mail.eros-os.org>,        Implementation and use of web-calculus 
technology <waterken-server at lists.sourceforge.net>

I'm releasing an initial beta of the ref_send library, which provides
eventual reference operations in Java. Using this library, you can do
eventual invocations and eventual promise handling in Java in much the
same way you can in the E language. The library is smallish and can
use whatever event loop your application currently has, such as the
AWT event loop. As a result, it should be fairly painless to start
doing eventual reference operations in an existing Java program using
the ref_send library.

On its own, the ref_send library enables eventual reference operations
within a single, non-persistent Java thread. However, the ref_send
library also defines the entire public API for the next release of the
Waterken Server. As a result, applications written to the ref_send API
can use the orthogonal persistence and transparent networking provided
by the Waterken Server, without change.

For now, I'm only releasing the ref_send library, but the rest of the
Waterken Server will follow soon. In the security review last week, we
found several implementation errors in the Waterken Server, but only
one in the ref_send library. Fortunately, these errors were only
implementation errors and not design errors, so they can all be fixed
without API changes. So I decided to release the ref_send library and
start collecting feedback while I'm making the implementation fixes on
the Waterken Server.

At this point, the documentation for the ref_send library is a little
thin. There is extensive Javadoc and a small collection of example
programs. I think there is enough documentation for cap-talk readers
to learn the code and start criticizing it. I'ld like to start
collecting this criticism before producing much more documentation.

In many ways, the ref_send library creates a new language within Java.
So criticism of the API, and the names used in the API, is more
important than usual. These names and idioms shape how the programmer
thinks about flow of control in a program that does eventual

We're also still developing standards for how Joe-E code should be
written to facilitate security review. I'ld like the ref_send library
to serve as an example of these coding standards, so being
particularly picky about implementation clarity is warranted.

I won't be able to get back to this thread for about a week. But I
hope there will be lots of feedback for me to work on when I get back
to it.

You can get the ref_send distribution at:


The Javadoc is online at:



Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
Waterken-server mailing list
Waterken-server at lists.sourceforge.net

Text by me above is hereby placed in the public domain


More information about the e-lang mailing list