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.
-
New Timer Service and Work Manager JSRs (8 messages)
- Posted by: Floyd Marinescu
- Posted on: December 08 2003 12:38 EST
Threaded Messages (8)
- What happend to the SDO spec? by Sandeep Dath on December 08 2003 12:48 EST
- What happend to the SDO spec? by Floyd Marinescu on December 08 2003 13:08 EST
- These JSRs are proposed, but not yet accepted. by Richard Monson-Haefel on December 08 2003 15:25 EST
- These JSRs are proposed, but not yet accepted. by Sandeep Dath on December 08 2003 15:57 EST
-
These JSRs are proposed, but not yet accepted. by Sandeep Dath on December 08 2003 05:11 EST
-
Problems with the JCP by Monte Kluemper on December 09 2003 05:14 EST
- Problems with the JCP by Brian Miller on December 09 2003 02:19 EST
-
Problems with the JCP by Monte Kluemper on December 09 2003 05:14 EST
-
These JSRs are proposed, but not yet accepted. by Sandeep Dath on December 08 2003 05:11 EST
- These JSRs are proposed, but not yet accepted. by Sandeep Dath on December 08 2003 15:57 EST
- New Timer Service and Work Manager JSRs by Erik Bengtson on December 10 2003 15:59 EST
-
What happend to the SDO spec?[ Go to top ]
- Posted by: Sandeep Dath
- Posted on: December 08 2003 12:48 EST
- in response to Floyd Marinescu
Is the SDO spec going to be added as a JSR as well?
Sandeep. -
What happend to the SDO spec?[ Go to top ]
- Posted by: Floyd Marinescu
- Posted on: December 08 2003 13:08 EST
- in response to Sandeep Dath
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 -
These JSRs are proposed, but not yet accepted.[ Go to top ]
- Posted by: Richard Monson-Haefel
- Posted on: December 08 2003 15:25 EST
- in response to Floyd Marinescu
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 -
These JSRs are proposed, but not yet accepted.[ Go to top ]
- Posted by: Sandeep Dath
- Posted on: December 08 2003 15:57 EST
- in response to Richard Monson-Haefel
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 -
These JSRs are proposed, but not yet accepted.[ Go to top ]
- Posted by: Sandeep Dath
- Posted on: December 08 2003 17:11 EST
- in response to Sandeep Dath
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. -
Problems with the JCP[ Go to top ]
- Posted by: Monte Kluemper
- Posted on: December 09 2003 05:14 EST
- in response to Sandeep Dath
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. -
Problems with the JCP[ Go to top ]
- Posted by: Brian Miller
- Posted on: December 09 2003 14:19 EST
- in response to Monte Kluemper
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. -
New Timer Service and Work Manager JSRs[ Go to top ]
- Posted by: Erik Bengtson
- Posted on: December 10 2003 15:59 EST
- in response to Floyd Marinescu
aggressive schedule. Will they accomplish that?