JSR-111 Accepted for Developement

[Berin Loritsch <bl...@apache.org>]

As of April 3, 2001 JSR 111 (Java Services) has been approved.
The link to the approval summary page is:
http://java.sun.com/aboutJava/communityprocess/vote/jsr/jsr_111.html

Here is the summary provided by Sun:

				 
On 02-Apr-2001, Oracle voted YES with no comment.

------------------------------------------------------------------------------

*** On 02-Apr-2001, Inprise voted NO with the following comment:
Borland shares the concerns expressed by Sun, BEA, Caldera and Doug Lea.

------------------------------------------------------------------------------

*** On 02-Apr-2001, WebGain voted NO with the following comment:
WebGain likes the basis of this JSR, but also believes that the scope is too broad and has concerns on the impact to the development
process.

------------------------------------------------------------------------------

On 02-Apr-2001, IBM voted YES with the following comment:
IBM are voting yes, with some reservations over the scope of this proposed framework JSR. On balance, we feel that the effort has
sufficient potential of value that it is worth letting an Expert Group get to grips with a more detailed work definition. If this
proceeds, we recognize the risk of a no-vote at Community review if we're surprised (although similar comments could be made about
other recent JSRs).
Coexistence with certain other JSRs needs addressing early by the Expert Group.
Specifically:
- We assume that this JSR can coexist with JSRs for J2EE 1.x, without requiring
co-requisite changes/extensions if possible,
- Co-ordination with JSR 109 (Implementing Enterprise Web Services) is vital (and has been agreed, I believe),
- Continued commitment to keeping in sync with JSR 96 (Java Daemons) is also necessary.

------------------------------------------------------------------------------

*** On 02-Apr-2001, Sun voted NO with the following comment:
Sun shares the concerns expressed by BEA, Caldera,
and Doug Lea.  At present the JSR seems overly
broad and vague.  It may be appropriate to define
some APIs in this space, but we would suggest that
a narrower and more focused JSR is more desirable,
and is more likely to achieve widespread adoption.

------------------------------------------------------------------------------

On 02-Apr-2001, Apache voted YES with the following comment:
Apache believes, from a pure technological point
of view, a framework as discussed in this JSR needs more direct research (even if current
Avalon is reaching the point where it's solid enough from a design point of view) and research cannot easily be done at a JSR
level.  However, we are willing to give the nod to this JSR with the following considerations:

1) This JSR should *NOT* have a tight schedule: developing a framework is something that takes time, even with lots of previous
experience.

2) Apache is very happy to contribute to the global experience in this field with one or more Avalon developers.  We suggest the
mailing list be run in an open manner, similar to JSR-102.

3) Apache offers to host the reference implementation, and will be glad to refactor Avalon's next generation to make it compliant
with what the JSR comes out with, if the Avalon community finds it appropriate to do so.

------------------------------------------------------------------------------

On 02-Apr-2001, Fujitsu voted YES with the following comment:
We consider this JSR should describe more clearly the coverage of this JSR and the relationship with JSR96 and other JSRs.

------------------------------------------------------------------------------

*** On 02-Apr-2001, Doug Lea voted NO with the following comment:
This proposal is in too preliminary a state to approve. It whould be reworked to be more concrete and to indicate interactions with
other
JSRs. Alterntively, the proposers may wish to
consider working within other existing JSRs to
achieve their goals.

------------------------------------------------------------------------------

On 02-Apr-2001, IONA voted YES with no comment.

------------------------------------------------------------------------------

*** On 30-Mar-2001, Caldera voted NO with the following comment:
Caldera views this project as overly ambitious and needs to better defined.

------------------------------------------------------------------------------

*** On 30-Mar-2001, BEA voted NO with the following comment:
BEA is concerned that this JSR is overly broad in scope, and not sufficiently well understood to be ready for standardization. We
are also not convinced that the envisioned uniform services model for all of Java is desirable given the substantial usage
differences between J2EE, SE, and ME. Finally, BEA would also like to better understand why this JSR is directly relevant to the
rank and file Java developer---i.e., what are the salient APIs going to look like? (Systems programming JSRs inherently should have
a more compelling case behind them than those focused at Java APIs).

------------------------------------------------------------------------------

On 30-Mar-2001, Compaq voted YES with no comment.

------------------------------------------------------------------------------

On 23-Mar-2001, Apple voted YES with no comment.

------------------------------------------------------------------------------

On 23-Mar-2001, HP voted YES with no comment.

------------------------------------------------------------------------------

On 23-Mar-2001, Cisco voted YES with no comment.

------------------------------------------------------------------------------

---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org