Thu, 10 Jun 2010 16:08:01 -0700
6944312: Potential rebranding issues in openjdk/langtools repository sources
Reviewed-by: darcy
duke@1 | 1 | <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN"> |
duke@1 | 2 | <html> |
duke@1 | 3 | <head> |
duke@1 | 4 | <!-- |
duke@1 | 5 | |
ohair@554 | 6 | Copyright (c) 2004, Oracle and/or its affiliates. All rights reserved. |
duke@1 | 7 | DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. |
duke@1 | 8 | |
duke@1 | 9 | This code is free software; you can redistribute it and/or modify it |
duke@1 | 10 | under the terms of the GNU General Public License version 2 only, as |
ohair@554 | 11 | published by the Free Software Foundation. Oracle designates this |
duke@1 | 12 | particular file as subject to the "Classpath" exception as provided |
ohair@554 | 13 | by Oracle in the LICENSE file that accompanied this code. |
duke@1 | 14 | |
duke@1 | 15 | This code is distributed in the hope that it will be useful, but WITHOUT |
duke@1 | 16 | ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or |
duke@1 | 17 | FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License |
duke@1 | 18 | version 2 for more details (a copy is included in the LICENSE file that |
duke@1 | 19 | accompanied this code). |
duke@1 | 20 | |
duke@1 | 21 | You should have received a copy of the GNU General Public License version |
duke@1 | 22 | 2 along with this work; if not, write to the Free Software Foundation, |
duke@1 | 23 | Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. |
duke@1 | 24 | |
ohair@557 | 25 | Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA |
ohair@557 | 26 | or visit www.oracle.com if you need additional information or have any |
ohair@557 | 27 | questions. |
duke@1 | 28 | --> |
duke@1 | 29 | </head> |
duke@1 | 30 | |
duke@1 | 31 | <body bgcolor="white"> |
duke@1 | 32 | |
duke@1 | 33 | The Mirror API is used to model the semantic structure of a program. |
duke@1 | 34 | It provides representations of the entities |
duke@1 | 35 | declared in a program, such as classes, methods, and fields. |
duke@1 | 36 | Constructs below the method level, such as |
duke@1 | 37 | individual statements and expressions, are not represented. |
duke@1 | 38 | |
duke@1 | 39 | <p> Also included is support for writing |
duke@1 | 40 | {@linkplain com.sun.mirror.apt.AnnotationProcessor annotation processors} |
duke@1 | 41 | to examine and process the annotations |
duke@1 | 42 | of program elements. An annotation processor may, as an example, create |
duke@1 | 43 | new source files and XML documents to be used in conjunction with the |
duke@1 | 44 | original code. |
duke@1 | 45 | |
duke@1 | 46 | |
duke@1 | 47 | <h4> Characteristics of the API </h4> |
duke@1 | 48 | |
duke@1 | 49 | A program is represented at the language level, rather than at the |
duke@1 | 50 | level of the virtual machine. Nested classes, for example, are |
duke@1 | 51 | handled as first-class constructs, |
duke@1 | 52 | rather than in the translated form understood by the VM. |
duke@1 | 53 | Both source code and compiled code (class files) may be modeled |
duke@1 | 54 | in this way. |
duke@1 | 55 | |
duke@1 | 56 | <p> Programs are modeled in their static, or build-time, form. |
duke@1 | 57 | This differs from the {@linkplain java.lang.reflect reflection} API, |
duke@1 | 58 | which provides run-time information about classes and objects. |
duke@1 | 59 | |
duke@1 | 60 | <p> The API does not provide direct support for generating new code. |
duke@1 | 61 | |
duke@1 | 62 | |
duke@1 | 63 | <h4> Declarations and Types </h4> |
duke@1 | 64 | |
duke@1 | 65 | The mirror API represents program constructs principally through the |
duke@1 | 66 | {@link com.sun.mirror.declaration.Declaration} interface |
duke@1 | 67 | and its hierarchy of subinterfaces in the package {@link |
duke@1 | 68 | com.sun.mirror.declaration}. A <tt>Declaration</tt> represents a |
duke@1 | 69 | program element such as a package, class, or method. |
duke@1 | 70 | The interface hierarchy is depicted |
duke@1 | 71 | <a href="com/sun/mirror/declaration/package-tree.html"> here</a>. |
duke@1 | 72 | |
duke@1 | 73 | <p> Types are represented by the {@link com.sun.mirror.type.TypeMirror} |
duke@1 | 74 | interface and its hierarchy of subinterfaces in the |
duke@1 | 75 | package {@link com.sun.mirror.type}. Types include primitive types, |
duke@1 | 76 | class and interface types, array types, type variables, and wildcards. |
duke@1 | 77 | The interface hierarchy is depicted |
duke@1 | 78 | <a href="com/sun/mirror/type/package-tree.html"> here</a>. |
duke@1 | 79 | |
duke@1 | 80 | <p> The API makes a clear distinction between declarations and types. |
duke@1 | 81 | This is most significant for generic types, where a single declaration |
duke@1 | 82 | can define an infinite family of types. For example, the declaration of |
duke@1 | 83 | <tt>java.util.Set</tt> defines the raw type <tt>java.util.Set</tt>, |
duke@1 | 84 | the parameterized type {@code java.util.Set<String>}, |
duke@1 | 85 | and much more. Only the declaration can be annotated, for example, |
duke@1 | 86 | and only a type can appear in a method signature. |
duke@1 | 87 | |
duke@1 | 88 | <p> A program being modeled may be incomplete, in that |
duke@1 | 89 | it may depend on an unknown class or interface type. |
duke@1 | 90 | This may be the result of a processing error such as a missing class file, |
duke@1 | 91 | or perhaps the missing type is to be created by an annotation processor. |
duke@1 | 92 | See {@link com.sun.mirror.type.DeclaredType} for information on |
duke@1 | 93 | how such unknown types are handled. |
duke@1 | 94 | |
duke@1 | 95 | |
duke@1 | 96 | <h4> Utilities and Tool Support </h4> |
duke@1 | 97 | |
duke@1 | 98 | The {@link com.sun.mirror.util} package provides |
duke@1 | 99 | utilities to assist in the processing of declarations and types. |
duke@1 | 100 | Included is support for using the visitor design pattern when |
duke@1 | 101 | operating on declaration and type objects. |
duke@1 | 102 | |
duke@1 | 103 | <p> The {@link com.sun.mirror.apt} package supports the writing |
duke@1 | 104 | of annotation processors. It provides the mechanism for them to |
duke@1 | 105 | interact with an annotation processing tool. |
duke@1 | 106 | |
duke@1 | 107 | |
duke@1 | 108 | @since 1.5 |
duke@1 | 109 | |
duke@1 | 110 | </body> |
duke@1 | 111 | </html> |