Hard Core Tech Talk with Glen Martin, Sun's J2EE Product Manager

Discussions

News: Hard Core Tech Talk with Glen Martin, Sun's J2EE Product Manager

  1. TheServerSide presents a Hard Core Tech Talk interview with Glen Martin, the Senior Product Manager of J2EE at Sun Microsystems. In this interview, Glen discusses how J2EE API's take shape, the JCP, and the evolution of the EJB spec. He addresses various issues that have affected the spec's development, the improvements it has undergone, and talks about the future of J2EE.

    We are pleased to bring you Tech Talks of this quality. Glen Martin is a powerful man behind the scenes, and has direct influence over the J2EE specs. He is also manages Sun's relationships with the major J2EE vendors.

    Watch Glen Martin's interview here.

    Feel free to discuss this here.

    Threaded Messages (26)

  2. Basics[ Go to top ]

    I support his view of Web Services. It's here to stay wheter we like it or not. Also the discussion around JDO, I think, it is nice to have alternatives to EJB.

    What I miss with the EJB 2.0 spec is some of the most basic function from SQL, like sorting for instance. I mean, it's much more efficient letting the db sort rather than working on objects. I hope they can incorporate that feature in the next release.

    I haven't done my homework on JDBC 3.0 so I'm not sure if the latest version has this feature incorporated, but right now we got all these different ways of retrieving primary keys on newly created objects. Is this addressed in EJB 2.0 / JDBC 3.0?
  3. JDO[ Go to top ]

    I find it interesting that Glen doesn't think many people care about JDO in the market. In my experience, a lot of people DO care about it, and think that there "must be something better than Entity Beans".

    I especially see this from Microsoft guys who are coming over to the Java world. They are coming from a world of ADO, which is very powerful, and thinking that they are stepping back, and laugh about Entity beans.

    What do you guys think out there? Do you think a solid JDO approach would be good for the industry?
  4. JDO[ Go to top ]

    JDO support will bring much needed structure to the data tier of web based applications. How many times do I need
    to write the same old code to get in-and-out of the database?

    Glen asked, why do so many developers think that entity
    beans map a row in a table? Could it be that what we really
    need is a standard way to persist entire graphs of objects
    and not a component that half hartedly 'does' persistance?
    Is that maybe what they are asking for?

    IMO, persistant objects are more important than EJB, or
    Web Services. I think we may have the cart before the horse.

    +1 for JDO!
  5. JDO[ Go to top ]

    This is true. I am tired of trying to always solve the O/R mismatch.

    I've tried Cocobase (nice product) and have used Object dbs like Poet and DB4O and think that after using DB4O that I wish that all db access could be so easy.

    I really hope JDO heads in a direction which will allow developers to persist objects in the simplest way possible......

    Cory
  6. JDO[ Go to top ]

    I have been hearing about JDO for almost the past two years. Most discussions center on how JDO will solve persisting Java objects. Well, how is it doing so far? I have yet to see an implementation of this. If this is indeed the "silver bullet" many people have made it out to be, lets see it!

    Until then, perhaps we can focus on how to better use what we have now. The new EJB spec addresses a lot of issues that we lacking in the 1.1 spec (defining relationships, most notably). There are also several O-R mapping tools out there that can help remove almost all JDBC from our code. Both of these are fairly sound solutions (CocoBase, TopLing, Castor). These tools already solve the O-R mismatch, they just needed to be implemented for a specific application.

    We are never going to get away of the O-R mismatch (or at least not any time in the near future). There are to many applications that rely on both an object representation of the data (in a web app, perhaps) and a relational representation of the data (most data mining/reporting tools). The sooner we figure this out and deal with what we have and quit pining for the magic answer (JDO), the better off we will be.
  7. JDO[ Go to top ]

    There are implementations out there now.
    OpenFusion JDO from Prism Technologies for example (http://www.prismtechnologies.com/). Also Castor has a great open source product (Castor JDO).

    If I had to work with a large database, I would much prefer using a good tool (Cocobase, TOPLink, or one of these) than having to use JDBC, or Entities directly (some tools will generate the CMP or BMP beans for me which is nice).

    It isn't as though JDO is a "new" idea. Java copied ODBC to make JDBC, why not copy ADO to make JDO? :)

  8. JDO[ Go to top ]

    It isn't as though JDO is a "new" idea. Java copied ODBC >> to make JDBC, why not copy ADO to make JDO? :)


    JDO is object-peristence and object-relational mapping API and
    ADO is object-oriented high-level database access API.
    These two are very different beasts !

    Regards,
    Mileta

  9. JDO[ Go to top ]


    ObjectBridge boys are developing a Open Source JDO based O-R tool:

    http://objectbridge.sourceforge.net/

    JDO probably is the long-awaited standard to persistence.

    By example: CMP standard doesn´t support INHERITANCE! because is very coupled to RDBMS. I think is a very severe missing feature in an object oriented world. O-R mapping tools support inheritance, why not CMP standard?.

    JDO is more database technology agnostic, very oriented to enhancer technology but perhaps it is the only possible and simple approach to programming objects with transparent persistence: code very simple and I (the enhancer) will overload.

    Support JDO please.

  10. JDO[ Go to top ]

    Right, ADO and JDO sound similar, but that's as far as it goes. Microsoft is working on an O/R mapping tool - ObjectSpaces. My karma-whore cut-n-paste description is below. Pity if the J2EE world has to wait until this gets established before going back to JDO, but I have some sympathy as it's a tricky problem - perhaps one best left to DB vendors?

    "A brief intro:

    The ObjectSpaces architecture enables you to expose data as objects and lists of objects rather than as tables, columns, rows, or XML elements.
    Objects defined within the ObjectSpaces architecture are known as "persistent objects", and are defined using standard .NET Framework conventions in such a way that the ObjectSpaces architecture can manage them with a specified data store. Once you have defined a persistent object, you
    use an ObjectSpace to create instances of the object and to persist the object data to a data store, retrieve and persist objects back to the data store, as well as to delete instances of the object from the data store."
  11. JDO[ Go to top ]

    * EJBs are for building managed components and many folks
      just want to map object graphs to a relational store.
      Obviously there are vendors that provide ORM solutions
      today *but* can you easily swap them out? The answer is
      no. The spec will help in this regard as it will help
      foster a market. Markets = Goodness

    * Who said anything about a "silver bullet"?
  12. JDO[ Go to top ]

    I see your point. Perhaps "silver bullet" was not the perfect term to use. What I was driving at is that I have been hearing about the promise of JDO for quite sometime, but have not seen much more than that. From reading other posts, there does appear to be real products out there that implmement the JDO spec.

    Perhaps my question is - why hasn't this garnered more momentum? Why hans't the spec been released (as far as I know it hasn't: http://jcp.org/jsr/detail/012.jsp). If this spec does define an abstraction of the persistance of Java objects in a standard way, that would be great. I am all for having this. If this is as good as it sounds - what is the hold up? Is JDO being (voluntarily or involuntarily) pushed aside by "competing" specs, such as Entity Beans. Are the technical problems being addressed by JDO to complex to be realized? Or is the expert group just taking their time to get it right?

    Don't get me wrong - I am not trying to criticize JDO. I just wonder if all of its promise will ever be met and whether it will gain the industry momentum that other J2EE technologies have.
  13. JDO[ Go to top ]

    There are several commercial JDO implementations becoming available now, including our own, PrismTech's OpenFusion JDO, which can be downloaded from www.prismtechnologies.com.
    Have a look at http://access1.sun.com/jdo/ for a full list, plus other good JDO information.
    We are seeing a lot of interest in the market, evidenced by 1000's of downloads from our website.
    JDO is aimed at making object persistence easy and transparent and in our experience it does this. We use it internally for our own product developments and are seeing benefits from it.
    JDO is very easy to use - we advise anyone who needs to persist Java objects to download a copy and try it out.
  14. JDO[ Go to top ]

    There is an article on "Using JDO" located at:
    http://www.onjava.com/pub/a/onjava/2002/02/06/jdo1.html

    The code in this article uses the OpenFusion JDO implementation.

  15. JDO[ Go to top ]

    Dion,

    I too am terribly disappointed at Glen's attitude toward JDO. I expected this kind of talk from these O/R tools vendors who always discredited JDO, but not from within Sun of all places. And what a lame argument he puts forward. Confusion. Then let's get rid of JDBC, if that's the case. I can't believe that JDO is losing out to such an inferior technology like CMP entity beans. But after hearing this guy I no longer wonder why. JDO biggest ennemy is not all these proprietary tool vendors, it turns out, but it's from within. But despite all this, I still put the blame squarely on the JDO group within Sun (including Craig Russell, and the product manager if there is any) for not doing a good enough job, and not being agressive enough in pushing JDO in the marketplace. I think Craig is more worried about selling Forte licenses, than about promoting JDO per se. Explain to me then why we haven't had not even one single session on JDO at last year's JavaOne conference. Or tell me why haven't we yet seen a fully functional (RDBMS and all) open source Reference Implementation of JDO, that they keep promising us. If you want widespread adoption of JDO, that's what you need to do. Otherwise the only thing we'll always keep hearing is that same self fulfilling prophecy about JDO from the likes of Glen.
      
  16. JDO[ Go to top ]

    I agree, it was very disappointing to hear that Sun does not think that many people are interested in JDO. IMO, that's a big mistake and the sooner it's corrected the better.
  17. JDO[ Go to top ]

    <quote>
    Explain to me then why we haven't had not even one single session on JDO at last year's JavaOne conference. Or tell me why haven't we yet seen a fully functional (RDBMS and all) open source Reference Implementation of JDO, that they keep promising us. If you want widespread adoption of JDO, that's what you need to do.
    </quote>

    Do you really think that all it takes for a technology to succeed in the marketplace is a session at JavaOne? I guess we would all be happily using Spring, JINI or JXTA, in that case.

    No, it takes more than that. It takes solid implementations and filling a need.

    The failure of JDO to emerge so far is simply because it needs to prove itself, and it hasn't so far.

    You don't go out to customers and tell them that you have the solution to their problems. You listen to them first, and then you deliver. Not the other way round.

    --
    Cedric
  18. JDO - what are the real advantages?[ Go to top ]



    I am yet to be fully convinced of the promised benefits of JDO. There was a lot of talk early on how JDO would replace entity beans - and a lot of flak has been directed towards Entity Beans on the basis that JDO would fix everything. Yet, the fact that the major O-R vendors have been hesitant to implement it (and there has been public disquiet regarding the direction of the specification - particularly from the major O-R vendors) would suggest that it may not be the holy O-R grail.
    (I am basing the following post on the assumption that RDBMS persistance will continue to be the most popular persistance - apart from the odd OODB evangelist, people with OO database experience are thin on the ground - and ERP persistance implementations are even thinner)

    CMP1.1 entity beans were, without question, inadequate for all but the most basic persistance of objects (I wouldnt have even called it O-R mapping).

    CMP2.0, however, is a different story and now solves a lot of the EJB1.1 problems:
    1) Relationships are standardised by CMR
    2) Fine-grained performance improved by local interfaces
    3) Performance/scalability improved by abstract persistance schema - more hooks for containers to implement (distributed) caching, lazy loading, eager-loading, tuned updates and other such optimisations.

    So, what is missing?

    Simplicity?
    The common arguments against entity beans has been that they are too complicated. There are 3 classes and 2-3 deployment descriptors. This is a valid point.

    However, consider that even if you are using JDO (or even Toplink) and you are programming to interfaces instead of implementations (good OO practice) then you will again have three classes (interface, impl, factory).
    Consider also, that just like Entity Beans, JDO will (as Toplink etc do) have some means of declaring and storing the O-R mapping. An XML DD, in this case, is no different to any other O-R mapping storage. If you have good tools, then the issues of DD's should be irrelevent.

    I guess this brings me to my main gripe regarding entity beans (and probably also resonates with a lot of the criticisms of simplicity): In general, the tools available for generating Deployment Descriptors are far from adequate for complex O-R mapping. There are very few tools at all that give any support for the generation of the O-R mapping DD's for Entity Beans. In my mind, neither the application server vendors nor the IDE vendors have done a particularly good job in this area. (JBuilder is the closest I have seen to something acceptable - but its nowhere near the quality of the Cocobase/Toplink mapping tools)
    In order for JDO to be successful where entity beans havent, it will require the support of strong implementations with good mapping tools.


    There is one interesting thing that JDO offers - and that is the "Transactional - Transient" object - a non-persistant, in memory transactional object. In my mind, this is something very valuable that EJB certainly does not offer - currently any shared access object's data is forced into an Entity Bean (even though it makes no sense to persist).

    Whether JDO makes it into J2EE is anyones guess. The J2EE guys were very anti-JDO 12 months ago at last years JavaOne (so I heard) so I am not surprised that there was little enthusiasm from Glen Martin. Cedric has a valid point though - if customers arent demanding it, then there is little point in forcing 30-odd J2EE vendors to support it.

    I guess that my money is going to stay in my pocket until such time as the Toplink/Cocobases support JDO with full vigour (Webgain have announced some support for JDO in Toplink 4.0... but its not exactly front-page news for them)


  19. JDO is more transparent than CMP to make persistency and can be used outside of J2EE if you like and it is more flexible and simple.

    The most important thing IMHO is inheritance support: at last!

      EJB boys are jealous about JDO because can be a substitute of CMP.

    I think that OODBMS boys are glad with JDO because they could get a greater piece of the market cake.

     I like OODBMS (I was a developer of ObjectStore C++/ObjectForms) but the most important issue was the coupling with OODBMS technology and our clients had problems to migrate, in a RDBMS world fully of kiddies making plain programming with ASP-VBasic against SQL Server in a similar way of C with embedded SQL days (and they thought that it was Object Oriented Programming because they used objects!).

    It seems this crap programming technology is ending thanks to J2EE (ok .Net is doing the same). CMP is the first step, JDO is the next in persistence.

      With JDO and Sun (and others) support, this can change and people will can have really freedom selecting standardized DBMS technology without sacrificing programming capabilities (easy persistence of data model and inheritance) and future migration to other database vendor and technology.

      JDO relays very much in ODMG specification, but ODMG boys seemed more worried in shelling books than promoting an standard and the OODBMS industry: you had to buy the book to see it!

      I don't like very much enhancing technology proposed in JDO but there is no other way to implement extreme transparent. Perhaps JDO could have specified a lower level of transparency (like ODMG) and relaying in Java Reflection to access data fields (JDK 1.4 promises it works very speedy). Besides, JDO could relay in EJBQL to queries.

  20. JDO is more transparent than CMP to make persistency and

    >> can be used outside of J2EE if you like and it is more
    >> flexible and simple

    I know that the *goals* of JDO is to be much more transparant - but, in reality, how is this achieved? Where is the simplicity? (examples?)

    I agree that JDO can scale down to much smaller, lightweight applications (read: no need for an appserver). But, then again, there are also some very light CMP containers like JBoss has.


    >> EJB boys are jealous about JDO because can be a substitute of CMP.

    I dont think it is an issue of jealousy. It think it is a case of searching for key differentiating features in order to justify the two competing persistance mechanisms. If the two technologies have the same goals, and no differentiating factors to distinguish them - then one mechanism is redundant and should be deprecated.


    >>The most important thing IMHO is inheritance support: at last!
    What do you mean by inheritance here? In the context of JDO - what does it allow you to do that CMP cannot?


    >> I think that OODBMS boys are glad with JDO because they
    >> could get a greater piece of the market cake

    My concerns regarding JDO is exactly that. It is more aimed as an OODBMS technology rather than O-R mapping (its inheritance from the ODMG specification is testament to that). From reading the public complaints made by the O-R vendors, this seems to be their concern also.

    Just about every organisation uses RDBMS - and a lot were burned by OODBMS. The reasons why OODBMS have such a bad name have mainly been due to poor performance (improper usage?) and, ultimately, nowhere near enough expertise. RDBMS's, on the other hand, are a well understood technology with loads of support (vendor implementations, reporting tools, design tools and a good population of experienced designers, developers, production support people).

    Are OO databases dead? I dont know. I dont see too many people keen to use them... I think there is more of a market for O-R tools - I am just not sure that is where JDO has placed itself.


  21. Along the same lines of RDBMS vs. OODBMS...

    I am not sure about how OODBMS can be used, but many RDBMS are used to back OO applications, but also support applications that have absolutely no OO technology. Two types of processes that come to mind are reporting (stored and ad-hoc) and batch processes, such as uploading the data to be used elsewhere. These processes are very often read-only and have no need for any transactional support that may be handled by the "main" application.

    Do OO databases allow this? Or do they require an application that "knows" about the objects being persisted. Because in the end, it is the data that is important, not how it is stored.
  22. The most important thing IMHO is inheritance support: at last!

    >>What do you mean by inheritance here? In the context of JDO - what does it allow you to do that CMP cannot?

    Persistent inheritance.

    CMP doesn't standardize how persist an object whose class inherits from other class persistent too.

    JDO do, but it leaves freedom about mapping with the native persistent data store (because is neutral in theory).

    Why JDO seems OODMBS oriented? because OODBMS is the most transparent way to persistent objects, they store objects. See Object Store C++ by example: it stores memory images of normal C++ objects! (ok it is a bit more complicated but it is the principle).

     The bad name of OODBMS is not performance only (ObjectStore by example has its niche in Telecom systems! where performance is the first issue), is price (ObjectStore was very expensive) and especially object oriented skills needed. Expertise issue will not so important problem because J2EE world is object oriented and OODBMS are very transparent (very simple API to learn). I think that J2EE can be a step fordward to OODBMS systems.

    Why CocoBase/Thought Inc. is ugly with JDO? because JDO try to be so transparent as OODBMS can be => use of enhancer technology, CocoBase is not based in enhancer then they probably would need rewrite important parts of their product to comply with JDO. They would like a JDO-Cocobase based but it isn´t.

     







  23. >> CMP doesn't standardize how persist an object whose class
    >> inherits from other class persistent too.

    OK. I agree - there is no object-level inheritance.
    You can achieve *some* level of Bean implementation inheritance - but you can run into some problems with PK classes and ejbCreate methods - however, they are treated as separate beans - and you do have to define the O-R mapping for each one seperately...

    >> Why JDO seems OODMBS oriented? because OODBMS is the most
    >> transparent way to persistent objects,

    While that may be true, most companies still store their the large part of their data in a RDBMS. I think it is a mistake that JDO does not reflect that - it should be oriented towards O-R mapping.

    >> The bad name of OODBMS is not performance only

    The bad name of OODBMS's came from people thinking that the ability to transparently persist objects would be the end of their persistance problems. The result was that at a time when OODBMS technology was somewhat immature, there were few people who truly understood OODBMS's and how to design for them. When their project got ready for production and the performance and reliability was diabolical, there was no-one around with the skills to solve it. A few years on, and the situation is largely the same - there are very few people who can support an OODBMS.
    Moreover, OODBMS's are great for transparent *persistance* of an object-tree. The problems usually come when people want to do something useful with that data - it is at this point that they are no longer interested in the object tree. Querying and Reporting is not an access mode particularly suited to OODBMS's.

    >> Why CocoBase/Thought Inc. is ugly with JDO? because JDO try
    >> to be so transparent as OODBMS can be => use of enhancer
    >> technology, CocoBase is not based in enhancer then they
    >> probably would need rewrite important parts of their
    >> product to comply with JDO. They would like a JDO-Cocobase
    >> based but it isn´t

    This, for me, is a further sticking point with JDO. There are not too many people who are comfortable with byte-code enhancement - the idea of not being able to debug the persistance code is not attractive.
    With CMP, despite its short-comings, it is possible to inspect and debug the persistance source code - you can examine the SQL and work out why a bug exists (is it in your app code, your O-R mapping cfg - or the vendors code).


  24. JDO - the real advantages[ Go to top ]

    <quote>
    There are not too many people who are comfortable with
    byte-code enhancement - the idea of not being able to
    debug the persistance code is not attractive.
    </quote>

    AFAIK, the spec does not dictate byte-code enhancement, that's one of the options. Vendor may choose to implement a precompiler, for example.

    You can run queries against JDO cache, which makes JDO cache much more useful than EB's cache.

    From the desing perspective, if you front-end your EBs with SLSBs, JDO makes more sense than EB if used in place of EB.

    My $.02
  25. JDO - the real advantages[ Go to top ]

    I just like:

    - Inheritance: I want to be able to use inheritance in my data model too
    - Transient: My data can be in a transient state as well as persistent
    - Standalone: I can use JDO standalone, and don't need a container (e.g. can use it locally from a GUI or what have you)
    - J2EE CA: Fits in w/ J2EE Connector Arch right now, so you can plug n play
  26. JDO - the real advantages[ Go to top ]


    Has anybody tried PrismTech's OpenFusion JDO yet?

  27. It is very unfortunate JDO is not picking up thanks to SUN.

    Also I am unable to understand comparison of CMP/BMP vs JDO.

    Why not application servers underneath can use JDO for CMP and BMP for persistence?

    Please any comments from experts.