JSR-305 plans
Bill Pugh
working on getting lots of things ready for JavaOne.
At the moment, my thoughts are as follows.
I think we have a rough sketch of what we might do for JSR-305, and
some real
practical experience is needed to move the JSR further down the road.
So my thoughts are to get a implementation of the JSR-305 strawman
proposal we've been
discussing done over the summer, as well as the application of
JSR-305 annotation
to some major open source software.
Now, the fact that I'm planning to prepare a rough draft
implementation of
a JSR-305 doesn't mean I plan to lock into any of the of the design
decisions
in that strawman. It won't be shipped with FindBugs, and I'll
discourage anyone
from starting to apply the annotations defined in the strawman, since
I expect
them to change.
And I'm hoping that SureLogic and Brian Goetz will move the
concurrency annotations
down the court, since I don't think we really have enough experience
with the JCIP
annotations yet.
The strawman proposal is sort of scattered here and there, but I hope
to write
it up by the end of May, and will of course accept any feedback on
refining the
strawman. But is just a strawman, and we don't need complete
agreement on the
strawman proposal.
Of course, anyone else if welcome to implement their own strawman
proposal and we can
have a bake-off.
Bill
Brian Goetz
> concurrency annotations
> down the court, since I don't think we really have enough experience
> with the JCIP
> annotations yet.
I'll put it on my list to do a pass on something like java.util with the
JCiP annotations and see how it goes.
I suspect I'm going to want @Factory for that.
Dan Kogan
to the retention policy
question. Did we have a closure on that subject?
Dan
Bill Pugh
On May 4, 2007, at 6:08 AM, Dan Kogan wrote:
>
> Bill, I was searching the discussions and could not find the
> resolution
> to the retention policy
> question. Did we have a closure on that subject?
>
> Dan
Not really, let's try to bring that one home.
OK, so two points about runtime-retention for JSR-305 annotations:
* JSR-305 annotations will likely be more prevalent than any other
annotations. So if the overhead of runtime retention is a concern for
any annotation, it should be a concern for JSR-305 annotations.
* However, the additional overhead of runtime retention, over that of
classfile retention, is really, really low. The reports we have are
that unless you reflectively query the annotations of a class, there
is no overhead for runtime retention annotations. However, if you
query any runtime annotations for a class, all annotations with
runtime retention for that class get materialized. But even then, it
is only a one-time overhead for the class, not a per instance overhead.
So, what do we do?
In order to allow for future innovation, I'd like to go for runtime
retention in the strawman, and then do some experiments with the cost
of that on an annotated JDK. If the cost is high in some cases, then
people can make an argument for going with only classfile retention.
Bill
Bill Pugh
On May 4, 2007, at 6:08 AM, Dan Kogan wrote:
>
> Bill, I was searching the discussions and could not find the
> resolution
> to the retention policy
> question. Did we have a closure on that subject?
>
> Dan
Not really, let's try to bring that one home.
Tom Ball
since there isn't a substantial known cost, but verify that assertion
before making anything final. Thanks, Bill, for summing this up so
well.
Dan Kogan
+1
Dan
David Morgenthaler
David