unitsofmeasurement / unit-ri Goto Github PK

public ParserException(String message, CharSequence parsedData, int position) should be the constructor used when there is an error message as this stores the error message in the exception message. Currently, we are getting unhelpful messages like javax.measure.format.ParserException: Parse Error which do not contain any useful message.

The OutputHelper class is currently in the "format" package. It is closer to logging/output than formatting and parsing, so it is advisable to move it to "util".

This is related to unitsofmeasurement/unit-api#45 on the API level, but a CompoundUnit could be introduced without an API level "convenience" method if this type of unit is found useful.

Maybe we could use ServiceProvider.current().getUnitFormatService().getUnitFormat() instead of SimpleUnitFormat.getInstance() in relevant parts of:
https://github.com/unitsofmeasurement/unit-ri/blob/master/src/main/java/tec/units/ri/AbstractUnit.java

It would make it a little more implementation-neutral although SimpleUnitFormat exists in all major implementations. And allow to use a UnitFormat of your choice if e.g. an extension or application overrides the default. Then e.g. MyUnitFormat instead of SimpleUnitFormat could be used. Where this is not overriden, the default would still apply.

The constructor TransformedUnit(String symbol, Unit<Q> parentUnit, UnitConverter unitConverter) currently does not use the symbol, but should use it. Unlike those without a symbol argument.

Also change JavaDoc

See https://java.net/jira/browse/UNITSOFMEASUREMENT-195

The multiply(Number) method in
https://github.com/unitsofmeasurement/unit-ri/blob/master/src/main/java/tec/units/ri/quantity/LongQuantity.java
usesintValue()of Number, but it should use longValue() to handle bigger numbers.

Via StackOverflow: http://stackoverflow.com/questions/43308544/jsr-363-formating-a-volume-unit-in-decilitre?sem=2

I am curious if there is a factory available that will return Units based on their standard string names

e.g

if it is "m" it should return Units.METRE
if it is "km" it should return MetricPrefix.KILO(Units.METRE)

UnitFactory.getUnit("m") => Units.METRE

Thanks!

At the moment, UnitFormat.label() helps format units in most cases where the symbol may not be available or a different display character is required for a particular unit.
As examples like https://github.com/unitsofmeasurement/uom-demos/blob/master/domain/energy/src/main/java/tec/uom/demo/energy/DemoUnitSystem.java show, this right now has to be done for all known (or used) multiples and submultiples of a unit, too. E.g.

 SimpleUnitFormat.getInstance().label(WATTHOUR, "Wh");
 SimpleUnitFormat.getInstance().label(KILO(WATTHOUR), "KWh");

Even with SimpleUnitFormat known multiples and sub-multiples (like those defined by MetricPrefix of a unit should ideally be formatted automatically, so "Wh" becomes "KWh", "MWh", "mWh" etc. when KILO, MEGA or MILLI are applied.

Given most JSRs have more or less fancy and "divine" code names for Reference Implementations like

• Moneta (JSR 354)
• Soteria (JSR 375)
• Diana / Artemis (Eclipse JNoSQL, not a JSR yet)
  I wanted to raise the question of a code name for this RI if the JSR progresses (likely with a new number)

Two mythological names both related to senses or measurement are:

• Indriya - the Sanskrit and Pali term for physical strength or ability in general, and for the senses more specifically
• Thoth or Djehuti - Ancient Egyptian God of Knowledge, the Moon, Measurement, Wisdom,...
• Seshat - Companion/daughter of Thoth

Something like

The current one is broken

Hi

When working with alternate unites like Feet, Fahrenheit and so on, a custom symbol can be used, but in the TransformedUnit constructor, the symbol is being ignored:

  public TransformedUnit(String symbol, Unit<Q> parentUnit, UnitConverter unitConverter) {
    this(null, parentUnit, parentUnit.getSystemUnit(), unitConverter);
  }

A simple change would really help out:

  public TransformedUnit(String symbol, Unit<Q> parentUnit, UnitConverter unitConverter) {
    this(symbol, parentUnit, parentUnit.getSystemUnit(), unitConverter);
  }

Thanks and regards

Remove VersionEye badges, add a stability badge

See unitsofmeasurement/uom-se#156

To improve ME/SE interoperability, all parts of the RI that do not explicitely require it should not use Serializable.

Following unitsofmeasurement/uom-se#139 to be consistent between RI and SE implementation

The Measurement interface is the general abstraction of a Quantity. Allowing even non-numeric or complex type values (e.g. Image or Video) in certain use cases. However, Quantity specializes, thus extends Measurement, so abstract base types like AbstractQuantity and everything extending it also implements Measurement.

Do we want to keep a base class like AbstractMeasurement in the RI or leave it to 3rd party libraries, either at unitsofmeasurement.org or elsewhere?

Are there plans to create multidimensional quantities? I'm looking for a replacement for JScience VectorMeasure.
http://jscience.org/api/javax/measure/VectorMeasure.html

Thanks!

While API classes and interfaces are generally in the ~1 or below range (representing the maturity of some interfaces like Unit or Quantity that seems appropriate) some 4.x or 5.x numbers in the RI (driven by JScience or other implementations) seem a bit high.

As a rule of thumb, if a version was 5.4, we'll down-scale it to 0.4, if it was 5.0, on a case by case basis the overall RI version sounds best.

Related to #14 how about the following suggestion:
Except for Abstract* classes

• move BaseQuantity and BaseMeasurement into a "quantity" package
  (it's a bit of a pickle for *Measurement, but we could think of something if it's a real problem)
• move all concrete Unit implementations to a new sub-package like "unit"
  The "model" package could be renamed "dimension", but that has a lower priority, optional if we feel this is a better name. Other than that the concrete classes are already in their package for Dimension.

See unitsofmeasurement/uom-se#165

See unitsofmeasurement/uom-se#158 but for #62

Plus refining primitive comparison so only compatible types like "floating point" or "integer" ones get compared in a resource-effective manner.

Remove references to BigDecimal in the RI to ensure ME compatibility