Last week, two new JSRs were posted to the JCP that expand the number of scenarios in which a J2EE appserver can be used. JSR 237, the Work Manager for Application Servers will finally open the door to multi-threaded development within the appserver. JSR 236, the appserver Timer Service will allow you to schedule and receive timer notification callbacks to an application-specified listener.

Check out JSR 237 Work Manager for Application Servers, and JSR 236 Timer for Application Servers.

Is the SDO spec going to be added as a JSR as well?

Sandeep.

The SDO spec was also posted as a JSR last week:
http://www.jcp.org/en/jsr/detail?id=235

The new spec was discussed on TSS here, but we didn't specifically announce the JSR.
https://theserverside.com/home/thread.jsp?thread_id=22646

Thanks Sandeep!

Floyd

The three JSRs (235, 236, and 237) proposed by IBM/BEA are exactly that, proposals. They have not been accepted into the JCP process yet, and so we cannot conclude that will become a part of J2EE.

I'm not saying that they won't be accepted, I'm just saying that its not a forgone conclusion. The members of the EC are still reviewing these proposals and will vote on them next week.


Richard Monson-Haefel
http://www.monson-haefel.com

It was pretty fascinating to see BEA and IBM came in from left field announcing three new specs. Which they obviously plan to muscle (oops I meant see) through the JCP process, to being part of J2EE eventually.

This was right after Tod Nielsen, a top BEA executive, ex-Microsoft "software speedster" declared that things needed to move a little faster in the JCP.

His point was that "...the speed at which J2EE innovations are made available to customers--is equally important to overcome. No matter how simple J2EE becomes, if it pursues a glacial pace of innovation, it will freeze itself out of the market. Someone somewhere will come up with something faster. Perhaps not better--but faster. And speed rules..."

And then he went on to say that the JCP process needs to be changed: "...we need to reorder the process: innovate, implement and then standardize...".

What he did not say that the reordering seems to have started. Already! And we're three JSRs into the new regime already.

The message is quite clear:
Attention, everybody! Yes, especially you non-multi-billion-market-cap ones in the corner! Java and J2EE will now move at Microsoft speed!

And going back to the post about premature talk, I think what's premature is to suggest that the rest of the committee (and, Richard, I strictly refer to the corporate members of the JCP) will EVER develop the gumption to stand up to the double IBM/BEA juggernaut.

There. Now that that I've doing my Gerald Bauer rant, I can go back to coding.

Sandeep

Richard had some interesting comments on the subject of IBM/BEA within the context of the JCP.

I don't know if its so much about the "medium" of introducing change as the "method". So we move away from an utopian democratic process, to a process where some are "more equal" than others.

The ability of smaller players in the JCP to influence Java standards is primarily through participating in the spec development process, and secondarily, through feedback.

So, (IMHO!) while the JCP lets AllOfThem participate, they participate at the pleasure of TheFew.

Sandeep.

"Any customer can have a car painted any color that he wants so long as it is black" - (reputedly) Henry Ford.

I attended a J2EE "meet the experts" session at some Java event over 3 years ago, and the question came up regarding how small companies benefit from the JCP given that the lion's share of JCP technology benefits Sun, BEA, and IBM (paraphrasing). This was not an uncommon perception BEFORE the DotCom bust (when everyone was supposedly making money from Java), and, frankly, none of the "experts" were able to clearly enunciate a response.

My feeling is that the JCP is beneficial to smaller companies and developers only as long as the larger companies remain dedicated to supporting a portable, pluggable set of technologies. That creates a ecosystem for any smaller companies that can offer a competitive advantage (cost, geography, niche technologies, etc.)

On the other hand, I think the JCP needs to respond to Enterprise Java's two primary risks going forward:

1. Fragmentation (or lack of portability) - TSS shows that portability is achievable today. It needs to stay that way, and any efforts to maintain portability (initiated within or without the JCP) are good.
2. Inability to meet market needs - The JCP needs to move faster or Java will be at risk of being treated as a niche technology within a couple of years as taking down Java has become a high-priority for Microsoft. We need "easy development", "easy integration", and "easy multichannel" technologies, to name a few.

That doesn't mean that I think the JCP should try to achieve Microsoft's speed of decision-making. Microsoft can announce a new "standard" as easily as picking up the phone or sending an email. MS considers most of the MS-compatible software companies to be theives stealing their revenues.

The JCP has to strike a balance between creating an agile organization with the ability to react (offensively and defensively) to new market technologies and nurturing the ecosystem of companies and offer value to the core technology.

My feeling is that the JCP is beneficial to smaller companies and developers only as long as the larger companies remain dedicated to supporting a portable, pluggable set of technologies. That creates a ecosystem for any smaller companies that can offer a competitive advantage (cost, geography, niche technologies, etc.)

I totally agree that is what the JCP could be if it wanted. But most JSRs languish for year(s) without noticeable progress. Take for example JSR 198 (a year old and nothing to show) that's supposed to standardize IDE plugins -- except that Sun recently announced that NetBeans won't collaborate with Eclipse since porting the plugin API would be too much work. One possible explanation is that the JCP is an anti-competitive body, and the expert vendors are using it as a venue for long lasting and vaporous pre-announcements that discourage new arrivals. I've also heard a more benign explanation: that commitees are inherently slow, but I don't believe this -- these dot-com firms know how to dance in Internet time, else they never would have become market leaders.

aggressive schedule. Will they accomplish that?