Re: Joe-E Taming Policies

Mohsen Vakilian  wrote:
> Can anyone explain the rationale behind the following Joe-E error messages?
> I don't see why the following classes should be disabled by Joe-E. For
> instance, does creating a StringBuffer as a local variable of a method cause
> impurity? Why is StringBuilder allowed but not StringBuffer?

Thanks for your interest in Joe-E, Mohsen!

You're absolutely right that StringBuffer should be safe.  Adrian
has nailed the explanation.

As you may know, Joe-E is a research project.  When we run into tasks
that require a lot of engineering effort but have little clear research
benefit, we have to evaluate carefully whether we can justify spending
the effort on them -- and often there isn't time to do those tasks as
completely as we'd like.  Taming the Java library is one of those cases.
I'd prefer to go through the entire Java library carefully, and analyze
each API to determine which ones are safe to expose to Joe-E code.
However, that is a time-consuming process, and it's hard to justify
spending a lot of time on it, when it won't lead to any publications.
As a result, the taming that has been done is very minimalistic and much
less thorough than ideally we'd like.  Only a small fraction of the Java
class library has been analyzed.

For security, we are using a default-deny strategy.  Until we analyze
an API, it is tamed away (not exposed to Joe-E code).  Put another way,
you can think of the taming database as a whitelist of methods that
we have analyzed and determined to be safe to expose to Joe-E code.
That whitelist is missing a whole lot of safe APIs, because we just
haven't had time to look at it yet.  If we haven't examined a method,
it is denied by default.  As a result, a whole lot of safe methods are
currently not accessible to Joe-E code.  If you find a "default deny"
comment, that's likely a sign that we have not analyzed that method or
that API yet and hence have not made it accessible to Joe-E code.

Another thing that's missing from the current taming database is good
documentation on why various methods are tamed away.  Ideally, when we
tame away a method (when we mark it as unsafe and not available to Joe-E
code), we'd like the add a comment to the taming database explaining
why it is unsafe and what to use instead.  That would make Joe-E easier
to use for programmers and less frustrating.  However, we just haven't
had time to do that.  As a result, the comments currently in the taming
database are often extremely minimalistic and not terribly useful to
Joe-E programmers.

I realize that the incompleteness of the taming database is likely
to be a real pain in the butt.  Sorry about that.  I know it sucks,
and I wish I had more time to work on remedying that.

> Disabled constructor from class ArrayIndexOutOfBoundsException called:
> default deny

Probably a case that just wasn't analyzed yet.

> Method from disabled type Hashtable called: no policy specified for this
> class

Hashtable is one of those that we deliberately suppressed, because 
it provides access to non-determinism (the enumeration order of keys
is non-deterministic).  The intent is to allow use of LinkedHashMap,
since that has a deterministic enumeration order and does not provide
access to non-determinism.  However I don't think that class has been
allowed in the taming database yet.  Like I said, the taming database
is highly incomplete.

> Disabled constructor from class StringBuffer called: default deny

Adrian answered this one.