With Microsoft pushing .Net as an easy alternative to J2EE, Sun Microsystems is fighting back with a strategy designed to make J2EE more accessible to programmers at all skill levels. InfoWorld's Tom Yager and Tom Sullivan spoke to Rich Green, Sun's Vice President of Tools, about how the company is reaching out to developers.
Q: Isn't ordinary Java the right solution for developers who think J2EE is too complex?
There is a raft of services available to the developer depending on what they need to do, the kind of applications they need to build. Developers tend to pick and choose from the platform the services they need to use to get their jobs done. When I hear people say J2EE is too complicated and ask them follow-up questions, what they say is "when you look at it all, if you had to use it all, there are some parts in there that are complex." Well, yeah, but there are lots and lots of applications built off the J2EE stack that narrow their focus, perhaps using JSPs (Java Server Pages) or database connections. Is it a J2EE app? Yes. Is it relatively simple? Absolutely yes. There has to be a more stratified view of J2EE.
Q: There is a bit of controversy raging now about how developers are doing a lot of work with vendor-proprietary extensions to J2EE application servers. None of the J2EE licensees really encourages you to color inside the lines and write only portable, spec-compliant code.
With any J2EE product offering, there is more in there than J2EE. Your complex apps may be richer than just what's offered by J2EE. And yes, you do run the risk of the code not being portable, but that's not because J2EE itself is not compatible. You're adding other stuff to it.
Q: I understand, but it is not made clear by the licensees when your code crosses the line and becomes unportable.
That is why Sun developed the AVK, the Application Verification Kit. It actually examines the application that you construct, and it tells you if you built it using only the standard interfaces. So before dissemination into use, you can determine if you have built a compliant application. We decided to do that for the reasons you're citing. We're not going to sit here and position, or de-position, or be critical of the vendors of these products. We want to make clear to developers and IT shops when they're in the space, when they're out of the space, so they can be assured that they're writing spec-compatible apps.
Q: Sun has been criticized for its poor record of integrating its various properties, for example its iPlanet servers install differently and don't really talk to other elements of the Sun enterprise stack. The APIs are not merged together. Is Orion going to improve the integration across elements of Sun's software stack?
I think you're on to something here; that is an active investment at Sun. The evolutionary pattern of Orion is first to align the products with respect to interoperation and availability, i.e. deliver them all in a simple, integrated fashion. That's stage one, and sometimes we talk about Orion with too much focus on that. The grand plan is to do what you're describing and then some. Orion is not a collection of components as you're describing it. It's a systems platform. We must ensure a consistency of API, developer experience and deployment experience so that you no longer see the historic barriers of the piece parts. It becomes one whole of systems platform technology.