Community
Participate
Working Groups
Source based, v_835. On the documentation front: - this refers to JLS2, which is dated; - this is talking about public, private etc. as flags, whereas the language spec calls them modifiers; - the notion of 'standard string representation' is somewhat odd since the same doc must confess that the ordering of modifiers, while inspired from the JLS, is a design choice (it is compatible with the spec, but the spec does not prescribe a fixed order). On the design front, the need for the API client to modify the flags when they come from a method is clumsy. There might be better solutions, but passing an extra parameter that tells which type of element the flags come from and reacting to it would be an obvious first step.
org.eclipse.jdt.core.dom.AST#newModifiers(int) also defines a modifiers sequence, but the description is also referring to JLS2, and it chose a different ordering. I have not checked which ordering makes more sense, but I guess jdt.ui mostly relies on AST#newModifiers(int) and doesn't care too much about Flags#toString(int).
The correct order according to JLS7 8.1.1, 8.3.1,8.4.1, 8.4.3, 8.8.3, 9.1.1, 9.3, 9.4 is: public protected private abstract static final synchronized native strictfp transient volatile The only room for discussion is the position of "transient volatile". These modifiers can be inserted anywhere after "final", but they must keep their relative order. Note that in chapter 18 of JLS7, the summarizing "Modifier:" production uses a wrong order. The proposed lambda spec puts "default" here: ... abstract default static ... For JLS7, AST#newModifiers(int) was already correct. Fixed the insertion point of "default" and adjusted Flags#toString(int): http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=e6029c8b1adfe1296ee554ed42f00e5a663cecbf
