The Java Community Process(SM) Program - JSRs: Java Specification Requests

Use of JCP site is subject to the JCP Terms of Use and the Oracle Privacy Policy

JSR #108
Units Specification
JSR Review Ballot
Ballot duration: 2001-03-06 to: 2001-03-19

These are the final results of the JSR Review Ballot for JSR #108. The Executive Committee for SE/EE has approved this ballot.

Votes

SE/EE

Accenture

Apache Software Foundation

Apple Computer, Inc.

BEA Systems

Borland Software Corporation

Caldera Systems

Cisco Systems

Compaq Computer Corporation

Fujitsu Limited

Hewlett-Packard

IBM

Lea, Doug

Oracle

Progress Software

Sun Microsystems, Inc.

WebGain

Icon Legend
Yes
No
Abstain
Not voted

View Vote Log

SE/EE

On 2001-03-19 BEA Systems voted Yes with no comment.
------------------------------------------------------------------------------
On 2001-03-19 WebGain voted Yes with no comment.
------------------------------------------------------------------------------
On 2001-03-19 Borland Software Corporation voted Yes with no comment.
------------------------------------------------------------------------------
On 2001-03-19 Hewlett-Packard voted Yes with no comment.
------------------------------------------------------------------------------
On 2001-03-19 Progress Software voted Yes with no comment.
------------------------------------------------------------------------------
On 2001-03-19 Compaq Computer Corporation voted Yes with no comment.
------------------------------------------------------------------------------
On 2001-03-16 Lea, Doug voted Yes with no comment.
------------------------------------------------------------------------------
On 2001-03-16 IBM voted Yes with the following comment:
A units facilty for Java seems potentially useful.  However, the approach proposed by the JSR (and embodied in the ucar.units package) has some problems.  Specifically, the class hierarchy seems poorly structured, with different units represented by instances of the Unit interface instead of by separate classes.  This means that relationships between units are not represented in the class hierarchy.  The ucar.units package also has problems with extensibility, since its BaseQuantity class includes hardwired constants for specific unit types such as AMOUNT_OF_SUBSTANCE, ELECTRIC_CURRENT, MASS, SOLID_ANGLE, etc, and it is not clear how additional types would be added without updating this class.  The Expert Group also needs to ensure that the specification includes sufficient usage scenarios and examples, which are somewhat lacking from the current ucar.units documentation. ** Fuller note sent to Spec Lead **
------------------------------------------------------------------------------
On 2001-03-15 Sun Microsystems, Inc. voted Yes with the following comment:
Sun supports this JSR, on the understanding
that it will not involve any Java language changes.

We agree with the submitter of the JSR that language
changes for units are likely to be difficult and
that library APIs should provide adequate support.
------------------------------------------------------------------------------
On 2001-03-06 Cisco Systems voted Yes with the following comment:
Couple of observations:
1. As a Mechanical Engineer and having written a few engineering programs, I think this is a good initiative.

2. We might have to take into consideration the context like Geography, time zones et al. If we are dealing with pure physical quantities may be not, but if we venture into derived units, we would need these standardized context as well.

-- cheers

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