Bug 127213

Summary:	Flags class missing methods
Product:	[Eclipse Project] JDT	Reporter:	Ian Harrison <irharris>
Component:	Core	Assignee:	Jerome Lanneluc <jerome_lanneluc>
Status:	VERIFIED FIXED	QA Contact:
Severity:	normal
Priority:	P3	CC:	philippe_mulet
Version:	3.1.1
Target Milestone:	3.2 M5
Hardware:	PC
OS:	Windows XP
Whiteboard:

Description Ian Harrison

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

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

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

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

2006-02-13 04:23:36 EST

I think #isDefault() and #isSuper() is all asked for consistency purpose.

Comment 5 Philipe Mulet

2006-02-13 04:24:17 EST

Reassigning given Olivier is away.

Comment 6 Jerome Lanneluc

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

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

2006-02-14 12:44:19 EST

Verified for 3.2 M5 using build I20060214-0010.