|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
News
News
News
|
Messages: 21
Messages: 21
Messages: 21
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
Opinion: Do We Really Need the JCP?
Allen Holub has written an opinion piece which discusses the juxtaposition of Sun open-sourcing Solaris, and some of the JCP standards. The article is obviously looking to provoke.
In the news we have Sun open-sourcing Solaris—a robust, tested, nonstandard technology—possibly setting a standard by doing so (a good thing). We also have Sun cobbling together a committee to wrest control of persistence away from open-source standards like Hibernate (a bad thing). I could support welcoming Hibernate into the JCP, but creating yet another competing technology is divisive and (I hope) an effort doomed to failure. The last thing we need is another bad standard.
Opinion: Do We Really Need the JCP?
|
|
|
Message #151036
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Inertia.
The real issue with JCP is that it fits an already existing market with already existing needs. Solaris did fit an already existing (yes, it was dying but it still existed) market with several needs and customers (I cannot believe how many Solaris servers I've seen around where I work...).
OpenSolaris is the biggest and widest testing ground for opensourcing software at Sun Microsystems, and it is (in my own opinion) the last testing ground that opensource software needs to pass before becoming THE standard.
OpenSolaris will become OSS but it is doing so only after having shed blood and tears, after having drawn criticisms ("why didn't you opensource it before, clowns!") and doubts.
What would have happened if Sun opensourced Java instead?
In my opinion it could have been worse, far worse than opensourcing Solaris.
Sun is striving to becoming an OpenSource Framework Provider AND a Business Services Oriented company. If Solaris manages to do it, in my opinion sometimes in the future we will have an Opensource / OSI compliant version of Java... with all the good features, and all the bad features that will come out of it (re-read the BileBlog for a good point of view on the limits of OpenSource software...).
On the other hand, I feel that JCP will be needed even in then to preserve the trademark and compatibility with standards, that's just to avoid the baseline Java becoming too "banchi" accepting every one-liner written by a random Joe Programmer out there.
Of course this is only my own personal unrequested opinion :)
|
|
|
Message #151038
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Holub's right *and* wrong, IMO.
The JCP's not trying to necessarily take valid working standards and warp them just for the sake of ... the JCP. The JCP represents a broader user base than just the original author group, and has a public mechanism (more than "this works and people seem to like it") for validation.
"Hibernate is the standard persistence mechanism" seems biased, too. When I look at what people are using and what they say they're using, I find that straight JDBC is very common, comparable to Hibernate usage - and so is DAO. This statement - "Here's the winner!" - invalidates much of the rest of his essay.
His ranting against EJB also smells like a "everyone thinks this" rant. EJB was overused; blaming EJB for its misuse is like saying "I used a dinner plate as a tire, and IT BROKE! DARN THOSE PLATES!" To be sure, Sun could have (and should have) done a better job of propagating use cases, but consider what EJB was: a better version of IBM's San Francisco. (If you're a SF advocate, please don't kill me.)
He then goes on to talk about message-driven beans being an attempt by the EJB people to keep themselves relevant, which is sort of the last nail in his coffin-lid. God forbid we should have deployable mechanisms.
I'm sorry, but having Holub use EJBs to decry the JCP just sounds retarded by the time you reach the end.
|
|
|
Message #151048
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Opinion: Do We Really Need the JCP?
Lot of people have a problem with SUN.
So maybe do not use SUN's stuff and go somewhere else. Maybe to MS ...
SUN is responsible to it's shareholders, not to you ...
EJB criticism is so common in last days. It starts to be boring ...
|
|
|
Message #151053
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
futility
Quite frankly, if you don't like what commercial companies are offering, use OSS. Given the maturity of OSS middleware today, the are plenty of choices. If you really think the JCP is broken, than get involved and fix it. If you think it's hopeless, than ignore it.
Crying about JCP without getting off your butt is easy. How about get off the seat and do some work. All the people in the community working on specs spend a lot of time and effort, so lets give credit to those individuals. No process is perfect. How about describe concrete steps for improving the JCP process. I love to bitch as much as the next guy, but that doesn't mean it should be published as an article.
|
|
|
Message #151071
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
why we call jsr group "Expert Group"
actually i dislike the way things going in the java community....
jcp is very lenthy process(yes it takes a long time to produce a standard) first it propose an idea then it provide an early draft followed by several revisionsthen voting then provide the final version then provide the TCK then approve the RI and finally allow vendors toimplement their impl.,this simply may take years to give the developers a technology and accordingly supposed to produce something near perfect as it take all that time from the EXPERT GROUP to finish BUT look at what we have.... any spec they provide is not usable in its first release,and getting better by revisions till it become usable in third or forth release as the community use it and provide feed back
So why we need such experts when the real improvement come from the community not from the expert group
for example
EJB1.1 the worst technology ever and partially usable at the stage of 2.1 as all of us know that CMP is not practical solution but a performance killer and doesnot support basic OO concepts as inheritance
JSF1.0,1.1 not mature enough although there is older and better solutions in the opensource world, it does not even provide interoperability with existing solutions from jcp itself as jsp and jstl(as if and forEach tags) and need a non standard bridge to work in jsr168 portlet container and the worst,it does not support flexible templating framwork such as tiles or sitemesh and does not provide alternative
JDO 1: although it provide good abstractions such as object life cycle it does not provide by itself a good solution for persistance and users used to depend on vendor extensions and the first revision doesn't provide anything new and finally and after about 2 years it become usable in version2
servlets and jsp: several revisions has been made to allow them to be really used by web developers, that take about 4-5 years
and many more , while in opensource world a very short cycle happens, the ideas is being developed and mentained by the actual developers who really needs it and know the market requirements
so why the JCP and why they called Expert groups?!!!!
|
|
|
Message #151074
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
because they actually have a ton of experience
I only follow a dozen or so specs, but the ones that I do follow, the people in the JSR actually have experience. Rarely do the individuals involved in writing the spec have zero experience. having said that, everyone participating in the JSR comes from a different perspective and coming to an agreement isn't easy. It's not like developers magically create great standards out of thin air. The projects that succeed and rise to the top take time and require a ton of experience. so let's not kid ourselves with assumptions like developers know better than the people participating in the JSR. In many cases, the guys participating in JSR have much more experience and know the pitfalls of simplistic solutions. Making a spec simple and flexible isn't easy or remotely close to being easy.
The best way to fix the problem is to get involved. The JCP could change how it works to make it easier for developers to contribute ideas and get feedback. for example, when JAXB 1.0 was in beta, I discovered a bug and wanted to fix it. Since the RI source code wasn't available, I couldn't go in and fix it. In the meantime, I tried to work around the bug, but it would have been better for me if I could just fix the bug and be done with it. In comparison, when I discovered a bug in Castor, I simply posted a bug entry and provided a patch. I didn't have to wait 3-5 months for the JSR team to fix the RI and go through the lengthy process of releasing jaxb 1.0. Obviously there are licensing issues related to opening up the RI source code, but something can be done to make it easier to contribute.
|
|
|
Message #151078
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Opinion: Do We Really Need the JCP?
We also have Sun cobbling together a committee to wrest control of persistence away from open-source standards like Hibernate (a bad thing). I could support welcoming Hibernate into the JCP, but creating yet another competing technology is divisive and (I hope) an effort doomed to failure. The last thing we need is another bad standard.
Hibernate is not a standard. It's a high-quality, widely used open-source product, but it is not a standard.
Competition is good. Having more than one supplier implementing an API is good, as this encourages continuously improving quality of products. It is certainly not divisive - but wishing doom on competition certainly is.
|
|
|
Message #151082
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Opinion: Do We Really Need the JCP?
From the article:
Even now that JDO 2.0 has played catch-up, why should I go with a JDO Hibernate clone whose APIs are essentially untested in real applications
JDO has played catch-up in some ways, but has been in advance in others (fetch groups, support for non-relational stores). As for JDO being essentially untested - this is blatant nonsense. JDO has been used in many mission-critical high-performance applications.
|
|
|
Message #151083
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Opinion: Do We Really Need the JCP?
"I don’t buy the “if they knew what they were doing, they wouldn’t do that” argument. Well-thought-out technology doesn’t let you hang yourself in this way."
I have yet to see technology invented that could not be used to hang yourself no matter how well thought out it was.
Also blaming the technology choices for a companies failure sounds to me like sour grapes. In most cases generally the blame for a companies failure lied with the CEO's who had no business plan, inexperienced architects who wanted to do the coolest technology (I worked with a lot of those) and VC's who had more money than sense.
This article to me smells of jumping on the band wagon with out much real thought.
|
|
|
Message #151084
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Opinion: Do We Really Need the JCP?
Glad I am not the only person who finds this constant assumption that somehow EJBs are hard to write and work with kind of depressing.
I actually think EJB is a very good example of why we need the JCP. Trying to define an open standard that was flexible enough for the various web servers, application servers, database servers and CTM's was a pretty tall order. I have no doubt that no-one wanted to sacrifice their architecture for the common good and so on. Yet EJB came out and was adopted by vendors from almost every field and by Java developers almost everywhere. The reason it took off like a rocket when it first emerged in 1998 wasn't because Sun was really good at politics or marketing (it was pretty lousy at both), it was because it was such a huge leap forward from trying to build high-performance mission critical systems when compared to using DCOM, CORBA or indeed Java RMI. But it needed co-operation from the major players in transaction processing (IBM, Oracle, BEA, NEC and the like) to work, and the JCP enabled that to happen.
The truth is whether you're using COM+ or EJB to do it, building large scale, highly available distributed systems remains hard. The 3rd major release of EJB is on the drawing bard and people from the open source community (though the JCP) have been heavily involved in the design of it. Hopefully it will further lower the bar for people trying to build complex systems by getting rid of a lot of the (rather tedious) boilerplate type code you need to write for an EJB. But the real point is no one has a better solution to this yet. Blaming EJB for business failures is just dumb – If you need to use it learn how to use the technology for goodness sake, its really not that difficult. If you don't need to use it or don't like it use something like Hibernate or Toplink or whatever.
Its easy to say "the JCP is too slow" or "the JCP is broken" and it would be great if the process could be sped up in some way, but there is very little point in throwing away something which is working (all be it not as fast as you would like) unless you have a good idea about how to improve it. One thing I think would be a benefit would be if (just occasionally) Sun would simply adopt something direct from the Open Source community around Java. Examples? Well LOG4J, Struts and JfreeChart all spring to mind as things which could be adopted wholesale as part of J2EE/J2SE.
|
|
|
Message #151085
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Opinion: Do We Really Need the JCP?
One thing I think would be a benefit would be if (just occasionally) Sun would simply adopt something direct from the Open Source community around Java. Examples? Well LOG4J, Struts and JfreeChart all spring to mind as things which could be adopted wholesale as part of J2EE/J2SE. This sounds like a wonderful idea. I am in this camp too, but I don't know how you can adopt something like struts and let the developers who have been maintaining it continue to maintain it. You would have to get a snapshot of it and call it the standard, then what? Anything that the struts community chooses to change is no longer the standard. Open source works as a product because it is not a standard. I don't see how you can get past that part of it, but it is a wonderful idea.
|
|
|
Message #151094
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Opinion: Do We Really Need the JCP?
Time and again we see this dicussion crop up.. sometimes with different groups of people... sometimes the same! :-) I guess the concept of "open source" has gathered enough momentum and support of relevant individuals by now, that we will see this happen more and more for any "standards" driven tool/toolset implementation. But I agree with people who say that Java standards can never be properly governed without a central community driven body! I guess the people who are talking about doing away with JCP are actually talking about some issues with JCP that need to be corrected rather than eliminating JCP altogether. Changes can definitely be made to both expedite the JCP work and also make it more better (leaner and less meaner?)! So let those thoughts flow!
Regards,
KR
|
|
|
Message #151096
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
One thing I'd like to see is access to RI
In some cases, I think access to the RI would be great. This way, those of us who use bleeding edge stuff before the official release can fix bugs and move on with work. I don't mind bugs in the RI while it's actively being developed, but for god sake, let me fix a bug if I find one. Otherwise, I have to find a work around, when fixing the bug is a better solution.
|
|
|
Message #151105
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Opinion: Do We Really Need the JCP?
Hmmm, let me see.
Servlets, JDBC, JMS, JNDI, JAX*, RMI, JavaMail, JMX, JTA/JTS, ...
Sure looks relevant to me.
|
|
|
Message #151113
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Opinion: Do We Really Need the JCP? Yes Open source even better
Yes we do but it would be great if Java was open source. One thing I dont understand that SUN is say putting in a CVS tree is hassel... well let others do it for you. Another thing all the linux desktops can be Java enabled similar to MAC OSX
|
|
|
Message #151192
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Opinion: Do We Really Need the JCP?
But it needed co-operation from the major players in transaction processing (IBM, Oracle, BEA, NEC and the like) to work, and the JCP enabled that to happen.
This is the key point that many seem to be missing.
In the .NET camp, you have Microsoft and its "standards". Microsoft doesn't have a similar process to support different vendors because it simply doesn't need one due to its dominance in the market. Whatever MS says, goes. Plus it has the advantage of being able to merge the application server tier with its core OS. If they feel that their .NET system needs access to the OS kernel to run better, they have that option.
Recall that Back In The Day, there were several "application servers" on the market, notably Borland and BEA as well as others, but save for CORBA, you were pretty well locked in to the vendor for your application.
If Java is to do well, it needs to have vendor support. Sun can edict all it wants from On High, but if the vendors don't implement Suns edicts, then you have no standard at all, just another spec/implementation of a competing technology.
JCP gives vendors (among others) input into and a stake in the standards being produced. It lets them work in options that make it easier to port their existing applications and infrastructure to the new standards when they come out (think of the various caveats etc. with JMS for example).
It also give the standards less of an ivory tower "here's how things should work in a perfect world" flavor because it is being forged by folks who have implemented these things in the past.
Finally, it also enables vendors who can work towards a published spec rather than creating out of whole cloth. Witness the OSS projects that implement the JCP standards. The standards give them a large "TO DO" list that they can review and check off.
The JCP gives the market a better chance at learning and evolving as it moves forward because it takes consensus from a broad base.
|
|
|
Message #151194
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Inertia.
OpenSolaris is the biggest and widest testing ground for opensourcing software at Sun Microsystems, and it is (in my own opinion) the last testing ground that opensource software needs to pass before becoming THE standard.
OpenSolaris is a red herring and unrelated to the concept of OSS Java. In fact, OpenSolaris is the exact example of why Sun is wary of OSS Java.
OpenSolaris is a proprietary implementation and platform that implements several standards, but offers several features on its own. The whole thing that OpenSolaris is becoming is the exact thing that Sun does not want to happen to Java.
OpenSolaris will include a Linux compatability layer (Janus) to facilitate porting, but otherwise to run on OpenSolaris, there are certainly large chunks of source code that will not build on OpenSolaris because of "Linuxisms" in the code.
Just as there will be code and applications built on OpenSolaris that won't run on Linux.
Sun does not want, if it can possibly help it, that situation to exist in Java and the JVM. That was the prime complaint against Microsoft.
That's why it relies on the things like the JCP, to keep getting input from vendors and to help ensure that a JVM vendor doesn't get off the path and does their own Java.
Fragmenting the UNIX industry is what gave a company like Microsoft the ability to rise up and dominate the market. Much like some suggest the lack of a desktop standard is keeping Linux down on the desktop.
People have a love/hate relationship with choice. On the one hand choice is great: options, freedoms, variety. On the other it's very risky: which one is better, this has A, B, C while that one has B, C, D. There are some who love Baskin and Robins 31 flavors, but I still get Vanilla when I'm there (French Vanilla, actually...).
When people choose Java, Sun wants that choice to be simple. Java. Period. Not Suns Java vs IBMs Java. Having competing implementations actually shrinks the market place for Java. If I have to choose between different JVMs, well, why not start looking at something else, like .NET, or Perl, or whatever. Perl, Python, Ruby is very similar to Sun Java, IBM Java, Gnu Java. Because on the surface they're all bullet point compatible, but it's the details that matter.
Having a single Java makes Java a safer choice for companies. It's why I chose Java many years ago. Not because of Sun, but because of Sun, IBM, Oracle, BEA, etc. etc. It had community buzz and corporate buzz. The only group who hadn't jumped on the bandwagon was Microsoft. All of those options makes Java a safe choice. Fragment Java, and it loses that safety.
OpenSolaris is already in a fragmented world, so one more won't hurt it. Solaris is trying to compete against a free competitor, so making it OpenSolaris is viable tactic to maintain and grow marketshare. Lot less risk with OpenSolaris.
But OSS Java, and risk it forking and fragmenting, and having a major vendor participate, and something "safe" like .NET looks all that much more appealing.
|
|
|
Message #151208
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
because they actually have a ton of experience
Having worked in a company that "does standards" (and oversees them).
There is one simple truth, all the kids that come along to the party have one goal in mind...
"How do I modify the standard to be as close to my implementation as possible"
The JCP is no exception. Change == cost so the less change you have for making your implementation "compliant" then the less cost, simple as that. Issues of "best solution" don't really apply...
The process to get a standard created is (for everyone and every standard) painful and difficult and brings out the worst in everyone. Frankly I'm suprised there are standards at all. And when you get Sun and Microsoft around the same table...
|
|
|
| New content on TheServerSide.comNew content on TheServerSide.comNew content on TheServerSide.com |
|
|
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)
In this session Nati Shalom demonstrates how to take a standard Java EE web application and scale it out or down dynamically without changes to the application code. Seeing as most web applications are over-provisioned to meet infrequent peak loads, this is a dramatic change because it enables growing your application as needed, when needed, without paying for unutilized resources.
(May 19, Tech Talk)
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)
|
|
