Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 95349

Summary: Access rule pattern matching should ignore file extension
Product: [Eclipse Project] JDT Reporter: Jerome Lanneluc <jerome_lanneluc>
Component: CoreAssignee: Jerome Lanneluc <jerome_lanneluc>
Status: CLOSED FIXED QA Contact:
Severity: normal    
Priority: P3 CC: dirk_baeumer, jeem, martinae, maxime_daniel, philippe_mulet
Version: 3.1   
Target Milestone: 3.1 RC2   
Hardware: PC   
OS: Windows XP   
Whiteboard:

Description Jerome Lanneluc CLA 2005-05-16 09:16:44 EDT 
I20050513-1415

If a user specifies an access rule that includes a file extension (e.g.
"foo/X.class" is NON ACCESSIBLE), the Java builder will match this rule with the
corresponding .class file, but the reconciler will match it with a .java file
and thus will consider that foo/X.java is accessible. Simetricaly, .java
extensions will be ignored by the Java builder, and considered by the reconciler.

The only way for a user to have a portable access rule, is to have a .*
extension (e.g. foo/X.*).

We should change it to not have extension in access rules. The user would
specify "foo/X" is NON ACCESSIBLE instead.
Comment 1 Philipe Mulet CLA 2005-05-16 09:38:22 EDT 
Indeed current spec is error prone. Also classpath validation or access rule
should capture this scenario.
Comment 2 Martin Aeschlimann CLA 2005-05-17 03:17:33 EDT 
If possible, we should have the pattern match against the qualified type name,
not the file name. E.g.
to discourrage the inner type java.util.Map.Entry you currently have to know
that the compiler creates a file Map$Entry.class. We usually keep such names
away from the user. In source one deals with names like Map.Entry.
If this isn't too much of an effort, this would make the feature easier to
understand. The description in the UI are currently quite tricky as they have to
avoid saying that you're discourraging types and packages, as the correct
description is to discourrage folders and files.
Comment 3 Philipe Mulet CLA 2005-05-17 04:57:36 EDT 
Why would you discourage using a member type only ? I mean in real life...

We could currently only support main type (or file name with no extension), and
could evolve into true type granularity in the future, however this would
require extensive rework on our end (i.e. post 3.1).
BTW, I could argue that I never want to see secondary types of some discouraged
main type name, and given these are implementation details, I don't want to need
to list them all.
Comment 4 Jerome Lanneluc CLA 2005-05-31 08:46:23 EDT 
*** Bug 97446 has been marked as a duplicate of this bug. ***
Comment 5 Philipe Mulet CLA 2005-06-01 04:58:51 EDT 
+1 for RC2
Comment 6 Jerome Lanneluc CLA 2005-06-01 05:06:04 EDT 
Clarified spec on IAccessRule to say that the file extension is ignored.
Changed references to AccessRuleSet#getViolatedRestriction(...) to pass in a
file name without extension.
Updated tests BatchCompilerTests and ReconcilerTests to reflect this new behavior.
Comment 7 Dirk Baeumer CLA 2005-06-01 05:16:38 EDT 
Martin, does this affect UI ?
Comment 8 Martin Aeschlimann CLA 2005-06-01 05:30:11 EDT 
I think we are fine. The messages were kept unspecific regarding to file extensions.
Comment 9 Maxime Daniel CLA 2005-06-07 11:00:51 EDT 
Verified for 3.1 RC2 using build N20050607-0010 +JDT/Core HEAD.
Comment 10 Frederic Fusier CLA 2005-06-10 06:26:04 EDT 
Verified for 3.1 RC2 using build I20050610-0010