|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
News
News
News
|
Messages: 26
Messages: 26
Messages: 26
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
Java Persistence API 2.0 JSR approved
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.
|
|
|
Message #237254
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Java Persistence API 2.0 JSR approved
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.
|
|
|
Message #237260
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
re: IBM, for that matter
Is it IBM's public opinion that they are pissed that Sun owns Java...
+1 on childish...
|
|
|
Message #237271
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Java Persistence API 2.0 JSR approved
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
|
|
|
Message #237272
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Java Sandbox
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.
|
|
|
Message #237273
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Java Persistence API 2.0 JSR approved
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.
|
|
|
Message #237274
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Java Persistence API 2.0 JSR approved
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
|
|
|
Message #237275
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
hints
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
|
|
|
Message #237278
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: hints
My guess is that this is optional per JPA vendor implementation and per SQL dialect. (After all, it's just a hint.)
|
|
|
Message #237279
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: re: IBM, for that matter
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).
|
|
|
Message #237283
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Java Persistence API 2.0 JSR approved
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.
|
|
|
Message #237290
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: hints
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.
|
|
|
Message #237294
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
A technical comment about JPA 2.0
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 ?
|
|
|
Message #237295
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: hints
...and every vendor has its own SQL dialect nonetheless you can use JPA with most of the databases.
|
|
|
Message #237296
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Java Persistence API 2.0 JSR approved
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.
|
|
|
Message #237298
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: A technical comment about JPA 2.0
Before adding more features, just add the basic missing things such as declaring Indexes !!!! Identifying relationships, etc....
Or better, just copy JDO.
|
|
|
Message #237300
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: A technical comment about JPA 2.0
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!
|
|
|
Message #237301
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Java Persistence API 2.0 JSR approved
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.
|
|
|
Message #237306
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Java Persistence API 2.0 JSR approved
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
|
|
|
Message #237316
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
ASF is
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
|
|
|
Message #237329
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JPA v. JDO: Here we go again...
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. :)
|
|
|
Message #237426
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Java Persistence API 2.0 JSR approved
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.
|
|
|
Message #237430
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Java Persistence API 2.0 JSR approved
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
|
|
|
Message #237463
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
re: we get it
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...
|
|
|
| New content on TheServerSide.comNew content on TheServerSide.comNew content on TheServerSide.com |
|
|
Reza Rahman continues to explore the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(January 21, Article)
Ted Neward is an independent consultant specializing in high-scale enterprise systems, and an authority in Java and .NET technologies. He is the author and co-author of several books, including Effective Enterprise Java. At TheServerSide Java Symposium in March, he will be presenting sessions on pragmatic architecture, ECMAScript and Scala.
(January 15, Article)
Now that Oracle is absorbing Sun Microsystems, there mixed views on what should come of the Java Community Process (JCP). While some say Oracle should become the new steward of Java and keep the JCP much as it was, others argue that it may be time to open-source this widespread language.
(November 24, Article)
Reza Rahman explores the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(November 2, Article)
SAML is an XML-based standard for exchanging authentication and authorization data between security domains. The single most important problem that SAML was created to solve is the Web browser Single Sign-On problem. Many organizations are debating whether to stay with version 1.1 or move to 2.0. This article makes observations about both options.
(September 28, Article)
Joe Ottinger takes a look at how people learn, and applies it to the practice of programming. He notes that understanding how people learn is an essential part of working in a programming team.
(September 22, Article)
Stephen Maryka gave us an article about the Asynchronous Web and posed a number of questions that get examined like an approach to delivering Asynchronous Web capabilities through extensions to existing Java EE technologies.
(July 14, Article)
JavaServer Faces Flex goal is to provide users capability in creating standard Flex components, part of flexSDK which is open sourced through MPL license, as normal JSF components. This article by Ji Hoon Kim will provide an overview of creating a simple multilingual JSF page consisting of JSF Flex tags.
(June 29, Article)
In this session Jeff explores the key characteristics of successful SOA projects. He covers some of the patterns, and anti-patterns, tool sets, and strategies that he himself learned the hard way. Last, he provides a strategy and blueprint for achieving a high likelihood of success in your SOA project.
(June 23, Tech Talk)
Ari Zilka, CTO of Terracotta, Inc., talks about the new features in Terracotta 3.1, announced during JavaOne and available now.
(June 15, Tech Talk)
In this Tech Talk, Josh Long explores an integration challenge using Spring Integration and walks through the implementation, employing and expanding on the basic patterns of Enterprise Application Integration to tie together components into a function integration solution, and then demonstrates how Spring Integration helps address the integration requirements.
(June 15, Tech Talk)
In this Tech Talk, David Geary teaches you: The basics of Google Web Toolkit; How to implement Ajax-enabled applications in Java; Internationalization; Hooking into the browser history mechanism; Remote procedure calls.
(June 4, Tech Talk)
Jon Kern discusses the best architecture/technical solutions and ensure that they are repeated by all developers. By tackling the architecture up-front in a serial manner, subsequent parallel development will be much more manageable and predictable.
(May 28, Tech Talk)
This keynote describes the frustrations of modern knowledge workers in their quest to actually get some work done, and solutions for how to guard yourself against all those distractions. Neal Ford talks about environments, coding, acceleration, automation, and avoiding repetition as ways to defeat the misguided attempts to sap your ability to produce good work.
(May 26, Tech Talk)
Gil demonstrates how new, aggressive uses of already abundant compute capacity by common applications offer competitive value for application designers.
(May 21, Tech Talk)
Chris Keene introduces WaveMaker as a new way to automate the ability to generate Hibernate classes in order to more quickly bring OR mapping into an application.
(May 19, Article)
Mastering EJB was one of the original and most influential EJB books in the industry. Mastering EJB III now returns with two new expert co-authors, updated for EJB 2.1 and 30% new chapters including security, integration, best practices, open source, and more.
(Book PDF Download)
The Application Server Matrix is a detailed listing of J2EE vendors and their application server products, with information on latest version numbers, J2EE spec support and licensing, pricing, platform support, and links to product downloads and reviews.
(Application Server Comparison Matrix)
|
|
