Discussions

News: Java Persistence API 2.0 JSR approved

  1. Java Persistence API 2.0 JSR approved (26 messages)

    The next revision of the Java Persistence API (JSR-317) has been approved by the JCP. This revision is to include query by criteria, standardization of hints and metadata, validation, and extended mapping capabilities. The votes were "yes" by all except Google (who abstained) and Apache (who voted no based on the fact that Sun submitted it, and Apache's position is that no JSR should be submitted by Sun until their issues with the compatibility testing kits. Intel, IBM, and Red Hat voted "yes" with the understanding that there was no "field of use" restriction in the JSR.

    Threaded Messages (26)

  2. Whilst I have some simplify with Apache's position on the field of use restrictions for the compatibility testing kit I do think their current behaviour on the JCP is childish in the extreme. Frankly if they're going to vote no to every JSR that Sun proposes regardless of whether it has any relevance to the Harmony project or not than they should seriously consider if they want to remain involved in the JCP at all.
  3. Whilst I have some simplify with Apache's position on the field of use restrictions for the compatibility testing kit I do think their current behaviour on the JCP is childish in the extreme. Frankly if they're going to vote no to every JSR that Sun proposes regardless of whether it has any relevance to the Harmony project or not than they should seriously consider if they want to remain involved in the JCP at all.
    From the ASF's POV, Sun hasn't met with their obligations as a spec lead in the JCP. Why is it "childish" for the ASF to suggest they shouldn't be the spec lead on new JSRs until they resolve the problem with outstanding obligations? Would you call your credit card company "childish" if they suspended use of your credit card if you refused to pay your bill? geir
  4. Why is it "childish" for the ASF to suggest they shouldn't be the spec lead on new JSRs until they resolve the problem with outstanding obligations?
    A boycott, or no show, of the JCP seems a more dignified approach. I'm an ASF supporter and agree with you on the underlying issue, but voting no on the merits of a JSR because of your issues with the JCP in general seems childish to me also.
  5. Why is it "childish" for the ASF to suggest they shouldn't be the spec lead on new JSRs until they resolve the problem with outstanding obligations?


    A boycott, or no show, of the JCP seems a more dignified approach. I'm an ASF supporter and agree with you on the underlying issue, but voting no on the merits of a JSR because of your issues with the JCP in general seems childish to me also.
    I think the key thing here is that the EC votes both on technical merits, as well as other aspects, like suitability of spec lead. I think that the ASF's comment was clear - that the "no" vote was based on the ASF's contention that Sun isn't meeting it's obligations, and that it would have voted yes on the technical merits of the JSRs. geir
  6. Geir, Sun is promising per JSR to open the licenses for TCK and RI. For the 5 JSRs I am on, All the TCKs and RIs are going to be open (4 of which are sun-led). Clearly they are showing their willingness to cooperate in practise if not in policy (yet). In this light what you are continuing to do is rightly described as childish or puerile. ASF should recuse itself from the JCP if it is so principled in its stance that it won't even accede to the ostensible cooperation we ARE getting from sun. Dhanji.
  7. Sun promised to open the licenses for TCK and RI for _all_ JSRs 5 years ago. You're not being told anything new. The issue is that they've shown their willingness to not cooperate in practice, though it is defined in policy. Personally I think the ASF should remain in the JCP, but refuse to use TCKs. They're negative to open-source in general, so I see no driving reasons to use them. Implement specs sure, be involved on JSRs sure (as individuals maybe, I'm not sure there's any value in being involved as a member of the 'ASF corporation'), but don't waste time on crappy little private test kits.
  8. Sun promised to open the licenses for TCK and RI for _all_ JSRs 5 years ago. You're not being told anything new. The issue is that they've shown their willingness to not cooperate in practice, though it is defined in policy.
    It isn't just a case of them promising to open the TCKs. How long does it take to actually "get" a TCK when you request one ? I applied for the TCK for JPA1 in September 2006. It took 5+ months to finally get my hands on it! SUN "lost" the paperwork several times between departments. It hardly encourages me to ever ask again. If they want Java technology and its specifications adopted and implemented then provision of an open framework for dialogue and testing is a prerequisite. On the other hand we have the JDO2 TCK which is totally open, and managed by a responsible group interested in helping people adopt their technology. Having JPA(2) with an open TCK would help its adoption in that people could feedback where it lacks tests in certain areas.
  9. Dhanji Prasanna :
    Geir,

    Sun is promising per JSR to open the licenses for TCK and RI.
    I'm not so sure about that. They've made some noises about the JCK for Java SE 7, a JSR that doesn't exist and won't be done until the end of 2008 at the earliest. But as someone who has been licensing TCKS from Sun for years both for the ASF and for commercial entities, I've seen no material change in their stance on this other than PR.
    For the 5 JSRs I am on, All the TCKs and RIs are going to be open (4 of which are sun-led). Clearly they are showing their willingness to cooperate in practise if not in policy (yet).
    That's interesting. Can you name those JSRs? By open, you mean I can just download under an open source license, or do you mean something else?


    In this light what you are continuing to do is rightly described as childish or puerile. ASF should recuse itself from the JCP if it is so principled in its stance that it won't even accede to the ostensible cooperation we ARE getting from sun.

    Dhanji.
    I don't agree. A primary reason why JSRs are implementable in open source is because Apache led the way to force the changes in the JSPA. (You may or may not recall Jason Hunter, our JCP EC rep at the time, on stage with Rob Gingell and Scott McNeely to announce those changes...) Right now, Sun is in violation of that same JSPA as well as their related public promises from that timeperiod. While I won't go as far as asking you to thank the ASF for the work they do in this area, I'd at least expect that we wouldn't be called names for trying to get Sun to abide by it's obligations and public promises. Personally, I'm a big fan of the JCP, and have worked hard for many years as the ASF's EC rep to promote positive change wrt open source. I'm not giving up now. I think Java is too important. geir
  10. Geir, I am sorry that you feel slighted--I have nothing but the utmost respect for ASF's achievements (we wouldnt be able to do our jobs without ASF projects). I *will* go so far as to thank you, ASF and your contributors for that. However, that doesn't mean I should blind myself from the stubborn and unhelpful stance of voting against every JSR that Sun is leading (note that they are NOT the only authors of said JSRs). By open I mean there are assurances that there will be no "field of use" restrictions on the TCKs and many of the RIs (example, JSR-311 as CDDL) are available as purely OSS/FSF licensed. Dalibor Topic contacted me to clarify my position and ASF's regarding the availability of implementation tools (i.e. restrictions around their use). I am following up with Sun to get assurances that jsr311's TCK will be available with similar freedom from field-of-use restrictions (we already have such assurances around 314, 315 and 316, all of which you have either abstained or voted against). If the turnaround times in obtaining the TCK from Sun are the primary source of ASF's frustration then I completely empathize. I would suggest however that a vote-blockade is hardly the best solution to that problem (which is more mechanical than political). Whilst I am entirely of the opinion that both RIs and TCKs ought to be released under OSS or FSF compatible licenses unequivocally, I believe that Sun's current position is showing cooperation and that ASF's non-negotiable stand (to vote against every JSR regardless of technical merits or industry needs) is counter productive. It is your actions, not your character (which I obviously respect) that I'm calling into question. Regards, Dhanji.
  11. Geir,

    I am sorry that you feel slighted--I have nothing but the utmost respect for ASF's achievements (we wouldnt be able to do our jobs without ASF projects). I *will* go so far as to thank you, ASF and your contributors for that.
    Thanks
    However, that doesn't mean I should blind myself from the stubborn and unhelpful stance of voting against every JSR that Sun is leading (note that they are NOT the only authors of said JSRs).

    By open I mean there are assurances that there will be no "field of use" restrictions on the TCKs and many of the RIs (example, JSR-311 as CDDL) are available as purely OSS/FSF licensed. Dalibor Topic contacted me to clarify my position and ASF's regarding the availability of implementation tools (i.e. restrictions around their use). I am following up with Sun to get assurances that jsr311's TCK will be available with similar freedom from field-of-use restrictions (we already have such assurances around 314, 315 and 316, all of which you have either abstained or voted against).
    I have no idea what Dalibor told you. The problem isn't a "restriction around their use" - we'd accept a license which limited the *ASF's* use of the TCK. But Sun is trying to limit what *our users* can do with the software, which is totally unacceptable. Please note that their assurances for no FOUs are simply promises of something that is *required*. They don't have the option of providing those TCKs w/o a Field-Of-Use restriction if they wish to stay w/in the rules of the JSPA and public promises they have made. It's like your credit card company thanking you because you've told them that you'd make a payment each month. These are "table stakes". Don't thank them for meeting their obligations - thank them for going beyond the basic requirements and doing something extra - like putting their TCKs or RIs in open source (which, btw, the ASF is not demanding), giving to charity, raising their stock price, coherently explaining the KKR investment....
    If the turnaround times in obtaining the TCK from Sun are the primary source of ASF's frustration then I completely empathize. I would suggest however that a vote-blockade is hardly the best solution to that problem (which is more mechanical than political).
    It's not about turn-around time (although I'll note we're approaching the 1 year - 12 months, 365 days, 8760 hours... - anniversary of us trying to get this license.) Through their intransigence, Sun is deliberately blocking the progress of the Apache Harmony project. Period. No spec lead should be allowed to control "the market" like this. We think that spec leads that don't conform to the rules of the JCP shouldn't be allowed to participate in the JCP until they conform. From the ASF's POV, Sun doesn't conform to the JSPA, the "rules" of the JCP.
    Whilst I am entirely of the opinion that both RIs and TCKs ought to be released under OSS or FSF compatible licenses unequivocally, I believe that Sun's current position is showing cooperation and that ASF's non-negotiable stand (to vote against every JSR regardless of technical merits or industry needs) is counter productive. It is your actions, not your character (which I obviously respect) that I'm calling into question.
    Sun isn't being helpful or showing cooperation, and this isn't about Sun releasing TCKs or RIs under OSS or FSF-compatible licenses. Very simply, they aren't living up to their promised obligations. You praise them for offering the above-mentioned licenses w/o a Field-Of-Use restriction - which is *required* - yet you condemn us for asking that they do the same - which is *required* - for the Java SE TCK? We're not asking for special treatment or anything new - just that Sun honor their public promises and JSPA obligations and provide a Java SE TCK license w/o requiring that Field-of-Use restrictions be placed upon the users of Apache Licensed software. geir
  12. re: we get it[ Go to top ]

    1. JPA 2. JDK 2 very different issues, to everyone not outside the Java world...however, I am being persuaded by your efforts, Geir, though i don't expect a thanks from you, as that is expected through the rules of the JSPA :)... This is a developer issue, and I think you have arose the interests of the ranks, but you are also alienating some of your most natural allies, with the Apache v. Sun battle-royale... What can be done, other than let Jonathan get involved in a sticky political mess: - proceed afoot with Harmony and not install in kiosks - proceed with Harmony and directly dis-obey the terms from Sun - take openJDK as the 'only' validated OSS JDK bad options all the way around, I can see your point, and would only anticipate that you will fight the cause...it is a critical juncture for OSS Java, and one that needs all of the resources you can bring to bear against entrenched corporate interests... come up with something other than treating Sun as a non-legitimate player in the build-out of the Java platform, by voting against all of their measures...I don't know what you do other than make political statements, but don't give Sun the grievance that Apache is painting them in to a corner... i still think they are a more natural ally to the ASF efforts than IBM, and you are making some of us in the TSS world believe that you have it in for them, rather than vice-versa on the JDK issue...this is my mea culpa on this issue, but still find another strategy before splitering becomes cause du jour... JPA is too important to ASF to do it this way...
  13. ASF is[ Go to top ]

    not being represented right imo, it is Geirs opinion, and it's time for someone else to represent ASF. Don't we remember the jBoss code base ending up in Geronimo and then IBM? .V
  14. Re: ASF is[ Go to top ]

    Don't we remember the jBoss code base ending up in Geronimo and then IBM?
    Not really, but I actually remember the thread. http://www.theserverside.com/news/thread.tss?thread_id=22337 All those messages....
  15. Some ideas for JPA 2.0[ Go to top ]

    My 2 cents: http://www.ninthavenue.com.au/blog/jpa-2.0-feature-requests * em.getObjectId(o) * Mutable primary keys * Non-PK Generated values * More Collection mappings * Dependent Elements * Indexed fields * JPQL LIMIT keyword * Automatic relationship management * Automatic attach/merge
  16. re: IBM, for that matter[ Go to top ]

    Is it IBM's public opinion that they are pissed that Sun owns Java... +1 on childish...
  17. Re: re: IBM, for that matter[ Go to top ]

    The thing is Sun will be owned by IBM or someone else sooner or later. Not the right time yet (until Java is more "stable" or "stagnant" depending on your pick of the word).
  18. Java Sandbox[ Go to top ]

    The term Java Sandbox suddenly gets a new meaning.
  19. Re: Java Sandbox[ Go to top ]

    The term Java Sandbox suddenly gets a new meaning.
    +1 Its toys out of the sandbox time. Seriously, if you care about java why them would you engage in acts bent on harming it? Why vote 'no' for issues that clearly have nothing to do with the JCP? I think these are issues that need to be dealt with outside of the JCP lest they be deemed efforts to derail progress especially at a time where there is competition at many levels; this is the last thing we need.
  20. hints[ Go to top ]

    What is meant by "standardization of hints"? Are these hints to the database engine that affect the query plan? Every vendor has their own syntax.. Thanks
  21. Re: hints[ Go to top ]

    My guess is that this is optional per JPA vendor implementation and per SQL dialect. (After all, it's just a hint.)
  22. Re: hints[ Go to top ]

    My guess is that this is optional per JPA vendor implementation and per SQL dialect. (After all, it's just a hint.)
    So if it is optional for all of that, then it is not "standardisation" at all then. ok.
  23. Re: hints[ Go to top ]

    ...and every vendor has its own SQL dialect nonetheless you can use JPA with most of the databases.
  24. Hi, apart of the politic issues, I have the next comments about JPA2: 1. @Converter or @Type (as hibernate @Type) for data type conversion missing. 2. The possibility of use JPA apis inside callback methods. 3. I think that validation is better in JSR-303. 4. fetch of ManyToOne by default at application level. 5. ManyToOne and OneToMany optional? You can declare @Transient or @Basic if you do not want a reference. For me points 1 and 2 are important! What do you think about these issues ?
  25. Before adding more features, just add the basic missing things such as declaring Indexes !!!! Identifying relationships, etc.... Or better, just copy JDO.
  26. Before adding more features
    Points 1 and 2 are basic features, How to work against legate database (databases in AS/400 designed by RPG programmers, for example) without converters ? THIS IS A BASIC FEATURE In real application that we are developing with JPA, we need to use query and to save objects in @PrePersist and so. This is a normal case. Now we use Hiberante API inside callback JPA api. Why do we need to do such perversion ? THIS IS A BASIC FEATURE 3 is just removing a feature, not adding one! 4 and 5 are for doing the work more implicit, just to write less code! But they are not critical!
  27. JPA v. JDO: Here we go again...[ Go to top ]

    Before adding more features, just add the basic missing things such as declaring Indexes !!!! Identifying relationships, etc....

    Or better, just copy JDO.
    Here we go again...only it'll be JPA 2.0 v. JDO 2.1. :)