Hi Joel,
On 12/10/2015 12:27 PM, Joel Borggrén-Franck wrote:
Hi Joe,
Inline,
On Thu, 10 Dec 2015 at 02:09 Joseph D. Darcy <joe.da...@oracle.com
<mailto:joe.da...@oracle.com>> wrote:
Hi Joel,
For the specification, it should seem reasonable to me to have the
default implementation of AnnotatedType.getAnnotatedOwnerType() to
return null rather than throwing an UnsupportedOperationException.
I disagree but I think this is a very theoretical point since with a
very high probability there is exactly one implementation and we
control that. Because of that I'm fine with either so I changed it.
Following experience with similar structures in the javax.lang.model
APIs, e.g.
JDK-7015530: Reiterate API specializations in
javax.lang.model.element subinterfaces
http://cr.openjdk.java.net/~darcy/7015530.1/
<http://cr.openjdk.java.net/%7Edarcy/7015530.1/>
I think it is clearer to readers of the specification if
description of
behavior like
// Supertype
/**
* In these subtypes, do this. In these other subtypes, do that.
*/
void foo();
is additionally copied down and specialized into the subtypes, even if
trivial overriden methods are defined whose only purpose is to
serve as
a hook to hang the javadoc.
Sounds reasonable, I coped the supertypes doc and cut out pieces for
unrelated subtypes (like Element/PackageElement for getSimpleName).
Question, is it better to remove the throws clauses for the cases that
return null?
I think so; they aren't applicable in those case and it is fine to
remove exceptions in subtypes of course.
Please also add @Override annotations to the methods in the subtypes as
a check that a new method is not accidentally being declared.
New webrev: http://cr.openjdk.java.net/~jfranck/8057804/webrev.02/
<http://cr.openjdk.java.net/%7Ejfranck/8057804/webrev.02/>
Diff of patch 01 and patch 02 (a diff-diff):
http://cr.openjdk.java.net/~jfranck/8057804/diff_v1-v2.patch
<http://cr.openjdk.java.net/%7Ejfranck/8057804/diff_v1-v2.patch>
Please add an @implSpec note in AnnotatedType saying that "this
implementation returns null", or words to that effect.
Shouldn't some of the implementation overrides in
AnnotatedTypeFactory.java which throw null now be removed? Ah, I see the
BaseImpl type is in the way. Is there an easy way to refactor that?
(I'll take care of the ccc changes once the new spec is finalized.)
Thanks,
-Joe
