Community
Participate
Working Groups
20060117 The spec says: * Returns whether the rule should be ignored if a better rule is found. * E.g. if a rule K_NON_ACCESSIBLE | IGNORE_IF_BETTER matches type p.X * and a rule K_DISCOURAGED that also matches p.X is found after the first * one, then p.X will be reported as discouraged. Assume the following typical example of access rules for one entry: com/ibm/** FORBIDDEN, IGNORE_IF_BETTER com/** DISCOURRAGED ** ACCESSIBLE Having ignoreIfBetter defined on com/ibm/** means (according to the spec) that it will be ignored because better a rule com/** can be found that is better. That practically means that com/ibm/** is useless to write; com/** matches for all. What would be a good example where the new bit really has an impact? As I see it it only has when you look at the full picture on how a type is found in a classpath. There a type is searched in many classpath entries, were each has rules defined. So the real use case would be, search in the next _entry_ (not rule!) for better accessibility. And as far as I understood, it is not about finding a different accessibility, but about finding a type with the same name, and then this accessibility is chosen. So, in summary I think the spec is wrong. I also think that the bit doesn't really belong to the rule. It's not about ignoring a rule, but ignoring a type in a entry. If it's about ignoring a type, better introduce a separate 'HIDDEN' rule.
Thanks for pointing the API flaw. I will change API to state that the next entry is considered instead of the next rule.
Changed spec to: /** * Returns whether the rule should be ignored if a better rule is found on * another classpath entry. * E.g. if a rule K_NON_ACCESSIBLE | IGNORE_IF_BETTER matches type p.X on * a library entry 'lib1' and a rule K_DISCOURAGED that also matches p.X is * found on library entry 'lib2' - 'lib2' being after 'lib1' on the classpath, * then p.X will be reported as discouraged. * * @return whether the rule should be ignored if a better rule is found on * another classpath entry * @since 3.2 */
I would focus on the type. It's not the rule that is ignored, but the type. When a source or class file matches this access rule's pattern, the type in this classpath entry is ignored if no other type with the same qualified name can be found later in the build path that has a better accessibility.
Ok, that wasn't correct either: When a source or class file matches this access rule's pattern, the type in this classpath entry is ignored iff an type with the same qualified name can be found later in the build path with a better accessibility.
Thanks Martin. Changed spec to: /** * Returns whether a type matching this rule should be ignored iff a type with * the same qualified name can be found on a later classpath entry with a better * accessibility.</p> * <p>E.g. if a type p.X matches a rule K_NON_ACCESSIBLE | IGNORE_IF_BETTER * on a library entry 'lib1' and another type p.X also matches a rule * K_DISCOURAGED on library entry 'lib2' ('lib2' being after 'lib1' on the * classpath), then p.X from 'lib2' will be used and reported as * discouraged.</p> * * @return whether a type matching this rule should be ignored iff a type * with the same qualified name can be found on a later classpath * entry with a better accessibility * @since 3.2 */
Verified for 3.2 M5 using build I20060214-0010.
