On the 0x2DA day of Apache Harmony Mikhail Fursov wrote: > Alexey, > any public method can delegate execution to a private one. The private > methods are not under specs. Using this pattern we will not expose any > implementation specific annotation to end users
OK then, thank you for clarification > On 5/18/07, Alexey Varlamov <[EMAIL PROTECTED]> wrote: > > > > 2007/5/18, Mikhail Fursov <[EMAIL PROTECTED]>: > > > On 18 May 2007 00:36:06 -0700, Egor Pasko <[EMAIL PROTECTED]> wrote: > > > > > > > > On the 0x2D9 day of Apache Harmony Mikhail Fursov wrote: > > > > > On 5/18/07, Alexey Varlamov <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > As long as annotations are not a part of specifications, and magic > > > > > > impls are general enough to not depend on runtime configuration > > > > > > (particular VM components etc), this approach looks neat. > > > > > > Another issue with using arbitrary magics is potential risk of > > > > > > security breaches; we need to think how to control & restrict > > origin > > > > > > of magic codes - like allowing only predefined bootstrap packages > > a la > > > > > > "org.apache.harmony.security.fortress" or introducing & checking > > > > > > dedicated security permissions. > > > > > > > > > > > > > > > It's good to restrict magics to be used only in bootstrap classes. > > In > > > > this > > > > > case I see no security problems. (?) > > > > > > > > Does The Standard allow extra unspecified annotations in bootstrap > > > > classes? > > > > > > > > > I know that it does not say anything about privates. With help of > > @Inline > > > pragma it's enough. > > > > Egor probably meant annotations on those public methods to be replaced > > by magics - then this is the same question as I meant above saying "As > > long as annotations are not a part of specifications". > > The short answer is: only TCK knows. More detailed answer is: > > 1) Annotations are listed in javadocs and probably should be checked by > > the JCK; > > 2) Extra annotations do not affect compatibility in any way and should > > be allowable from common POV. > > > > > > > > -- > > > Mikhail Fursov > > > > > > > > > -- > Mikhail Fursov -- Egor Pasko
