Joe-E Taming Policies

[Mohsen Vakilian]

Hi,

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?

Disabled constructor from class ArrayIndexOutOfBoundsException called: default deny
Method from disabled type Hashtable called: no policy specified for this class
Disabled constructor from class StringBuffer called: default deny

_______________________________________________
e-lang mailing list
e-lang@...
http://www.eros-os.org/mailman/listinfo/e-lang

[Adrian Mettler]

For the most part, the prohibitions you've encountered are a result of
the taming process being incomplete at present -- there are a lot of
would-be-safe classes that we haven't looked at yet.  We're hoping to
add more on an on-demand basis, so people can build more stuff with it.
   StringBuffer and StringBuilder should both be safe; the only reason
one is currently allowed and not the other is that we have mostly written
single-threaded (or vat-based-concurrency) code, which does not need
StringBuffer's thread-safety.

Hashtable is unsafe to use if you want Joe-E's determinism guarantees to
hold: the iteration order of the hashtable depends on the hash codes
assigned to the objects placed in it; for many classes, the hash code is
nondeterministic as it is the JVM's internal identifier for the object
instance.  Hashtable is OK if you do not need the determinism guarantees.

-Adrian

Mohsen Vakilian wrote:

> Hi,
>
> 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?
>
> Disabled constructor from class ArrayIndexOutOfBoundsException called:
> default deny
> Method from disabled type Hashtable called: no policy specified for this
> class
> Disabled constructor from class StringBuffer called: default deny
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> e-lang mailing list
> e-lang@...
> http://www.eros-os.org/mailman/listinfo/e-lang

_______________________________________________
e-lang mailing list
e-lang@...
http://www.eros-os.org/mailman/listinfo/e-lang

[Mohsen Vakilian]

So, given that ArrayIndexOutOfBoundsException is an honorary interface in Joe-E, there is no need to suppress its constructors. Right?
How can I overwrite some of the taming policies for my project?

Date: Thu, 17 Sep 2009 21:32:50 -0700
From: Adrian Mettler <amettler@...>
Subject: Re: [e-lang] Joe-E Taming Policies
To: Discussion of E and other capability languages
       <e-lang@...>
Message-ID: <4AB30D72.8070600@...>
Content-Type: text/plain; charset=UTF-8; format=flowed

For the most part, the prohibitions you've encountered are a result of
the taming process being incomplete at present -- there are a lot of
would-be-safe classes that we haven't looked at yet.  We're hoping to
add more on an on-demand basis, so people can build more stuff with it.
  StringBuffer and StringBuilder should both be safe; the only reason
one is currently allowed and not the other is that we have mostly written
single-threaded (or vat-based-concurrency) code, which does not need
StringBuffer's thread-safety.

Hashtable is unsafe to use if you want Joe-E's determinism guarantees to
hold: the iteration order of the hashtable depends on the hash codes
assigned to the objects placed in it; for many classes, the hash code is
nondeterministic as it is the JVM's internal identifier for the object
instance.  Hashtable is OK if you do not need the determinism guarantees.

-Adrian

Mohsen Vakilian wrote:
> Hi,
>
> 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?
>
> Disabled constructor from class ArrayIndexOutOfBoundsException called:
> default deny
> Method from disabled type Hashtable called: no policy specified for this
> class
> Disabled constructor from class StringBuffer called: default deny

_______________________________________________
e-lang mailing list
e-lang@...
http://www.eros-os.org/mailman/listinfo/e-lang

[David Wagner-3]

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.
_______________________________________________
e-lang mailing list
e-lang@...
http://www.eros-os.org/mailman/listinfo/e-lang

[David Wagner-3]

Mohsen Vakilian  wrote:
> So, given that ArrayIndexOutOfBoundsException is an honorary interface in
> Joe-E, there is no need to suppress its constructors. Right?

Actually, the "honorary" business is something else and unrelated.
ArrayIndexOutOfBoundsException is a class from the Java class library.
Its constructors just happened to be tamed away because we never
analyzed the class itself, and because the default is to suppress
anything we haven't manually analyzed and determined to be safe.

Honoraries are orthogonal to which methods/constructors are
suppressed/allowed in the taming database.  For some description of
"honorary", see Sections 3.2 and 3.3 of the Joe-E spec.  For more on
taming, see Section 5 of the spec.

> How can I overwrite some of the taming policies for my project?

We have not yet written any documentation on how to do this,
so you're mostly on your own.  If you ask Adrian nicely, he might
be able to provide some explanation when he gets a chance.  (If you
feel like giving back and are inspired to write a Wiki page for
the Joe-E project on how to do this, that'd be useful.)

The taming database is under the directory safej/ in the Joe-E
distribution.

If you look at the file safej/java/lang/ArrayIndexOutOfBoundsException.safej
in the Joe-E distribution, you find this:

# auto-generated safej: default deny everything
class("java.lang.ArrayIndexOutOfBoundsException",
  honorary("org.joe_e.Powerless"),
  static(constructor(suppress, "ArrayIndexOutOfBoundsException()", comment("default deny")),
    constructor(suppress, "ArrayIndexOutOfBoundsException(String)", comment("default deny")),
    constructor(suppress, "ArrayIndexOutOfBoundsException(int)", comment("default deny"))))

I believe this is the output of a tool that Adrian has written
to traverse the Java class libraries and output a default taming
file for every Java API, where the default is to deny/suppress
everything.  This provides a starting point, and then one can make
taming decisions by editing the auto-generated file to allow
methods that have been analyzed and determined to be safe.

For another example, see safej/java/lang/String.safej.  Hopefully
you'll be able to puzzle out what the syntax means.  Sorry for the
shortage of documentation or tool support at the moment.
_______________________________________________
e-lang mailing list
e-lang@...
http://www.eros-os.org/mailman/listinfo/e-lang

[Mohsen Vakilian]

David,

Thanks for your detailed response. I should say that Joe-E far exceeds my expectations as a research project. I definitely expected to see glitches. I found Joe-E quite interesting and I've been trying it out on a small program to get more familiar with it. As a result, I encountered some problems but I wasn't sure whether they are due to incomplete implementation of Joe-E. For instance, I didn't realize that Hashtable exhibits some nondeterminism until Adrian pointed that out.

I've already figured how to overwrite Joe-E's taming policies. You are right, the first step is to modify the safej files. And, the next step is to have Eclipse generate the Policy class by right clicking on the project, selecting Joe-E and enabling the "Automatically build Policy class."

Thanks,
Mohsen Vakilian

On Mon, Sep 21, 2009 at 11:12 AM, David Wagner <daw@...> wrote:

Mohsen Vakilian  wrote:
> So, given that ArrayIndexOutOfBoundsException is an honorary interface in
> Joe-E, there is no need to suppress its constructors. Right?

Actually, the "honorary" business is something else and unrelated.
ArrayIndexOutOfBoundsException is a class from the Java class library.
Its constructors just happened to be tamed away because we never
analyzed the class itself, and because the default is to suppress
anything we haven't manually analyzed and determined to be safe.

Honoraries are orthogonal to which methods/constructors are
suppressed/allowed in the taming database.  For some description of
"honorary", see Sections 3.2 and 3.3 of the Joe-E spec.  For more on
taming, see Section 5 of the spec.

> How can I overwrite some of the taming policies for my project?

We have not yet written any documentation on how to do this,
so you're mostly on your own.  If you ask Adrian nicely, he might
be able to provide some explanation when he gets a chance.  (If you
feel like giving back and are inspired to write a Wiki page for
the Joe-E project on how to do this, that'd be useful.)

The taming database is under the directory safej/ in the Joe-E
distribution.

If you look at the file safej/java/lang/ArrayIndexOutOfBoundsException.safej
in the Joe-E distribution, you find this:

# auto-generated safej: default deny everything
class("java.lang.ArrayIndexOutOfBoundsException",
 honorary("org.joe_e.Powerless"),
 static(constructor(suppress, "ArrayIndexOutOfBoundsException()", comment("default deny")),
   constructor(suppress, "ArrayIndexOutOfBoundsException(String)", comment("default deny")),
   constructor(suppress, "ArrayIndexOutOfBoundsException(int)", comment("default deny"))))

I believe this is the output of a tool that Adrian has written
to traverse the Java class libraries and output a default taming
file for every Java API, where the default is to deny/suppress
everything.  This provides a starting point, and then one can make
taming decisions by editing the auto-generated file to allow
methods that have been analyzed and determined to be safe.

For another example, see safej/java/lang/String.safej.  Hopefully
you'll be able to puzzle out what the syntax means.  Sorry for the
shortage of documentation or tool support at the moment.

_______________________________________________
e-lang mailing list
e-lang@...
http://www.eros-os.org/mailman/listinfo/e-lang

_______________________________________________
e-lang mailing list
e-lang@...
http://www.eros-os.org/mailman/listinfo/e-lang