Joe-E 2.0 Release

Tyler Close writes:
>> Tyler Close writes:
>>  >Also, rather than have separate safej files, I recommend there just be
>>  >a Policy.java file in the Joe-E distribution that contains all the
>>  >Java taming decisions. If people want to add more taming decisions,
>>  >they edit the Policy.java file.
>>
>>  Interesting.  Can you say more about why?
>>
>>  I had thought that safej files were a better way of manually
>>  specifying taming decisions, for several reasons: (a) They provide
>>  a facility for recording comments about the reasons behind taming
>>  decisions; (b) They can be consistency-checked (e.g., if you suppress
>>  a method in class C it must be suppressed in all superclasses of C;
>>  we can build tools to check this); (c) They are human-readable.
>
>And none of the above can be true of Java code?

Okay, you're right.

Here are some of the lesser considerations I can see:

Right now, the .safej -> Policy.java transformation loses
information: it discards comments.  That could presumably be
addressed.

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.

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.

.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.

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.

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?

>>  In contrast, the idea was that Policy.java would be a compiled
>>  version of the safej files, for faster enforcement of the taming
>>  policy specified in safej files.
>>
>>  What do you think?  What makes you suggest that the way to extend
>>  the taming policy is by editing the Policy.java file?  Does it have
>>  some advantages that I've overlooked?  (Simplicity?)
>
>Generating Java code based on safej files creates a requirement for
>the developer to be using the Joe-E verifier. I must be able to ship
>code that developers can use even if they don't run the Joe-E
>verifier. In designing Joe-E, a major requirement was that it was just
>a subset of Java, and did not require code transformation. The current
>taming design defeats that work by requiring code generation. I want
>something that runs out-of-the-box. The current Joe-E distribution
>does not.

Ahh, I see.  Okay, that's a big deal.  What do you think of the
latest proposal I just posted?  With that proposal, Joe-E programmers
who don't want to modify the taming database won't need to run the
Joe-E verifier, so for those programmers, it's a subset of Java and
does not require any kind of transformation or code generation.

Programmers who do want to modify the taming database will need to
run our tool that compiles .safej files -> Policy.java.  This does
involve code generation.  (It might be possible to make that tool be
a standalone utility, if that would make a difference.)  Does this
seem like a problem?

Thanks for all your feedback and for keeping us honest on these issues.
I'm interested to hear what you think about this.