Re: Joe-E 2.0 Release
Adrian Mettler <[email protected]>
| Newsgroups | gmane.comp.lang.e.general |
|---|---|
| Message-ID | <[email protected]> |
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 <[email protected]> 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 > [email protected] > http://www.eros-os.org/mailman/listinfo/e-lang