News: Interview with Rob Gingell on Proprietary J2EE Extensions

  1. Artima.com has published Part II of an interview with Sun Microsystems' fellow and chief engineer Rob Gingell in which he discusses the pressures on J2EE vendors to both create froth -- to add value on top of standards -- and maintain compatibility in a multi-vendor industry.

    Read Rob's comments about J2EE Compatibility here.

    Here's an excerpt:

    Here's the basic conundrum: If you only implement the standard, you don't solve any new problems. If no new problems are solved, where does the evolving "practice" come from that finds its way into new standards? If you use a new thing, aren't you thus locked in? How do you meet new needs without doing a new thing?

    Here's how life works: Assuming a shared initial condition, some derivation will occur, often in cactus-like fashion across an industry through competition. With time, the economic benefit of standardization is sought to codify what has emerged as existing practice. If the derivation branching grows too large, we criticize it for being fragmented. If the derivation is zero or too small, then we criticize it for being stagnant, non-innovative. There's a happy medium in which the "froth" ahead of the standard progresses the industry, but doesn't damage the base of commonality that defines a marketplace.

    What do you think of Rob's comments?
  2. The article poses the question: "Could that trend lead to the same vendor lock-in the J2EE specs were supposed to protect against?"

    But is this truly the intent of the J2EE specs? It seems to me that Sun deliberately leaves certain aspects of J2EE components loosely defined as an incentive for vendors to create J2EE implementations. The regularity with which I find myself specifying a JNDI name for a component in a vendor-specific deployment descriptor is absurd. There are situations (JCA/RAR, EJB) where it is obvious that deploying the component with a JNDI name is a common requirement, yet this is not covered in the spec.

    It seems apparent that the goal of the J2EE specs is NOT to protect against vendor lock-in, rather it is to provide a high level of standardization that makes applications mostly portable, while retaining enough vendor lock-in to give vendors an incentive to write the app servers. The fault is in the spec, not with the vendors, and it is difficult to fault Sun completely, since the J2EE licensing is one of the few obvious revenue streams from Java.
  3. |
    | The regularity with which I find myself specifying a JNDI
    | name for a component in a vendor-specific deployment
    | descriptor is absurd

    You have to remember that at the time, most of these specs were written by vendors that *already* had appserver products. The vendor-specificness was there in order to encourage those vendors to join the J2EE effort without having to re-write substantial portions of their application server in order to meet the spec.

    JNDI, is one particular example where, say, Weblogic declared it their XML Deployment Descriptor, but IBM stored it in a database...
    I think that now, since many of these designs have converged to XML DD's, there is argument for further standardisation.

  4. proactive vendors[ Go to top ]

    I don't see any particular advantage for a large company to forsake portability
    in liew of vendor lock-in froth. This company has it's lightweight mission critical business
    logic in an Enterprise Application server that is portable to any j2EE certified App server.
    To confound or compromise this single feature with vendor froth, or lock in, from
    an Enterprise point of view, makes the J2EE platform almost undesirable. I believe
    that if, at least vendors were more proactive with standard J2EE, instead of being
    mostly only proactive with the froth, an Enterprise company might even trust them, if
    not at least find it worthwhile to pursue the portability of the J2EE platform. I do find
    it encouraging to hear about the application verifier. Where would one get this tool,
    or is it not available yet?