unitsofmeasurement / indriya Goto Github PK

Set up a CI instance for Indriya

Java 10 just went Final: https://www.oracle.com/corporate/pressrelease/Java-10-032018.html

Let's test it with Indriya and the current JSR 385 snapshot to see, if there are any side-effects or issues.
Of the (very few) features introduced with Java 10, the local variables are certainly something we must evaluate against JSR 385 to ensure, units and quantities work well with the new var declaration.
Not sure about Class-Data-Sharing, it could mean some performance-benefit, if e.g. JSR related classes are shared at the right time, but mabe a bit less crucial than local variables.

To match the underlying SimpleUnitFormat, DefaultQuantityFormat should better be called SimpleQuantityFormat

Currently to reuse it across different implementations, BinaryPrefix resides in uom-lib-common. While Indriya is likely to use much of that library also in 2.0 we could move BinaryPrefix to the unit package next to MetricPrefix, too.

This is related to unitsofmeasurement/unit-api#45 on the API level.

See unitsofmeasurement/unit-ri#65

Following its addition with #26 there should be more JUnit tests for BinaryPrefix.

Should we add the Maven plugin for PIT, so we can use mutation testing to check unit test code coverage?

Info about PIT: http://pitest.org/
How to add the plugin: http://pitest.org/quickstart/maven/

See unitsofmeasurement/uom-se#158

Follow-up to unitsofmeasurement/uom-se#145

Example (currently failing):

IntegerQuantity<ElectricResistance> oneIntOhm = new IntegerQuantity<ElectricResistance>(Integer.valueOf(1).intValue(), Units.OHM);
LongQuantity<ElectricResistance> oneLongOhm = new LongQuantity<ElectricResistance>(Long.valueOf(1).longValue(), Units.OHM);
Quantity<ElectricResistance> sum = oneIntOhm.add(oneLongOhm);
assertEquals(LongQuantity.class, sum.getClass());

IntegerQuantity + LongQuantity should result in a LongQuantity, just like LongQuantity + IntegerQuantity currently results in a LongQuantity.

The widening should probably be as follows (transitively):

byte → short → int → long → BigInteger
float → double → BigDecimal
any integer type → any decimal type

This behavior should apply to addition, subtraction, multiplication and division.

With JUnit 5 offering many new and advanced features, it seems a good idea to adopt the new version.

• Create Wiki page
• Copy/Move relevant portions of the Equality documentation to the [UoM Guide]
  (https://github.com/unitsofmeasurement/uom-guide)
• Mention this problem in the Specification, probably in a new chapter

See unitsofmeasurement/uom-se#164

Right now the string representation of any Unit based on AbstractUnit uses SimpleUnitFormat in its default variant.
There was an attempt to make this dynamically use the current UnitFormat of the current ServiceProvider, but it had unpredictable and unwanted side-effects that could lead to initialization of AbstractUnit being prevented. Since a chain of different modules may have a similar effect, it is not too likely to work here in the future either (if you feel you have a working, stable answer, please propose it)

However, it should be possible to offer a simple and easy tweak, e.g. via System properties to select e.g. between:

• SimpleUnitFormat.DEFAULT (predefined)
• SimpleUnitFormat.ASCII for ASCII characters only
• EBNFUnitFormat
• LocalUnitFormat

All of which are build in.

Similar to https://github.com/unitsofmeasurement/unit-api/tree/gh-pages for the API

The code coverage is currently 40%, see codecov badge. We should create more JUnit tests especially in packages with a very low coverage. At least 60% like the JSR 363 RI should be archived, if more, even better.

Both ComparableQuantity and ComparableUnit interfaces have an isEquivalentOf() method. Should we keep that name or use a shorter version like:

• isEquivalent()
• equivalentOf()
• equivalent()

According to Oxford English using "of" or "to" depend, if "equivalent" is used as adjective or noun. We should decide which one better applies here.

Please select from the following options:

https://github.com/unitsofmeasurement/unit-ri/blob/9e5b2556b41dfc470c3b9bfb6d23d5f74d115485/src/main/java/tec/units/ri/function/RationalConverter.java#L178

In this line, the hash is the sum of dividend is added to itself. I think it should be the sum of dividend added to divisor.

See unitsofmeasurement/uom-se#180
Rest under #7

To be in better sync with the API the initial version should be 1.0. This version fully implements Unit-API 1.0 until the new version is created.

EBNFUnitFormat takes TransformedUnit into consideration, especially if a symbol was set. SimpleUnitFormat currently does not use the symbol unless the same string is also applied as label.

Update headers for JSR 385.

After AbstractQuantityFormat has its new name it should implement a QuantityFormat interface from the API.

The SI redefinition https://www.euramet.org/publications-media-centre/news/?tx_news_pi1%5Bnews%5D=637&tx_news_pi1%5Bcontroller%5D=News&tx_news_pi1%5Baction%5D=detail&cHash=d1b21b8e8a4522f5cfcf3b101a095f04 makes elementary constants like the Avogadro constant, Planck constant or Elementary charge more important than they already used to be.

Right now a few of them are defined internally in the NonSI class of the SI Units module.

Given their increased role, we could either:

The CompoundUnit class was introduced, but it can use some improvement. E.g. the notion of upper/lower changed into a more list-like representation.

Follows #1
Needs #17

Currently SystemOfUnits has a descriptive name and getName() method. Although registered under a key and possible aliases (currently this is implementation-specific, using the getter in the SPI interface) the UnitFormat implementation class only has a class name. Which may not always be a nice, human-readable string. Overriding toString() can help, so this could be sufficient, but let's discuss the question of a descriptive string when new versions of the API arise.

unitsofmeasurement/uom-se#172

Before the "tech" domain became available after March 2015 the RI and TCK used a "virtual" domain name units.tec I registered instead. Since then units.tech is also registered. While the "tec" domain is fairly cheap, it won't work as a URL, it is just virtual.
Should we use the 2.0 release and switch to units.tech instead?

Depending on the choice for Indriya, the new TCK would also match its package namespace.

The package-info contains old or badly formatted content like

• unitsofmeasurement.org (old project site)
• [code]

Right now all Unit classes rely on UnitFormat.label() if the string representation needs to be altered or overriden. TransformedUnit also defines a symbol, but it does not seem used when formatting. Also see unitsofmeasurement/uom-se#188

The System class Units returns WATT as AlternateUnit. it should be just a Unit.

To make Indriya backward-compatible with other Java versions (at least SE 8, maybe also 7) and explore new features in upcoming versions of the JDK, we plan to support the Java 9 Multi-Release JAR feature.

This blogpost by JSR 380 Spec Lead Gunnar http://in.relation.to/2017/02/13/building-multi-release-jars-with-maven/ may help. Seems either for Bean Validation or other Hibernate projects he already used that.

Also an interesting lead is this GitHub project: https://github.com/metlos/multi-release-jar-maven-plugin

The helper class Calculus is quite similar to e.g. NaturalQuantityComparator which also resides in the function package. The top level package is primarily for abstract base classes.

Hi,

I did a bit of brush-up to Indriya over the holidays. And through JUnit tests for CompoundUnit a problem occurred to me we should rethink the need for a CompoundUnit as opposed to something like a CompoundQuantity.

It is currently possible to create a compound chained across even multiple steps like HOUR.compound(MINUTE).compound(SECOND). However, trying to combine this type of Unit into the current Quantity, how to handle "1 hour: 5 minutes: 30 seconds", if only the unit part is multidimensional? We may need something along the lines of a CompoundQuantity. JSR 310 TemporalAmount could be a very vague inspiration, but we should ask ourselves questions like do we need a List or Set of units, because TemporalAmount states

The list of units completely and uniquely represents the state of the object without omissions, overlaps or duplication

Which would speak for a Set avoiding duplication.

Either way, it seems we have to think about that and come up with an idea how to best combine a "list" of Unit elements and numeric values attached. JSR 310 TemporalAmount implementations are overly simplified, they do not allow more than 2 or 3 distinct units each. E.g. "Year, month, day" in case of the Period. We need a more flexible approach for general purpose unit support.

See unitsofmeasurement/uom-se#124

Right now AbstractQuantityFormat is a factory for package-local concrete implementations. This is less flexible for extensions outside the RI, so similar to UnitFormat implementations each concrete class should be able to instantiate itself.

It should include:

• Convention on how to relate commits and pull requests to issues
• Setting up the code formatter in Eclipse

#6

If there is a large difference in the metric prefixes such that overflow becomes possible, the implementation of the addition and the subtraction is too naive.

Example using IntegerQuantity:
2 YΩ - 1 yΩ = 2 YΩ (correct)
2 yΩ - 1 YΩ = -2147483645 yΩ (incorrect, should have been -1 YΩ)

The implementations should cast the values to the largest metric prefix, not the metric prefix of the first element.

Add a BigIntegerQuantity type for large integer numbers.

The abstract base class QuantityFormat should be renamed to AbstractQuantityFormat

It should return 1,001 mΩ on 1 Ω + 1 mΩ.

I recently stumbled on some pretty nasty behavior that I think should probably be changed.

What does the following return?

public Quantity<Length> scale(Quantity<Length> q) {
  return q.multiply(Math.sqrt(2));
}

Unfortunately, it depends. If you pass in an IntegerQuantity, you end up with exactly the same value you passed in, because IntegerQuantity truncates before multiplying: https://github.com/unitsofmeasurement/unit-ri/blob/master/src/main/java/tec/units/ri/quantity/IntegerQuantity.java#L91

But, Quantities.getQuantity(...) returns the same static type independent of the type of the number you pass in, which makes this behavior very surprising.

This seems very dangerous, especially for a library whose main point is to avoid silent calculation bugs due to unit mismatch...

See unitsofmeasurement/unit-api#80

Right now AnnotatedUnit is not properly supported by SimpleUnitFormat while it works in other UnitFormat implementations like EBNFUnitFormat.