[e-lang] Joe-E 2.0 Release

[Adrian Mettler]

David and I discussed the package annotation and agreed that it sounds 
like a very good solution for this problem.  Thank you for taking the 
time to come up with it!  With this in place, org.joe_e.taming.Policy 
would only need to be updated if taming decisions for legacy libraries 
change.  For a waterken or plug-in application, the policy in use would 
be determined by the hosting framework.  For a standalone application, 
the developer could either use the canonical org.joe_e.taming.Policy 
file that we will provide, or they could construct it from a custom set 
of safej specifications.

For Joe-E code, the verifier can use the @verified annotation to 
determine what packages to verify.  This will allow the specification of 
which packages in a project are Joe-E code to be persisted when the 
project is exported (the persistent properties that I am currently using 
for this purpose are not, which is less than ideal)  The drop-down 
toggle that enables and disables verification can instead turn on and 
off the annotation.

A per-project option (off by default) will enable the auto-generation of 
a Policy file (based only on safej files; it will no longer need to 
include any Joe-E code).  Someone using the "canonical" set of taming 
decisions won't have to use this feature, as they can just use the 
standard Policy.java.

The verifier will no longer need to generate safej files for verified 
code.  This also means that you will no longer be able to get template 
safej by pretending that non-Joe-E code is Joe-E.  If you have the 
source, there's some code you can uncomment that builds template safej 
files for a specified package; at some point I'd like to make this 
functionality available from the UI, but the other changes above are 
much higher priority.

Please let me know if these plans won't work well for you.

Thanks,
-Adrian

Tyler Close wrote:
> On Sat, Mar 8, 2008 at 6:10 PM, David Wagner <daw at cs.berkeley.edu> wrote:
>> Tyler Close writes:
>>  >I've got an alternate proposal for marking Joe-E code.
>>  >
>>  >Java supports package annotations that are available at both compile
>>  >time and runtime. I suggest Joe-E define an annotation
>>  >org.joe_e.verified. To enable Joe-E verification of a package, the
>>  >programmer adds the standard package-info.java file with content:
>>  >
>>  >@org.joe_e.verified package org.example.stuff;
>>  >
>>  >The Policy class can then check that a reflected member is either
>>  >defined in a Joe-E verified package, or is enabled in the safej
>>  >database. The safej database then doesn't need to contain any
>>  >information about Joe-E verified code, only tamed Java code.
>>
>>  Interesting.  Thanks for the concrete proposal.  This sounds worth
>>  mulling over.
> 
> It looks like the Joe-E library can be updated to use this proposal by
> simply adding the last 3 lines below to
> org.joe_e.reflect.Reflection#safe():
> 
>     static private boolean safe(final Member member) {
>         final Class declarer = member.getDeclaringClass();
>         if (declarer.getPackage().isAnnotationPresent(verified.class)) {
>             return true;
>         }
>          ...
> 
> --Tyler
> _______________________________________________
> e-lang mailing list
> e-lang at mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/e-lang