-
Enhancement
-
Resolution: Fixed
-
P2
-
1.4.1, 5.0
-
tiger
-
generic, sparc
-
generic, solaris_9
Name: jb33418 Date: 02/11/2002
Within the Java platform there has been a growing trend towards marking fields,
or methods, or classes as having particular characteristics that indicate they
should be processed in special ways by development tools, or deployment tools,
or run-time libraries.
For example, the JavaBeans architecture introduced various stylistic naming
patterns (such as getFoo/setFoo method names) that could be used to indicate
that particular methods were used for accessing properties, for registering
event handlers, etc. Similarly the Enterprise JavaBeans architecture introduced
various stylistic patterns that allow methods to be marked as remote methods,
home methods, etc. In addition, the EJB architecture defined significant extra
information in its deployment descriptors that is used to provide information
on things like the persistence relationships of fields, or the transaction
properties of methods, etc. Many other areas could benefit from this work,
including component architectures and testing platforms.
In general, the desire to provide various kinds of auxiliary information for
Java elements appears to be growing. While the existing mechanisms have been
adequate for simple uses, they are becoming increasingly awkward for more
complicated uses.
Since there seems to be a recurrent need to be able to provide auxiliary
information on Java language elements, it appears to be appropriate to define
an explicit way of doing this in the Java language, to allow arbitrary
attribute information to be associated with particular
classes/interfaces/methods/fields. We refer to this mechanism as "Java language
metadata".
We believe there are several elements needed as part of this work:
Definition of a Java language extension that allows metadata information to
be supplied for (at least) classes, interfaces, methods, and fields. This
language extension will allow metadata to be recognized by development tools.
It appears likely that it will be useful to allow attribute values to be
associated with given metadata attributes.
The exact syntax will need to be determined by the expert group. There appear
to be a number of possibilities, including (but not limited to!) using a
javadoc tag "@meta" or adding a new Java language keyword "meta".
Definition of a runtime delivery format for metadata and of runtime APIs so
that tools and libraries can access metadata information at deployment time
and at runtime.
Definition of rules for the attribute namespace so as to avoid accidental
collisions over the same attribute name. Details will be determined by the
expert group, but it seems that a mechanism similar to the Java class naming
conventions might be useful.
======================================================================
Within the Java platform there has been a growing trend towards marking fields,
or methods, or classes as having particular characteristics that indicate they
should be processed in special ways by development tools, or deployment tools,
or run-time libraries.
For example, the JavaBeans architecture introduced various stylistic naming
patterns (such as getFoo/setFoo method names) that could be used to indicate
that particular methods were used for accessing properties, for registering
event handlers, etc. Similarly the Enterprise JavaBeans architecture introduced
various stylistic patterns that allow methods to be marked as remote methods,
home methods, etc. In addition, the EJB architecture defined significant extra
information in its deployment descriptors that is used to provide information
on things like the persistence relationships of fields, or the transaction
properties of methods, etc. Many other areas could benefit from this work,
including component architectures and testing platforms.
In general, the desire to provide various kinds of auxiliary information for
Java elements appears to be growing. While the existing mechanisms have been
adequate for simple uses, they are becoming increasingly awkward for more
complicated uses.
Since there seems to be a recurrent need to be able to provide auxiliary
information on Java language elements, it appears to be appropriate to define
an explicit way of doing this in the Java language, to allow arbitrary
attribute information to be associated with particular
classes/interfaces/methods/fields. We refer to this mechanism as "Java language
metadata".
We believe there are several elements needed as part of this work:
Definition of a Java language extension that allows metadata information to
be supplied for (at least) classes, interfaces, methods, and fields. This
language extension will allow metadata to be recognized by development tools.
It appears likely that it will be useful to allow attribute values to be
associated with given metadata attributes.
The exact syntax will need to be determined by the expert group. There appear
to be a number of possibilities, including (but not limited to!) using a
javadoc tag "@meta" or adding a new Java language keyword "meta".
Definition of a runtime delivery format for metadata and of runtime APIs so
that tools and libraries can access metadata information at deployment time
and at runtime.
Definition of rules for the attribute namespace so as to avoid accidental
collisions over the same attribute name. Details will be determined by the
expert group, but it seems that a mechanism similar to the Java class naming
conventions might be useful.
======================================================================
- duplicates
-
JDK-4636468 Java Language Metadata (Annotation)
- Closed
-
JDK-4777110 propose @realizes javadoc tag
- Closed
- relates to
-
JDK-4904495 Doclet API: support for annotations and annotation types
- Resolved
-
JDK-4906358 (reflect) Extend reflection libraries to support generics, enums, and varargs
- Closed
-
JDK-4905985 Standard doclet needs to handle metadata (annotation)
- Resolved
-
JDK-4906359 (reflect) Extend reflection libraries to support annotations
- Resolved
(1 relates to)