Aleksey Shipilev wrote:
Thanks for attention to this topic, guys! That's the point on which JIT and Classlib code interact together: Classlib can provide the hints how to compile it, JIT can favor such hints. While we shipping Harmony JRE I think it makes sense to provide such the hints across the components. Whether or not some other JIT will favor these annotation is completely relies on "that-other-JIT" developers, and we don't really care because it does not break functionality.
Agreed.
Let's emphasize that one more time - @NoBoundCheck is unsafe and should be used in trusted code only, there is a clear security breach if such the annotation work for user code. We can imagine a load of other annotations that can't be exposed to user. On the other hand I really doubt that any user code will add the dependency upon internal Harmony annotation for it's own code, e.g. org.apache.harmony.luni.annotations.Inline (ok, I wouldn't do that being Java developer). Should we care about user code and support @Inline pragma originating from any package user wants?
I wouldn't prevent people from adding @Inline to their application methods if they choose to do so. But I would prevent @NoBoundsCheck of course for any classes not loaded by the bootstrap class loader.
Regards, Tim
