Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jdt-debug-dev] requesting input re: Java model changes for 1.5

The debugger is not a heavy user of these interfaces - I imagine the 
refactoring code will be more affected?

However, from a debug point of view, option (2) would make sense (treat 
the new types as specializations of classes and interfaces). For example, 
when it comes to setting breakpoints, only classes are (currently) 
supported. Our could might continue to work if an enum type was treated as 
a class - we would attempt to set breakpoints in enum types, and not allow 
breakpoints to be set in annotation types.

The Java debugger also exposes some type information in its API - 
IJavaReferenceType, IJavaClassType, and IJavaInterfaceType. So, it looks 
like we may need to make a similar decision (unless we can represent an 
enum type sufficiently with an IJavaClassType). Which ever direction the 
Java model takes, should be followed in the Java debugger.

Darin




Jim des Rivieres/Ottawa/IBM@IBMCA 
Sent by: jdt-debug-dev-admin@xxxxxxxxxxx
03/03/2004 02:58 PM
Please respond to
jdt-debug-dev


To
jdt-ui-dev@xxxxxxxxxxx, jdt-debug-dev@xxxxxxxxxxx
cc
Philippe P Mulet <philippe_mulet@xxxxxxxxxx>
Subject
[jdt-debug-dev] requesting input re: Java model changes for 1.5






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

_______________________________________________
jdt-debug-dev mailing list
jdt-debug-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/jdt-debug-dev




Back to the top