There is no strategic shooting, no dispute vote, during the process of our five months, the first round of Parliament for JDO2.0 is over.
Since the opening process of JDO2.0 standard (JSR243) on April 20, 2004, JDO has begun to return to people's line of sight, and before the end of the May Day holiday, the regulatory development committee members have conducted voting. Express the respective support, current voting has all ended. The following is the case of the voting results and the last time I have a few personal fools.
Let's list the results of the voting:
On April 30, 2004, Sun voted to support JDO2.0, and published the following statement: This statement is a response to some voting statements for previous: If there is no JDO, we value whether Java should be in this field. It is obvious to make a discussion, and the benefits are obvious. However, since JDO already exists, there is already enough user group, and they want JDO to continue to develop. Sun As a leader of JDO norms, Sun is justified to further develop JDO urgency. Sun believes that JDO and EJB can coexist, I hope that the two panels can be fully coordinated to avoid unnecessary norms overlap. Whether JDO should be classified into J2EE will be the next topic. Based on the current JDO already exists and attracts considerable Java development user group, I think the most important thing in the eyes is to further develop by JDO on the basis of absorbing user feedback and new needs. - Graham April 20, 2004, LEA, DOUG (New York State University Calculation Department) Vote expressed support from April 20, 2004, SAP AG's vote expressed support from April 20, 2004, Monson-Haefel, Richard voting On April 22, 2004, Iona Technologies PLC expressed support from April 26, 2004, NOKIA NetWorks voted to support April 26, 2004, BEA's vote expressed opposition, and published the following statement: JDO is currently One of a wide range of server data persistence solutions. In J2EE1.5, it has been focused on reducing complexity and ease of use. We don't understand why we have to continue to launch a new JDO, and its market is concentrated in a limited object database, in addition, EJB3 will also Add similar (similar to JDO) improvements. We need to carefully consider how to introduce JDO into other new areas, such as discrete data set support, etc., what is the consequence of such a combination. Unless these questions are explained, we believe that Java communities should focus on more competitive similar technologies. On April 26, 2004, Apache Software Foundation expressed support from April 30, 2004, Fujitsu Limited voting expressed support from April 30, 2004, IBM voting expressed opposition, and published the following statement: This Java standard demand recommendation JDO's extension is significantly overlapping with other already launched JSRs. Under the Java community, we have not hit the J2EE's simplified trend, we do not want to establish a repetitive mechanism to complete the same function. On April 30, 2004, Macromedia, Inc. voted supported and published the following statement: Although we don't want to see the JDO and other JSR overlap, we have long long-term calls, but they are willing I will do my decision if these overlaps are handled, not for the platform manufacturers. Users often want to choose one of a variety of data storage schemes, without spending more time and effort for these repetitive technologies. We support JDO is not because it is a perfect idea, but is based on the true feelings of the long-term development practice of users. On May 2, 2004, Caldera Systems voted supported May 3, 2004, Hewlett-Packard voting expressed support from May 3, 2004, Apple Computer, Inc. Voting expressed support from May 3, 2004, Oracle voting Opposition, and publish the following statement: JDO2.0 has conflict with the lightweight storage model proposed by the EJB3.0 expert group.
To describe the same problems, while using different APIs, different storage and transaction semantics, different mapping definitions, and query mechanisms, which cannot make J2EE easier. The lightweight storage solution for EJB3.0 will perfectly meet the mainstream enterprise Java application developers, including those that now make criticism to the EntityBean model. In short, since EJB3.0 is already progressing, another independent data storage criteria is not necessary, it will only make decision makers who are going to adopt J2EE more unceregious. The above is the 16 martial arts gactor's voting results (Borland abstained) participating in the J2EE specification. In general, 12 votes support 3 votes against 1 abstentive power, it is passed. However, in the three votes opposed, we can figure out some intriguing things:
Oracle has been hateful to JDO last year. Toplink also! Because JDO directly threatens the non-standard Toplink market, there is even a very much voice requires toplink to support JDO's API, which essentially affects the many corporate users who have locked to Toplink.
IBM and BEA? Most small and medium-sized database applications do not require complex systems such as EJB, while JDO and other lightweight O / R mapping techniques have fill this gap, perhaps this is the attitude of IBM and BEA. Both are the absolute two big names in the EJB market, and they must actively support the EJB3.0 and plan to occupy the market at the fastest speed of occupying the market. The new technique of a cup, of course, will be temporarily abandoned, and cooperate to deal with such an abnormality. From this aspect, the two companies supported each other are worthy of persons, completely unlike the Nationalist Party of the Anti-Japanese Date. Say, the attitude of the two is ultimately served for their own benefit, which is the basic principle of a commercial company, but the JDO referred to in BEA is limited to the application of the object database, which is purely nonsense.
As a regulation leader, Sun's attitude is self-evident. JDO and JSP2.0 can better integrate, allowing page producers to simply complement the combination of dynamic data in the HTML editor, Macromedia is naturally adolescent.
What is fascinating is that always advocates why people-oriented Borland remain silent at this time? Is it .NET? Here, the author is inconvenient to speculate, only keep paying attention, all the answers are retained to publish.
Let's take a look at what is something that EJB3.0 of the debate focus.
Simplify the EJB descriptor using the label function provided by J2SE 1.5. J2SE1.5 is indeed too great, you can perform embedded annotations for classes, methods, fields, etc., so we can count on all descriptors and metadata. Although we already have XDoclet to help development, it is only existing in the source code for the description of the storage map details. Now the J2SE1.5 annotation can exist in the compiled class binary code, really fast! However, this is completely impossible to conflict with EJB3.0. This is only a change in the other category, just like Intel's higher frequency CPU, JDO and EJB can be enjoyed, and cannot explain that JDO and EJB conflicts Provide more default behavior, which can effectively reduce configuration workload. This point is now much better than EntityBean. Provide a predefined adapter class to reduce the number of interfaces that developers need to implement. In JDO, you have no need to implement any interfaces in JDO, so you can't decrease. Is this not as good as EJB? More convenient JNDI processing. This is the tutrain of EJB itself, which is no longer comment here. Simplified in stateless session bean. This is better support with JDO-independent of CMP entity bean and related EJBQL. This is the key to the most concentrated place for the so-called conflict with JDO. EJBQL and JDOQL may be two different query specification, but must be part of the two, or leave the option to the user? EJBQL can only be static, how to dynamically make no expectation, which can not conflict with JDOs at present. Reduce some exceptions that must be captured. Some abnormalities that are unrelated to business logic will be converted to dynamic abnormalities. In this regard, all the exceptions involving the database operations have been packaged as dynamic abnormalities, only if necessary, can be captured. This is also a point that EJB is close to JDO. Performance adjustment features. This is also improved in this article. In summary, we have seen JDOs, and the Java database development has a gratifying change. You don't have to be limited to complex EJBs, or some unreplaceable existing O / R mapping technology, but have new, Standardized choice. These results affect the entire industry, including EJB. I hope that Oracle, IBM, and BEA's giants will start from the user, starting from the actual situation and seriously face this change.
Finally, it is important to note that the author is a JDO supporter, but I want to hear different voices. Welcome to comment on this. (There have been many netizens on http://theserverside.com/news/thread.tss?thread_id=25695)
The copyright of this translation belongs to the author, but welcome to reprint, the premise is to indicate the source and the original author. In addition, welcome to some of my articles in my column, and make valuable comments!
