[JSR308] Wrapper types

Artemus Harper subanark at gmail.com
Sun Mar 2 01:19:06 EST 2008


A big concern I have is that for annotations that don't put Object at
the base of the hierarchy (like @ReadOnly) break the paradigm that
everything is assignable to Object. Many methods that simply take an
object will be unusable unless retrofitted which may not be possible.

Even simple code like:
@ReadOnly Date d = ...;
System.out.println(d);

Won't work since PrintStream doesn't define a method that takes a
@ReadOnly value. Although anyone can define their own wrapper class
for ReadOnly to get around this problem, you end up having many people
define their own wrapper, and any code that might actually want to
unwrap them must do so in a non-standard way. Although it would be
nice if wrapping and unwrapping happened automatically, it would cause
annotations to change the way the code compiles.

So far as Method.invoke is concerned, I don't think its current form
can allow safe operations while being completely backwards compatible.
At the same time I strongly discourage having any special invoke
method that is particular to any of the annotations currently being
designed. A smart invoke would be needed to handle any kind of special
behavior.

If Method.invoke cannot be locked down to at least untrusted code then
none of the core APIs can assume that the annotations are being
followed at all, similar to the way that Generics are never assumed to
be correct.
-- 
Artemus Harper



More information about the JSR308 mailing list