Java Annotations can simplify J2EE

As J2EE enters the 5.0 era, many features of Java EE5.0 are also widely used in J2EE programs. The Annotations feature of Java EE5.0 is one of the most widely used features.

If you look at the latest Java EE5.0 (EJB3.0, JPA) standard specifications, you can find that the creators or supporters of these specifications claim the most, using these specifications makes development as simple and concise as developing POJOs. However, if you look at or view the source code a little, the most striking thing is the comments that replace the XML description. So I can't help but ask, can the usage of annotations really simplify the development of complex J2EE or components?

I. Introduction

In earlier versions of J2EE, a large number of configuration files were used to set Web programs and ejbs. But all of this has been thoroughly improved in Java EE5.0. Annotation in Java EE5.0 is specially designed for Web and EJB programs. For example, @ Resource, @ EJB, @ WebServiceRef, and other security-related annotations, such as @ RunAs and @ DeclareRoles.

In Java EE5.0, the data supported by Meta-data is annotation. By using annotations, program developers can embed supplementary information in the source file without changing the original logic. Code analysis tools, development tools, and deployment tools can be verified or deployed through these supplemental information. For example, if you want the parameter or return value of a method to be not null, although it can be described in Java doc, there are many methods to express the same meaning, for example, "The return value shocould not be null" or "null is not allowed here ". It is difficult for the testing tool to analyze the Pre-condition and Post-condition conditions expected by the programmer based on these languages ). However, using Annotation can easily solve this problem.

Annotation, in short, is the mark in the code, which can be interpreted during class loading, runtime, or compilation. This makes people feel like C ++'s macros.

In fact, the annotation syntax is familiar to any Java developer. Every day we use @ author, @ param, and so on. In fact, all of them are writing annotations, then generate a document using Javadoc. Java's convenient document generation method has been widely praised by developers. Since JDK1.5, the annotation Syntax provides more powerful functions.

Ii. comment-can it be simplified?

I have asked some Java developers about comments. Many of them say that Java1.4 and EJB2.0 are still used in actual projects, because there is no need to use annotations. Of course, annotations may be involved in normal learning.

Annotations are pseudocode in code files. Some configuration files outside the Code, such as XML and *. properties, are more easily embodied in compiled deployment classes. The two may have their own advantages. What are the basis for our common developers to decide whether to write the metadata in the source file code or in a separate configuration file?

It is certain that there are not many other languages that can provide annotation functions like Java. The purpose of introducing comments is to reference and solve some problems that need to be solved independently or additionally in the source file. However, this does not necessarily play a medical effect.

Let's take a look at the situation where the configuration information is written using annotations in the class file: this means that the configuration information needs to be re-compiled to reflect the change, and the configuration cannot be operated and configured separately outside the Java program. At the same time, the use of the two types of frameworks that support annotation and non-annotation will undoubtedly make the configuration of the project more chaotic and increase the maintenance difficulty.

If a software is in trial run or in real use, and the user needs change or the original function cannot run normally, if some basic configuration information is written into the Java source file, the general practice is: the requirement is fed back to the programmer of the program design. The programmer modifies the code and tests it again. The test may fail, affecting other functions. Then, the programmer tests the program for a long time, finally compiles and packs the program, and delivers the program to the customer.

If the XML and Java separation method is used: low-level maintenance personnel arrive at the site and modify the configuration XML without compiling Java code and testing. The problem is solved immediately. Obviously, which one is faster?

Therefore, the development of software should not only be convenient during self-development, but also take into account whether it is convenient during operation and maintenance. The software is not like a refrigerator, so it is very solid and stable to deliver to users, the user will not propose any modification opinions. Of course Haier's customized refrigerators mean this, but this level is not something that can be done by general manufacturers.

Of course, the author does not oppose or reject any methods or technologies that can improve the efficiency of software development and save time, but there is a premise that this is the cost or cost of this technology or method. Some may say that embedding some deployment logic or information in code can reduce indirect access to files and increase code concentration. However, in a source file full of comments, extracting specific configuration comments will undoubtedly increase the code analysis time. In addition, how can I comment out class files without source files? Finally, why do annotations need a new set of syntaxes? It is like Java syntax. Is it necessary to set up another set of its own syntax?

Of course, I also admit that comments have a positive aspect and can be affirmed. The original intention is good. However, I believe that in EJB3.0, the annotation standards are too extreme. Obviously, this violates the software's simplicity principle, increases the development complexity, and reduces the maintainability of the Code.

Iii. Annotations-making J2EE development easier

As we know, annotations are actually a modifier. Annotations can be used anywhere other modifiers (such as public, static, or final) can be used. As specified, the comment takes precedence over other modifiers. It includes a @ symbol, followed by the annotation type and element value pairs enclosed in parentheses. These values must be the compile time. That is to say, Java itself improves the detailed list of annotation information. Annotations do not directly affect the semantics of the program, but they affect the methods of tools and library processing programs, thus affecting the semantics of running programs. Annotations can be read from source files and class files, and are also reflected at runtime. Separating definitions from the execution and providing a way to save the constraints, which makes the execution process more flexible. Most Java developers are already familiar with annotations. For example, all JavaDoc labels and instantaneous labels are annotated examples.

From a general point of view, it is recommended that you do not write comments in the source file for configuration information, because you need to compile and modify the annotated classes each time, and it is best to write them into a separate XML file.

Any J2EE developer knows that developing Java programs is not simple. But the new Java EE 5.0 will make your development process easier. Java EE 5.0 has Web service support, annotation, and enhanced CMP performance.

To develop a simple J2EE application, a programmer must write a large amount of sample file code (such as JavaBeans Enterprise Edition) and set up countless configuration files (description files in XML ). To become a J2EE developer, programmers must be familiar with EJB and XML. For beginners, these will make them daunting.

The current J2EE specification (1.4) is very long and is written in older JDK 1.2 versions, which makes J2EE more complex and difficult to understand. The new JDK version provides a wide range of simple and easy-to-use performances, such as the general performance and annotation support of Java EE 5.0.

In the latest Java EE 5.0, one of the main purposes is to maintain the powerful functions of J2EE and make general development tasks easier. To achieve this, Java EE 5.0 will provide better default behavior and settings, allowing most containers to get what they need without using deployment descriptors. Therefore, Java EE 5.0 has made many comments. Developers do not need to know the execution details (the container completes the execution task ). These new performances make Enterprise Java applications smaller and faster.

4. comment-what is done and what is not

Annotations are useful for saving or holding metadata. For example, it is easy to build an entity class or controller. It is also useful when two classes are associated.

However, using annotations for configuration purposes violates the original design intention. Because configuration files or information often need to be modified, such as database ing files, using annotations in this respect clearly leads to misuse or excessive use of components. Therefore, Java EE5.0 and Hibernae are a little biased in this regard, which often makes annotations mix between metadata and configuration files.

However, this does not mean that there is a problem with annotations. It can only be said that the problem is caused by misuse of users. Annotations are suitable for defining or saving metadata. But it does not apply to the configuration information of application running.

In addition, commenting on another very successful application may be the application in JUnit4 API. For example:

Add a @ Test comment instead of testXxx () as before ();

Add a @ Test annotation to replace the previous try/catch error handling;

Add a @ Before @ After annotation to replace the previous setUp () and other methods;

Add @ RunWith (Parameterized. class) and a method @ Parameters public static Collection parameters (). The construction Parameters of the tested class are stored in Object. In this way, the parameterized Test is performed without the public static Test suite () as before ().

As far as I know, the use of annotations in the JUnit framework indeed makes it more flexible and the code is more compact.

In fact, annotation is just a tool in the hands of common developers. It may be a new thing, but it is also somewhat annoying. It is actually a double-edged sword. I remember that when I first learned the design patterns, I wanted to quickly apply all these patterns to development, regardless of their applicability. These new features can be used properly and correctly only after such freshness.

V. Summary

Is the comment used or not? I believe that you can apply comments to meaningful places rather than abuse them blindly. For example, comments must be added when there are no annotations to run. Another example is that changing annotations may lead to class behavior during runtime. You can consider using annotations.

Java EE5.0 uses a new syntax such as annotation to replace XML. Of course, you still need to re-compile the modified meta annotation, which is similar to modifying the source code, however, without the Human Engineering Management of unit testing, the program was officially launched, and all kinds of trivial problems such as carelessness all broke out, which is even more terrible.

In addition, I believe that the conventions in ROR are better than the Convention Over Configuration. This Java framework can be used as a reference to solve all the problems in the early stage, this is better than modifying XML by searching left and right in the later stage of maintenance implementation. At the cost of flexibility, it is reliable and stable. When using an interpreted language like ROR, you do not need to compile the comment. Of course, the conventions are better than the configuration rather than the one first proposed by ROR. The default setting is simple and easy to use. You can still use XML for details. In short, conventions are better than configuration improvements based on XML. Of course, I have no objection to simplified exploration, but at present, we still find that XML is stable and can be robust in line with the separation OO idea.