You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jcp-open@apache.org by "Geir Magnusson Jr." <ge...@pobox.com> on 2010/01/25 14:26:25 UTC
JSR 275 - I would like to vote no
JSR 275 is a "Unit Specification" JSR. I've seen two presentations on the spec, and I'm not comfortable at a technical level that this is on the right track.
However, I represent the ASF (and not me), so I'd like some feedback on the spec - talk me out of it if you want :)
Sorry about the short timeframe - I have to vote tonight...
http://www.jcp.org/en/jsr/detail?id=275
Re: JSR 275 - I would like to vote no
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
it didn't pass.
On Jan 26, 2010, at 2:12 PM, Scott O'Bryan wrote:
> I'd support a no vote on this and from the looks of it, I don't think you're alone.. :)
>
> On 01/25/2010 06:26 AM, Geir Magnusson Jr. wrote:
>> JSR 275 is a "Unit Specification" JSR. I've seen two presentations on the spec, and I'm not comfortable at a technical level that this is on the right track.
>>
>> However, I represent the ASF (and not me), so I'd like some feedback on the spec - talk me out of it if you want :)
>>
>> Sorry about the short timeframe - I have to vote tonight...
>>
>> http://www.jcp.org/en/jsr/detail?id=275
>>
>>
>
Re: JSR 275 - I would like to vote no
Posted by Scott O'Bryan <so...@apache.org>.
I'd support a no vote on this and from the looks of it, I don't think
you're alone.. :)
On 01/25/2010 06:26 AM, Geir Magnusson Jr. wrote:
> JSR 275 is a "Unit Specification" JSR. I've seen two presentations on the spec, and I'm not comfortable at a technical level that this is on the right track.
>
> However, I represent the ASF (and not me), so I'd like some feedback on the spec - talk me out of it if you want :)
>
> Sorry about the short timeframe - I have to vote tonight...
>
> http://www.jcp.org/en/jsr/detail?id=275
>
>
Re: JSR 275 - I would like to vote no
Posted by Craig L Russell <Cr...@Sun.COM>.
Hi Geir,
I looked briefly at the specification and it seems ok to me.
On Jan 25, 2010, at 5:26 AM, Geir Magnusson Jr. wrote:
> JSR 275 is a "Unit Specification" JSR. I've seen two presentations
> on the spec, and I'm not comfortable at a technical level that this
> is on the right track.
Do you have any specific concerns?
Seems like they got the big issues right, defining ways of identifying
independently the "unit of measurement" and the "measurement".
Craig
>
> However, I represent the ASF (and not me), so I'd like some feedback
> on the spec - talk me out of it if you want :)
>
> Sorry about the short timeframe - I have to vote tonight...
>
> http://www.jcp.org/en/jsr/detail?id=275
>
Craig L Russell
Architect, Sun Java Enterprise System http://db.apache.org/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: JSR 275 - I would like to vote no
Posted by Andrus Adamchik <aa...@apache.org>.
On Jan 25, 2010, at 4:38 PM, Geir Magnusson Jr. wrote:
> rather than run to standardization, they EG was encouraged to get
> broad input, and create an implementation and USE IT in running code
> for real scientific and other workloads to see if it really works.
This approach makes sense to me.
Andrus
Re: JSR 275 - I would like to vote no
Posted by Craig L Russell <Cr...@Sun.COM>.
On Jan 25, 2010, at 6:38 AM, Geir Magnusson Jr. wrote:
>
> On Jan 25, 2010, at 8:58 AM, Andrus Adamchik wrote:
>
>> Hi Geir,
>>
>> I am not currently working with the problem domain touched by this
>> JSR, although I have some science background (a degree in
>> chemistry) and understand exactly where the need for this is coming
>> from.
>
> me too. I'm also/was a physicist, which is why some of this stuff
> rubbed me the wrong way (Mass isn't weight, for example...)
As I read it, Mass is in the standard, weight is only used as class,
variable, and method names in examples (not normative). They have
several examples of Weight as a subclass of Mass so they can use
Weight as a type in Person. Most developers (physicists excluded, of
course) would model a Person's mass as Weight, not Mass.
>
>> One day is not enough time to evaluate its technical merit, but
>> what I DON'T like is seeing the JRE standard library expand adding
>> yet another package ("javax.measure") that is too specialized.
>
> Yes
>
>>
>> Could you clarify something in this regard. Say this JSR goes
>> final. Does it automatically become a part of J2SE, or is it
>> possible for it to exist as a standalone package, and who defines
>> each of the outcomes?
>
> It is not automatically a part of J2SE, but it will be *very*
> difficult to replace once it "owns" the units/measure space, and to
> me, this is somewhat fundamental.
>
>>
>> I'd be -1 for the former and +1 for the later (unless I overlooked
>> some other warning signs in the API). I.e. this may (or may not)
>> turn out to be a fine library for scientists, but let's not put it
>> in the JRE.
>
> So of the problems, there is no time and date in this, and there
> should be.
Methinks there is another JSR for time and date. This JSR is already
complex just dealing with the relatively (compared to time/date)
issues of reconciling different units of measurement.
> There are oddities like constants in interfaces, things are named
> strangely, it's been argued that the API doesn't play well with
> existing APIs, etc.
>
> If you look at the initial vote :
>
> http://www.jcp.org/en/jsr/results?id=3216
>
> You'll see plenty of concerns and a real honest intent that rather
> than run to standardization, they EG was encouraged to get broad
> input, and create an implementation and USE IT in running code for
> real scientific and other workloads to see if it really works....
Was this ever done? If so, where is it? If not, it's a good reason to
reject it (EGs should take EC input seriously).
Craig
>
> geir
>
>
>
>>
>> Andrus
>>
>> On Jan 25, 2010, at 3:26 PM, Geir Magnusson Jr. wrote:
>>> JSR 275 is a "Unit Specification" JSR. I've seen two
>>> presentations on the spec, and I'm not comfortable at a technical
>>> level that this is on the right track.
>>>
>>> However, I represent the ASF (and not me), so I'd like some
>>> feedback on the spec - talk me out of it if you want :)
>>>
>>> Sorry about the short timeframe - I have to vote tonight...
>>>
>>> http://www.jcp.org/en/jsr/detail?id=275
>>>
>>>
>>
>
Craig L Russell
Architect, Sun Java Enterprise System http://db.apache.org/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: JSR 275 - I would like to vote no
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
On Jan 25, 2010, at 8:58 AM, Andrus Adamchik wrote:
> Hi Geir,
>
> I am not currently working with the problem domain touched by this JSR, although I have some science background (a degree in chemistry) and understand exactly where the need for this is coming from.
me too. I'm also/was a physicist, which is why some of this stuff rubbed me the wrong way (Mass isn't weight, for example...)
> One day is not enough time to evaluate its technical merit, but what I DON'T like is seeing the JRE standard library expand adding yet another package ("javax.measure") that is too specialized.
Yes
>
> Could you clarify something in this regard. Say this JSR goes final. Does it automatically become a part of J2SE, or is it possible for it to exist as a standalone package, and who defines each of the outcomes?
It is not automatically a part of J2SE, but it will be *very* difficult to replace once it "owns" the units/measure space, and to me, this is somewhat fundamental.
>
> I'd be -1 for the former and +1 for the later (unless I overlooked some other warning signs in the API). I.e. this may (or may not) turn out to be a fine library for scientists, but let's not put it in the JRE.
So of the problems, there is no time and date in this, and there should be. There are oddities like constants in interfaces, things are named strangely, it's been argued that the API doesn't play well with existing APIs, etc.
If you look at the initial vote :
http://www.jcp.org/en/jsr/results?id=3216
You'll see plenty of concerns and a real honest intent that rather than run to standardization, they EG was encouraged to get broad input, and create an implementation and USE IT in running code for real scientific and other workloads to see if it really works....
geir
>
> Andrus
>
> On Jan 25, 2010, at 3:26 PM, Geir Magnusson Jr. wrote:
>> JSR 275 is a "Unit Specification" JSR. I've seen two presentations on the spec, and I'm not comfortable at a technical level that this is on the right track.
>>
>> However, I represent the ASF (and not me), so I'd like some feedback on the spec - talk me out of it if you want :)
>>
>> Sorry about the short timeframe - I have to vote tonight...
>>
>> http://www.jcp.org/en/jsr/detail?id=275
>>
>>
>
Re: JSR 275 - I would like to vote no
Posted by Andrus Adamchik <aa...@apache.org>.
Hi Geir,
I am not currently working with the problem domain touched by this
JSR, although I have some science background (a degree in chemistry)
and understand exactly where the need for this is coming from. One day
is not enough time to evaluate its technical merit, but what I DON'T
like is seeing the JRE standard library expand adding yet another
package ("javax.measure") that is too specialized.
Could you clarify something in this regard. Say this JSR goes final.
Does it automatically become a part of J2SE, or is it possible for it
to exist as a standalone package, and who defines each of the outcomes?
I'd be -1 for the former and +1 for the later (unless I overlooked
some other warning signs in the API). I.e. this may (or may not) turn
out to be a fine library for scientists, but let's not put it in the
JRE.
Andrus
On Jan 25, 2010, at 3:26 PM, Geir Magnusson Jr. wrote:
> JSR 275 is a "Unit Specification" JSR. I've seen two presentations
> on the spec, and I'm not comfortable at a technical level that this
> is on the right track.
>
> However, I represent the ASF (and not me), so I'd like some feedback
> on the spec - talk me out of it if you want :)
>
> Sorry about the short timeframe - I have to vote tonight...
>
> http://www.jcp.org/en/jsr/detail?id=275
>
>