Recently the EE6 co-lead, Roberto Chinnici, blogged about the state of profiles in EE6, and requested feedback on which direction the group should take. This was also posted to InfoQ and TSS. Essentially we have a choice between two options:
- Rubberstamp Tomcat
- Provide a complete framework for web development.
The first option offers nothing new that doesn't already exist today. Right now you can download Tomcat and, unless you are still developing with just Servlets and JSPs, install the many different frameworks you need to build a modern web application. You are then left to discover the magic version combination that doesn't have dependency conflicts or integration issues.
What we really need is a standardized solution which addresses the three most common needs of modern web applications:
- A data persistence framework
- A component framework
- A rich presentation framework
The full Java EE platform has good solutions for all of these aspects today, and more work is being done to improve them (e.g Web Beans, ability to deploy EJBs in a war, etc). However, the full EE platform also contains many other standards, most of which are focused towards EIS (like CORBA, RMI, JMS, JCA, etc). EIS is, of course, not necessary for a significant portion of web applications. So, the central idea behind option 2, is to deliver a version of the platform that is truly focused towards web development.
Not only can we omit specifications that don't serve the above goals, we can also improve the ones that do to better meet our new-found focus. A good example of this, is EJB-Lite, which only requires support for local session components and JPA.
Taking all of this into account we end up with what I view is the ideal combination, which I have strongly advocated on the EG:
Data Persistence
- JPA 2.0
- JTA 1.1
Component Framework
- EJB Lite 3.1
- Web Beans 1.0
Rich Presentation
- JSF 2.0
- Servlet 3.0 (and friends, jsp, el, jstl etc)
I should also mention that non-standard frameworks would of course still be usable on this profile. As an example, Web Beans will offer an SPI so that any web framework can take advantage of the improved/simplified component integration layer, should it choose to.
However, I think the goal should be to provide a good out-of-the-box solution for web development, and a tomcat profile
definitely falls short.
Wow. Somebody really hates Tomcat. Why do more than 64 % of Java developers disagree with this?
Why is there no room for GWT on your list?
Might be because these are specs whereas GWT is a specific framework. If GWT does the job as well it might be right either.
When GWT is WebBeans compatible indeed there's nothing to say against. And I guess it will be.
To be honest, I really don't see the point in all of these standardization attempts. Developers choose different frameworks for whatever reasons they have, when each framework has its strengths and weaknesses, but there is no way anyone can come up with a super-framework that can provide the functionality that everyone needs. Take JPA for example - compared to Hibernate and TopLink it contains almost no features beyond a very basic ORM. I tried to use JPA but in reality more than half of the mapping and APIs I use are pure Hibernate, so what was gained by using JPA? On the same token, if someone uses Struts for example, should they switch to this JEE 6 super web framework? If they wanted a component-based framework they would switch to JSF/Seam and get exactly the functionality they need, without caring about how standard it is. So far if a framework got to be good and popular it became as supported as the standards, as can be determined by the huge number of Spring/Hibernate/Struts/JSF/Tapestry/Seam/(and many others) books, websites, courses, presentations, certifications and companies offering support, and I really don't think anyone would make the switch just because a new JEE standard was invented.
In my opinion, companies should focus their effort on their own implementations, rather than try to create standards. There is no way JPA 2.0 is going to be better than Hibernate core, or that WebBeans be than the version of Seam that would implement it. I think you should focus your efforts at the points where different frameworks/components interact. For example, in order to make Hibernate work on OC4J, we need to replace a JAR in OC4J - This could be prevented if companies worked together to make sure their products work together (even if they have competing products), and it would benefit the community/costumers more than another standard that would probably be useless without vendor-specific extensions.
Interesting point, Gabriel. I agree with you a lot. Most of the true innovations did not come out of the JCP. Icefaces - one of the best JSF component libraries - has its own addition to the JSF lifecycle spec. Seam provides extensions beyond JSF and EJB 3.
Afterwards we wait a few years to get a standard that wont be compliant to the actual development of the underlying opensource projects. They will have more features or be easier to use by the time the standard is fully implemented.
Maybe for a 10 year investment those standards are interesting in order to protect the investment. But for everyday's work, I dont see much use in a watered down version of a opensource project.
Sakuraba,
I don't have anything against Tomcat. The point of my blog was that it doesn't make sense for an EE profile, who's stated goal is , to only provide what Tomcat provides. Surely your applications need more than just JSPs and Servlets?
As to your question about GWT, standards can only refer to other standards, since a critical component of them is compatibility. To give you an example, If we released a spec that was based on GWT, and then GWT decided to change their API, the spec would be broken. If we complained to them they would likely say (If I were them). that they never intended that API to stay around forever, and that it was our fault for assuming that (it's not standardized after all).
However, what we can do, is provide SPIs that allow non-standard frameworks to easily extend or take advantage of the standard components. As Stefan mentions, GWT could use the Web Beans SPI in some way that made sense to the framework. If one day GWT becomes a standard, we can then look at even deeper integration.
Gabriel,
It is true that standards lag behind bleeding edge technology. Mostly because it takes quite a bit of time to write the specification, get feedback from preexisting frameworks and community, develop an RI. write a test suite that ensures compliance, and wait for vendors to adopt the standard. The benefit to this is that by the time this is done, the spec is usually better understood and described than the preexisting frameworks. In the JPA example, the lessons learned by Hibernate and Toplink lead to a better spec, which also in turn lead to a better Hibernate and Toplink.
It is also true that implementations of a spec often have excellent extensions that some applications just have to have. However, there is still a choice in whether or not and how often they are used. Even an application that uses a great number of them (like you indicate), it is still easier to port than one which uses no standards.
Regarding your suggestion about working with other companies to achieve compatibility instead of writing standards. This would involve every vendor agreeing on how X should be compatible with Y, which is exactly what a standard as. In your hibernate OC4j case, this sounds like a problem with classloading and extensiblility. Both are aspects of the Java EE standard that definitely need to be improved. To assist with problems like this JBoss AS5 is going to support OSGi style package imports. However, something like this needs to make its way into EE.
Standards are very important, but they are not intended to stifle innovation. In fact, as Jason points out, they drive innovation because they help us understand, as a collective, what people's needs are and how the technologies work (and what they really do for us). They are really a history of which we know to be true and then we can move forward using that as a starting point. You could call them theorems. TopLink and Hibernate are successful now, more than ever, because they were made (perhaps forced) to communicate through the JSR. The scientific community figured this out a long time ago. The software industry is just catching up.
Standards require patience. So does progress. You can compare standards to writing a book. Sure, I could just put together endless blog posts to dump the information, but a book is important because 1) it is validated and 2) it has a well-defined structure that is ideal for reference and proper learning. But it takes time to write and may be slightly out of date when published. But the core information will never be useless because 1) it happened, it is history and 2) it provides the foundation on which we build.
One of the areas where Tomcat falls woefully short and does not provide a good foundation for writing apps is its lack of support for JTA (and tied in with that is a writable JNDI tree).
Getting JTA to work with Tomcat is a freakin' nightmare and frankly I don't want to deal with it every time I go to deploy an application. It wastes my time. Sure, there are some libraries that try to make it work, but they are an uphill battle against what just wasn't meant to be. JTA is so critical to writing applications that frankly I consider Tomcat broken without it.
Quoting the number of Tomcat users is a meaningless point. Look at the number of worldwide PHP deployments. It doesn't say much about those applications. Real enterprise applications need some of the Java EE services that are absent from Tomcat. We need them in a web profile. I would go so far as to say that JMS is critical too. How many applications do you think hang the browser because developers have no easy way to kick off a task.
Click HELP for text formatting instructions. Then edit this text and check the preview.I'm going to write more about my prototype toolset next week and I hope that it's going to be useful not only for myself and the next book but also for other projects, like the last toolset.