fix state conversion between HSBType and DecimalType #2504
Conversation
fixes eclipse-archived#2471 Signed-off-by: Simon Kaufmann <simon.kfm@googlemail.com>
| @@ -165,6 +165,9 @@ public State as(Class<? extends State> target) { | |||
| } else { | |||
| return UnDefType.UNDEF; | |||
| } | |||
| } else if (target == HSBType.class) { | |||
| return new HSBType(DecimalType.ZERO, PercentType.ZERO, | |||
| new PercentType(this.toBigDecimal().multiply(new BigDecimal(100)))); | |||
There was a problem hiding this comment.
BigDecimal.valueOf(100) is preferred to new BigDecimal(100): "This 'static factory method' is provided in preference to a (long) constructor because it allows for reuse of frequently used BigDecimal values." (link) (another instance above also)
There was a problem hiding this comment.
@watou Thanks for that hint, didn't know that. But this valueOf talks about the constructor using a long. Does this argument also fit to ints (I need to look at the code why the static method is better then the constructor.
There was a problem hiding this comment.
This code shows that any ints between 0 and 10, inclusive, are better to use the valueOf(long) static factory method to avoid unnecessary construction of new BigDecimals. But remaining ignorant of the current implementation of valueOf and just going by the JavaDoc's advice seems sensible, should later/other implementations ever cache other values outside that range based on frequent usage (however unlikely we think that might be). I think there is no valueOf(int) static factory method because the int is just widened to a long without side effects.
There was a problem hiding this comment.
An alternative approach to minimizing the number of duplicate immutable objects in the heap, but with more certainty of outcome, would be to define and use a static member HUNDRED like
private static final BigDecimal HUNDRED = BigDecimal.valueOf(100);
Signed-off-by: Simon Kaufmann <simon.kfm@googlemail.com>
|
Many thanks @SJKA! |
|
Thanks a lot for fixing the failure. If I update now to the latest snaphot is it than implemented allready? |
|
No, you have to wait for this fix to be part of the next ESH stable build, see https://hudson.eclipse.org/smarthome/job/SmartHomeDistribution-Stable/changes. |
It looks like #2471 was caused by the missing conversion from DecimalType to HSBType. It got lost in #2334 because it was very well hidden in the super classes (i.e. PercentType/DimmerItem).
fixes #2471
Signed-off-by: Simon Kaufmann simon.kfm@googlemail.com