On a given classpath entry, the access rules are considered in the order given when the entry was created. When a source or class file matches an access rule's pattern, the access rule's kind define whether the file is considered accessible, non accessible, or its access is discouraged. If the source or class file doesn't match any accessible rule, it is considered accessible. A source or class file that is not accessible or discouraged can still be refered to but it is tagged as being not accessible - the Java builder will create a problem marker for example. The severity of the marker created from a non accessible rule is controled through the {@link JavaCore#COMPILER_PB_FORBIDDEN_REFERENCE} compiler option.The severity of the marker created from a discouraged rule is controled through the {@link JavaCore#COMPILER_PB_DISCOURAGED_REFERENCE} compiler option.Note this is different from inclusion and exclusion patterns on source classpath entries, where a source file that is excluded is not even compiled. Files patterns look like relative file paths with wildcards and are interpreted relative to each entry's path. File patterns are case-sensitive and they can contain '**', '*' or '?' wildcards (see {@link IClasspathEntry#getExclusionPatterns()} for the full descriptionof their syntax and semantics). Note that file patterns must not include the file extension. com/xyz/tests/MyClass is a valid file pattern, whereas com/xyz/tests/MyClass.class is not valid.
For example, if one of the entry path is /Project/someLib.jar, there are no accessible rules, and there is one non accessible rule whith pattern com/xyz/tests/**, then class files like /Project/someLib.jar/com/xyz/Foo.class and /Project/someLib.jar/com/xyz/utils/Bar.class would be accessible, whereas /Project/someLib.jar/com/xyz/tests/T1.class and /Project/someLib.jar/com/xyz/tests/quick/T2.class would not be accessible.
This interface is not intended to be implemented by clients.
@since 3.1 | |