App Server customizations bad for Java

The message all along througout the history and development of Java is simply "Write once run anywhere". How can BEA claim to have a truly J2EE compliant app server if in fact the custom extensions only allow code to be run BEA Weblogic app servers?It sounds to me like BEA is doing a "Microsoft" by locking in the implementation of J2EE apps on their platform.

That's what Sun did to Microsoft with J++ and should apply the same criteria to J2EE vendors. And definitely companies like BEA will give a bad rep to Java (openness).
What BEA should do instead is to go through the JCP and standarize their new extensions, if they are needed for J2EE growth.

As long as an implementation supports all the requirements that it is required to there is nothing to prevent the vendor going 'beyond' the specification. This is obviously in an attempt to tie people to their product the only hope is to resist using any extension then the application will not be tied to a particular implementation.

The only people that really think this will be the nail in the coffin of J2EE are people that wanted it to die already.

Vendors will add custom things to their servers. All of them do it. Even the reference implementation of the servlet spec (tomcat) has a feature called valves which is proprietary.

Developers need to decide if they want to write in standard code or use the extensions. If they use the extensions, they pay the price.

Obviously J2EE applications using this framework will be bound to Weblogic server.Where does the property of "write once run anywhere" arise then.
It smacks of vendor-lock-in ideas of Microsoft

Yes, I agree that BEA's Cajun violates the write-once-run-anywhere ideology, but I also think that such vendor specific extensions are one of the reasons for Java's strength. Sun is in the process of releasing the specs for version 1.3 of J2EE, and it has said that a framework for web services will not make it's way into J2EE until version 1.4. In the meantime, BEA has decided to move ahead with it's own web services extensions in Cajun.

Java evolves when vendors like BEA spend R&D dollars on technology such as Cajun, and they submit such technology as proposals to Sun for future versions of Java and J2EE. If Sun were to carry the entire burden of advancing Java on it's own, Java would never have advanced as quickly as it has. For example, IBM was a major contributor to J2EE, and IBM has more Java programmers than Sun does. With this open model, Sun is leveraging economies of scale in spreading R&D costs similar to the ones Microsoft enjoys by virtue of the its massive installed base of Windows.

Something similar happened with relational databases. Most relational databases implement SQL, but vendors have added their own extensions and tools over time to gain differentiation. However, SQL does not have a guardian like Java has in Sun.

Any customer who chooses to go with non-standard technology must realize that there will come a time when s/he might have to abandon it. But for those early adopters who can?t wait, the early experimentation and learning might prove tobe a competitive advantage when the standards eventually arrive, especially if the standards incorporate some of that with which they were experimenting.

All manufacturers of Application Servers (WebLogic, WebSphere) extend the capabilities of J2EE's architectural guidelines in some fashion.

The key in developing and deploying J2EE applications and maintaining portability, is the responsibility ofthe programmer. How you construct EJBs, Servlets and JSPs will have an impact on portability if you leverage proprietary app server extensions into the J2EE application.