On Tue, Jun 18, 2013 at 12:34 PM, Pinaki Poddar <ppod...@apache.org> wrote:
> While I will keep aside the later design principle for now, the former > principle applies for the current topic. This forward-looking tendency can > be observed when many "new" JPA features can be mapped onto "existing" > OpenJPA features (FetchPlan being a notable example). > > So it does sound strange when we discuss about implementing JPA 2.1 > features > as if the decision is subjected to someone asking for it. > > A Open Source group builds features not because a spec committee or a > customer, but because , the members, as engineers, think that a feature > will > be useful -- today or tomorrow. Time may prove otherwise, but unless we > carry that spirit of innovation backed by our love for a technology domain, > we, as a group, will fall into the trap of factory-built, proprietary > software that is so twentieth century. > > Yes, a popular spec like JPA can provide a guideline, but our decision of > how to take OpenJPA forward should not depend on it. > I agree with you to a certain point, Pinaki. Yes, with open source, folks are free to innovate and see what's valuable, but in the face of limited resources, it does make sense that resources be assigned in order to address those issues with the most votes. The thorn in the side of this desire-ocracy is the need to implement the specification that, like it or not, defines the minimum bar of entry of the space OpenJPA occupies. For OpenJPA to remain competitive, it not only has to implement those features that have been commoditized by the specification, but also innovate to provide value above and beyond the specification. I am pretty comfortable saying that most customers are going to expect matter-of-factly that OpenJPA implement the latest version of JPA, with an appropriate, but small, lag time after the specification's GA release, which was in May 2013. Otherwise, OpenJPA is at a disadvantage in a competitive situation versus other persistence implementations. Further, it is usually those innovative features that tip an organization's decision to use X or Y. The various JPA implementations find themselves in the now-common dilemma of having their features commoditized by the spec, which then puts pressure on them to innovate. After a particular innovation (or set thereof) is commonplace across implementations, it is standardized and commoditized, and the cycle repeats. I see this a Good Thing. Personally, I think all of the implementations should be striving to implement JDO, since it is and always has been datastore-agnostic and there is a significant NoSQL movement. Most of JPA's innovations have been longstanding features of JDO for years, including fetch plans/entity graphs. Contrary to what many think, JDO has continued undergoing active development this whole time, and 3.1 is now beginning its release process. I have long told customers that if their priority is have choice of implementation, then go with JPA, but if their priority is choice of datastore type, then go with JDO. Hibernate, EclipseLink and Batoo may be conventionally thought of as OpenJPA's competition, but forward thinkers should see DataNucleus as the primary competition, especially as people continue to consider NoSQL solutions. In any case, OpenJPA must, IMHO, implement JPA 2.1 ASAP to be considered legitimate in the space. Further, the roadmap should be to target JDO compliance, as Pinaki alluded to in describing OpenJPA's datastore-agnostic kernel (thanks to its predecessor, Kodo). I mean, seriously, the writing is on the wall. I guess I'm up to my $0.04 now... :) -matthew
