The most useful path expressions to select nodes:
| Expression | Description |
|---|---|
| nodename | Selects all child nodes of the named node |
| / | Selects from the root node |
| // | Selects nodes in the document from the current node that match the selection no matter where they are |
| . | Selects the current node |
| .. | Selects the parent of the current node |
| @ | Selects attributes |
XPath wildcards to select unknown XML elements.
| Wildcard | Description |
|---|---|
| * | Matches any element node |
| @* | Matches any attribute node |
| node() | Matches any node of any kind |
XPath axes defines a node-sets relative to the current node.
| AxisName | Result |
|---|---|
| ancestor | Selects all ancestors (parent, grandparent, etc.) of the current node |
| ancestor-or-self | Selects all ancestors (parent, grandparent, etc.) of the current node and the current node itself |
| attribute | Selects all attributes of the current node |
| child | Selects all children of the current node |
| descendant | Selects all descendants (children, grandchildren, etc.) of the current node |
| descendant-or-self | Selects all descendants (children, grandchildren, etc.) of the current node and the current node itself |
| following | Selects everything in the document after the closing tag of the current node |
| following-sibling | Selects all siblings after the current node |
| namespace | Selects all namespace nodes of the current node |
| parent | Selects the parent of the current node |
| preceding | Selects everything in the document that is before the start tag of the current node |
| preceding-sibling | Selects all siblings before the current node |
| self | Selects the current node |
Annotations are presented as metadata – that is data about data. In the case of Java this means that they provide information about various elements of a Java class. For example, they may annotate a method, class or instance variable. One example of an annotation is to note that a method has been deprecated, or that it overrides a method in the superclass. These annotations can then be used by an annotation processing tool (such as APT), or an IDE (such as Eclipse) or indeed a framework, to validate, configure or add to the original Java. For example, if you have annotated a method as overriding a parent class method, then the annotation processing can confirm that you are indeed overriding a method.
There are seven annotations provided in the J2SE 5.0 release (see the annotations guide here; these are provided in two packages, java.lang and java.lang.annotation:
In the package java.lang there is:
• @Deprecated – indicates that the associated Java element has been deprecated. It is an alternative to using the Javadoc @deprecated element. A deprecated method or class is essentially one that should no longer be used and that is not guaranteed to be available in future versions of the software. It is thus often useful to know that you are using “old” versions of an API. Although the use of the Javadoc tag already allows many tools (such as Eclipse) to indicate that a language feature is deprecated, the use of the @Deprecated annotation makes this simpler and allows a wider range of tools to report on the use of deprecated features.
• @Override - indicates that the method should override a method in the superclass.
• @SuppressWarning – directs the compiler to suppress the specified warning.
In the package java.lang.annotaiton:
• @Documented – directs tools to automatically generate Javadoc for the annotated element (e.g. a method or variable).
• @Inherited – this indicates that the associated annotation is inherited by subclass of the current class.
• @Retention – indicates how long annotations with the annotated type are to be retained. For example, a retention type of RUNTIME indicates…
• @Target – This indicates the Java element to which associated annotations apply.
It is also possible to extend the set of annotations available by defining your own annotations. This enables project, task and company specific annotations to be created.
Annotations are intended to provide three basic facilities. These facilities are:
• The provision of additional semantics for various class elements. This additional semantic information can help developers to understand the intent behind some feature or implementation detail.
• The execution of additional compile time checks that ensure various constraints are met.
• The support of additional code analysis by annotation-aware tools.
None of these requirements are new and indeed many developers have found ways of overcoming the lack of any annotation-like feature in previous versions of Java.
For example, I have tended to make extensive use of Marker Interfaces over the last few years. These are interfaces that may not contain any methods, but are used to denote a particular concept or entity within an application. This is not a particularly radical idea and indeed there is an example of such an interface in the Java language itself - the java.io.Serializable interface. This interface is a marker interface in that it does not require any methods to be implemented but indicates that a class is capable of being serialized via the Java Serialization mechanism.
Such marker interface can now be replaced with annotations. We can define our own annotation that can be used to mark a class as being a particular concept or entity etc.
Annotations are straightforward to use; they merely require that an appropriate annotation type be placed directly before the Java language element being annotated. For example:
This means that when this code is compiled, or when it is analysed by tools such as Eclipse, a check can be made to ensure that the method getName() does override a method in the class Person’s superclass. In this particular case, the class Person extends the class Object as a default. The class Object does not contain a method getName() and thus it does not override such a method. This therefore results in an error message being generated. For example, in figure 1 Eclipse has identified that the method getName() should override a method in the parent class and has provided a pop up to this effect.
However, marking which methods you expect to override parent class methods is probably a step two far for many developers. A rather more useful annotation may be the @SuppressWarnings annotation.
The @SuppressWarnings annotation can be very useful if you have some code that uses a deprecated method or class (possibly because it has been in your system since before that method was deprecated) and you do not want the compiler to churn out lots of warnings about using deprecated APIs. By using the @SuppressWarning annotation and the parameter value “deprecation” it is possible to suppress (turn off) the production of the deprecated warning. For example:
You can easily create your own annotations by defining a new annotation type. This is done using a new piece of language syntax, the @interface key word. For example, to define a new annotation @Auditor we would define the following annotation type.
Note that although the syntax for this is almost exactly the same as for a standard interface, the “@” symbol at the start of the keyword changes this to be an annotation declaration. When you compile the resulting Auditor.java file this creates a standard Auditor.class file. If you place this class file on your class path, then you can use this new annotation type within your Java code. For example, if you place the @Auditor just before the class declaration, this marks the class as being of the entity type Auditor. This is illustrated in Figure 2.
You can also define parameters that can be used with annotations, and accessor methods for retrieving information about the options specified with an annotation.
Annotations are not without their drawbacks. Not least of which is that they are not really metadata – that is they are not data about data – they are data about classes, methods, instance and static variables etc.
As such annotations are syntactic sugar – they coat the elements of a class without actually telling you anything in detail about that class (you can use the reflection API for some of that). Thus they provide guidance to processors, tools and frameworks to help in the analysis, compilation or deployment of that software.
One of the major features of an object-oriented system is inheritance. You can subclass a class, and subclass an interfaces – but you can’t subclass annotations.
If a null value should be treated as an un-initialized value then annotations are somewhat awkward in the way they handle these – rely on the developer to provide a way of indicating un-initialised rather than initialised to null.
These are somewhat limited in what you can use – although in the main this is fine.
The values used with annotations are hard coded rather than variable. Thus if an annotation takes a literal value of 40 – then that value is now hard coded into your program.
Just as with Javadoc comments themselves, annotations need to be maintained to reflect any code changes that may occur. However, as we all know, it is all too easy to change the source code and not to update the associated Javadoc (even when they are next to each other). Exactly the same is true for annotations. If the code relating to an annotation changes, then the associated annotation may also need modification. This may not be as straightforward as it seems. For example, if I rename a method in a class I am working on, then this may impact on another class, that I may know nothing about; if that class requires that one of its methods overrides mine (due to the use the @Override annotation). Of course this may be what is desired or it may not! As you can define your own annotations this situation may become much worse, with significant repercussions for on-going maintenance, clarity and general stability of the code.
Lý do:- Khi applet được cài đặt vào JC, phương thức install được thực thi một lần duy nhất cho mỗi thể hiện của applet. Các phương thức khởi dựng không nên được truy cập một cách trực tiếp mà phải thông qua phương thức install. Nhiệm vụ chính của phương thức install là tạo thể hiện của applet thông qua các constructor và đăng ký applet với JCRE thông qua phương thức register(). Chỉ khi được đăng ký thành công, JCRE mới có thể cho phép thao tác lệnh APDU với applet.public static void install(
byte[] bArray, short bOffset
, byte bLength )throws ISOException;
protected final void register()throws SystemException;- Phương thức này được dùng để đăng ký một thể hiện của ứng dụng "cardlet" với JCRE với một mã (AID) xác định. Mã AID xác định bởi một chuỗi Hexadecimal, có độ dài trong khoảng 5-11 bytes (1byte = 8bits). Mã AID này là tham số đầu vào cho lệnh Select applet. Thông thường, phương thức register() được gọi từ thân của phương thức install() để applet được đăng ký với JCRE 1 lần cho mỗi card.
protected final void register(
byte[] bArray,short bOffset
,byte bLength)throws SystemException;
public boolean select();public void process(APDU apdu) throws ISOException;public void deselect();- Phương thức được gọi thực thi bởi JCRE khi có yêu cầu hoặc khi có hành động select một Applet khác. JCRE sẽ tự động thực hiện deselect() Applet hiện tại.
Posts
All Comments
