Comments on: A Word About the Election http://blog.springsource.com/2008/10/27/a-word-about-the-election/ The voice of SpringSource Sat, 20 Mar 2010 12:14:29 -0500 http://wordpress.org/?v=2.8.5 hourly 1 By: Recent Faves Tagged With "boya" : MyNetFaves http://blog.springsource.com/2008/10/27/a-word-about-the-election/comment-page-1/#comment-143828 Recent Faves Tagged With "boya" : MyNetFaves Fri, 23 Jan 2009 05:21:04 +0000 http://blog.springsource.com/?p=601#comment-143828 [...] inşaatçılar demir boya karşılığı ev satıyor First saved by marcoil | 2 days ago Comment on A Word About the Election by boya First saved by guillefar | 13 days ago Filli Boya’dan Opel’i kazanan kim? First saved by [...] [...] inşaatçılar demir boya karşılığı ev satıyor First saved by marcoil | 2 days ago Comment on A Word About the Election by boya First saved by guillefar | 13 days ago Filli Boya’dan Opel’i kazanan kim? First saved by [...]

]]> By: Blog Xebia France - Revue de Presse Xebia http://blog.springsource.com/2008/10/27/a-word-about-the-election/comment-page-1/#comment-127555 Blog Xebia France - Revue de Presse Xebia Mon, 03 Nov 2008 16:56:03 +0000 http://blog.springsource.com/?p=601#comment-127555 [...] sous le signe de la transparence, de l’écoute de la communauté et du pragmatisme (Cf. A word about the election et our approach to the JCP). Cette vision s’inscrit dans la tendance actuelle du JCP dont les [...] [...] sous le signe de la transparence, de l'écoute de la communauté et du pragmatisme (Cf. A word about the election et our approach to the JCP). Cette vision s'inscrit dans la tendance actuelle du JCP dont les [...]

]]> By: OtengiM http://blog.springsource.com/2008/10/27/a-word-about-the-election/comment-page-1/#comment-127532 OtengiM Mon, 03 Nov 2008 12:54:27 +0000 http://blog.springsource.com/?p=601#comment-127532 Finally, The man that will lead Java to the success, after all this years. Also Rod I hope you could suggest improvements to the SE and Client side Java too, So it gets in better position. The server side is moving as Spring framework direction but now with Rod help it will be awesome. Java will be fun and easy to use thanks to Rod and SpringSource on the JCP, Congratulations. Note:Rails or PHP are in the dust after this. Finally, The man that will lead Java to the success, after all this years. Also Rod I hope you could suggest improvements to the SE and Client side Java too, So it gets in better position. The server side is moving as Spring framework direction but now with Rod help it will be awesome.

Java will be fun and easy to use thanks to Rod and SpringSource on the JCP, Congratulations.

Note:Rails or PHP are in the dust after this.

]]> By: Rod Johnson http://blog.springsource.com/2008/10/27/a-word-about-the-election/comment-page-1/#comment-126785 Rod Johnson Tue, 28 Oct 2008 19:23:37 +0000 http://blog.springsource.com/?p=601#comment-126785 Grzegorz I completely agree about openness and I like your specific suggestions. As Ryan says, it *is* possible for individuals to join expert groups, and I think it would be better for the JCP and Java if more individuals did. How much they can contribute depends on how well the process runs at a JSR level. Pre-Spring/SpringSource I was a member of two EGs as an individual. One was run in an inclusive manner and participation felt worthwhile. In the other it was clear that input was going to be ignored, whether it came from inside or outside the EG, and the independents (and some of the corporate reps) rapidly lost interest. I'll be trying to work at JCP level to try to promote an inclusive, open approach to JSRs. Rgds Rod Grzegorz
I completely agree about openness and I like your specific suggestions. As Ryan says, it *is* possible for individuals to join expert groups, and I think it would be better for the JCP and Java if more individuals did. How much they can contribute depends on how well the process runs at a JSR level. Pre-Spring/SpringSource I was a member of two EGs as an individual. One was run in an inclusive manner and participation felt worthwhile. In the other it was clear that input was going to be ignored, whether it came from inside or outside the EG, and the independents (and some of the corporate reps) rapidly lost interest. I'll be trying to work at JCP level to try to promote an inclusive, open approach to JSRs.
Rgds
Rod

]]> By: Ryan de Laplante http://blog.springsource.com/2008/10/27/a-word-about-the-election/comment-page-1/#comment-126776 Ryan de Laplante Tue, 28 Oct 2008 16:22:43 +0000 http://blog.springsource.com/?p=601#comment-126776 @Grzegorz: I've noticed that there are a number of individuals participating in expert groups such as Reza Rahman, Adam Bein, Doug Lea, etc. I imagine the C in JCP is because anyone can join expert groups and there are public drafts every x months. I agree that the work done within the expert groups should be a lot more open. @Grzegorz: I've noticed that there are a number of individuals participating in expert groups such as Reza Rahman, Adam Bein, Doug Lea, etc. I imagine the C in JCP is because anyone can join expert groups and there are public drafts every x months. I agree that the work done within the expert groups should be a lot more open.

]]> By: Grzegorz Borkowski http://blog.springsource.com/2008/10/27/a-word-about-the-election/comment-page-1/#comment-126746 Grzegorz Borkowski Tue, 28 Oct 2008 09:26:24 +0000 http://blog.springsource.com/?p=601#comment-126746 Good to hear such news. I absolutely agree with all of your points from your earlier post "Our approach to the JCP": openess, responsiveness, maturity, awareness of bug picture, ... This is what should be focus of JCP. From my point of view, this is the current picture of JCP and JSRs: 1. It is definitely not Java Community Process. It is something like "Java Biggest-Vendors Process". What it has to do with community? No idea. 2. Each JSR seams to be lead by "black magic masters" (expert groups). The rest of world are simply mortals, and the mortals are not allowed to be informed about progress of the JSR. The JSR progress is a black magic, accessible only to masters. This would be ok for me, if they really are unerring masters, and all they do is perfect. But after java.util.logging and entity beans distaters I don't believe in unerring masters anymore. 3. Let's look at any JSR page. It all looks the same: some formal information about the origins of the JSR; results of the review ballot; eventually, download of spec. There is also a link to Expert Group Private Page (only for black magic masters) and link to JSR Community Update Page (whatever it is - anyway, still only for masters!). What's the value of such page for me, Java developer? No value at all. In most cases, I would really like to get information about the progress of the JSR. What should I expect from it? What's the current status? Is this JSR active or dead? (there are many JSR like this: "final version is expected around 2005" - I look at the page: "current status: In Progress" last activity on the page: "early draft review, 2006" - so what is REAL status? "dead"?). What are problems to be solved? How can i help with it? etc. All of us have seen the real community portals (aka "Web 2.0") on arbitrary topics. This is what I would like to see in JCP: I go to the JCP page, select JSR I'm interested in, and I'm presented the page with some valuable, live information: I see what is discussed in expert group, i see activity reports (is this JSR live or dead?), I can ask question, I can put proposals, discuss the problematic points etc. Then I would start to believe it is really COMMUNITY process. (Obviously, some balance and time frame is still needed, otherwise each JSR process could be stuck on neverending discussions - this is the role of expert group to take control on it). Good to hear such news. I absolutely agree with all of your points from your earlier post "Our approach to the JCP": openess, responsiveness, maturity, awareness of bug picture, … This is what should be focus of JCP.

From my point of view, this is the current picture of JCP and JSRs:
1. It is definitely not Java Community Process. It is something like "Java Biggest-Vendors Process". What it has to do with community? No idea.
2. Each JSR seams to be lead by "black magic masters" (expert groups). The rest of world are simply mortals, and the mortals are not allowed to be informed about progress of the JSR. The JSR progress is a black magic, accessible only to masters. This would be ok for me, if they really are unerring masters, and all they do is perfect. But after java.util.logging and entity beans distaters I don't believe in unerring masters anymore.
3. Let's look at any JSR page. It all looks the same: some formal information about the origins of the JSR; results of the review ballot; eventually, download of spec. There is also a link to Expert Group Private Page (only for black magic masters) and link to JSR Community Update Page (whatever it is – anyway, still only for masters!). What's the value of such page for me, Java developer? No value at all. In most cases, I would really like to get information about the progress of the JSR. What should I expect from it? What's the current status? Is this JSR active or dead? (there are many JSR like this: "final version is expected around 2005" – I look at the page: "current status: In Progress" last activity on the page: "early draft review, 2006" – so what is REAL status? "dead"?). What are problems to be solved? How can i help with it? etc.

All of us have seen the real community portals (aka "Web 2.0") on arbitrary topics. This is what I would like to see in JCP: I go to the JCP page, select JSR I'm interested in, and I'm presented the page with some valuable, live information: I see what is discussed in expert group, i see activity reports (is this JSR live or dead?), I can ask question, I can put proposals, discuss the problematic points etc. Then I would start to believe it is really COMMUNITY process. (Obviously, some balance and time frame is still needed, otherwise each JSR process could be stuck on neverending discussions – this is the role of expert group to take control on it).

]]> By: Ryan de Laplante http://blog.springsource.com/2008/10/27/a-word-about-the-election/comment-page-1/#comment-126725 Ryan de Laplante Tue, 28 Oct 2008 04:13:30 +0000 http://blog.springsource.com/?p=601#comment-126725 Congratulations to both Rod and SpringSource! I am very happy to see SpringSource in a highly influential position within the JCP. I think that most, if not all vendors in the Java EE comities share a common goal of creating standardized APIs that developers want to use in hope that their customers will buy middleware products or support contracts. They want to make decision making easy: whatever your need, there is a standardized API for it and you are not locked into any one vendor provided the standards are thorough, leave little room for interpretation, and have a strong TCK. What's wrong? In the past standards were developed that solved only part of a problem, had poor APIs, etc. After a while many alternatives popped up. Many years later these alternatives have been refined and are being integrated back into Java EE standards. I would like to see the JCP take steps to ensure that any new JSR is fully usable before going final. For example, allowing JPA 1.0 to be released without a criteria API, one to many unidirectional mapping, cache hints, etc. should not have been allowed. Allowing EJB 3.0 to be released without singleton beans and proper scheduling features in the timer service should not have been allowed. Allowing JSF to have been released without HTTP GET, stateless support, a radio button component that isn't in a table, etc. should not have been allowed. Allowing any of the specs to be released without addressing unit testability should not have been allowed. If the JCP is going to create standardized APIs then they need to make sure that developers will want to use them, otherwise it is pointless. I think Java EE 6 is doing a great job of integrating the best ideas from the last few years into all areas and that it will be more successful than any previous version of Java EE. As a serious influencer in the JCP, embrace EJB 3.1 and WebBeans and ensure that they address all serious problems you see. Does WebBeans give EJB 3.1 proper IoC? Will EJB 3.1 provide more sophisticated pointcuts to interceptors? Also, I wish the JCP was a lot more open. Blog more often, have detailed public issue trackers, forums where interested community members can give feedback and see feedback from other community members, make sure the expert group responds to every feedback, etc. Give access to "nightly builds" of the specs and reference implementations if possible... assuming the RIs are open source. Congratulations to both Rod and SpringSource! I am very happy to see SpringSource in a highly influential position within the JCP.

I think that most, if not all vendors in the Java EE comities share a common goal of creating standardized APIs that developers want to use in hope that their customers will buy middleware products or support contracts. They want to make decision making easy: whatever your need, there is a standardized API for it and you are not locked into any one vendor provided the standards are thorough, leave little room for interpretation, and have a strong TCK.

What's wrong? In the past standards were developed that solved only part of a problem, had poor APIs, etc. After a while many alternatives popped up. Many years later these alternatives have been refined and are being integrated back into Java EE standards. I would like to see the JCP take steps to ensure that any new JSR is fully usable before going final. For example, allowing JPA 1.0 to be released without a criteria API, one to many unidirectional mapping, cache hints, etc. should not have been allowed. Allowing EJB 3.0 to be released without singleton beans and proper scheduling features in the timer service should not have been allowed. Allowing JSF to have been released without HTTP GET, stateless support, a radio button component that isn't in a table, etc. should not have been allowed. Allowing any of the specs to be released without addressing unit testability should not have been allowed. If the JCP is going to create standardized APIs then they need to make sure that developers will want to use them, otherwise it is pointless.

I think Java EE 6 is doing a great job of integrating the best ideas from the last few years into all areas and that it will be more successful than any previous version of Java EE. As a serious influencer in the JCP, embrace EJB 3.1 and WebBeans and ensure that they address all serious problems you see. Does WebBeans give EJB 3.1 proper IoC? Will EJB 3.1 provide more sophisticated pointcuts to interceptors?

Also, I wish the JCP was a lot more open. Blog more often, have detailed public issue trackers, forums where interested community members can give feedback and see feedback from other community members, make sure the expert group responds to every feedback, etc. Give access to "nightly builds" of the specs and reference implementations if possible… assuming the RIs are open source.

]]>