One of the things that makes the JCP strongest is the participation of multiple groups with vastly different points of view, arguing for standards where the groups stand to lose work. However, it's conceivable that vendors might use this to save themselves work at the expense of the JSR. Most people who watch the JCP can find specifications that were weakened by the lack of specific language (i.e., "implementors may include...") or the inclusion of features meant to ease requirements for JSR participants (such as the local interfaces for EJBs in EJB 2.) Is there a solution? The JCP doesn't lend itself to a workable democracy; populism is too easy to find, where a group that has a popular voice is able to wield more power over a JSR than, perhaps, it should. On the other hand, in some cases popularity is good: witness the EJB3 persistence model, influenced greatly by Hibernate, in a nearly total break with the pre-JPA persistence model. Can you think of examples where specs are affected negatively or positively by the inclusion of a specific vendor? Do you think this is something the JCP can actually fix in any meaningful way, outside of a spec lead being a tyrant?

Is there a solution?

For start they could make JCP EG discussions public. This would be a useful step in people actually seeing *who* objects to particular features, and associated vested interests against objections. Of course this is only part of the problem, so then we get on to the (lack of) openness of the TCK's for testing compliance with such specifications ...

Amen...enough said... There is no reason to continue to hide what goes on behind the expert groups. It simply causes credibility gaps and gives expert group members a false sense of security. We should be ready to do what we do under a microscope and say what we have to say in a public setting. Reza Rahman

Amen...enough said...

There is no reason to continue to hide what goes on behind the expert groups. It simply causes credibility gaps and gives expert group members a false sense of security. We should be ready to do what we do under a microscope and say what we have to say in a public setting.

Reza Rahman

+1. With the microscope maybe expert group members would be more inclined to focus on improving, innovating, and fixing specifications rather than their own selfish interests. Expert group members can make a good start by blogging about what is going on within committee. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com

Expert group members can make a good start by blogging about what is going on within committee

I know it's not enough, but one of my own personal efforts has been trying to get people to know what is going on in the EJB 3.1 committee by publishing a series of articles on ServerSide and soliciting feedback from folks. It's in Joe's editorial pipeline and should be out soon! I'm very tempted to blog about Java EE 6 too...maybe I'll kick my lazy b#tt into gear and do that soon too. Reza Rahman Co-Author, EJB 3 in Action Expert Group Member, Java EE 6 and EJB 3.1 Chief Software Architect, Tripod Technologies

Is there a solution?

For start they could make JCP EG discussions public. This would be a useful step in people actually seeing *who* objects to particular features, and associated vested interests against objections.

Of course this is only part of the problem, so then we get on to the (lack of) openness of the TCK's for testing compliance with such specifications ...

+1 I don't see any reason for secrecy. Now that so many critical projects are developed in open source, and there's so much innovation from open source, why should the JCP be any different? Rgds Rod

Is there a solution?

For start they could make JCP EG discussions public. This would be a useful step in people actually seeing *who* objects to particular features, and associated vested interests against objections.

Of course this is only part of the problem, so then we get on to the (lack of) openness of the TCK's for testing compliance with such specifications ...

+1

I don't see any reason for secrecy. Now that so many critical projects are developed in open source, and there's so much innovation from open source, why should the JCP be any different?

Rgds
Rod

+1 Taking it a step further, why not see if Sun could set up a JCP forum on the Java forums to allow input from individual users, allowing Java community members to actually take ownership and help shape the JSRs, enabling more of a community stakeholdership (if that's a word) in the process? This would give JSR spec leads an opportunity to converse with potential end users as well, resulting in more polished specs and better thought out APIs/SPIs and RIs. The end result is that everybody wins because they all had a part in the process (or at least had the opportunity to take part). Thanks, Jim Bethancourt President, Houston Java Users Group

This has long been a problem within the JCP - http://www.loopfuse.org/blog/?p=11 Is getting better, but still has a ways to go.

A little history lesson. Remote interfaces had RMI baggage. Local interfaces were supposed to provide a local, collocated way to invoke. Pass-by-reference vs. pass-by-value. Seems a pretty valid contract considering it affects client implementation. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com

Most people who watch the JCP can find specifications that were weakened by...the inclusion of features meant to ease requirements for JSR participants (such as the local interfaces for EJBs in EJB 2.)

A little history lesson. Remote interfaces had RMI baggage. Local interfaces were supposed to provide a local, collocated way to invoke. Pass-by-reference vs. pass-by-value. Seems a pretty valid contract considering it affects client implementation.

Right -- Local interfaces were added so PBR semantics (avoiding arg copying overhead) would be available for co-located scenarios; it really had nothing to do with easing requirements for a JSR participant. (Arguably it would have been "easier for JSR participants" if customers continued to have only PBV/remote as an option.) If you were thinking that the EJB2 expert group should have had a single "uber" interface that automatically switched between PBV and PBR depending on whether caller and callee happened to be co-located; well, that might not have been the greatest idea because many apps don't enjoy having their calling semantics switched on them based on the whims of how the sysadmin partitioned the app. :)

Most people who watch the JCP can find specifications that were weakened by...the inclusion of features meant to ease requirements for JSR participants (such as the local interfaces for EJBs in EJB 2.)

A little history lesson. Remote interfaces had RMI baggage. Local interfaces were supposed to provide a local, collocated way to invoke.

Pass-by-reference vs. pass-by-value. Seems a pretty valid contract considering it affects client implementation.

Right -- Local interfaces were added so PBR semantics (avoiding arg copying overhead) would be available for co-located scenarios; it really had nothing to do with easing requirements for a JSR participant. (Arguably it would have been "easier for JSR participants" if customers continued to have only PBV/remote as an option.)

If you were thinking that the EJB2 expert group should have had a single "uber" interface that automatically switched between PBV and PBR depending on whether caller and callee happened to be co-located; well, that might not have been the greatest idea because many apps don't enjoy having their calling semantics switched on them based on the whims of how the sysadmin partitioned the app. :)

I was one of the ppl who begged for some kind of "uber" interface that I call them "Business Interface" on Bill's blog. Let the container find out "how the sysadmin partitioned the app" locate the needed resource and inject it where I have put an annotation. If the JEE would shine as a platform it should ease the devs pain, and be productive in the managers eyes. declarative programming++ visual tooling++ esoteric sorcery-- Regards Daoud AbdelMonem Faleh.

If the JEE would shine as a platform it should ease the devs pain, and be productive in the managers eyes.
declarative programming++
visual tooling++
esoteric sorcery--

Regards
Daoud AbdelMonem Faleh.

All great advice for us esoteric sorcerers on the JCP expert groups :) Reza Rahman Co-Author, EJB 3 in Action Expert Group Member, EJB 3.1 and Java EE 6 Chief Software Architect, Tripod Technologies

Let the container find out "how the sysadmin partitioned the app" locate the needed resource and inject it where I have put an annotation. If the JEE would shine as a platform it should ease the devs pain, and be productive in the managers eyes.
declarative programming++
visual tooling++
esoteric sorcery--

Regards
Daoud AbdelMonem Faleh.

Doing what you are asking (locating the desired resource) is certainly doable and useful, but is completely separate from switching between PBR and PBV semantics.

+1 Taking it a step further, why not see if Sun could set up a JCP forum on the Java forums to allow input from individual users, allowing Java community members to actually take ownership and help shape the JSRs, enabling more of a community stakeholdership (if that's a word) in the process?

There is actually such a thing: http://community.java.net/jsr/ Onno.

I believe Websphere will handle method calls to EJBObjects with PBR if it recognizes that the caller and EJBObject are in the same JVM. This is super, but when moves from unpartitioned development into partitioned production the performance has been known to suffer.

I believe Websphere will handle method calls to EJBObjects with PBR if it recognizes that the caller and EJBObject are in the same JVM.

This is super, but when moves from unpartitioned development into partitioned production the performance has been known to suffer.

Nope, this is incorrect and would violate the EJB specification if it worked this way. (The EJB compatibility test suite from Sun actually tests whether app servers handle this correctly.) WebSphere does perform some optimizations if the caller and callee are in the same JVM, but the arguments are still passed by value (always) when using a remote interface. The optimizations are that we don't marshall the args into an IIOP buffer because they'd just be immediately unmarshalled by the receiver, so instead we skip the marshall/unmarshall completely.