Community
Participate
Working Groups
Build 20040506 After addressing bug 61882, we forced to fault-in type hierarchies of all types for which members are further accessed. Thus we match javac behavior, and our expectation when doing reference recording for incremental builds. Question: why does the reference recording need to trigger resolution at all ? It should only collect information about the types which already got resolved during name resolution. It would be up to the name resolution to trigger the proper initializations. I suspect the faulting-in during reference recording is unnecessary and simply add unnecessarily to the build state. Fix for bug 61882 addresses short term behavior, and compliance to other tools, but we should clarify whether: 1- accesses to members should really force to fault-in hierarchies (suspecting this is just an artifact from javac implementation, and not mandated by the spec). 2- we really need the extra information about unresolved supertypes amongst dependencies (providing we disable the faulting-in behavior of (1)).
Once addressed, should add regression tests along the line of: NegativeTest#test424-426.
Got confirmation from spec lead that indeed specs do not mandate this behavior, and that we can freely implement smarter (lazy) behavior. "You are correct - there is no specification for this. The JLS assumes the entire program exists, and it is up to implementations to figure out what compilation units they need and when. So you are free to implement the smarter behavior, as you suggest."
Removing the faulting in of hierarchies addresses bug 36397. I cannot come up with a case when we need to do it. We record dependencies as we walk hierarchies looking for receiver types, etc.
424 & 425 now compile without errors but 426 still walks the hierarchy so it continues to fail.
Needed to rework findExactMethod since it did its own hierarchy walk. Added DependencyTests to test out changes.
Added DependencyTests to test out changes.
Verified for 3.1 M2 with build I200409230010.
