One immediate follow-up ...
On 26/10/2017 2:03 PM, John Rose wrote:
On Oct 25, 2017, at 8:54 PM, David Holmes <david.hol...@oracle.com> wrote:
On 26/10/2017 1:11 PM, John Rose wrote:
On Oct 25, 2017, at 8:07 PM, John Rose <john.r.r...@oracle.com> wrote:
On Oct 25, 2017, at 3:33 PM, Remi Forax <fo...@univ-mlv.fr
<mailto:fo...@univ-mlv.fr>> wrote:
getClasses() throws an exception but getAnnotations() skips unavailable
annotations.
that said, i'm not against throwing in this case.
I'm not against throwing either, but I think scrubbing (like annotations)
is a little better, because it is more robust about retaining partial results.
Aren't annotations a different situation because annotations are well known to
potentially not be available at runtime? A missing annotation does not
necessarily reflect an error in the runtime environment of an application. Also
AFAIK see from the jdk/java/lang/annotation/Missing/ test the throw/no-throw
behaviour depends on exactly how the missing annotation is used.
I think the most likely cause of a missing nestmate will be JAR minimization.
As long as the nest-host isn't deleted, a dropped nestmate is of no concern,
in that scenario.
This is obviously different from annotations, but is enough like them to
make me think favorably on the scrubbing of lists. Drop an annotation,
drop a nestmate; both seem to benefit from a fail-over tactic that ignores
the dropped thing, when asking about neighboring things.
Partial results are important if you are just asking about one or two
classes and don't care about their other nestmates.
How do you know to only ask about "one or two classes"? Sorry I'm not
understanding the potential usecase here.If you've already identified specific classes of
interest then you can call getNestHost on them.
I'm thinking about code that emulates hasNestMateAccess by
scanning the getNestMembers list. Perhaps if we have a correctly
functioning hasNestMateAccess, my concern goes away.
And even if H.getNestMembers() throws because of some missing N1,
we have to be careful to allow N2.getNestHost() to return H, if we can
validate that N2 points to H and vice versa. We don't want the validated
relation between N2 and H to be collateral damage to a failure of N1.
Absolutely not. The two queries would be completely unrelated in that regard.
Yep, good.
(If H goes missing there is nothing we can do with N1 and N2, except
to assign each to its own 1-nest. Which is OK with me.)
Then presumably we should do the same at the VM level instead of allowing
resolution related exceptions to propagate as currently proposed? We could just
throw IAE as we do if a nest-host validation check fails. Though a case can
still be made to allow VME's to pass through.
Please don't throw IAE that case. I don't want to bikeshed exception types,
but I think we have a strong precedent for using ICCE when encountering
a questionable classfile configuration (one that shouldn't have come out of
javac). Note also the ICCE <: VME, so it just gets passed through.
You must have missed Dan's update regarding access checks. He's already
proposed to throw IAE - and I've implemented it. :)
http://cr.openjdk.java.net/~dlsmith/nestmates.html
David
------
Though I still feel uncomfortable lying about the nest-host. I don't see what
usecases would be served by doing that. Other than informational uses, I can't
see a reason to actually identify the nest-host which would not be impacted by
lying about that identity. The only truly useful query is for nestmate access
and that doesn't need to expose the identity of the nest-host and
conservatively rejects access if anything goes wrong.
I'm sympathetic to this, but that implies that getNestHost should return null
rather than this for a non-nesty class. I think it's more valuable that
getNestHost
return 'this' for non-nesty classes, and therefore also for broken-nest classes.
Bottom line for my personal preferences:
- hasNestMateAccess: never throws, always returns true or false
Yes!
- getNestHost(): throw if the host isn't there or else a membership validation
check fails
See above.
- getNestMembers(): throw if any nest member isn't there or a membership
validation check fails
As I said before, I don't mind this choice. Especially if we have
hasNestMateAccess.
Cheers,
David
