[
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