Father of hibernate: It's time to upgrade to Java EE 6!

Hibernate
The father of Gavin King [1] suggested that developers upgrade to the Java EE 6 platform, and pointed out that some ideas that do not want to upgrade are not justified.

After the release of Java EE 6, I saw a lot of ideas against the upgrade to the new platform. Most of these objections are caused by Tomcat
/Jetty and some open-source frameworks (such as Hibernate and spring.

Of course, there are many advantages to choosing non-standard and open-source technologies. In addition, in EE 6, you can use open-source frameworks that interest you, Servlet 3 and CDI
Seamless integration with third-party frameworks. Therefore, there is no reason not to use ee 6. However, I still see someone saying:

It is difficult to upgrade to the EE application server.

This seems to be a political issue of a specific organization, rather than a technical issue. Of course, upgrade the server (for example, glassfish or

JBoss) is a very trivial task. (Upgrading a third-party framework is even more painful .) Some organizations have a very important process for upgrading servers, but the upgrading process for the Framework running on servers is
There is no such heavy process control. Therefore, it is easier for the development team to upgrade the third-party framework.

I think that developing a more convincing and better process is the most important thing, rather than giving up Java
Ee. There are many risks when running your application on an old and outdated server platform. This practice should not be encouraged.

From a practical perspective, almost everyone is preparing to upgrade to servlet 3 recently. Whether you are using
Tomcat, Jetty, JBoss, glassfish, resin, WebLogic, Oracle or
WebSphere means upgrading the server. This is a golden opportunity to upgrade to ee 6 Web profile.

EE application server is too large

The objection is that the EE server contains many (currently) functions that cannot be used. Opponents usually discuss jar
Compare the disk space occupied by the package size, Servlet Engine + third-party framework, and EE application server. In fact, such arguments are problematic:

1. Disk usage and disk space discussed
   $ Is actually insignificant, and
2. Apply war
   The package size is much more important than the Server installation package size. The server actually contains many functions to minimize the war size.

In addition, I think the most convincing thing is that Java EE 6 Web profile
It is not huge. Once the Authenticated Web profile server is put on the market, we can use the large EE application server and small Servlet
Find a balance between containers.

Bad J2EE and ejb2!

With the JCP standardization process, this problem does not exist anymore:

1. Ejb2
   It has been eight years since its appearance! Is it still your best choice?
2. Many good specifications have been passed
   Through the continuous standardization of JCP, some of these specifications can be used with great certainty. However, JCP has not been standardized by 100%.
3. Almost all people who work on EE 6 hate ejb2 and
   J2EE. This is why someone is constantly adding JCP to help fix these problems. For example, the founder of hibernate, the author of this article. You really want to give him a lesson about
   Question about ejb2? :-)
4. Invention Entity Bean (Entity
   Beans) almost all of them are retired now!

In fact, Java EE 6 Web profile is enough. If you do not try Java
EE 6, you cannot really feel EE

6. benefits for development.

Application Server
The portability of server is too mysterious!

Really? How many people deploy applications on different application servers after splitting them? Oh, I have seen that this means that the 100% perfect application 0
Changes the portability, an ideal kind of Plato portability. I understand the weakness of the absolute truth and the Plato's ideal, but let's take a look at the example first.

This is a typical portability View:

• 99%
  Code, 85% of the external metadata is fully compatible on different server platforms, and the remaining 1% and 15% can be properly separated.
• 40% of the Code, 80% of the external metadata is bound to the non-standard, single vendor container architecture.

When I divide these points, I suddenly wantAPP server portability is too mysterious
ChangeI don't care about container portability at all
. Thoughts on Theme Changes
This proves that the server portability problem exists, and it is very useful for many organizations.

 

I always wanted to see non-ee 6 Technical maintainers on EE 6
True comments. Some arguments mentioned above are not from the real world, so it is difficult to discuss the practical technical issues of application development on the EE platform. The latest JCP specifications seem to have left the opposite
EE camp (temporarily leaving ?), However, it lacks the factual support for success.

Note: [1] Gavin King: Founder of hibernate, member of ejb3 Expert Committee, one of the core members of JBoss, seam
Framework leaders, JSR-299
(CDI
)
The normative leader is also the author of hibernate in action.

Source: You shoshould upgrade to Java EE 6

 

Editing
Profile: Ding Liang, csdn special correspondent, software designer. Network ID: 88250, Linux, open source lovers, good

Javase/javaee development, familiar with the architecture and development of framework applications such as JSF, EJB, spring, seam, and osgi.

I am studying OOAD and agile processes in depth. Personal blog: simple design and ghost Art
.