2 Replies Latest reply: Aug 5, 2008 1:34 AM by 843793 RSS

    Round particulars question.

      This is a general question concerning classes that contain unresolved references in methods or fields in any particular round and how Element or Type instances should be treated on subsequent rounds.

      If you have a set of source files, where some subset references classes generated by some other subset as a super class. Round 1's version of a type-element resolves the super class to <any>, but round 2's version resolves to the generated class. If you want your processor to examine the ancestry of a referring class, you basically have to defer examination of the element types to round 2's version of the type element.

      My question is does the same condition hold for a class's type element where it's contents may have unresolved references? Basically if a method of a class on round 1, returns or has a unresolved type on round1, then the elements representing the method remain invalid unless you find round2's version of the type element. I suspect it is, but this leads to a question or feature request: It would be rather handy if there was a method call available to the processor that would indicate if a particular element's version has changed from round to round. The motivation for this is that classes of interest to my processor are typically discovered in round1, but proccessing them need to be deferred. This means I need to test if a class has any incomplete references, then perform book keeping to track them.

      It seems like the individual programmer would have to grovel quite deeply into the network of references in order to determine if a type-element is 'complete'. It would be handy to have a call that would answer the above question or if 'round-version stamp' where available from elements and the processor environment. Kick me if it's there already or if I'm pursuing a red-herring.
        • 1. Re: Round particulars question.
          At least in the javac implementation of JSR 269, objects from a round are not valid after the round ends. Objects modeling changed types should be re-queried to get up to date information; this is admittedly an awkward correctness constraint. The issue is noted in Sun bug:

          6191665 JSR 269 could throw IllegalStateException for use of declarations from prior rounds
          • 2. Re: Round particulars question.
            Hm. Well, what I am finding then is that certain questions about the completeness of any particular type references could be supplied by the processor or type/element classes, because for my particular case, my problem is that I really need to only handle classes that have all their references resolved to known types and defer processing of incomplete classes to subsequent rounds where references have had a chance to be resolved. There's no handy query (that I know of) that answers that particular question. It also would be helpful if there where some mechanism in the processor to tell it to hand back a "refreshed" set of classes or methods one is interested in.

            Now I am rather curious if it is required or just very useful to (seemingly) chuck out everything parsed in the previous round.