(This article will be published in "Programmer" 2005 No. 2) is like the old routine in the movie, I have to say: "I have a good news, there is a bad news."
Good news is AspectJ and AspectWerkz merge. These two are important open source AOP implementations in the industry, but they have gone different technical routes: AspectJ has always adhered to "Pre-Translation Source Generation". AspectWerkz is a representative of "metadata runtime." Regarding the two technical routes, the debate of the two products has always been a hot topic of the AOP community, and now two open source organizations have decided to completely solve this trouble. The first product after the two mergers will be AspectJ 5, which existing aspectj style, language-extensible AOP, also ASPECTWERKZ style, XML (and JSR-175 Annotation) AOP. Subsequently, both sides will continue to integrate their respective strengths and experiences, and strive to provide a perfect and unified AOP platform.
This is a good thing - for developers. People who write AOP programs know that Aspectj and AspectWerkz (of course, there are other AOP frames) are very injured: there are many resources available, but biased with a set of self-descriptive syntax that cannot be portable. The latter uses the standard Java syntax and XML configuration, the transplantability is no problem, but there is not much resource can be utilized. Although AspectJ 5 is not possible to solve these problems once again, at least let us see hope that the leaders of the AOP community work hard to eliminate obstacles and strive to make programmers have a better development platform. AspectWerkz has changed its homepage to AspectJ in the first time, from this little thing you can feel: In order to the benefit of the entire developer community, these technologists do not mind their respective portal factions. Unlike some people ...
Who is this "some people"? Don't worry, now you should talk about the bad news. Bad news comes from JCP, JSR-243 (JDO 2.0) specification, public review voting results, let me scream: 16 votes have 10 opposition. I also track some JSR voting, such as JSR-168 (Portlet), JSR-94 (Java Rules Engine), JSR-54 (JDBC 3.0), etc., seems to have never seen any JSR encounters so many opposition ticket. The JSR-243 expert group also has two Chinese Sun Bin (Sun Bin) and Charles Huang (Huanghai Bo), and I will tell you: This is a quite mature technical specification, and there are already many business. Implement product. In this case, who is against JDO 2.0 becomes a real technical specification? Take a look at this picture below.
At a glance, the company name in front of the red fork is either in the high-end J2EE application server market, such as BEA and Oracle, or in the high-end server hardware market unique (such as IBM and HP); and green hook front The name can make developers feel kind: Apache, Borland, Sun, and "Godfather" Doug LEA designed concurrently. Intuition tells me that there seems to be a battlefield of "Developer Interests VS. Manufacturer". However, to understand the coming of this war, the story has to start from EJB.
Back to EJB 2.x, many architects I still remember such best practices: "Use stateless session beans, do not use Entity Bean." As a persistent technical solution for the EJB system, Entity Bean is a completely unpaspened failure [1]. Java developers need o / r mapping, but Entity Bean cannot be competent. In a considerable period of time, JDO and Hibernate are the most popular O / R mapping technology of the Java community. JDO is also one of the JSR technical specifications (JSR-12), but as O / R mapping has some detailed defects; Hibernate is an open source project of civil nature, although there is no name, but from the practical design idea to let It is very popular. Overdinding is a universal issue, behind the persistence tool contains such a huge market, and large manufacturers cannot think of it. So, in the preview of EJB 3.0 Specification (JSR-220), we saw an Entity Bean design similar to Hibernate, and Hibernate's author Gavin King also became a member of the EJB 3.0 expert group. The EJB 3.0 specification is described in this way: "EJB 3.0 will thoroughly improve the EJB architecture, lowered its complexity from the developer's angle." This seems that no matter whether IBM is still BEA or HP, they are willing to help developers reduce system development. The difficulty, they are happy to become a developer's friend ...
As long as the application continues to use their high-end servers!
This is the key to the problem. Any friendship, any developer relationship must be built on this bottom line. Any programmer who has made J2EE applications knows that IBM WebSphere, BEA WebLogic, Oracle Application Server is sold with EJB containers, is sold, and running these application servers is higher. - There are many e-government projects in China running under the "noble environment" of "IBM small machine AIX WebSphere". Similarly, any programmer who has done J2EE applications knows that most of the small and medium-sized web applications don't need such a high-end environment. Too many hardware and software resources are planted in white. However, as long as you continue to use EJB, you must choose an expensive, applying server with EJB containers, and a high-end server that allows huge application servers to run, even if you have only 100,000 visitments per day. Don't choose.
Java technology community work hard to change this status quo. Popular architecture based on IOC and AOP, as well as JDO and Hibernate and other POJO-based persistence frameworks are committed to helping J2EE applications to get rid of dependence on EJB containers. Practice has proved that these lightweight architectures are used, coupled with reasonable design and configuration, and domestic at least 90% of e-government and e-commerce systems can run on the servlet container, and EJB is not required. This is a good thing for developers because they only need to load Tomcat on a normal PC, they can get a development environment, and the products developed can also adapted to most users' needs. Moreover, get rid of EJB cumbersome deployment and commissioning, the development efficiency will greatly improve, but also do not have to buy expensive server hardware and software, and the cost of enterprises will also decrease.
But what do most manufacturers think? "90% of the project no longer use EJB", earning huge profits from high-end application servers, IBM, Oracle ... How can I watch this happening? So JDO 2.0 became the headless bird that was only shot: providing convenient and powerful O / R mapping, very good, all manufacturers are willing to help developers, but must be within EJBs; like JDO 2.0 In this way, the O / R mapping that can be used outside the EJB system is not given the reason for the majority of developers to abandon EJB. The manufacturers must naturally be removed before. Is this a guess for the author? Let's take a look at the opinions behind those against tickets:
Ø IBM: JDO 2.0 has obvious competition with other Java persistence technology, and the current regulations cannot clarify how these competitions are solved.
Ø BEA: JSR-243 (ie JDO 2.0) will bring confusion to the Java persistent product market.
Ø JBoss: JDO 2.0 should be used as the maintenance version of JDO 1.0.1, and more new features should be introduced less.
Ø Oracle: We feel that JSR-243 has repeated with other Java persistence techniques, which will cause confusion in the field of persistence technology and reduce the productivity of the entire J2EE community.
Ø Fujitsu: JDO 2.0 should be divided into boundaries between other Java persistence technologies.
Seeing this, the answer of the story has not been revealed - the "other Java persistence technology" that repeatedly filed, is not EJB 3.0 Entity Bean? If the market of persistence technology is currently presenting the pattern of "Entity Bean-JDO-Hibernate", now Hibernate's founder has joined the EJB camp, as long as the JDO is limited to the existing version of the small repair small repair, do not let It has a long development, then Entity Bean naturally became the only strong persistence technology in Java world. The rest of the problem is just how many application server vendors have a market share, and in the absence of fertilizers. The abacus really played!
The old saying is good, there is no friends forever, only forever interests. Although the BEA and IBM spell your life in the application server market, although JBoss has been self-employed by "programmers", once they touched the bottom line of interest, the manufacturers immediately stationed to the same side - stationed to developers and SME companies opposite. Fortunately, developers also have their own interests: Apache has horses open source JDO 2.0 implementation projects, KODO, LIDO and other commercial products will continue to provide small and medium-sized businesses. JDO support. The only unfortunately, I am afraid we can't see the JDO 2.0 technical specification is officially released - at least before the EJB 3.0 is officially released.
Finally, the reader may ask: The manufacturers say "JDO 2.0 will bring confusion to the persistent technology market", which is not unreasonable. Does Java developers are not often worried about choosing too much? This problem is left to the reader to think about it. The following is listed below, and the views of the votes are listed, and may be inspired by the reader.
Ø Apache: Perhaps JDO 2 is indeed a competition with EJB 3.0 Entity Bean, but choices should not be made by several manufacturers. It should be allowed to be released, and the market decides to success or fail.
Ø Borland: Only introducing full competition can we get the best technology for the entire Java community.
[1] See "Programmer" 2004 No. 6 "Analyzing EJB".
