[e-lang] Joe-E 2.0 Release

[Tyler Close]

On 3/11/08, David Wagner <daw at cs.berkeley.edu> wrote:
> The syntax of .safej files is specialized for recording taming
> decisions, so .safej files will probably be a bit more human-readable
> than Policy.java.  However, with clever enough formatting, a
> Policy.java file could likely be made human-readable enough.

I think the Policy.java file could use almost exactly the same syntax
as the current .safej files. The only difference would be the class()
and static() methods would have to be renamed, since they are reserved
keywords in Java.

> Having a separate .safej file for each Java class makes it a bit easier
> for Joe-E users to customize their taming database without requiring
> CVS-style merges.  If a Joe-E programmer wants to tame a part of the Java
> class library that isn't in our standard taming database, they can just
> add new .safej files corresponding to those classes.  If we release a
> new version of Joe-E that comes out with new taming decisions for some
> yet third portion of the Java class library, integrating that can be
> done easily without any annoying merges.  If users were to edit their
> Policy.java file directly, that would require CVS-style merges, which
> is doable.

Should be a merge without conflicts, unless there are conflicting
taming decisions.

> .safej files are declarative and used for multiple purposes.
> For instance, they record comments about taming decisions.  Those
> comments aren't used at reflection time but are used in generating
> the Joe-E API Docs.  Those could be included in a Policy.java file,
> though the syntax would probably be either a bit uglier for
> humans or a bit less convenient for programs to parse.

See previous comment on syntax.

> Right now we have already built a JoeEDoc program that parses
> .safej files.  We'd have to modify it to parse the Policy.java
> file or load and access the contents of the Policy class.  There's
> no fundamental reason we couldn't do that; just resources.

Loading the Policy class and accessing its contents should be a fairly
minor change.

> None of these are showstoppers or fundamental objections to your
> proposal, so none of these are convincing arguments.
>
>
> Ultimately, I think one of the biggest reasons we built the taming
> infrastructure based on .safej files was: MarkM strongly encouraged
> us to.  Do you think we should re-consider that approach?

Whether you're reconsidering or not is a matter of perspective. Are
you reconsidering if the major change is reusing the Java compiler,
instead of writing your own parser for the same syntax?

--Tyler

-- 
Use web-keys for RESTful access-control:
http://waterken.sourceforge.net/

Name your trusted sites to distinguish them from phishing sites.
https://addons.mozilla.org/firefox/957/