[jdt-debug-dev] requesting input re: Java model changes for 1.5

[Jim des Rivieres <Jim_des_Rivieres@xxxxxxxxxx>]

We'd like your input on an issue above how to evolve the Java model APIs 
for dealing with 1.5 features.

As you probably know, in JDK 1.5, there are 2 new kinds of type 
declarations: enums, and annotation types.
Enum declarations are for defining enumeration classes. They look like

        public enum Color {RED, GREEN, BLUE};

Annotation type declarations are for defining annotation types, which are 
used in annotations. They looks like:

        public @interface JLSRef {
                public int edition();
                public float section();
        }

Both enum and annotation type declarations can be more complex than the 
examples show; for example, the
body declarations for enums can include constructor, method, and regular 
field declarations.  Enum declarations are like class declarations with 
minor syntactic changes ("enum" instead of "class") and some restrictions 
(no superclass can be specified; restricted body declarations). Annotation 
type declarations like are interface declarations with minor syntactic 
changes ("@" before "interface") and some restrictions (no superclass or 
superinterfaces can be specified; restricted body declarations).

The question is what is the most effective way to evolve the Java model 
API to deal with these newcomers. In the Java model API, IType is used to 
represent types. There are a pair of mutually exclusive predicates, 
IType.isClass() and IType.isInterface(), for distinguising classes from 
interfaces. Compatibility considerations dictate that enum and annotation 
types will also be represented by instances of IType.

However, there is a choice in how we add new predicates IType.isEnum() and 
IType.isAnnotation() alongside the existing ones.

Option 1: Make all 4 predicates mutually exclusive.

Under this option:
class X {}   // isClass; !isInterface; !isEnum; !isAnnotation
interface X {}   // !isClass; isInterface; !isEnum; !isAnnotation
enum X {}   // !isClass; !isInterface; isEnum; !isAnnotation
@interface X {}   // !isClass; !isInterface; !isEnum; isAnnotation

Option 2: Make isEnum() a subpartition of isClass(), and isAnnotation() a 
subpartition of isInterface()

class X {}   // isClass; !isInterface; !isEnum; !isAnnotation
interface X {}   // !isClass; isInterface; !isEnum; !isAnnotation
enum X {}   // isClass; !isInterface; isEnum; !isAnnotation
@interface X {}   // !isClass; isInterface; !isEnum; isAnnotation

Both approaches have their pluses and minuses.

Option 1 means that existing client code will not inadvertently deal with 
the new constructs. But it may cause problems because enums and annotation 
types do not fit either of the existing categories and may leave code 
stumped as to what to do with something that is neither a class nor an 
interface.

Option 2 means that existing clients will automatically treat enum 
declarations as if they were class declarations, and annotation types as 
if they were interface declarations. This is both good and bad. Good, in 
that existing code will think that it's working; bad, because the existing 
code will likely run roughshod over the differences and restrictions.

We'd like to hear from Java model clients about the desirablility in 
practice of one option over the other.

Thanks,
jim & philippe