Bug 127213 - Flags class missing methods
Summary: Flags class missing methods
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.1.1   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: 3.2 M5   Edit
Assignee: Jerome Lanneluc CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-02-09 22:25 EST by Ian Harrison CLA
Modified: 2006-02-14 12:44 EST (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ian Harrison CLA 2006-02-09 22:25:55 EST
While using the Flags class I have observed that there are variables AccDefault and AccSuper but there are no corresponding isDefault() or isSuper() methods.

This may be desired, but I know I have wanted to use both methods during plug-in development.

API:
http://help.eclipse.org/help21/index.jsp?topic=/org.eclipse.jdt.doc.isv/reference/api/org/eclipse/jdt/core/Flags.html
Comment 1 Ian Harrison CLA 2006-02-09 23:27:31 EST
On further examination I may have found a much deeper problem.  Several flags seem to have duplicate values.  Some of these may be duplicate values, but I am unable to determine whether a method is synchronized or is merely inherited on the ground that they are both represented by setting the 6th bit to 1.

The pigeon hole principle states that it should be possible to fit 20 flags into a 32 bit number (the java int being 4 bytes = 32 bits)

Am I missing something or is this the inteded use.

The following test yields this:

System.out.println(Flags.AccDefault);		//0
System.out.println(Flags.AccPublic);		//1
System.out.println(Flags.AccPrivate);		//2
System.out.println(Flags.AccProtected);		//4
System.out.println(Flags.AccStatic);		//8
System.out.println(Flags.AccFinal);		//16
System.out.println(Flags.AccSuper);		//32
System.out.println(Flags.AccSynchronized);	//32
System.out.println(Flags.AccBridge);		//64
System.out.println(Flags.AccVolatile);		//64
System.out.println(Flags.AccTransient);		//128
System.out.println(Flags.AccVarargs);		//128
System.out.println(Flags.AccNative);		//256
System.out.println(Flags.AccInterface);		//512
System.out.println(Flags.AccAbstract);		//1024
System.out.println(Flags.AccStrictfp);		//2048
System.out.println(Flags.AccSynthetic);		//4096
System.out.println(Flags.AccAnnotation);	//8192
System.out.println(Flags.AccEnum);		//16384
System.out.println(Flags.AccDeprecated);	//1048576

Flags.AccSuper duplicates Flags.AccSynchronized
Flags.AccBridge duplicates Flags.AccVolatile
Flags.AccTransient duplicates Flags.AccVarargs
Comment 2 Philipe Mulet CLA 2006-02-10 10:57:37 EST
These values are coming from the VM spec and are mandatory.
There are indeed cases where the values overlap, but in reality there is no ambiguity, as the 2 flags are not used by the same constructs.
e.g. AccSuper can only affect types, AccSynchronized can only affect fields/methods

AccTransient -> field
AccBridge    -> method

AccVolatile  -> field
AccVarargs   -> method
Comment 3 Olivier Thomann CLA 2006-02-10 21:22:49 EST
Philippe,

What do you expect from me for M5? I have limited time till next week.
Comment 4 Philipe Mulet CLA 2006-02-13 04:23:36 EST
I think #isDefault() and #isSuper() is all asked for consistency purpose.
Comment 5 Philipe Mulet CLA 2006-02-13 04:24:17 EST
Reassigning given Olivier is away.
Comment 6 Jerome Lanneluc CLA 2006-02-14 05:10:30 EST
Added Flags#isDefault(int) and isSuper(int).
Added tests CompilationUnitTests#testDefaultFlag1/2 and testSuperFlag1/2
Comment 7 Jerome Lanneluc CLA 2006-02-14 07:07:30 EST
Actually isDefault(int) is not very useful in the presence of the @deprecated flag. What is really needed is isPackageDefault(int) to find out if no visibility flags has been set.

Renamed Flags#isDefault(int) to isPackageDefault(int) and tests CompilationUnitTests#testDefaultFlag to testPackageDefaultFlag1/4
Comment 8 Frederic Fusier CLA 2006-02-14 12:44:19 EST
Verified for 3.2 M5 using build I20060214-0010.