migrated from Bugzilla [#434006](https://bugs.eclipse.org/bugs/show_bug.cgi?id=4…34006)
status ASSIGNED severity _enhancement_ in component _Core_ for _---_
Reported in version _unspecified_ on platform _All_
Assigned to: gael lhopital
On 2014-05-02 11:02:11 -0400, Kai Kreuzer wrote:
> To facilitate type determination, value formatting and calculations, an optional unit property should be introduced to number items. This could e.g. make use of Eclipse UOMo.
On 2014-10-16 03:16:42 -0400, Kai Kreuzer wrote:
> **\* Bug 447299 has been marked as a duplicate of this bug. ***
On 2015-03-19 04:02:29 -0400, gael lhopital wrote:
> (In reply to Kai Kreuzer from comment # 0)
>
> > To facilitate type determination, value formatting and calculations, an
> > optional unit property should be introduced to number items. This could e.g.
> > make use of Eclipse UOMo.
>
> I'm ok to work on this point. I had a first look at UOMo and this introduces a dependency an issue with the package com.ibm.icu (version 1.50 needed while 1.52 is present). On the other hand, I found the JScience package that relies also on JSR-275 spec. Is it possible to choose go with this one in an eclipse project ?
>
> I started my tests by adding a unit member in DecimalType, but wondering what would be the best approach : adding unit capability to DecimalType, subclassing DecimalType to something like MeasureType, or putting unit in NumberItem ?
On 2015-03-20 11:51:17 -0400, Kai Kreuzer wrote:
> Gael,
>
> > I found the JScience package that relies also on JSR-275 spec. Is it possible to choose go with this one in an eclipse project ?
>
> JSR-275 has never made it to be an official Java-API. Its "living" successor is JSR-363 (https://www.jcp.org/en/jsr/detail?id=363) and we were already in contact with the spec lead about it and filed a CQ for the Eclipse IP team about it. You can find its current reference implementation at https://github.com/unitsofmeasurement/unit-api.
> I am not sure though, how it feels from a developer point of view in comparison to JSR-275. From your implementation it seems that JSR-275 is quite straight forward and useful. Could you check if JSR-363 is similar or if it is lacking anything you would expect?
>
> > I started my tests by adding a unit member in DecimalType, but wondering what would be the best approach
>
> This indeed needs to be discussed. Originally, I though it could be some kind of optional field in DecimalType, but thinking about it a bit more, this does not seem to be a workable solution.
> I pretty much like your suggestion with the MeasureType extending DecimalType - this seems to integrate pretty well with the existing structures.
> I have one concern, though: It leaves the unit unspecified for a NumberItem, i.e. an item can receive first a state "1 m" and afterwards "4 V" and it would happily accept this. A solution to this problem is the very recently introduced StateDescription on the Item interface - this could probably the resolution for this problem. We could add a unit information in here. Or would dimension actually be the better choice (to allow cm, m, km as possible states)? I am still a bit undecided here and would welcome your opinion :-)
On 2015-03-20 11:59:58 -0400, Dennis Nobel wrote:
> > I though it could be some kind of optional field in DecimalType, but thinking about it a bit more, this does not seem to be a workable solution.
>
> Why does it not seem to be a workable solution? What is better with introducing a new type? And for what kind of data is the NumberItem used then? If there is data without a unit (or maybe without a dimension) the unit can be empty or null in the NumberItem.
On 2015-03-20 12:15:42 -0400, Kai Kreuzer wrote:
> Ok, this might probably depend on whether we choose JSR-275 or JSR-363.
> I was already thinking along JSR-363 - in this case I would not want to split the value and the unit apart, but directly use a Quantity (https://github.com/unitsofmeasurement/unit-api/blob/master/src/main/java/javax/measure/Quantity.java) inside.
> Having a subclass would make it more obvious what you are actually holding. Note that we also already have PercentType as a subclass of DecimalType, this is imho a pretty similar situation.
On 2015-03-20 12:33:16 -0400, gael lhopital wrote:
> Funny, one of the expert in JSR-363 is the project owner of JScience (Jean-Marie Dautelle). Then I suppose the directions shall not be too different :)
>
> > Could you check if JSR-363 is similar or if it is lacking anything you would expect?
>
> I'll do
>
> > This indeed needs to be discussed. Originally, I though it could be some kind of
> > optional field in DecimalType, but thinking about it a bit more, this does not seem to be
> > a workable solution.
>
> It was my first attempt (to make it an optional field of DecimalType), but this introduces such ugly checks that I preferred to switch to MeasureType
On 2015-03-20 12:49:14 -0400, Kai Kreuzer wrote:
> Regarding the naming, I think I would prefer QuantityType over MeasureType - especially in case we go for JSR-363.
On 2015-03-20 12:50:26 -0400, gael lhopital wrote:
> You really never like the names I choose for my classes :)
On 2015-03-21 04:29:06 -0400, gael lhopital wrote:
> Hello Kai,
> I would need a bit of help, I really don't get how/what to add to project in order to have unitsofmeasurement operational in a project. There is so much spec docs everywhere but not concrete exemple on how to use this.
On 2015-03-21 06:19:01 -0400, gael lhopital wrote:
> Forget this last comment, I think I got it.
On 2015-03-22 16:33:06 -0400, gael lhopital wrote:
> Hello,
> A new version of former MeasureType, renamed to QuantityType and now based on unit-api is available here https://github.com/clinique/smarthome/tree/bug434006 for your comments.
>
> The transposition from JSR-275 is quite straitforward as you can see in the test unit. As I switched to quantity, it was not obvious why it should be a subclass of DecimalType, here I choosed to make it distinct.
On 2015-04-15 16:43:16 -0400, Kai Kreuzer wrote:
> Sorry for not having answered yet - I just want to let you know that the JSR363 CQ has not yet been approved as there is some discussion with the license. Once this is settled, I will come back on this.
On 2015-04-15 17:42:25 -0400, Werner Keil wrote:
> (In reply to Kai Kreuzer from comment # 12)
>
> > Sorry for not having answered yet - I just want to let you know that the
> > JSR363 CQ has not yet been approved as there is some discussion with the
> > license. Once this is settled, I will come back on this.
>
> Hopefully it won't be necessary, but just to mention it, there's another (approved) CQ for Unit-API 0.6: https://dev.eclipse.org/ipzilla/show_bug.cgi?id=5260 I would go for JSR 363 if we all get the go, but technically the intermediary 0.6 API is far closer to 363 than JSR 275 was.
On 2015-04-17 05:43:36 -0400, Werner Keil wrote:
> Had a short peek at QuantityType. Looks nice and similar to the idea that occurred to me when I saw the "types" library some while ago.
>
> Even without exposing it in a public method or member (it's already protected though) instead of the RI-specific AbstractQuantity it would be good to treat quantity as Quantity (API/JSR type) instead.
>
> Please note, for portability reasons and IoT support (Java ME) the JSR 363 RI does not support BigDecimal or BigInteger while the Java SE (8) port or UOMo (currently based on Unit-API 0.6, see https://dev.eclipse.org/ipzilla/show_bug.cgi?id=5260) do as they are intended for SE/EE environments. If this is not a problem and individual data items won't exceed Double or Long number values, the RI seems fine, but to be flexible, it would really be good to stick to Unit and Quantity wherever you can.
On 2015-04-17 11:52:45 -0400, gael lhopital wrote:
> Can you please point me more specifically on what you mean here :
>
> > Even without exposing it in a public method or member (it's already protected >though) instead of the RI-specific AbstractQuantity it would be good to treat >quantity as Quantity (API/JSR type) instead.
On 2015-04-27 09:41:46 -0400, Werner Keil wrote:
> Sure, line 40 of QuantityType should be:
> protected Quantity<?> quantity;
> instead of:
> protected AbstractQuantity<?> quantity;
>
> If you'd merge back any relevant changes from your GitHub fork into either GitHub or Eclipse.org repositories if the changes go live, I'd be happy to check it out when I can, then I may offer a pull-request for this or similar changes.
On 2015-04-28 09:57:18 -0400, gael lhopital wrote:
> Modified the code to follow your suggestion regarding AbstractQuantity and BigDecimal.
>
> Do you mean I shall push a PR on ESH right now ? I thought we had to wait for the discussion on this topic to go on.
On 2015-04-28 11:24:09 -0400, Werner Keil wrote:
> (In reply to gael lhopital from comment # 17)
>
> > Modified the code to follow your suggestion regarding AbstractQuantity and
> > BigDecimal.
> >
> > Thanks, good, will have a look.
> > As long as you're passing or retrieving numeric values mostly via Number (or methods like doubleValue(), etc.) there should be no risk of a BigDecimal overflow.
> >
> > Do you mean I shall push a PR on ESH right now ? I thought we had to wait
> > for the discussion on this topic to go on.
>
> No I thought if I added a PR to your fork you may merge that.
> http://dev.eclipse.org/ipzilla/show_bug.cgi?id=9154 states, it's up to the project (SmartHome) If you're in touch with Kai or other team members, feel free to ask them what their status is or if they have some internal clarification. Eclipse Legal and PMC all gave their "go";-)
On 2015-04-28 11:28:30 -0400, Kai Kreuzer wrote:
> Werner, where do you read that Eclipse Legal is fine with it? Afaik, the CQ in question is https://dev.eclipse.org/ipzilla/show_bug.cgi?id=9208 and there is no approval yet from the IP team, so I cannot do any further steps, I'm afraid.
On 2015-04-28 12:09:22 -0400, Werner Keil wrote:
> (In reply to Kai Kreuzer from comment # 19)
>
> > Werner, where do you read that Eclipse Legal is fine with it? Afaik, the CQ
> > in question is https://dev.eclipse.org/ipzilla/show_bug.cgi?id=9208 and
> > there is no approval yet from the IP team, so I cannot do any further steps,
> > I'm afraid.
>
> But https://dev.eclipse.org/ipzilla/show_bug.cgi?id=9154 says "Waiting for Project" (In reply to Kai Kreuzer from comment # 19)
>
> > Werner, where do you read that Eclipse Legal is fine with it? Afaik, the CQ
> > in question is https://dev.eclipse.org/ipzilla/show_bug.cgi?id=9208 and
> > there is no approval yet from the IP team, so I cannot do any further steps,
> > I'm afraid.
>
> The actual Orbit CQ clearly says
>
> > Approving for Orbit, subject to the projects approval.
> > https://dev.eclipse.org/ipzilla/show_bug.cgi?id=9154
>
> I asked and was told, "project" here means those that would like to to use it, AKA SmartHome.
>
> So since the actual Orbit CQ has been approved by Eclipse PMC, looks like there's an action item for you, on either or both of them (please ask Sharon or PMC members which, I also am not sure) Although one project is usually enough to justify adding to Orbit, I may file a similar request for UOMo referring to https://dev.eclipse.org/ipzilla/show_bug.cgi?id=9154. However, all projects that are interested should approve their tickets´.
On 2015-04-28 14:43:59 -0400, Kai Kreuzer wrote:
> > I asked and was told, "project" here means those that would like to to use it, AKA SmartHome.
>
> Right, and this is what Orbit probably usually does: They rely on the fact that a project CQ has been thoroughly checked and approved and then it is easy to add it to Orbit. But this does not mean that there is no approval for the project CQ necessary anymore. So let's see what Sharon will answer.
On 2015-07-02 03:45:55 -0400, gael lhopital wrote:
> Hi all,
>
> Any chance to move further on this topic ?
On 2015-07-09 06:09:38 -0400, Kai Kreuzer wrote:
> Unfortunately, there is still no decision from the Eclipse IP team :-|
> I will follow up on this, it is really time... Thanks for your patience.
On 2015-08-17 15:36:01 -0400, Werner Keil wrote:
> I'm afraid, Eclipse IP team refuses to use JSR 363 due to a misunderstanding of the JCP Spec License that applies to a whole lot of JSRs already in Orbit. Most significantly JSR 275 (which was added to Orbit under the wrong assumption it was BSD licensed, but it isn't)
>
> The only recommendation I can safely make is use Unit-API 0.6 like UOMo does, see https://dev.eclipse.org/ipzilla/show_bug.cgi?id=5260
>
> That is sound because it was done outside the JCP and not JCP Spec License applies here. The API is frozen but more supportable than the "dead" and rejected 275, so it would be a safe bet and do everything the JSR 275 or 363 API also do.
>
> HTH,
> Werner
On 2015-08-17 19:27:33 -0400, Werner Keil wrote:
> From looking at the "NumberUnit" branch, it seems, that actually uses JSR 275.
> Judging from https://dev.eclipse.org/ipzilla/show_bug.cgi?id=7583 (which I had to correct since the license assumption was simply wrong, the relevant versions of JSR 275 between 0.9.3 and 0.9.5 all share the same non-final Spec License you may know from JSR 363) the IP team's assumption won't make JSR 275 advisable to use either.
>
> Especially in the OSGi context of SmartHome, using Unit-API 0.6 and an implementation like UOMo could be best. It seems, ICU4J is also used by other parts of SmartHome, which (with~10MB) is the only significant dependency UOMo also uses under the hood. The actual UOMo bundles themselves are under 600 kb together. And the API JAR less than 50kb.
>
> How does that sound?
On 2015-08-18 20:19:58 -0400, gael lhopital wrote:
> As said higher, using UOMU v0.6 introduces a dependency issue :
>
> > I'm ok to work on this point. I had a first look at UOMo and this introduces a >dependency an issue with the package com.ibm.icu (version 1.50 needed while 1.52 >is present).
>
> Any idea on how to workaround ?
On 2015-08-19 13:31:17 -0400, Werner Keil wrote:
> Will have a look. In parallel we try to see, if a little to non invasive license presentation might work. Fortunately JSR 363 is still in progress, so before it's final we can make such changes more easily than others with an exact similar license file in place (e.g. JSR 107)
On 2015-08-20 04:54:52 -0400, gael lhopital wrote:
> Thanks.
> I've got some issues with this version of UOMo :
> - I workarounded for ICU in adding correct version in a lib folder in org.eclipse.smarthome.core but it adds 9.2 Mb of jar
> - The documentation of UOMo v0.6 is not in phase at all with sources, then implementation is really tedious
> - Not much sources of information, examples...
On 2015-08-21 05:06:26 -0400, gael lhopital wrote:
> Hello,
>
> I finally managed to have a working version with UOMo, for your review here :
> https://github.com/clinique/smarthome/tree/bug434006_UOMo
>
> The point is still the ICU library, that I didn't found how to avoid including in
> the bundle.