JSR 291, Dynamic Component Support for Java SE, has passed its approval ballot, despite concerns from many JCP EC members regarding two primary issues: "rubberstamping," where the OSGi specification is being passed through without modification, and overlap with another JSR, JSR-277 (the Java Module System).

The "rubberstamping" aspect could be a problem because the JSR is basically a repeat of the normal OSGi specification, which means that instead of the development of a dynamic component JSR, one is simply being imported. That calls into question the worthiness of the JSR in the first place, as OSGi is quite able to stand on its own without JCP approval.

An example of the voting committee's concerns with the rubberstamping aspect, from JBoss (who voted no):

We fail to see the need for this work to be rubberstamped within the JCP process. If it cannot be simply referenced by some other JSR, then it's relevancy is immediately called into question. If the OSGi work is sufficiently well formed that no further input is required by JCP members, then why not have a 2 page JSR that simply says "Go to the OGSi site if you need this capability". If it really requires a more indepth specification, then we should be allowed to modify the work as it progresses through JCP.

Other members voted "Yes," despite some of the same concerns.

The overlap with JSR-277 comes into play because of JSR-291's aggressive timeline, which means that instead of having OSGi represented on the 277 expert group, it could be expected that JSR-277 should leverage JSR-291, as opposed to developing as a module system with input from the OSGi experts on the Expert Group, without an existing JSR imposing any stronger restrictions.

As an example of some of the concerns with the overlap between JSRs 277 and 291, Google (who also voted No) had this comment:

Google is concerned about the relationship between JSR-277 and JSR-291. JSR-277 defines the core platform's approach to modularity, an area that is crucial to the continuing success of the Java platform. We are confident of JSR-277's success, but worried about the possible effects of further constraints. We are sympathetic to JCP standardization of OSGi standards, but we believe that this task is best undertaken after the underlying foundations have been established by JSR-277.

It should be noted that despite the concerns being most clearly explained in comments by voters who rejected the JSR's approval, the concerns were echoed by some who approved the JSR, such as Borland, Nortel, Oracle, Apache, and Intel.

What do you think?

It seems that most JSR groups are dominated by the same set of companies over and over. This leads to a quid pro quo arrangement: "I'll bitch about your crappy JSR's, but I won't tank them if you don't tank mine."

Over the long term, that leads to a lot of crappy JSR's out there, which cripples the JCP.

The EC should look at how to get more diverse representation on these committees, and consider raising the requirements for JSR acceptance.

Why not have these corporate heavyweights have a weighted vote and the general/registered public have a weighted vote as well. We're seeing the same back washing that goes on in politics in the JCP.

It is a bit disappointing to read several of the negative reactions to the passing of JSR 291. Some elucidations:

The JSR passed with 11 for, 1 abstain, 4 against, which is a good score for a JSR that is not liked by SUN.

Some of the yes voters had comments, but they were more to alleviate the concerns of other voters. For example, Oracle, Intel and Nortel are clearly in favor unlike the article suggests.

OSGi is -not- IBM. IBM has played a major role in the OSGi specifications, and they are leading the JSR 291 but the specifications have been developed in close cooperation with the big guys: Ericsson, Nokia, Motorola, Deutsche Telekom, Siemens, BMW, etc. as well as smaller high tech companies like Espial, ProSyst, Gatespace, and many others. Anybody can become a member of the OSGi if they pay the fee, IBM, nor any other party can prevent somebody from becoming a member which is stated in the bylaws to prevent one company from dominating. Lately, Richard Hall (Apache Felix) was invited to help out on release 4. We also had extensive help from Jeff McAffer and Thomas Watson from the Eclipse/Equinox community. We always had Gatespace as a member, the company that runs the OSS Knopflerfish. The OSGi specifications were not designed by some 9-5 office jocks that decided to scribble some Java APIs on paper one day and use their political clout to get them accepted.

Since '99 there have been 4 releases which all have their RI, TCK and a very detailed specification book. A lot of the reactions in this forum are negative without giving any technical concerns, just political. Try it out, and then tell me why it is crappy. What happend to technical people not being political?

JSR 277 is a closed EG, it is impossible to get any information about what is going on. I was denied access, by Sun even after begging on my knees because I was deemed too close to OSGi. So was the Nokia representative Jon Bostrom because he was the JSR 232 spec lead (OSGi for J2ME).

From the description of 277 (which is the only info I get access to), there is an overlap with 291 but it does not go nearly as far as 291 which adds dynamics, backward compatibility, a large user base, maturity, 3 open source implementations with their own rapidly expanding communities, many commercial implementations, and a bridge between J2ME and JSE (any clue how fast these 2 Java's are forking?). Obviously, 291 must adapt the mechanisms that 277 will come up with, however, with a little bit of coordination and openness I fail to see the dichotomy. On the contrary, if they change the language to enable a module system, the OSGi should be the first to take advantage of this.

Why does OSGi need a JSR? The function of a JSR is to minimize fragmentation in the Java world. For a specific problem area, there should be one solution. I do not see why rubberstamping can not achieve that goal as good as designing from scratch? On the contrary, I think it is better to rubberstamp a good spec then start a new learning curve of a spec of unknown quality. When the JCP started, few Java APIs existed, but that will change over time. Redesigning good work that was not done in the JCP is imho silly. The power of the JCP should be used to control the quality which is independent of the the place of the design.

I hope that the 291 EG will get lots of feedback to improve the spec (the JSR 291 list is open to read for everyone, and we will listen), but the goal is less fragmentation, designing from scratch is only a means to an end.

I hope this community can judge the JSR 291 on its technical merits, and not be prejudiced because it was "not invented here".

Kind regards,

    Peter Kriens

Peter

Why does OSGi need a JSR? The function of a JSR is to minimize fragmentation in the Java world. For a specific problem area, there should be one solution. I do not see why rubberstamping can not achieve that goal as good as designing from scratch? On the contrary, I think it is better to rubberstamp a good spec then start a new learning curve of a spec of unknown quality. When the JCP started, few Java APIs existed, but that will change over time. Redesigning good work that was not done in the JCP is imho silly.

I was planning to post in this thread, but you've expressed what I was going to say so well that I'm not going to redesign your post, but simply second it :-)

OSGi seems to be a mature solution for addressing a set of problems that the JCP so far hasn't tackled. That solution is quite widely used and would not disappear if the JCP went down an incompatible path. Not recognizing OSGi in the JCP to some extent, at least, would be a recipe for fragmentation, unless a JCP solution was significantly superior.

Let's consider the big picture here. The goal should surely be to make the Java platform most compelling overall, rather than obsessing about where particular ideas come from.
 
Rgds
Rod

Peter

Why does OSGi need a JSR? The function of a JSR is to minimize fragmentation in the Java world. For a specific problem area, there should be one solution. I do not see why rubberstamping can not achieve that goal as good as designing from scratch? On the contrary, I think it is better to rubberstamp a good spec then start a new learning curve of a spec of unknown quality. When the JCP started, few Java APIs existed, but that will change over time. Redesigning good work that was not done in the JCP is imho silly.

I was planning to post in this thread, but you've expressed what I was going to say so well that I'm not going to redesign your post, but simply second it :-)OSGi seems to be a mature solution for addressing a set of problems that the JCP so far hasn't tackled. That solution is quite widely used and would not disappear if the JCP went down an incompatible path. Not recognizing OSGi in the JCP to some extent, at least, would be a recipe for fragmentation, unless a JCP solution was significantly superior. Let's consider the big picture here. The goal should surely be to make the Java platform most compelling overall, rather than obsessing about where particular ideas come from. RgdsRod

Agree with all of that but someone should be looking at the crossover between these two JSRs and doing any appropriate housekeeping before holding the vote.

i.e. Whether there is or is not crossover and how it is to be handled should have been dealt with prior to voting. Otherwise you get misunderstandings and potential API bloat.


Why do I say that? Because I'd have thought one element of acceptance for voting would be that everything is under control and this new set of specs

From my understanding, the goals of 277 and 291 are fairly orthogonal. If 277 opens up, then I think we can work together on the overlap. Obviously, any constructs that end up in the VM or language should be very usable by 291 or OSGi.
The issue is that for many companies the need for more modularity is urgent; with 291 we can supply a mature model quickly. 277 can make more profound changes in the language and/or VM that can be taken advantage of when they are released in 2007. I really do not see a danger of having two similar specifications coming out of this, the scope of 277 is much more language/VM fundamental. Of course assuming 277 defines with backward compatibility in mind.

Kind regards,

   Peter Kriens

Agree with all of that but someone should be looking at the crossover between these two JSRs and doing any appropriate housekeeping before holding the vote.i.e. Whether there is or is not crossover and how it is to be handled should have been dealt with prior to voting. Otherwise you get misunderstandings and potential API bloat.Why do I say that? Because I'd have thought one element of acceptance for voting would be that everything is under control and this new set of specs

That was my point above exactly. The JCP should have sent them back to have this discussion and bring the written up proposed resolution back for the vote.

It's interesting to me that JSR 277, with Sun leading that spec effort, pretty clearly states what they consider to be shortcomings in OSGi, and yet this JSR is adopting it as a standard that (as noted above) JSR 277 might be expected to have to use in some manner. What's also interesting to me is that Sun voted against this JSR, clearly stating that they consider JSR 277 to be covering similar ground and that it will accomodate OSGi.

Of course, 'accomodate' in this context seems to mean that they won't make changes which break using custom classloaders to manage module isolation. This isn't exactly the same as saying they will adopt OSGi, which seems to be the point of JSR 291.

Honestly, what this looks like to this casual outside observer is that one group (led by IBM) is trying to steal a march on another group (led by Sun) to claim the "high ground" in this important area of the Java specification.

Of course, the JSR 277 could easily just ignore OSGi and JSR 291 as it seemed they already planned to do, so long as they make it possible for OSGi to continue to function. Since customer classloaders are such a common solution for module isolation issues, I would be extremely surprised to see any changes made that would break this, even if the committee were so inclined.

So, in the end, JSR 291 may become a big no-op for the Java community, other than possibly as an interm half-step while JSR 277 completes its work. I'd be interested to hear other informed opinions on the likelihood of this scenario.

James

I would be extremely surprised to see any changes made that would break this, even if the committee were so inclined.So, in the end, JSR 291 may become a big no-op for the Java community, other than possibly as an interm half-step while JSR 277 completes its work. I'd be interested to hear other informed opinions on the likelihood of this scenario.James

It seems that JSR277 is a far out in the future premise and from an old post:

http://www.theserverside.com/news/thread.tss?thread_id=34578

The JSR has just been submitted and is due for it's review ballot/voting by June 27th, before continuing further development. Should it pass, the intention is to have it be a part of J2SE 7.

[emphasis mine]

So we're looking at a significant time gap for JSR277 whereas OSGI has been around for some time and is usable by the community.

Furthermore, if we look at Floyd's previously mentioned post:

The Java Module System intends to correct these problems by including:

    o A distribution format (i.e., a Java module) and its metadata as a unit of delivery for packaging collections of Java code and related resources. The metadata would contain information about a module, the resources within the module, and its dependencies upon other modules. The metadata would also include an export list to restrict resources from being exposed outside the module unintentionally. The metadata may allow subset of exposed resources to be used by other modules selectively.

    o A versioning scheme that defines how a module declares its own version as well its versioned dependencies upon other modules.

    o A repository for storing and retrieving modules on the machine with versioning and namespaces isolation support.

    o Runtime support in the application launcher and class loaders for the discovery, loading, and integrity checking of modules.

    o A set of support tools, including packaging tools as well as repository tools to support module installation and removal.

Sounds an awful lot like JINI to me(versioning notwithstanding). So what is the point of JSR277?

Sounds an awful lot like JINI to me(versioning notwithstanding). So what is the point of JSR277?

Eh? I'm sorry, I don't see a connection to JINI at all. JSR 277 is meant to be the next generation JAR technology. JINI and JARs are completely orthogonal as far as I know.

Does JINI include some module/library management technology that I'm completely unaware of?

James

Eh? I'm sorry, I don't see a connection to JINI at all. JSR 277 is meant to be the next generation JAR technology. JINI and JARs are completely orthogonal as far as I know.Does JINI include some module/library management technology that I'm completely unaware of?James

JINI may be known for distributed systems but the same problem domain of pushing services/modules/component packages or whatever you want to call them apply.

And yes, JINI does have module/library management they just call them services. This is what the whole technology is all about--syndication of services. There are registry functions(ie Repository), meta-data deployment of services to classify resource dependencies, partitioning of client vs. service exposure to classes, expose custom verifying classloaders and a bunch of tools to manage these functions. Sounds like the bullet points above to me.

Sounds an awful lot like JINI to me(versioning notwithstanding). So what is the point of JSR277?

Eh? I'm sorry, I don't see a connection to JINI at all. JSR 277 is meant to be the next generation JAR technology. JINI and JARs are completely orthogonal as far as I know.Does JINI include some module/library management technology that I'm completely unaware of?James

I'm not sure I'd call it next generation .jar technology but I think it could certainly be likened to Perl's CPAN.

You might consider implementing something like this with Jini but I'd say it was over specified for this task. I'd expect some form of lazily updated registry replicated across a bunch of web servers with downloads of "modules" done over http.

I thought what came out of the JDO mess was an understanding that JSRs which the JCP had issues with would be sent back to do their homework and resubmit? Why let this through without ironing out these issues?

I thought what came out of the JDO mess was an understanding that JSRs which the JCP had issues with would be sent back to do their homework and resubmit? Why let this through without ironing out these issues?

The JDO mess was not a issue with JSR people 'not doing their homework'. It was, in my view, a matter of politics outside of the JCP (such as the intention to unify JDO and EJB persistence). In the JDO/EJB case, the JSR that went beyond the range of the initial submission (EJB 3.0 - 'target platform J2EE') by offering JPA, which was also J2SE (and so conflicted with the existing JDO) was not the JSR that had to resubmit!

The politics of these things are interesting.

I think this is great news. OSGi has a really smart component model, hotloading etc etc, and lends itself already today to do componentized work on the server-side (J2SE stuff).
Business benefit? Simpler reuse, with pluggable web app components.
See http://www.infonoia.com/en/content.jsp?d=inf.05.07 for an opinion piece and http://www.infonoia.com/en/content.jsp?d=inf.05.09 for a technical walkthrough.
Wolfgang Gehner

I thought what came out of the JDO mess was an understanding that JSRs which the JCP had issues with would be sent back to do their homework and resubmit? Why let this through without ironing out these issues?

The JDO mess was not a issue with JSR people 'not doing their homework'. It was, in my view, a matter of politics outside of the JCP (such as the intention to unify JDO and EJB persistence). In the JDO/EJB case, the JSR that went beyond the range of the initial submission (EJB 3.0 - 'target platform J2EE') by offering JPA, which was also J2SE (and so conflicted with the existing JDO) was not the JSR that had to resubmit!The politics of these things are interesting.

The homework not done in that case was:

- Not having a solid marketing / positioning document detailing the relationship of JDO to EJB3/JPA, since it was obvious to everyone that JPA was going to happen and was a favorite of the powers that be.

- Not having talked to people and lined up support BEFORE the vote. Remember, in the US Congress, very few bills come to the floor where the outcome is not already known by both sides.

I agree that it's interesting, though... But then again I like watching the behind-the-scenes of politics, too :-)

The homework not done in that case was:- Not having a solid marketing / positioning document detailing the relationship of JDO to EJB3/JPA, since it was obvious to everyone that JPA was going to happen and was a favorite of the powers that be.

If I remember right, It was not obvious that JPA was going to happen when JDO 2.0 was started, or even when EJB 3.0 started. After all, the JSR for EJB 3.0 specifically states it is for J2EE alone, and does not impact any other JSRs, and the needs weren't met by existing JSRs - even though JDO had been used to provide CMP in some existing J2EE app servers. Also JDO 1.0 had been around for some time and had already been approved by the JCP as a standard API for J2SE persistence to relational stores. So, introducing JPA, available for use with J2SE, as part of EJB 3.0 was, in my opinion, a bit rich. At the very least, JPA should have been introduced as a new JSR.

My opinion is that if the JCP had worked right in this case, JPA should have been JDO 2.0, but with the ability to use a new EJBQL as well.

But I guess I am re-fighting old battles - sometimes I feel the need for a good rant :)

- Not having talked to people and lined up support BEFORE the vote. Remember, in the US Congress, very few bills come to the floor where the outcome is not already known by both sides. I agree that it's interesting, though... But then again I like watching the behind-the-scenes of politics, too :-)

Hey, I am only a Brit, so I don't understand that much of these things, in spite of being a very keen fan of The West Wing :)

Hey, I am only a Brit, so I don't understand that much of these things, in spite of being a very keen fan of The West Wing :)

And we all know hollywood always gets it right. :)

Not having a solid marketing / positioning document detailing the relationship of JDO to EJB3/JPA, since it was obvious to everyone that JPA was going to happen and was a favorite of the powers that be.

JPA was more than "a favorite of the powers that be". JDO was a total market failure and failed to bring key players like Oracle (toplink) and JBoss (Hibernate) into the fold. If you are a JDO advocate swallow your pride and be happy that J2EE now has integrated pojo persistence. JDO is dead. Get over it.

"JDO failed to bring key players like Oracle and JBoss into the fold". Bill, that is completely false.

Both Oracle and JBoss joined the JDO 2.0 expert group. In fact, Craig Russell (the JDO spec lead) was very open to allowing EJB members to join the JDO expert group. At the same time, the EJB spec lead had turned down several requests of people on the JDO expert group to join the EJB committee. (this situation changed over a year later in the process)

The same month that JDO 2.0 started, the EJB 3.0 expert group started planning a competing persistence API. They kept this a secret for about 8 months, they had meetings, but none of this was made public till it was announced at a ServerSide conference.

During the first few months of the JDO 2.0 expert group, Gavin King of Hibernate and the Oracle representatives pushed very hard for major changes to JDO. In addition to pushing for the dropping of binary compatibility in JDO, they even argued JDO should drop its source-level compatibility across implementations. The JDO expert group refused to drop the source code compatibility, but given a promise from Oracle and Hibernate that they would fully implement JDO 2.0, the expert group agreed to make binary compatibility an optional feature. Both Oracle and Gavin King made public their plans to implement JDO. The constant attempts by Oracle and Gavin King to change JDO caused things to progress slowly in the expert group. Once the EJB spec lead made it known that they had been meeting and planning to develop a competing persistence API, Gavin King and Oracle promptly resigned from the JDO expert group. They had been part of the EJB persistence group while stirring up controversy within the JDO group.

JPA was created by the "powers that be" to directly compete with JDO. When JDO 2.0 work started, JDO marketshare was really starting to escalate and the world had realized that EJB entity beans were not appropriate for persistence of object models. So the EJB group decided to construct their own lightweight persistence mechanism to directly compete with JDO, using their power to control J2EE specifications to give them more leverage.

JDO 2.0 is now officially a JCP standard, whereas JPA has not been released yet. The EJB community had criticized JDO 1.0 as being immature and that "one should never use the first release of a standard". Well JDO 2.0 is now out, JPA 1.0 is yet to be released and many say that its functionality is dramatically less than JDO. Perhaps we should take their advice and not use the first release of JPA? JDO 2.0 has a free, open source relational implementation (JPOX). Apache has a JDO implementation and there are over a dozen JDO implementations out there and 1000s of clients using JDO.

Sorry Bill, JDO is not dead.

After reading this back-and-forth, I can't wait to read what's on the "JDO 2.0 Passes" thread :)

Oh, David, David, David :-/

You have a long and famous history of posting lies about me on this and other forums, so I'll keep my response very brief, since you long ago discredited yourself.

(1) As you know, both myself and Mike pushed hard for many major changes to JDO (well beyond the silly binary compatibility stuff). However, the JDO group at the time was committed to backward compatibility with JDO 1.x, so there was no possibility to see the changes I wanted. Nor was there any desire for this in the JDO EG.

(2) I never made any promises to anyone that we would implement JDO. Our stated public position was "we will implement JDO if it looks like JDO will be adopted in the marketplace". Over time, it looked less and less likely that that would occur.

(3) My active involvement in the JDO EG was incredibly brief, since I saw quickly that it was a total waste of my time. (Lasted less than 2 months.)

(4) My membership of the EJB3 expert group at no time overlapped my active involvement with the JDO group (since it seemed to me that that would have been ethically questionable).

Statements like:

"Gavin King and Oracle ... had been part of the EJB persistence group while stirring up controversy within the JDO group."
"Given a promise from Oracle and Hibernate that they would fully implement JDO 2.0 ..."

are incredibly untrue, nutty and fantastical.

You guys have the most amazing history of blaming everyone else but yourselves for the failure of your own technology, and of vilifying anyone who dares criticize or try to compete with you. Get over it, its not *my* fault that no-one uses your stuff.

Hi Gavin,
1. Yes, you and Mike pushed for other changes to JDO, though I saw no need to enumerate them, but I would not say there were MANY changes you pushed for. Yes, the JDO group was committed to backwards compatibility, something that the many users of JDO appreciate, it will ease their migration to JDO 2.0. I think there may also be JCP requirements with regards to backwards compatibility. My main point was that the JDO expert group did put forth effort to bring Oracle and JBoss into the fold. But we had released the JDO 1.0 API and companies were building applications with it. Companies value the binary compatibility JDO provides.

2. No promises were made in writing that Hibernate or Oracle would support JDO, but there was definitely an "understanding" based on much discussion that we would drop the binary compatibility in exchange for Hibernate and Oracle supporting the API. Maybe the compromise was only fully committed to on the part of the JDO 1.0 expert group members when we made binary compatibility optional. We did it specifically so Hibernate and Oracle would support JDO, you guys were refusing to support JDO unless we dropped binary compatibility as a requirement.

3,4. Yes, your involvement in the JDO EG was brief, much shorter than Mike's (Oracle rep). I admit I don't know when you started with the EJB effort, it very well could have been after you left the JDO group, so I may be wrong on your overlap. Oracle itself must have had some overlap of JDO/EJB3 activities, because both the EJB and JDO expert groups started their persistence efforts the same month (JDO publicly, EJB privately), but it was a full 8 months later before this overlap was made public. When the EJB persistence effort was made public, Mike promptly resigned from the JDO expert group because of the potential for conflict. Since Mike heads the TopLink effort, I assume he had been part of the EJB JPA persistence efforts from the beginning. Mike is a real nice guy and we really valued his contributions to our discussions. The EJB and JDO communities have always been at odds with one another, this peaked at the time this EJB persistence was made public.

The EJB app server vendor community definitely has had a history of trying to discredit JDO, as it was viewed as a competitor to entity beans. There was lots of FUD they spread about JDO, false FUD. Yet in the end, the industry (even the EJB expert group) decided POJOs were the best answer for object persistence, not entity beans. JDO, Hibernate, EJB3 all support persistence of POJOs.

The biggest fault of JDO 1.0 is that it did not standardize the object-relational mapping, nor did it have a free relational implementation (but there were many, too many commercial JDO relational implementations). With JDO 2.0, OR mapping and a free relational implementation are available. If those had existed when JDO 1.0 was released, Hibernate would have had more competition. Hibernate had the advantage of being the only free object-relational mapping technology available, at a time when companies did not want to spend any money on technology.

I have not had the opportunity to use Hibernate yet, so I have no basis to criticize it. My biggest concern is that Hibernate's existence and popularity (which I don't deny) would negatively affect standardization, or atleast perceived standardization, making companies reluctant to adopt the technology. Object persistence technology provides significant development productivity gains, yet it seems to be avoided because people want and need standards, standards supported by multiple vendors competing to be the best of breed.

I consider it premature to say JDO is a failure, there are many companies using it. You are the one criticizing JDO (and criticizing me as you have other JDO supporters in the past). I am not criticizing Hibernate. My main goal has always been that we have a strong, capable, standardized object persistence API, with multiple vendors competing to support it, with binary compatibility across vendors. I believe this is necessary for broad adoption of object persistence technology. JDO provides for this, Hibernate does not, because it is proprietary and from a single source. That is the extent of my Hibernate criticism.

My postings about you dealt with your claims that Hibernate IS EJB 3.0, which I did not believe was true. Mike @ Oracle is on the JPA committee and he also published statements that your claims of Hibernate being EJB 3.0 were false. I know several companies that adopted Hibernate solely because they thought they were getting early access to EJB 3.0 POJO persistence. I have not done a direct comparison of EJB JPA and Hibernate, but my understanding is that they are not the same API.

My understanding is that JDO 2.0 and Hibernate are both supersets of the capabilities provided by EJB JPA 1.0. So it will be interesting to see which, if any, of these 3 APIs end up establishing one standard that will attain broad adoption. Right now we have 2 "standards" for object persistence that have gone through the JCP process (the released JDO 2.0 and the future JPA 1.0 release) and we have a free proprietary API (Hibernate) that right now probably has a higher level of adoption than the two "standards". My concern is that the market will decide not to make a decision and object persistence will continue to see limited adoption.

Apologies to those who are in this forum to read about dynamic component support... this discussion should have been done in the JDO 2.0 forum, but I wanted to respond to Burke's posting. The JDO discussions should move over to that forum.