[UNITSOFMEASUREMENT-195] Erroneous results when converting between transformed units Created: 29/Sep/16 Updated: 06/Oct/16 Resolved: 06/Oct/16 | |
Status: | Resolved |
Project: | unitsofmeasurement |
Component/s: | RI |
Affects Version/s: | 1.0 |
Fix Version/s: | 1.0.1 |
Type: | Bug | Priority: | Major |
Reporter: | omahdi | Assignee: | keilw |
Resolution: | Fixed | Votes: | 0 |
Labels: | None | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Description |
Quantities are not converted properly when converting between different transformed units, e.g. converting a quantity with unit Units.METRE to MetricPrefix.CENTI(Units.METRE) does not produce the expected result: This issue has been reported on stackoverflow.com and can be reproduced with the following code: package de.vsbw.obi.jtink; import javax.measure.spi.ServiceProvider; import javax.measure.Quantity; import javax.measure.quantity.Length; import javax.measure.spi.QuantityFactory; import tec.units.ri.unit.Units; import tec.units.ri.unit.MetricPrefix; public class JScienceUnits { public static void main(String[] args) { ServiceProvider provider = ServiceProvider.current(); QuantityFactory<Length> lengthFactory = provider.getQuantityFactory(Length.class); Quantity<Length> q = lengthFactory.create(3, Units.METRE); System.out.println("q = " + q + ", q.to(CENTI(METRE)) = " + q.to(MetricPrefix.CENTI(Units.METRE))); } The output is q = 5 m, q.to(CENTI(METRE)) = 0.05 cm instead of the expected q = 5 m, q.to(CENTI(METRE)) = 500.0 cm. Further investigation revealed a bug in the doubleValue(Unit<Q>) method of tec.units.ri.quantity.NumberQuantity at line 124, which erroneously builds a converter for the *inverse* unit transformation. Changing that line to UnitConverter converter = myUnit.getConverterTo(unit); seems to fix the issue. |
[UNITSOFMEASUREMENT-194] Prepare Final Created: 07/Aug/16 Updated: 28/Sep/16 Resolved: 28/Sep/16 | |
Status: | Resolved |
Project: | unitsofmeasurement |
Component/s: | API, RI, TCK |
Affects Version/s: | 0.9 |
Fix Version/s: | 1.0 |
Type: | Task | Priority: | Critical |
Reporter: | keilw | Assignee: | keilw |
Resolution: | Fixed | Votes: | 0 |
Labels: | None | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Tags: | final, release |
Epic Link: | Infrastructure |
Sprint: | Final Release |
Description |
Prepare Final release in JavaDoc and other areas where relevant. |
[Clarification]
best way to convert Product of units to product of baseUnits
(UNITSOFMEASUREMENT-182)
| |
Status: | Resolved |
Project: | unitsofmeasurement |
Component/s: | API |
Affects Version/s: | 0.8 |
Fix Version/s: | 0.9 |
Type: | Sub-task | Priority: | Major |
Reporter: | keilw | Assignee: | keilw |
Resolution: | Fixed | Votes: | 0 |
Labels: | None | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Issue Links: |
| ||||||||
Tags: | design, naming | ||||||||
Sprint: | Final Draft |
Description |
If Unit.getProductUnits() is renamed to getBaseUnits() or similar, would that imply, Dimension.getProductDimensions() should also be renamed or does Product make sense in its case? |
Comments |
Comment by keilw [ 22/Jun/16 ] |
The JavaDoc is oriented on descriptions by e.g. Wikipedia: https://en.wikipedia.org/wiki/Dimensional_analysis#Mathematical_properties
In UCAR they called it "factors" but its API consists of several additional elements, so we cannot directly compare them any more. https://en.wikipedia.org/wiki/Physical_quantity usually speaks of "Base Quantity" (though the dimension is also there) so should we rename getProductDimensions() to either getBaseDimensions() or e.g. getFundamentalDimensions() ? |
[UNITSOFMEASUREMENT-192] Short number support for Quantities Created: 18/Apr/16 Updated: 21/Jun/16 Resolved: 21/Jun/16 | |
Status: | Resolved |
Project: | unitsofmeasurement |
Component/s: | RI |
Affects Version/s: | 0.8 |
Fix Version/s: | None |
Type: | Improvement | Priority: | Major |
Reporter: | keilw | Assignee: | keilw |
Resolution: | Fixed | Votes: | 0 |
Labels: | None | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Tags: | embedded, number |
Epic Link: | Portability |
Sprint: | Final Draft |
Description |
See https://github.com/unitsofmeasurement/uom-systems/issues/29 embedded systems tend to use very small numeric types like Short which has no "wrapper" type in the RI (or SE port) right now. Therefore it is cast to some of the closest equivalent types which leads to differrent results/rounding errors. |
Refactoring
SPI (UNITSOFMEASUREMENT-152)
| |
Status: | Resolved |
Project: | unitsofmeasurement |
Component/s: | API |
Affects Version/s: | 0.8 |
Fix Version/s: | 0.9 |
Type: | Sub-task | Priority: | Major |
Reporter: | keilw | Assignee: | keilw |
Resolution: | Fixed | Votes: | 0 |
Labels: | None | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Tags: | factory, quantity, question, refactoring, vote |
Sprint: | Final Draft |
Description |
At the moment unlike the other 2 service interfaces, QuantityFactoryService only defines getQuantityFactory() for a single, default instance of QuantityFactory (per quantity). Although this involves some "caching" (depending on implementations) otherwise the service does not offer multiple factories or additional methods, so could we consider QuantityFactory itself a "service" (would not call it *Service here) and have ServiceProvider directly define getQuantityFactory() instead of getQuantityFactoryService() ? |
Comments |
Comment by desruisseaux [ 11/May/16 ] |
I would support this simplification proposal. |
Comment by keilw [ 11/May/16 ] |
Thanks, will speak to @otaviojava this week, too. If neither he nor others object we'll go for it. |
Refactoring
SPI (UNITSOFMEASUREMENT-152)
| |
Status: | Resolved |
Project: | unitsofmeasurement |
Component/s: | API |
Affects Version/s: | 0.8 |
Fix Version/s: | None |
Type: | Sub-task | Priority: | Major |
Reporter: | keilw | Assignee: | desruisseaux |
Resolution: | Fixed | Votes: | 0 |
Labels: | None | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Tags: | refactoring |
Sprint: | Final Draft |
Description |
This covers work done in https://github.com/desruisseaux/unit-api at the moment. |
Comments |
Comment by desruisseaux [ 31/Mar/16 ] |
Pull request created: https://github.com/unitsofmeasurement/unit-api/pull/30 |
Comment by keilw [ 31/Mar/16 ] |
Thanks. I suggest a tiny tweak after merging it. |
Comment by keilw [ 31/Mar/16 ] |
I had another thought on the static method names and it turns out, default() or getDefault() isn't really the right term if you look at it from a modular angle. As the API provides no fallback like Bootstrap did earlier, the "default" provider would be that offered by an implementation like the RI. Then if modules add their own providers with the right priority, they override that "default" and the "active" or "current" one is no longer the default. Let's try CDI's current() I think that puts it best. |
Refactoring
SPI (UNITSOFMEASUREMENT-152)
| |
Status: | Resolved |
Project: | unitsofmeasurement |
Component/s: | API |
Affects Version/s: | 0.8 |
Fix Version/s: | None |
Type: | Sub-task | Priority: | Major |
Reporter: | keilw | Assignee: | keilw |
Resolution: | Fixed | Votes: | 0 |
Labels: | None | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Issue Links: |
| ||||||||
Tags: | design, question | ||||||||
Sprint: | Final Draft |
Description |
Regardless of the name and functionality it offers, it's a valid question, if (the class currently known as) Bootstrap should be final as it is right now, making it the de-facto only <b>Singleton</b> for the API or if there was a need to sub-class it for some use cases? CDI is a good example although it is far more complex than what we need and our users may expect from the API and SPI, but one could imagine Bootstrap b = Bootstrap.current(); List<SystemOfUnitsService> systemOfUnitsServices = b.getServices(SystemOfUnitsService.class); ... Whether the name was Bootstrap, ServiceProvider (along the lines of JSONP: https://json-processing-spec.java.net/nonav/releases/1.0/pfd-draft/javadocs/javax/json/spi/JsonProvider.html) is subject to https://java.net/jira/browse/UNITSOFMEASUREMENT-152 and not directly relevant to this task. It could add more flexibility, but create an overhead having to call Bootstrap.current() (or default()) or similar first rather than just accessing static methods of Bootstrap. |
Comments |
Comment by keilw [ 30/Mar/16 ] |
I think this needs to be dealt with and documented, also see some later
discussions in https://java.net/jira/browse/UNITSOFMEASUREMENT-152. Each module may declare its "leaf" ServiceLoader class final if they want to prohibit extensions, otherwise keep it open to additional modules to extend. |
Comment by keilw [ 01/Apr/16 ] |
As it was merged with ServiceProvider that needs to be abstract by nature to allow extension. |
[UNITSOFMEASUREMENT-188] Comparator in RIServiceProvider Created: 22/Mar/16 Updated: 01/May/16 Resolved: 01/May/16 | |
Status: | Resolved |
Project: | unitsofmeasurement |
Component/s: | RI |
Affects Version/s: | 0.8 |
Fix Version/s: | None |
Type: | Improvement | Priority: | Major |
Reporter: | keilw | Assignee: | Unassigned |
Resolution: | Won't Fix | Votes: | 0 |
Labels: | None | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Epic Link: | Portability |
Description |
In the SE Port uom-se, its PriorityAwareServiceProvider uses Priority prio1Annot = o1.getClass().getAnnotation(Priority.class); via the @Priority annotation to sort services of a particular kind. That way e.g. extension modules can decide, if they want their own version of a service or that by the underlying implementation to be default or have a higher priority. Since getAnnotation() is not available on Java ME, we dropped this entirely from the RI. However, sorting by "some" criteria would be beneficial, but we have to make it available and use it under ME or leave this as a known limitation of the Reference Implementation. |
Comments |
Comment by keilw [ 01/May/16 ] |
This became irrelevant with refactoring of ServiceProvider which allows to use getPriority() and does not require extra annotations. |
[UNITSOFMEASUREMENT-187] uom-se doesn't compile with JDK 8 (update 73,74) Created: 21/Mar/16 Updated: 21/Mar/16 Resolved: 21/Mar/16 | |
Status: | Resolved |
Project: | unitsofmeasurement |
Component/s: | RI |
Affects Version/s: | 0.8, 0.9 |
Fix Version/s: | None |
Type: | Bug | Priority: | Critical |
Reporter: | lfoppiano | Assignee: | Unassigned |
Resolution: | Invalid | Votes: | 0 |
Labels: | None | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Description |
I'm trying to use the uom-se with JDK 8 but I'm facing some problem while compiling. I've seen similar problems were already raised and solved before but I could not find the cause of why it is still not compiling. I'm really not sure whether it is a problem on my local machine or something due to the JDK 1.8. I'm attaching the maven log: Johan:uom-se lfoppiano$ mvn clean install [INFO] Scanning for projects... [INFO] [INFO] ------------------------------------------------------------------------ [INFO] Building Units of Measurement Implementation for Java SE 0.8 [INFO] ------------------------------------------------------------------------ [INFO] [INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ uom-se --- [INFO] Deleting /Users/lfoppiano/development/inria/unit-normalization/uom-se/target [INFO] [INFO] --- maven-enforcer-plugin:1.2:enforce (enforce-maven) @ uom-se --- [INFO] [INFO] --- maven-resources-plugin:2.7:resources (default-resources) @ uom-se --- [INFO] Using 'UTF-8' encoding to copy filtered resources. [INFO] Copying 16 resources [INFO] [INFO] --- maven-compiler-plugin:3.3:compile (default-compile) @ uom-se --- [INFO] Changes detected - recompiling the module! [INFO] Compiling 83 source files to /Users/lfoppiano/development/inria/unit-normalization/uom-se/target/classes [parsing started RegularFileObject[/Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/format/AbstractUnitFormat.java]] [parsing completed 16ms] [parsing started RegularFileObject[/Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/spi/Range.java]] [parsing completed 3ms] [parsing started RegularFileObject[/Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/unit/ProductElement.java]] [parsing completed 1ms] [parsing started RegularFileObject[/Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/internal/format/Token.java]] [parsing completed 2ms] [parsing started RegularFileObject[/Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/quantity/time/TimeQuantities.java]] [parsing completed 3ms] [parsing started RegularFileObject[/Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/function/QuantityFunctions.java]] [parsing completed 8ms] [parsing started RegularFileObject[/Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/unit/package-info.java]] [parsing completed 1ms] [parsing started RegularFileObject[/Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/unit/Units.java]] [parsing completed 8ms] [parsing started RegularFileObject[/Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/quantity/time/TimedData.java]] [parsing completed 3ms] [parsing started RegularFileObject[/Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/function/QuantitySupplier.java]] [parsing completed 0ms] [parsing started RegularFileObject[/Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/format/DefaultQuantityFormat.java]] [parsing completed 1ms] [parsing started RegularFileObject[/Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/internal/DefaultSystemOfUnitsService.java]] [parsing completed 0ms] [parsing started RegularFileObject[/Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/unit/BinaryPrefix.java]] [parsing completed 2ms] [parsing started RegularFileObject[/Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/unit/AlternateUnit.java]] [parsing completed 2ms] [parsing started RegularFileObject[/Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/function/MinimumSupplier.java]] [parsing completed 0ms] [parsing started RegularFileObject[/Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/quantity/Quantities.java]] [parsing completed 2ms] [parsing started RegularFileObject[/Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/unit/MetricPrefix.java]] [parsing completed 3ms] [parsing started RegularFileObject[/Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/function/package-info.java]] [parsing completed 0ms] [parsing started RegularFileObject[/Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/internal/format/DefaultUnitFormatService.java]] [parsing completed 1ms] [parsing started RegularFileObject[/Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/quantity/DecimalQuantity.java]] [parsing completed 1ms] [parsing started RegularFileObject[/Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/spi/StandardModel.java]] [parsing completed 1ms] [parsing started RegularFileObject[/Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/internal/format/l10n/ResourceBundleEnumeration.java]] [parsing completed 1ms] [parsing started RegularFileObject[/Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/unit/BaseUnit.java]] [parsing completed 1ms] [parsing started RegularFileObject[/Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/function/ExpConverter.java]] [parsing completed 0ms] [parsing started RegularFileObject[/Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/function/QuantitySummaryStatistics.java]] [parsing completed 1ms] [parsing started RegularFileObject[/Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/quantity/DefaultQuantityFactory.java]] [parsing completed 2ms] [parsing started RegularFileObject[/Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/internal/format/LocalUnitFormatParser.java]] [parsing completed 8ms] [parsing started RegularFileObject[/Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/function/NaturalOrder.java]] [parsing completed 0ms] [parsing started RegularFileObject[/Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/spi/DimensionalModel.java]] [parsing completed 1ms] [parsing started RegularFileObject[/Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/ComparableQuantity.java]] [parsing completed 1ms] [parsing started RegularFileObject[/Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/internal/format/DefaultCharStream.java]] [parsing completed 4ms] [parsing started RegularFileObject[/Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/function/DescriptionSupplier.java]] [parsing completed 0ms] [parsing started RegularFileObject[/Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/format/Parser.java]] [parsing completed 0ms] [parsing started RegularFileObject[/Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/internal/format/l10n/BundleToMapAdapter.java]] [parsing completed 0ms] [parsing started RegularFileObject[/Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/format/SimpleUnitFormat.java]] [parsing completed 9ms] [parsing started RegularFileObject[/Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/function/MultiplyConverter.java]] [parsing completed 1ms] [parsing started RegularFileObject[/Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/function/PiDivisorConverter.java]] [parsing completed 1ms] [parsing started RegularFileObject[/Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/function/PiMultiplierConverter.java]] [parsing completed 0ms] [parsing started RegularFileObject[/Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/internal/quantity/DefaultQuantityFactoryService.java]] [parsing completed 0ms] [parsing started RegularFileObject[/Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/AbstractConverter.java]] [parsing completed 2ms] [parsing started RegularFileObject[/Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/internal/quantity/OldProxyQuantityFactory.java]] [parsing completed 4ms] [parsing started RegularFileObject[/Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/internal/format/UnitFormatParser.java]] [parsing completed 6ms] [parsing started RegularFileObject[/Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/function/LogConverter.java]] [parsing completed 0ms] [parsing started RegularFileObject[/Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/AbstractQuantity.java]] [parsing completed 2ms] [parsing started RegularFileObject[/Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/function/RationalConverter.java]] [parsing completed 1ms] [parsing started RegularFileObject[/Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/internal/format/TokenException.java]] [parsing completed 1ms] [parsing started RegularFileObject[/Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/format/EBNFUnitFormat.java]] [parsing completed 3ms] [parsing started RegularFileObject[/Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/function/MaximumSupplier.java]] [parsing completed 0ms] [parsing started RegularFileObject[/Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/function/ValueSupplier.java]] [parsing completed 0ms] [parsing started RegularFileObject[/Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/internal/PriorityAwareServiceProvider.java]] [parsing completed 0ms] [parsing started RegularFileObject[/Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/format/QuantityFormat.java]] [parsing completed 1ms] [parsing started RegularFileObject[/Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/AbstractSystemOfUnits.java]] [parsing completed 1ms] [parsing started RegularFileObject[/Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/internal/format/OutputHelper.java]] [parsing completed 1ms] [parsing started RegularFileObject[/Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/function/Nameable.java]] [parsing completed 0ms] [parsing started RegularFileObject[/Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/spi/Measurement.java]] [parsing completed 1ms] [parsing started RegularFileObject[/Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/internal/format/UnitTokenManager.java]] [parsing completed 2ms] [parsing started RegularFileObject[/Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/quantity/QuantityDimension.java]] [parsing completed 1ms] [parsing started RegularFileObject[/Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/quantity/NumberQuantity.java]] [parsing completed 0ms] [parsing started RegularFileObject[/Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/unit/TransformedUnit.java]] [parsing completed 1ms] [parsing started RegularFileObject[/Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/format/NumberSpaceQuantityFormat.java]] [parsing completed 1ms] [parsing started RegularFileObject[/Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/unit/ProductUnit.java]] [parsing completed 2ms] [parsing started RegularFileObject[/Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/package-info.java]] [parsing completed 0ms] [parsing started RegularFileObject[/Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/quantity/DoubleQuantity.java]] [parsing completed 2ms] [parsing started RegularFileObject[/Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/function/Converter.java]] [parsing completed 0ms] [parsing started RegularFileObject[/Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/internal/format/UnitTokenConstants.java]] [parsing completed 1ms] [parsing started RegularFileObject[/Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/function/UnitSupplier.java]] [parsing completed 0ms] [parsing started RegularFileObject[/Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/internal/format/l10n/NumberFormat2.java]] [parsing completed 2ms] [parsing started RegularFileObject[/Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/function/DoubleFactorSupplier.java]] [parsing completed 0ms] [parsing started RegularFileObject[/Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/format/FormatBehavior.java]] [parsing completed 0ms] [parsing started RegularFileObject[/Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/quantity/time/TimeUnitQuantity.java]] [parsing completed 0ms] [parsing started RegularFileObject[/Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/unit/AnnotatedUnit.java]] [parsing completed 0ms] [parsing started RegularFileObject[/Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/quantity/QuantityRange.java]] [parsing completed 1ms] [parsing started RegularFileObject[/Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/function/QuantityConverter.java]] [parsing completed 0ms] [parsing started RegularFileObject[/Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/function/UnitConverterSupplier.java]] [parsing completed 0ms] [parsing started RegularFileObject[/Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/internal/format/l10n/MultiPropertyResourceBundle.java]] [parsing completed 1ms] [parsing started RegularFileObject[/Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/format/LocalUnitFormat.java]] [parsing completed 3ms] [parsing started RegularFileObject[/Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/format/SymbolMap.java]] [parsing completed 1ms] [parsing started RegularFileObject[/Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/function/AddConverter.java]] [parsing completed 0ms] [parsing started RegularFileObject[/Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/internal/format/TokenMgrError.java]] [parsing completed 1ms] [parsing started RegularFileObject[/Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/quantity/time/TemporalQuantity.java]] [parsing completed 1ms] [parsing started RegularFileObject[/Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/spi/AbstractMeasurement.java]] [parsing completed 1ms] [parsing started RegularFileObject[/Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/AbstractUnit.java]] [parsing completed 2ms] [parsing started RegularFileObject[/Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/quantity/ProxyQuantityFactory.java]] [parsing completed 1ms] [search path for source files: /Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java,/Users/lfoppiano/development/inria/unit-normalization/uom-se/target/generated-sources/annotations] [search path for class files: /Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/jre/lib/resources.jar,/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/jre/lib/rt.jar,/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/jre/lib/sunrsasign.jar,/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/jre/lib/jsse.jar,/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/jre/lib/jce.jar,/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/jre/lib/charsets.jar,/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/jre/lib/jfr.jar,/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/jre/classes,/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/jre/lib/ext/cldrdata.jar,/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/jre/lib/ext/dnsns.jar,/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/jre/lib/ext/jfxrt.jar,/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/jre/lib/ext/localedata.jar,/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/jre/lib/ext/nashorn.jar,/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/jre/lib/ext/sunec.jar,/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/jre/lib/ext/sunjce_provider.jar,/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/jre/lib/ext/sunpkcs11.jar,/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/jre/lib/ext/zipfs.jar,/System/Library/Java/Extensions/MRJToolkit.jar,/Users/lfoppiano/development/inria/unit-normalization/uom-se/target/classes,/Users/lfoppiano/.m2/repository/javax/measure/unit-api/0.8/unit-api-0.8.jar,/Users/lfoppiano/.m2/repository/javax/annotation/javax.annotation-api/1.2/javax.annotation-api-1.2.jar,.] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/io/IOException.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/text/ParsePosition.class)]] [loading ZipFileIndexFileObject[/Users/lfoppiano/.m2/repository/javax/measure/unit-api/0.8/unit-api-0.8.jar(javax/measure/Unit.class)]] [loading ZipFileIndexFileObject[/Users/lfoppiano/.m2/repository/javax/measure/unit-api/0.8/unit-api-0.8.jar(javax/measure/format/ParserException.class)]] [loading ZipFileIndexFileObject[/Users/lfoppiano/.m2/repository/javax/measure/unit-api/0.8/unit-api-0.8.jar(javax/measure/format/UnitFormat.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/lang/Object.class)]] [loading ZipFileIndexFileObject[/Users/lfoppiano/.m2/repository/javax/measure/unit-api/0.8/unit-api-0.8.jar(javax/measure/UnitConverter.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/lang/reflect/Field.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/util/Enumeration.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/util/HashMap.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/util/Map.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/util/ResourceBundle.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/util/TreeMap.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/util/logging/Level.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/util/logging/Logger.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/lang/SuppressWarnings.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/lang/Appendable.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/lang/String.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/lang/CharSequence.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/lang/IllegalArgumentException.class)]] [loading ZipFileIndexFileObject[/Users/lfoppiano/.m2/repository/javax/measure/unit-api/0.8/unit-api-0.8.jar(javax/measure/quantity/Dimensionless.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/io/Serializable.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/math/BigInteger.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/lang/reflect/ParameterizedType.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/lang/reflect/Type.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/lang/Comparable.class)]] [loading ZipFileIndexFileObject[/Users/lfoppiano/.m2/repository/javax/measure/unit-api/0.8/unit-api-0.8.jar(javax/measure/Quantity.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/lang/StringBuilder.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/lang/Enum.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/lang/FunctionalInterface.class)]] [loading ZipFileIndexFileObject[/Users/lfoppiano/.m2/repository/javax/measure/unit-api/0.8/unit-api-0.8.jar(javax/measure/Dimension.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/util/Objects.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/lang/Class.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/lang/Integer.class)]] [loading ZipFileIndexFileObject[/Users/lfoppiano/.m2/repository/javax/measure/unit-api/0.8/unit-api-0.8.jar(javax/measure/UnconvertibleException.class)]] [loading ZipFileIndexFileObject[/Users/lfoppiano/.m2/repository/javax/measure/unit-api/0.8/unit-api-0.8.jar(javax/measure/IncommensurableException.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/math/BigDecimal.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/math/MathContext.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/util/function/DoubleSupplier.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/util/function/Supplier.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/util/ArrayList.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/util/List.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/lang/Number.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/lang/Double.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/lang/ArithmeticException.class)]] [loading ZipFileIndexFileObject[/Users/lfoppiano/.m2/repository/javax/measure/unit-api/0.8/unit-api-0.8.jar(javax/measure/quantity/Acceleration.class)]] [loading ZipFileIndexFileObject[/Users/lfoppiano/.m2/repository/javax/measure/unit-api/0.8/unit-api-0.8.jar(javax/measure/quantity/AmountOfSubstance.class)]] [loading ZipFileIndexFileObject[/Users/lfoppiano/.m2/repository/javax/measure/unit-api/0.8/unit-api-0.8.jar(javax/measure/quantity/Angle.class)]] [loading ZipFileIndexFileObject[/Users/lfoppiano/.m2/repository/javax/measure/unit-api/0.8/unit-api-0.8.jar(javax/measure/quantity/Area.class)]] [loading ZipFileIndexFileObject[/Users/lfoppiano/.m2/repository/javax/measure/unit-api/0.8/unit-api-0.8.jar(javax/measure/quantity/CatalyticActivity.class)]] [loading ZipFileIndexFileObject[/Users/lfoppiano/.m2/repository/javax/measure/unit-api/0.8/unit-api-0.8.jar(javax/measure/quantity/ElectricCapacitance.class)]] [loading ZipFileIndexFileObject[/Users/lfoppiano/.m2/repository/javax/measure/unit-api/0.8/unit-api-0.8.jar(javax/measure/quantity/ElectricCharge.class)]] [loading ZipFileIndexFileObject[/Users/lfoppiano/.m2/repository/javax/measure/unit-api/0.8/unit-api-0.8.jar(javax/measure/quantity/ElectricConductance.class)]] [loading ZipFileIndexFileObject[/Users/lfoppiano/.m2/repository/javax/measure/unit-api/0.8/unit-api-0.8.jar(javax/measure/quantity/ElectricCurrent.class)]] [loading ZipFileIndexFileObject[/Users/lfoppiano/.m2/repository/javax/measure/unit-api/0.8/unit-api-0.8.jar(javax/measure/quantity/ElectricInductance.class)]] [loading ZipFileIndexFileObject[/Users/lfoppiano/.m2/repository/javax/measure/unit-api/0.8/unit-api-0.8.jar(javax/measure/quantity/ElectricPotential.class)]] [loading ZipFileIndexFileObject[/Users/lfoppiano/.m2/repository/javax/measure/unit-api/0.8/unit-api-0.8.jar(javax/measure/quantity/ElectricResistance.class)]] [loading ZipFileIndexFileObject[/Users/lfoppiano/.m2/repository/javax/measure/unit-api/0.8/unit-api-0.8.jar(javax/measure/quantity/Energy.class)]] [loading ZipFileIndexFileObject[/Users/lfoppiano/.m2/repository/javax/measure/unit-api/0.8/unit-api-0.8.jar(javax/measure/quantity/Force.class)]] [loading ZipFileIndexFileObject[/Users/lfoppiano/.m2/repository/javax/measure/unit-api/0.8/unit-api-0.8.jar(javax/measure/quantity/Frequency.class)]] [loading ZipFileIndexFileObject[/Users/lfoppiano/.m2/repository/javax/measure/unit-api/0.8/unit-api-0.8.jar(javax/measure/quantity/Illuminance.class)]] [loading ZipFileIndexFileObject[/Users/lfoppiano/.m2/repository/javax/measure/unit-api/0.8/unit-api-0.8.jar(javax/measure/quantity/Length.class)]] [loading ZipFileIndexFileObject[/Users/lfoppiano/.m2/repository/javax/measure/unit-api/0.8/unit-api-0.8.jar(javax/measure/quantity/LuminousFlux.class)]] [loading ZipFileIndexFileObject[/Users/lfoppiano/.m2/repository/javax/measure/unit-api/0.8/unit-api-0.8.jar(javax/measure/quantity/LuminousIntensity.class)]] [loading ZipFileIndexFileObject[/Users/lfoppiano/.m2/repository/javax/measure/unit-api/0.8/unit-api-0.8.jar(javax/measure/quantity/MagneticFlux.class)]] [loading ZipFileIndexFileObject[/Users/lfoppiano/.m2/repository/javax/measure/unit-api/0.8/unit-api-0.8.jar(javax/measure/quantity/MagneticFluxDensity.class)]] [loading ZipFileIndexFileObject[/Users/lfoppiano/.m2/repository/javax/measure/unit-api/0.8/unit-api-0.8.jar(javax/measure/quantity/Mass.class)]] [loading ZipFileIndexFileObject[/Users/lfoppiano/.m2/repository/javax/measure/unit-api/0.8/unit-api-0.8.jar(javax/measure/quantity/Power.class)]] [loading ZipFileIndexFileObject[/Users/lfoppiano/.m2/repository/javax/measure/unit-api/0.8/unit-api-0.8.jar(javax/measure/quantity/Pressure.class)]] [loading ZipFileIndexFileObject[/Users/lfoppiano/.m2/repository/javax/measure/unit-api/0.8/unit-api-0.8.jar(javax/measure/quantity/RadiationDoseAbsorbed.class)]] [loading ZipFileIndexFileObject[/Users/lfoppiano/.m2/repository/javax/measure/unit-api/0.8/unit-api-0.8.jar(javax/measure/quantity/RadiationDoseEffective.class)]] [loading ZipFileIndexFileObject[/Users/lfoppiano/.m2/repository/javax/measure/unit-api/0.8/unit-api-0.8.jar(javax/measure/quantity/Radioactivity.class)]] [loading ZipFileIndexFileObject[/Users/lfoppiano/.m2/repository/javax/measure/unit-api/0.8/unit-api-0.8.jar(javax/measure/quantity/SolidAngle.class)]] [loading ZipFileIndexFileObject[/Users/lfoppiano/.m2/repository/javax/measure/unit-api/0.8/unit-api-0.8.jar(javax/measure/quantity/Speed.class)]] [loading ZipFileIndexFileObject[/Users/lfoppiano/.m2/repository/javax/measure/unit-api/0.8/unit-api-0.8.jar(javax/measure/quantity/Temperature.class)]] [loading ZipFileIndexFileObject[/Users/lfoppiano/.m2/repository/javax/measure/unit-api/0.8/unit-api-0.8.jar(javax/measure/quantity/Time.class)]] [loading ZipFileIndexFileObject[/Users/lfoppiano/.m2/repository/javax/measure/unit-api/0.8/unit-api-0.8.jar(javax/measure/quantity/Volume.class)]] [loading ZipFileIndexFileObject[/Users/lfoppiano/.m2/repository/javax/measure/unit-api/0.8/unit-api-0.8.jar(javax/measure/spi/SystemOfUnits.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/util/stream/Collectors.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/time/LocalTime.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/time/temporal/ChronoUnit.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/time/temporal/Temporal.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/time/temporal/TemporalAdjuster.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/time/temporal/TemporalUnit.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/util/concurrent/TimeUnit.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/time/Duration.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/time/temporal/TemporalAmount.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/util/Comparator.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/util/Set.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/lang/ClassCastException.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/lang/UnsupportedOperationException.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/util/function/BinaryOperator.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/util/function/Function.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/util/function/Predicate.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/util/stream/Collector.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/time/Instant.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/text/FieldPosition.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/text/Format.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/text/NumberFormat.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/lang/Cloneable.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/lang/StringBuffer.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/util/Collection.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/util/concurrent/ConcurrentHashMap.class)]] [loading ZipFileIndexFileObject[/Users/lfoppiano/.m2/repository/javax/measure/unit-api/0.8/unit-api-0.8.jar(javax/measure/spi/SystemOfUnitsService.class)]] [loading ZipFileIndexFileObject[/Users/lfoppiano/.m2/repository/javax/annotation/javax.annotation-api/1.2/javax.annotation-api-1.2.jar(javax/annotation/Priority.class)]] [loading ZipFileIndexFileObject[/Users/lfoppiano/.m2/repository/javax/measure/unit-api/0.8/unit-api-0.8.jar(javax/measure/spi/UnitFormatService.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/util/Locale.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/util/Iterator.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/util/NoSuchElementException.class)]] [loading ZipFileIndexFileObject[/Users/lfoppiano/.m2/repository/javax/measure/unit-api/0.8/unit-api-0.8.jar(javax/measure/spi/QuantityFactory.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/io/Reader.class)]] [loading ZipFileIndexFileObject[/Users/lfoppiano/.m2/repository/javax/measure/unit-api/0.8/unit-api-0.8.jar(javax/measure/MeasurementException.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/lang/RuntimeException.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/lang/Exception.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/lang/Throwable.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/io/InputStream.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/io/PrintStream.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/io/UnsupportedEncodingException.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/math/RoundingMode.class)]] [loading ZipFileIndexFileObject[/Users/lfoppiano/.m2/repository/javax/measure/unit-api/0.8/unit-api-0.8.jar(javax/measure/spi/QuantityFactoryService.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/lang/reflect/InvocationHandler.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/lang/reflect/Method.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/lang/reflect/Proxy.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/lang/Error.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/lang/StrictMath.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/io/StringReader.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/util/Formattable.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/util/Formatter.class)]] [loading ZipFileIndexFileObject[/Users/lfoppiano/.m2/repository/javax/measure/unit-api/0.8/unit-api-0.8.jar(javax/measure/spi/ServiceProvider.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/util/Collections.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/util/ServiceLoader.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/util/PropertyResourceBundle.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/util/Vector.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/lang/annotation/Target.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/lang/annotation/ElementType.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/lang/annotation/Retention.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/lang/annotation/RetentionPolicy.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/lang/annotation/Annotation.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/lang/Override.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/lang/SafeVarargs.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/lang/Deprecated.class)]] [checking tec.uom.se.format.AbstractUnitFormat] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/lang/AutoCloseable.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/lang/AbstractStringBuilder.class)]] [wrote RegularFileObject[/Users/lfoppiano/development/inria/unit-normalization/uom-se/target/classes/tec/uom/se/format/AbstractUnitFormat.class]] [checking tec.uom.se.format.SymbolMap] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/lang/reflect/GenericDeclaration.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/lang/reflect/AnnotatedElement.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/lang/Byte.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/lang/Character.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/lang/Short.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/lang/Long.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/lang/Float.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/lang/Boolean.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/lang/Void.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/util/SortedMap.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/util/AbstractMap.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/lang/NoSuchFieldException.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/lang/SecurityException.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/lang/reflect/AccessibleObject.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/lang/reflect/Member.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/lang/Iterable.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/lang/ClassNotFoundException.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/lang/ReflectiveOperationException.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/lang/IllegalAccessException.class)]] [wrote RegularFileObject[/Users/lfoppiano/development/inria/unit-normalization/uom-se/target/classes/tec/uom/se/format/SymbolMap.class]] [checking tec.uom.se.AbstractUnit] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/lang/Math.class)]] [wrote RegularFileObject[/Users/lfoppiano/development/inria/unit-normalization/uom-se/target/classes/tec/uom/se/AbstractUnit.class]] [checking tec.uom.se.unit.MetricPrefix] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/lang/CloneNotSupportedException.class)]] [wrote RegularFileObject[/Users/lfoppiano/development/inria/unit-normalization/uom-se/target/classes/tec/uom/se/unit/MetricPrefix.class]] [checking tec.uom.se.function.UnitConverterSupplier] [wrote RegularFileObject[/Users/lfoppiano/development/inria/unit-normalization/uom-se/target/classes/tec/uom/se/function/UnitConverterSupplier.class]] [checking tec.uom.se.unit.AnnotatedUnit] [wrote RegularFileObject[/Users/lfoppiano/development/inria/unit-normalization/uom-se/target/classes/tec/uom/se/unit/AnnotatedUnit.class]] [checking tec.uom.se.function.RationalConverter] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/util/AbstractList.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/util/AbstractCollection.class)]] [checking tec.uom.se.AbstractConverter] [wrote RegularFileObject[/Users/lfoppiano/development/inria/unit-normalization/uom-se/target/classes/tec/uom/se/function/RationalConverter.class]] [wrote RegularFileObject[/Users/lfoppiano/development/inria/unit-normalization/uom-se/target/classes/tec/uom/se/AbstractConverter$Identity.class]] [wrote RegularFileObject[/Users/lfoppiano/development/inria/unit-normalization/uom-se/target/classes/tec/uom/se/AbstractConverter$Pair.class]] [wrote RegularFileObject[/Users/lfoppiano/development/inria/unit-normalization/uom-se/target/classes/tec/uom/se/AbstractConverter$1.class]] [wrote RegularFileObject[/Users/lfoppiano/development/inria/unit-normalization/uom-se/target/classes/tec/uom/se/AbstractConverter.class]] [checking tec.uom.se.function.Converter] [wrote RegularFileObject[/Users/lfoppiano/development/inria/unit-normalization/uom-se/target/classes/tec/uom/se/function/Converter.class]] [checking tec.uom.se.function.ValueSupplier] [wrote RegularFileObject[/Users/lfoppiano/development/inria/unit-normalization/uom-se/target/classes/tec/uom/se/function/ValueSupplier.class]] [checking tec.uom.se.spi.Range] [wrote RegularFileObject[/Users/lfoppiano/development/inria/unit-normalization/uom-se/target/classes/tec/uom/se/spi/Range.class]] [checking tec.uom.se.function.MinimumSupplier] [wrote RegularFileObject[/Users/lfoppiano/development/inria/unit-normalization/uom-se/target/classes/tec/uom/se/function/MinimumSupplier.class]] [checking tec.uom.se.function.MaximumSupplier] [wrote RegularFileObject[/Users/lfoppiano/development/inria/unit-normalization/uom-se/target/classes/tec/uom/se/function/MaximumSupplier.class]] [checking tec.uom.se.unit.ElementProduct] [wrote RegularFileObject[/Users/lfoppiano/development/inria/unit-normalization/uom-se/target/classes/tec/uom/se/unit/ElementProduct.class]] [checking tec.uom.se.internal.format.Token] [wrote RegularFileObject[/Users/lfoppiano/development/inria/unit-normalization/uom-se/target/classes/tec/uom/se/internal/format/Token.class]] [checking tec.uom.se.unit.Units] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/util/HashSet.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/util/AbstractSet.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/util/stream/Stream.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/util/stream/BaseStream.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/util/function/BiConsumer.class)]] [checking tec.uom.se.AbstractSystemOfUnits] [checking tec.uom.se.function.Nameable] [checking tec.uom.se.quantity.time.TimeQuantities] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/time/temporal/TemporalAccessor.class)]] [checking tec.uom.se.unit.TransformedUnit] [checking tec.uom.se.quantity.time.TimeUnitQuantity] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/lang/IllegalStateException.class)]] [checking tec.uom.se.quantity.time.TemporalQuantity] [checking tec.uom.se.AbstractQuantity] [checking tec.uom.se.ComparableQuantity] [checking tec.uom.se.function.UnitSupplier] [checking tec.uom.se.unit.BaseUnit] [checking tec.uom.se.unit.AlternateUnit] [checking tec.uom.se.unit.ProductUnit] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/lang/System.class)]] [checking tec.uom.se.function.QuantityFunctions] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/util/function/BiFunction.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/util/stream/Collector$Characteristics.class)]] [checking tec.uom.se.function.QuantitySummaryStatistics] [checking tec.uom.se.quantity.time.TimedData] [checking tec.uom.se.function.QuantitySupplier] [checking tec.uom.se.format.DefaultQuantityFormat] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/lang/NullPointerException.class)]] [checking tec.uom.se.format.QuantityFormat] [checking tec.uom.se.format.Parser] [checking tec.uom.se.format.NumberSpaceQuantityFormat] [checking tec.uom.se.format.FormatBehavior] [checking tec.uom.se.internal.DefaultSystemOfUnitsService] [checking tec.uom.se.unit.BinaryPrefix] [checking tec.uom.se.quantity.Quantities] [checking tec.uom.se.format.SimpleUnitFormat] [checking tec.uom.se.internal.format.DefaultUnitFormatService] [checking tec.uom.se.function.MultiplyConverter] [checking tec.uom.se.function.DoubleFactorSupplier] [checking tec.uom.se.quantity.DecimalQuantity] [checking tec.uom.se.spi.StandardModel] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/util/Map$Entry.class)]] [checking tec.uom.se.spi.DimensionalModel] [checking tec.uom.se.internal.format.l10n.ResourceBundleEnumeration] [checking tec.uom.se.function.ExpConverter] [checking tec.uom.se.quantity.DefaultQuantityFactory] [checking tec.uom.se.internal.format.UnitTokenConstants] [checking tec.uom.se.internal.format.LocalUnitFormatParser] [checking tec.uom.se.internal.format.TokenException] [checking tec.uom.se.internal.format.UnitTokenManager] [checking tec.uom.se.internal.format.DefaultCharStream] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/lang/Readable.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/io/Closeable.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/io/InputStreamReader.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/nio/charset/CharsetDecoder.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/nio/charset/Charset.class)]] [checking tec.uom.se.function.NaturalOrder] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/util/function/ToDoubleFunction.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/util/function/ToLongFunction.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/util/function/ToIntFunction.class)]] [checking tec.uom.se.function.DescriptionSupplier] [checking tec.uom.se.internal.format.l10n.BundleToMapAdapter] [checking tec.uom.se.function.PiDivisorConverter] [checking tec.uom.se.function.PiMultiplierConverter] [checking tec.uom.se.internal.quantity.DefaultQuantityFactoryService] [checking tec.uom.se.internal.quantity.OldProxyQuantityFactory] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/util/concurrent/ConcurrentMap.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/lang/ClassLoader.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/lang/reflect/Executable.class)]] [checking tec.uom.se.internal.format.UnitFormatParser] [checking tec.uom.se.function.LogConverter] [checking tec.uom.se.format.EBNFUnitFormat] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/util/ResourceBundle$Control.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/io/Flushable.class)]] [checking tec.uom.se.internal.PriorityAwareServiceProvider] [checking tec.uom.se.internal.format.OutputHelper] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/io/FilterOutputStream.class)]] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/io/OutputStream.class)]] [checking tec.uom.se.spi.AbstractMeasurement] [checking tec.uom.se.spi.Measurement] [checking tec.uom.se.quantity.QuantityDimension] [checking tec.uom.se.quantity.NumberQuantity] [checking tec.uom.se.quantity.DoubleQuantity] [checking tec.uom.se.internal.format.l10n.NumberFormat2] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/lang/NumberFormatException.class)]] [checking tec.uom.se.quantity.QuantityRange] [checking tec.uom.se.function.QuantityConverter] [checking tec.uom.se.internal.format.l10n.MultiPropertyResourceBundle] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/util/RandomAccess.class)]] [checking tec.uom.se.format.LocalUnitFormat] [loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/lang/Package.class)]] [checking tec.uom.se.function.AddConverter] [checking tec.uom.se.internal.format.TokenMgrError] [checking tec.uom.se.quantity.ProxyQuantityFactory] [total 1249ms] [INFO] /Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/format/LocalUnitFormat.java: Some input files use or override a deprecated API. [INFO] /Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/format/LocalUnitFormat.java: Recompile with -Xlint:deprecation for details. [INFO] ------------------------------------------------------------- [ERROR] COMPILATION ERROR : [INFO] ------------------------------------------------------------- [ERROR] /Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/unit/Units.java:[102,34] incompatible types: inference variable Q has incompatible bounds equality constraints: javax.measure.quantity.Dimensionless,Q upper bounds: javax.measure.Quantity<Q>,javax.measure.Quantity<Q> [ERROR] /Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/unit/Units.java:[166,22] incompatible types: inference variable Q has incompatible bounds equality constraints: javax.measure.quantity.Length,Q upper bounds: javax.measure.Quantity<Q>,javax.measure.Quantity<Q> [ERROR] /Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/unit/Units.java:[176,22] incompatible types: inference variable Q has incompatible bounds equality constraints: javax.measure.quantity.AmountOfSubstance,Q upper bounds: javax.measure.Quantity<Q>,javax.measure.Quantity<Q> [ERROR] /Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/unit/Units.java:[187,22] incompatible types: inference variable Q has incompatible bounds equality constraints: javax.measure.quantity.Time,Q upper bounds: javax.measure.Quantity<Q>,javax.measure.Quantity<Q> [ERROR] /Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/unit/Units.java:[425,22] incompatible types: inference variable Q has incompatible bounds equality constraints: javax.measure.quantity.Speed,Q upper bounds: javax.measure.Quantity<Q>,javax.measure.Quantity<Q> [ERROR] /Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/unit/Units.java:[432,22] incompatible types: inference variable Q has incompatible bounds equality constraints: javax.measure.quantity.Acceleration,Q upper bounds: javax.measure.Quantity<Q>,javax.measure.Quantity<Q> [ERROR] /Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/unit/Units.java:[439,22] incompatible types: inference variable Q has incompatible bounds equality constraints: javax.measure.quantity.Area,Q upper bounds: javax.measure.Quantity<Q>,javax.measure.Quantity<Q> [ERROR] /Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/unit/Units.java:[501,11] no suitable method found for addUnit(tec.uom.se.unit.TransformedUnit<javax.measure.quantity.Angle>) method tec.uom.se.AbstractSystemOfUnits.<U>addUnit(U,java.lang.String) is not applicable (cannot infer type-variable(s) U (actual and formal argument lists differ in length)) method tec.uom.se.unit.Units.<U>addUnit(U) is not applicable (inference variable Q has incompatible bounds equality constraints: javax.measure.quantity.Angle upper bounds: javax.measure.Quantity<Q>,javax.measure.Quantity<Q>) method tec.uom.se.unit.Units.<U>addUnit(U,java.lang.Class<? extends javax.measure.Quantity<?>>) is not applicable (cannot infer type-variable(s) U (actual and formal argument lists differ in length)) [ERROR] /Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/unit/Units.java:[508,11] no suitable method found for addUnit(tec.uom.se.unit.TransformedUnit<javax.measure.quantity.Angle>) method tec.uom.se.AbstractSystemOfUnits.<U>addUnit(U,java.lang.String) is not applicable (cannot infer type-variable(s) U (actual and formal argument lists differ in length)) method tec.uom.se.unit.Units.<U>addUnit(U) is not applicable (inference variable Q has incompatible bounds equality constraints: javax.measure.quantity.Angle upper bounds: javax.measure.Quantity<Q>,javax.measure.Quantity<Q>) method tec.uom.se.unit.Units.<U>addUnit(U,java.lang.Class<? extends javax.measure.Quantity<?>>) is not applicable (cannot infer type-variable(s) U (actual and formal argument lists differ in length)) [ERROR] /Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/unit/Units.java:[515,11] no suitable method found for addUnit(tec.uom.se.unit.TransformedUnit<javax.measure.quantity.Angle>) method tec.uom.se.AbstractSystemOfUnits.<U>addUnit(U,java.lang.String) is not applicable (cannot infer type-variable(s) U (actual and formal argument lists differ in length)) method tec.uom.se.unit.Units.<U>addUnit(U) is not applicable (inference variable Q has incompatible bounds equality constraints: javax.measure.quantity.Angle upper bounds: javax.measure.Quantity<Q>,javax.measure.Quantity<Q>) method tec.uom.se.unit.Units.<U>addUnit(U,java.lang.Class<? extends javax.measure.Quantity<?>>) is not applicable (cannot infer type-variable(s) U (actual and formal argument lists differ in length)) [ERROR] /Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/unit/Units.java:[522,11] no suitable method found for addUnit(tec.uom.se.unit.TransformedUnit<javax.measure.quantity.Volume>) method tec.uom.se.AbstractSystemOfUnits.<U>addUnit(U,java.lang.String) is not applicable (cannot infer type-variable(s) U (actual and formal argument lists differ in length)) method tec.uom.se.unit.Units.<U>addUnit(U) is not applicable (inference variable Q has incompatible bounds equality constraints: javax.measure.quantity.Volume upper bounds: javax.measure.Quantity<Q>,javax.measure.Quantity<Q>) method tec.uom.se.unit.Units.<U>addUnit(U,java.lang.Class<? extends javax.measure.Quantity<?>>) is not applicable (cannot infer type-variable(s) U (actual and formal argument lists differ in length)) [ERROR] /Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/unit/Units.java:[561,47] no suitable method found for label(javax.measure.Unit<javax.measure.quantity.Length>,java.lang.String) method tec.uom.se.format.AbstractUnitFormat.label(javax.measure.Unit<?>,java.lang.String) is not applicable (argument mismatch; inference variable Q has incompatible bounds equality constraints: javax.measure.quantity.Length upper bounds: javax.measure.Quantity<capture#1 of ?>,javax.measure.Quantity<Q>) method tec.uom.se.format.SimpleUnitFormat.label(javax.measure.Unit<?>,java.lang.String) is not applicable (argument mismatch; inference variable Q has incompatible bounds equality constraints: javax.measure.quantity.Length upper bounds: javax.measure.Quantity<Q>,javax.measure.Quantity<Q>) [ERROR] /Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/format/SimpleUnitFormat.java:[1127,24] no suitable method found for label(javax.measure.Unit<javax.measure.quantity.Volume>,java.lang.String) method tec.uom.se.format.AbstractUnitFormat.label(javax.measure.Unit<?>,java.lang.String) is not applicable (argument mismatch; inference variable Q has incompatible bounds equality constraints: javax.measure.quantity.Volume upper bounds: javax.measure.Quantity<capture#1 of ?>,javax.measure.Quantity<Q>) method tec.uom.se.format.SimpleUnitFormat.label(javax.measure.Unit<?>,java.lang.String) is not applicable (argument mismatch; inference variable Q has incompatible bounds equality constraints: javax.measure.quantity.Volume upper bounds: javax.measure.Quantity<capture#2 of ?>,javax.measure.Quantity<Q>) method tec.uom.se.format.SimpleUnitFormat.DefaultFormat.label(javax.measure.Unit<?>,java.lang.String) is not applicable (argument mismatch; inference variable Q has incompatible bounds equality constraints: javax.measure.quantity.Volume upper bounds: javax.measure.Quantity<capture#3 of ?>,javax.measure.Quantity<Q>) [ERROR] /Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/format/SimpleUnitFormat.java:[1128,22] no suitable method found for label(javax.measure.Unit<javax.measure.quantity.Volume>,java.lang.String) method tec.uom.se.format.AbstractUnitFormat.label(javax.measure.Unit<?>,java.lang.String) is not applicable (argument mismatch; inference variable Q has incompatible bounds equality constraints: javax.measure.quantity.Volume upper bounds: javax.measure.Quantity<capture#1 of ?>,javax.measure.Quantity<Q>) method tec.uom.se.format.SimpleUnitFormat.label(javax.measure.Unit<?>,java.lang.String) is not applicable (argument mismatch; inference variable Q has incompatible bounds equality constraints: javax.measure.quantity.Volume upper bounds: javax.measure.Quantity<capture#2 of ?>,javax.measure.Quantity<Q>) method tec.uom.se.format.SimpleUnitFormat.DefaultFormat.label(javax.measure.Unit<?>,java.lang.String) is not applicable (argument mismatch; inference variable Q has incompatible bounds equality constraints: javax.measure.quantity.Volume upper bounds: javax.measure.Quantity<capture#3 of ?>,javax.measure.Quantity<Q>) [ERROR] /Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/format/SimpleUnitFormat.java:[1129,22] no suitable method found for label(javax.measure.Unit<javax.measure.quantity.Volume>,java.lang.String) method tec.uom.se.format.AbstractUnitFormat.label(javax.measure.Unit<?>,java.lang.String) is not applicable (argument mismatch; inference variable Q has incompatible bounds equality constraints: javax.measure.quantity.Volume upper bounds: javax.measure.Quantity<capture#1 of ?>,javax.measure.Quantity<Q>) method tec.uom.se.format.SimpleUnitFormat.label(javax.measure.Unit<?>,java.lang.String) is not applicable (argument mismatch; inference variable Q has incompatible bounds equality constraints: javax.measure.quantity.Volume upper bounds: javax.measure.Quantity<capture#2 of ?>,javax.measure.Quantity<Q>) method tec.uom.se.format.SimpleUnitFormat.DefaultFormat.label(javax.measure.Unit<?>,java.lang.String) is not applicable (argument mismatch; inference variable Q has incompatible bounds equality constraints: javax.measure.quantity.Volume upper bounds: javax.measure.Quantity<capture#3 of ?>,javax.measure.Quantity<Q>) [ERROR] /Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/format/SimpleUnitFormat.java:[1130,24] no suitable method found for label(javax.measure.Unit<javax.measure.quantity.Volume>,java.lang.String) method tec.uom.se.format.AbstractUnitFormat.label(javax.measure.Unit<?>,java.lang.String) is not applicable (argument mismatch; inference variable Q has incompatible bounds equality constraints: javax.measure.quantity.Volume upper bounds: javax.measure.Quantity<capture#1 of ?>,javax.measure.Quantity<Q>) method tec.uom.se.format.SimpleUnitFormat.label(javax.measure.Unit<?>,java.lang.String) is not applicable (argument mismatch; inference variable Q has incompatible bounds equality constraints: javax.measure.quantity.Volume upper bounds: javax.measure.Quantity<capture#2 of ?>,javax.measure.Quantity<Q>) method tec.uom.se.format.SimpleUnitFormat.DefaultFormat.label(javax.measure.Unit<?>,java.lang.String) is not applicable (argument mismatch; inference variable Q has incompatible bounds equality constraints: javax.measure.quantity.Volume upper bounds: javax.measure.Quantity<capture#3 of ?>,javax.measure.Quantity<Q>) [ERROR] /Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/format/SimpleUnitFormat.java:[1131,22] no suitable method found for label(javax.measure.Unit<javax.measure.quantity.Volume>,java.lang.String) method tec.uom.se.format.AbstractUnitFormat.label(javax.measure.Unit<?>,java.lang.String) is not applicable (argument mismatch; inference variable Q has incompatible bounds equality constraints: javax.measure.quantity.Volume upper bounds: javax.measure.Quantity<capture#1 of ?>,javax.measure.Quantity<Q>) method tec.uom.se.format.SimpleUnitFormat.label(javax.measure.Unit<?>,java.lang.String) is not applicable (argument mismatch; inference variable Q has incompatible bounds equality constraints: javax.measure.quantity.Volume upper bounds: javax.measure.Quantity<capture#2 of ?>,javax.measure.Quantity<Q>) method tec.uom.se.format.SimpleUnitFormat.DefaultFormat.label(javax.measure.Unit<?>,java.lang.String) is not applicable (argument mismatch; inference variable Q has incompatible bounds equality constraints: javax.measure.quantity.Volume upper bounds: javax.measure.Quantity<capture#3 of ?>,javax.measure.Quantity<Q>) [ERROR] /Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/format/SimpleUnitFormat.java:[1132,24] no suitable method found for label(javax.measure.Unit<javax.measure.quantity.Volume>,java.lang.String) method tec.uom.se.format.AbstractUnitFormat.label(javax.measure.Unit<?>,java.lang.String) is not applicable (argument mismatch; inference variable Q has incompatible bounds equality constraints: javax.measure.quantity.Volume upper bounds: javax.measure.Quantity<capture#1 of ?>,javax.measure.Quantity<Q>) method tec.uom.se.format.SimpleUnitFormat.label(javax.measure.Unit<?>,java.lang.String) is not applicable (argument mismatch; inference variable Q has incompatible bounds equality constraints: javax.measure.quantity.Volume upper bounds: javax.measure.Quantity<capture#2 of ?>,javax.measure.Quantity<Q>) method tec.uom.se.format.SimpleUnitFormat.DefaultFormat.label(javax.measure.Unit<?>,java.lang.String) is not applicable (argument mismatch; inference variable Q has incompatible bounds equality constraints: javax.measure.quantity.Volume upper bounds: javax.measure.Quantity<capture#3 of ?>,javax.measure.Quantity<Q>) [ERROR] /Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/format/SimpleUnitFormat.java:[1133,22] no suitable method found for label(javax.measure.Unit<javax.measure.quantity.Volume>,java.lang.String) method tec.uom.se.format.AbstractUnitFormat.label(javax.measure.Unit<?>,java.lang.String) is not applicable (argument mismatch; inference variable Q has incompatible bounds equality constraints: javax.measure.quantity.Volume upper bounds: javax.measure.Quantity<capture#1 of ?>,javax.measure.Quantity<Q>) method tec.uom.se.format.SimpleUnitFormat.label(javax.measure.Unit<?>,java.lang.String) is not applicable (argument mismatch; inference variable Q has incompatible bounds equality constraints: javax.measure.quantity.Volume upper bounds: javax.measure.Quantity<capture#2 of ?>,javax.measure.Quantity<Q>) method tec.uom.se.format.SimpleUnitFormat.DefaultFormat.label(javax.measure.Unit<?>,java.lang.String) is not applicable (argument mismatch; inference variable Q has incompatible bounds equality constraints: javax.measure.quantity.Volume upper bounds: javax.measure.Quantity<capture#3 of ?>,javax.measure.Quantity<Q>) [ERROR] /Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/format/SimpleUnitFormat.java:[1134,24] no suitable method found for label(javax.measure.Unit<javax.measure.quantity.Volume>,java.lang.String) method tec.uom.se.format.AbstractUnitFormat.label(javax.measure.Unit<?>,java.lang.String) is not applicable (argument mismatch; inference variable Q has incompatible bounds equality constraints: javax.measure.quantity.Volume upper bounds: javax.measure.Quantity<capture#1 of ?>,javax.measure.Quantity<Q>) method tec.uom.se.format.SimpleUnitFormat.label(javax.measure.Unit<?>,java.lang.String) is not applicable (argument mismatch; inference variable Q has incompatible bounds equality constraints: javax.measure.quantity.Volume upper bounds: javax.measure.Quantity<capture#2 of ?>,javax.measure.Quantity<Q>) method tec.uom.se.format.SimpleUnitFormat.DefaultFormat.label(javax.measure.Unit<?>,java.lang.String) is not applicable (argument mismatch; inference variable Q has incompatible bounds equality constraints: javax.measure.quantity.Volume upper bounds: javax.measure.Quantity<capture#3 of ?>,javax.measure.Quantity<Q>) [INFO] 20 errors [INFO] ------------------------------------------------------------- [INFO] ------------------------------------------------------------------------ [INFO] BUILD FAILURE [INFO] ------------------------------------------------------------------------ [INFO] Total time: 2.441 s [INFO] Finished at: 2016-03-21T09:16:24+01:00 [INFO] Final Memory: 19M/308M [INFO] ------------------------------------------------------------------------ [ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.3:compile (default-compile) on project uom-se: Compilation failure: Compilation failure: [ERROR] /Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/unit/Units.java:[102,34] incompatible types: inference variable Q has incompatible bounds [ERROR] equality constraints: javax.measure.quantity.Dimensionless,Q [ERROR] upper bounds: javax.measure.Quantity<Q>,javax.measure.Quantity<Q> [ERROR] /Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/unit/Units.java:[166,22] incompatible types: inference variable Q has incompatible bounds [ERROR] equality constraints: javax.measure.quantity.Length,Q [ERROR] upper bounds: javax.measure.Quantity<Q>,javax.measure.Quantity<Q> [ERROR] /Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/unit/Units.java:[176,22] incompatible types: inference variable Q has incompatible bounds [ERROR] equality constraints: javax.measure.quantity.AmountOfSubstance,Q [ERROR] upper bounds: javax.measure.Quantity<Q>,javax.measure.Quantity<Q> [ERROR] /Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/unit/Units.java:[187,22] incompatible types: inference variable Q has incompatible bounds [ERROR] equality constraints: javax.measure.quantity.Time,Q [ERROR] upper bounds: javax.measure.Quantity<Q>,javax.measure.Quantity<Q> [ERROR] /Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/unit/Units.java:[425,22] incompatible types: inference variable Q has incompatible bounds [ERROR] equality constraints: javax.measure.quantity.Speed,Q [ERROR] upper bounds: javax.measure.Quantity<Q>,javax.measure.Quantity<Q> [ERROR] /Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/unit/Units.java:[432,22] incompatible types: inference variable Q has incompatible bounds [ERROR] equality constraints: javax.measure.quantity.Acceleration,Q [ERROR] upper bounds: javax.measure.Quantity<Q>,javax.measure.Quantity<Q> [ERROR] /Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/unit/Units.java:[439,22] incompatible types: inference variable Q has incompatible bounds [ERROR] equality constraints: javax.measure.quantity.Area,Q [ERROR] upper bounds: javax.measure.Quantity<Q>,javax.measure.Quantity<Q> [ERROR] /Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/unit/Units.java:[501,11] no suitable method found for addUnit(tec.uom.se.unit.TransformedUnit<javax.measure.quantity.Angle>) [ERROR] method tec.uom.se.AbstractSystemOfUnits.<U>addUnit(U,java.lang.String) is not applicable [ERROR] (cannot infer type-variable(s) U [ERROR] (actual and formal argument lists differ in length)) [ERROR] method tec.uom.se.unit.Units.<U>addUnit(U) is not applicable [ERROR] (inference variable Q has incompatible bounds [ERROR] equality constraints: javax.measure.quantity.Angle [ERROR] upper bounds: javax.measure.Quantity<Q>,javax.measure.Quantity<Q>) [ERROR] method tec.uom.se.unit.Units.<U>addUnit(U,java.lang.Class<? extends javax.measure.Quantity<?>>) is not applicable [ERROR] (cannot infer type-variable(s) U [ERROR] (actual and formal argument lists differ in length)) [ERROR] /Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/unit/Units.java:[508,11] no suitable method found for addUnit(tec.uom.se.unit.TransformedUnit<javax.measure.quantity.Angle>) [ERROR] method tec.uom.se.AbstractSystemOfUnits.<U>addUnit(U,java.lang.String) is not applicable [ERROR] (cannot infer type-variable(s) U [ERROR] (actual and formal argument lists differ in length)) [ERROR] method tec.uom.se.unit.Units.<U>addUnit(U) is not applicable [ERROR] (inference variable Q has incompatible bounds [ERROR] equality constraints: javax.measure.quantity.Angle [ERROR] upper bounds: javax.measure.Quantity<Q>,javax.measure.Quantity<Q>) [ERROR] method tec.uom.se.unit.Units.<U>addUnit(U,java.lang.Class<? extends javax.measure.Quantity<?>>) is not applicable [ERROR] (cannot infer type-variable(s) U [ERROR] (actual and formal argument lists differ in length)) [ERROR] /Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/unit/Units.java:[515,11] no suitable method found for addUnit(tec.uom.se.unit.TransformedUnit<javax.measure.quantity.Angle>) [ERROR] method tec.uom.se.AbstractSystemOfUnits.<U>addUnit(U,java.lang.String) is not applicable [ERROR] (cannot infer type-variable(s) U [ERROR] (actual and formal argument lists differ in length)) [ERROR] method tec.uom.se.unit.Units.<U>addUnit(U) is not applicable [ERROR] (inference variable Q has incompatible bounds [ERROR] equality constraints: javax.measure.quantity.Angle [ERROR] upper bounds: javax.measure.Quantity<Q>,javax.measure.Quantity<Q>) [ERROR] method tec.uom.se.unit.Units.<U>addUnit(U,java.lang.Class<? extends javax.measure.Quantity<?>>) is not applicable [ERROR] (cannot infer type-variable(s) U [ERROR] (actual and formal argument lists differ in length)) [ERROR] /Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/unit/Units.java:[522,11] no suitable method found for addUnit(tec.uom.se.unit.TransformedUnit<javax.measure.quantity.Volume>) [ERROR] method tec.uom.se.AbstractSystemOfUnits.<U>addUnit(U,java.lang.String) is not applicable [ERROR] (cannot infer type-variable(s) U [ERROR] (actual and formal argument lists differ in length)) [ERROR] method tec.uom.se.unit.Units.<U>addUnit(U) is not applicable [ERROR] (inference variable Q has incompatible bounds [ERROR] equality constraints: javax.measure.quantity.Volume [ERROR] upper bounds: javax.measure.Quantity<Q>,javax.measure.Quantity<Q>) [ERROR] method tec.uom.se.unit.Units.<U>addUnit(U,java.lang.Class<? extends javax.measure.Quantity<?>>) is not applicable [ERROR] (cannot infer type-variable(s) U [ERROR] (actual and formal argument lists differ in length)) [ERROR] /Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/unit/Units.java:[561,47] no suitable method found for label(javax.measure.Unit<javax.measure.quantity.Length>,java.lang.String) [ERROR] method tec.uom.se.format.AbstractUnitFormat.label(javax.measure.Unit<?>,java.lang.String) is not applicable [ERROR] (argument mismatch; inference variable Q has incompatible bounds [ERROR] equality constraints: javax.measure.quantity.Length [ERROR] upper bounds: javax.measure.Quantity<capture#1 of ?>,javax.measure.Quantity<Q>) [ERROR] method tec.uom.se.format.SimpleUnitFormat.label(javax.measure.Unit<?>,java.lang.String) is not applicable [ERROR] (argument mismatch; inference variable Q has incompatible bounds [ERROR] equality constraints: javax.measure.quantity.Length [ERROR] upper bounds: javax.measure.Quantity<Q>,javax.measure.Quantity<Q>) [ERROR] /Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/format/SimpleUnitFormat.java:[1127,24] no suitable method found for label(javax.measure.Unit<javax.measure.quantity.Volume>,java.lang.String) [ERROR] method tec.uom.se.format.AbstractUnitFormat.label(javax.measure.Unit<?>,java.lang.String) is not applicable [ERROR] (argument mismatch; inference variable Q has incompatible bounds [ERROR] equality constraints: javax.measure.quantity.Volume [ERROR] upper bounds: javax.measure.Quantity<capture#1 of ?>,javax.measure.Quantity<Q>) [ERROR] method tec.uom.se.format.SimpleUnitFormat.label(javax.measure.Unit<?>,java.lang.String) is not applicable [ERROR] (argument mismatch; inference variable Q has incompatible bounds [ERROR] equality constraints: javax.measure.quantity.Volume [ERROR] upper bounds: javax.measure.Quantity<capture#2 of ?>,javax.measure.Quantity<Q>) [ERROR] method tec.uom.se.format.SimpleUnitFormat.DefaultFormat.label(javax.measure.Unit<?>,java.lang.String) is not applicable [ERROR] (argument mismatch; inference variable Q has incompatible bounds [ERROR] equality constraints: javax.measure.quantity.Volume [ERROR] upper bounds: javax.measure.Quantity<capture#3 of ?>,javax.measure.Quantity<Q>) [ERROR] /Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/format/SimpleUnitFormat.java:[1128,22] no suitable method found for label(javax.measure.Unit<javax.measure.quantity.Volume>,java.lang.String) [ERROR] method tec.uom.se.format.AbstractUnitFormat.label(javax.measure.Unit<?>,java.lang.String) is not applicable [ERROR] (argument mismatch; inference variable Q has incompatible bounds [ERROR] equality constraints: javax.measure.quantity.Volume [ERROR] upper bounds: javax.measure.Quantity<capture#1 of ?>,javax.measure.Quantity<Q>) [ERROR] method tec.uom.se.format.SimpleUnitFormat.label(javax.measure.Unit<?>,java.lang.String) is not applicable [ERROR] (argument mismatch; inference variable Q has incompatible bounds [ERROR] equality constraints: javax.measure.quantity.Volume [ERROR] upper bounds: javax.measure.Quantity<capture#2 of ?>,javax.measure.Quantity<Q>) [ERROR] method tec.uom.se.format.SimpleUnitFormat.DefaultFormat.label(javax.measure.Unit<?>,java.lang.String) is not applicable [ERROR] (argument mismatch; inference variable Q has incompatible bounds [ERROR] equality constraints: javax.measure.quantity.Volume [ERROR] upper bounds: javax.measure.Quantity<capture#3 of ?>,javax.measure.Quantity<Q>) [ERROR] /Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/format/SimpleUnitFormat.java:[1129,22] no suitable method found for label(javax.measure.Unit<javax.measure.quantity.Volume>,java.lang.String) [ERROR] method tec.uom.se.format.AbstractUnitFormat.label(javax.measure.Unit<?>,java.lang.String) is not applicable [ERROR] (argument mismatch; inference variable Q has incompatible bounds [ERROR] equality constraints: javax.measure.quantity.Volume [ERROR] upper bounds: javax.measure.Quantity<capture#1 of ?>,javax.measure.Quantity<Q>) [ERROR] method tec.uom.se.format.SimpleUnitFormat.label(javax.measure.Unit<?>,java.lang.String) is not applicable [ERROR] (argument mismatch; inference variable Q has incompatible bounds [ERROR] equality constraints: javax.measure.quantity.Volume [ERROR] upper bounds: javax.measure.Quantity<capture#2 of ?>,javax.measure.Quantity<Q>) [ERROR] method tec.uom.se.format.SimpleUnitFormat.DefaultFormat.label(javax.measure.Unit<?>,java.lang.String) is not applicable [ERROR] (argument mismatch; inference variable Q has incompatible bounds [ERROR] equality constraints: javax.measure.quantity.Volume [ERROR] upper bounds: javax.measure.Quantity<capture#3 of ?>,javax.measure.Quantity<Q>) [ERROR] /Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/format/SimpleUnitFormat.java:[1130,24] no suitable method found for label(javax.measure.Unit<javax.measure.quantity.Volume>,java.lang.String) [ERROR] method tec.uom.se.format.AbstractUnitFormat.label(javax.measure.Unit<?>,java.lang.String) is not applicable [ERROR] (argument mismatch; inference variable Q has incompatible bounds [ERROR] equality constraints: javax.measure.quantity.Volume [ERROR] upper bounds: javax.measure.Quantity<capture#1 of ?>,javax.measure.Quantity<Q>) [ERROR] method tec.uom.se.format.SimpleUnitFormat.label(javax.measure.Unit<?>,java.lang.String) is not applicable [ERROR] (argument mismatch; inference variable Q has incompatible bounds [ERROR] equality constraints: javax.measure.quantity.Volume [ERROR] upper bounds: javax.measure.Quantity<capture#2 of ?>,javax.measure.Quantity<Q>) [ERROR] method tec.uom.se.format.SimpleUnitFormat.DefaultFormat.label(javax.measure.Unit<?>,java.lang.String) is not applicable [ERROR] (argument mismatch; inference variable Q has incompatible bounds [ERROR] equality constraints: javax.measure.quantity.Volume [ERROR] upper bounds: javax.measure.Quantity<capture#3 of ?>,javax.measure.Quantity<Q>) [ERROR] /Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/format/SimpleUnitFormat.java:[1131,22] no suitable method found for label(javax.measure.Unit<javax.measure.quantity.Volume>,java.lang.String) [ERROR] method tec.uom.se.format.AbstractUnitFormat.label(javax.measure.Unit<?>,java.lang.String) is not applicable [ERROR] (argument mismatch; inference variable Q has incompatible bounds [ERROR] equality constraints: javax.measure.quantity.Volume [ERROR] upper bounds: javax.measure.Quantity<capture#1 of ?>,javax.measure.Quantity<Q>) [ERROR] method tec.uom.se.format.SimpleUnitFormat.label(javax.measure.Unit<?>,java.lang.String) is not applicable [ERROR] (argument mismatch; inference variable Q has incompatible bounds [ERROR] equality constraints: javax.measure.quantity.Volume [ERROR] upper bounds: javax.measure.Quantity<capture#2 of ?>,javax.measure.Quantity<Q>) [ERROR] method tec.uom.se.format.SimpleUnitFormat.DefaultFormat.label(javax.measure.Unit<?>,java.lang.String) is not applicable [ERROR] (argument mismatch; inference variable Q has incompatible bounds [ERROR] equality constraints: javax.measure.quantity.Volume [ERROR] upper bounds: javax.measure.Quantity<capture#3 of ?>,javax.measure.Quantity<Q>) [ERROR] /Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/format/SimpleUnitFormat.java:[1132,24] no suitable method found for label(javax.measure.Unit<javax.measure.quantity.Volume>,java.lang.String) [ERROR] method tec.uom.se.format.AbstractUnitFormat.label(javax.measure.Unit<?>,java.lang.String) is not applicable [ERROR] (argument mismatch; inference variable Q has incompatible bounds [ERROR] equality constraints: javax.measure.quantity.Volume [ERROR] upper bounds: javax.measure.Quantity<capture#1 of ?>,javax.measure.Quantity<Q>) [ERROR] method tec.uom.se.format.SimpleUnitFormat.label(javax.measure.Unit<?>,java.lang.String) is not applicable [ERROR] (argument mismatch; inference variable Q has incompatible bounds [ERROR] equality constraints: javax.measure.quantity.Volume [ERROR] upper bounds: javax.measure.Quantity<capture#2 of ?>,javax.measure.Quantity<Q>) [ERROR] method tec.uom.se.format.SimpleUnitFormat.DefaultFormat.label(javax.measure.Unit<?>,java.lang.String) is not applicable [ERROR] (argument mismatch; inference variable Q has incompatible bounds [ERROR] equality constraints: javax.measure.quantity.Volume [ERROR] upper bounds: javax.measure.Quantity<capture#3 of ?>,javax.measure.Quantity<Q>) [ERROR] /Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/format/SimpleUnitFormat.java:[1133,22] no suitable method found for label(javax.measure.Unit<javax.measure.quantity.Volume>,java.lang.String) [ERROR] method tec.uom.se.format.AbstractUnitFormat.label(javax.measure.Unit<?>,java.lang.String) is not applicable [ERROR] (argument mismatch; inference variable Q has incompatible bounds [ERROR] equality constraints: javax.measure.quantity.Volume [ERROR] upper bounds: javax.measure.Quantity<capture#1 of ?>,javax.measure.Quantity<Q>) [ERROR] method tec.uom.se.format.SimpleUnitFormat.label(javax.measure.Unit<?>,java.lang.String) is not applicable [ERROR] (argument mismatch; inference variable Q has incompatible bounds [ERROR] equality constraints: javax.measure.quantity.Volume [ERROR] upper bounds: javax.measure.Quantity<capture#2 of ?>,javax.measure.Quantity<Q>) [ERROR] method tec.uom.se.format.SimpleUnitFormat.DefaultFormat.label(javax.measure.Unit<?>,java.lang.String) is not applicable [ERROR] (argument mismatch; inference variable Q has incompatible bounds [ERROR] equality constraints: javax.measure.quantity.Volume [ERROR] upper bounds: javax.measure.Quantity<capture#3 of ?>,javax.measure.Quantity<Q>) [ERROR] /Users/lfoppiano/development/inria/unit-normalization/uom-se/src/main/java/tec/uom/se/format/SimpleUnitFormat.java:[1134,24] no suitable method found for label(javax.measure.Unit<javax.measure.quantity.Volume>,java.lang.String) [ERROR] method tec.uom.se.format.AbstractUnitFormat.label(javax.measure.Unit<?>,java.lang.String) is not applicable [ERROR] (argument mismatch; inference variable Q has incompatible bounds [ERROR] equality constraints: javax.measure.quantity.Volume [ERROR] upper bounds: javax.measure.Quantity<capture#1 of ?>,javax.measure.Quantity<Q>) [ERROR] method tec.uom.se.format.SimpleUnitFormat.label(javax.measure.Unit<?>,java.lang.String) is not applicable [ERROR] (argument mismatch; inference variable Q has incompatible bounds [ERROR] equality constraints: javax.measure.quantity.Volume [ERROR] upper bounds: javax.measure.Quantity<capture#2 of ?>,javax.measure.Quantity<Q>) [ERROR] method tec.uom.se.format.SimpleUnitFormat.DefaultFormat.label(javax.measure.Unit<?>,java.lang.String) is not applicable [ERROR] (argument mismatch; inference variable Q has incompatible bounds [ERROR] equality constraints: javax.measure.quantity.Volume [ERROR] upper bounds: javax.measure.Quantity<capture#3 of ?>,javax.measure.Quantity<Q>) [ERROR] -> [Help 1] [ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. [ERROR] Re-run Maven using the -X switch to enable full debug logging. [ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles: [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException |
Comments |
Comment by lfoppiano [ 21/Mar/16 ] |
I'm sorry, I've just realised I should have opened this task on github. I've done that here (https://github.com/unitsofmeasurement/uom-se/issues/115). You can close this ticket. |
Comment by keilw [ 21/Mar/16 ] |
Filed by mistake using an older JDK |
Refactoring
SPI (UNITSOFMEASUREMENT-152)
| |
Status: | Resolved |
Project: | unitsofmeasurement |
Component/s: | API |
Affects Version/s: | 0.8 |
Fix Version/s: | 0.9 |
Type: | Sub-task | Priority: | Minor |
Reporter: | keilw | Assignee: | keilw |
Resolution: | Fixed | Votes: | 0 |
Labels: | None | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Issue Links: |
| ||||||||
Tags: | Collection, design | ||||||||
Sprint: | Final Draft |
Description |
ServiceProvider.getAvailables() returns an array of ServiceProvider classes. It might be more convenient while not affecting e.g. current for loops to use a Collection or subtypes such as List (maybe better than Set although we probably won't expect duplicate providers there either). |
[UNITSOFMEASUREMENT-185] Non-functional Requirements (mostly for RI) Created: 17/Mar/16 Updated: 04/Oct/16 Resolved: 04/Oct/16 | |
Status: | Resolved |
Project: | unitsofmeasurement |
Component/s: | RI |
Affects Version/s: | None |
Fix Version/s: | 1.0.1 |
Type: | Story | Priority: | Trivial |
Reporter: | keilw | Assignee: | Unassigned |
Resolution: | Fixed | Votes: | 0 |
Labels: | None | ||
Σ Remaining Estimate: | Not Specified | Remaining Estimate: | Not Specified |
Σ Time Spent: | Not Specified | Time Spent: | Not Specified |
Σ Original Estimate: | Not Specified | Original Estimate: | Not Specified |
Sub-Tasks: |
| |||||||||||||||
Epic Link: | Documents | |||||||||||||||
Sprint: | Final Release, Maintenance Release |
Description |
Mostly for the RI-Guide (unless we face any of it that was good to mention in the Spec, too) See a possible list of Non-functional Requirements :http://users.csc.calpoly.edu/~jdalbey/SWE/QA/nonfunctional.html |
Non-functional
Requirements (mostly for RI) (UNITSOFMEASUREMENT-185)
| |
Status: | Resolved |
Project: | unitsofmeasurement |
Component/s: | Documentation, RI |
Affects Version/s: | 0.8 |
Fix Version/s: | 1.0.1 |
Type: | Sub-task | Priority: | Minor |
Reporter: | lfoppiano | Assignee: | keilw |
Resolution: | Fixed | Votes: | 0 |
Labels: | None | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Issue Links: |
| ||||||||
Sprint: | Final Release, Maintenance Release |
Description |
I've noticed the following problem, when converting complex units to
their bases it can happen to obtains incorrect results due to loss of
precision. Example: convert a simple value like 0.39 g, to its base unit (kg) result in a 0.0039000000000000005. A sample code like this: UnitFormatService formatService = Bootstrap.getService(UnitFormatService.class); UnitFormat defaultFormatService = formatService.getUnitFormat(); TransformedUnit unit = (TransformedUnit) defaultFormatService.parse("g"); System.out.println(unit.getSystemConverter().convert(0.39)); System.out.println(((AbstractConverter)unit.getSystemConverter()).convert(new BigDecimal("0.39"))); //BigDecimal implementation unit = (TransformedUnit) defaultFormatService.parse("%"); System.out.println(unit.getSystemConverter().convert(0.009)); System.out.println(((AbstractConverter)unit.getSystemConverter()).convert(new BigDecimal("0.009"))); //BigDecimal implementation Would return: 3.9000000000000005E-4 0.00039 8.999999999999999E-5 0.00009 It was a new problem for me, in fact, and I've done some research on the subject http://stackoverflow.com/questions/322749/retain-precision-with-double-in-java and I think this kind of library should aim to the maximum precision possible. My proposal: I'm asking here before sending code (I have done already the changes
for testing purposes), as I'm open to discussion and, maybe, alternative
solutions. Once we agreed I will create a pull request on github Thank you in advance |
Comments |
Comment by keilw [ 17/Mar/16 ] |
Thanks for your suggestions. However, convert(BigDecimal) is not acceptable in the API of JSR 363 which aims at the greatest possible number of platforms including and especially Java ME 8 Embedded. BigDecimal or BigInteger do not exist on Java ME, so both API and RI (which runs on both Java ME 8 Embedded and Java SE 7 or higher) obey to those platform constraints. Like JSR 107 RI is not a fully fledged implementation of the JCache API like e.g. EZCache, Hazelcast XYZ or other (commercial) implementations are, or Glassfish does not provide all aspects of scalability, failover or production guarantees you'll find in WebLogic, WebSphere, JBoss EAP or other commercial Java EE servers, the RI does not intend to be the only implementation for JSR 363. In fact, we created a full implementation for Java SE 8: https://github.com/unitsofmeasurement/uom-se please check out your examples there and file issues under https://github.com/unitsofmeasurement/uom-se/issues. Or submit those Pull-requests there. Unlike Unit-RI which is only for EG members, we can merge appropriate changes there more easily from non EG or JCP members. We'll keep the story open as we probably add something to the RI user guide regarding precision and why we left BigDecimal out, but for the RI there is no immediate action item. I hope you understand the rationale and have no problem using Java SE 8 or above? As soon as Eclipse IP helps us to get JSR 363 into its Orbit repository, we can also work on Eclipse UOMo again which is currently Java SE 6 backward compatible and uses BigDecimal in the same ways mentioned. UOMo ".next" should at least work under Java SE 7 like most Eclipse projects, too. |
Comment by lfoppiano [ 17/Mar/16 ] |
Thanks for your quick answer. I completely understand your remarks and
I agree on moving to the Java SE 8 implementation. We probabaly have to do it at some point so maybe this is a good opportunity. Regards |
Comment by keilw [ 17/Mar/16 ] |
That would be good. If you run into serious problems and need Java 7, UOMo shall be updated very soon (I may not have to wait for Eclipse IP confirmation at least in the incubator, later it should all be in Orbit of course) However, what's in uom-se aims at "future JDKs" from Java 8 on, and Oracle has already declared Java 7 as "End of Life" for most cases, so it's probably good to migrate if you can. I consider what's raised here a viable chapter for the RI User Guide: https://www.gitbook.com/book/unitsofmeasurement/unit-ri-userguide/details It is also in GitHub, and while adding a new page or chapter in the first place should be done by owners and editors of the GitBook, everybody is free to raise PRs for those files, too. So you could participate in these chapters if you like. Unlike the Spec or actual RI, this is also a "collaborative" part of the project open to non JCP or EG members alike. |
Comment by lfoppiano [ 18/Mar/16 ] |
Thanks a lot for your complete answer. I will try to migrate to java 8 (which makes sense since java 7 is anyway 5 years old already) and we'll see what to do if we have problems we cannot solve. |
Comment by keilw [ 04/Oct/16 ] |
Handled in RI guide |
[Clarification]
best way to convert Product of units to product of baseUnits
(UNITSOFMEASUREMENT-182)
| |
Status: | Resolved |
Project: | unitsofmeasurement |
Component/s: | API |
Affects Version/s: | 0.8 |
Fix Version/s: | 0.9 |
Type: | Sub-task | Priority: | Major |
Reporter: | keilw | Assignee: | keilw |
Resolution: | Fixed | Votes: | 0 |
Labels: | None | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Issue Links: |
| ||||||||||||||||||||
Tags: | naming | ||||||||||||||||||||
Sprint: | Final Draft |
Description |
Based on PR that as such was closed, but documented: It occured, that Unit method getProductUnits() could
be misleading. getBaseUnits() sounds shorter, but if there are other suggestions and arguments please elaborate here. |
Comments |
Comment by keilw [ 02/Mar/16 ] |
While one issue is related to Unit, the other to SystemOfUnits we may want do consider a method like getBaseUnits() only in one of these. |
Comment by keilw [ 14/Mar/16 ] |
Although until Final there is no guarantee the API doesn't change, I guess we'll duplicate getProductUnits() at least for a certain grace period into getBaseUnits() and deprecate the old form. To clean up implementations or other modules using the old version. Either with 0.9 milestone or at the very least 1.0 it will disappear. |
Comment by leomrlima [ 21/Jun/16 ] |
I vote for renaming before final; I'd say before the final freeze too just remove the old one. Let's not release something with @deprecated in it already... |
Comment by desruisseaux [ 21/Jun/16 ] |
Thanks for spotting that issue. I like the getBaseUnitDecomposition() proposal. |
Comment by keilw [ 21/Jun/16 ] |
I guess it's best to do a @deprecated transition at least as of 0.9-SNAPSHOT but since e.g. Parfait and other solutions (those public we should see sooner or later via https://www.versioneye.com/java/tec.units:unit-ri/references or similar) start using 0.8 now, I guess even 0.9 intended as "Proposed Final Draft" probably should not have both any more. The Snapshot should, but once it's changed from 0.9-SNAPSHOT to 0.9, I'd say delete the old one. |
Comment by keilw [ 21/Jun/16 ] |
As mentioned in the mail thread where suggestions came up, I still
think, that "getBaseUnits" sounds a little less scary than
"getBaseUnitDecomposition". |
Comment by keilw [ 21/Jun/16 ] |
Also we renamed getCompoundConverters into getConversionSteps which sounds a bit more "friendly" and natural IMHO, so probably stay with a more simple term in case of this task and interface, too? Plus respect the plural as it's also done in UnitConverter. WDYT? |
Comment by desruisseaux [ 21/Jun/16 ] |
I'm quite neutral on getBaseUnitDecomposition() versus getBaseUnits(). |
[UNITSOFMEASUREMENT-182] [Clarification] best way to convert Product of units to product of baseUnits Created: 16/Feb/16 Updated: 30/Jun/16 Resolved: 30/Jun/16 | |
Status: | Resolved |
Project: | unitsofmeasurement |
Component/s: | Documentation |
Affects Version/s: | 0.8 |
Fix Version/s: | None |
Type: | Story | Priority: | Major |
Reporter: | lfoppiano | Assignee: | keilw |
Resolution: | Fixed | Votes: | 0 |
Labels: | None | ||
Σ Remaining Estimate: | Not Specified | Remaining Estimate: | Not Specified |
Σ Time Spent: | Not Specified | Time Spent: | Not Specified |
Σ Original Estimate: | Not Specified | Original Estimate: | Not Specified |
Issue Links: |
| |||||||||||||||
Sub-Tasks: |
| |||||||||||||||
Tags: | clarification, design, documentation, question | |||||||||||||||
Epic Link: | Documents | |||||||||||||||
Sprint: | Final Draft |
Description |
Hi, I'm using unit-ri to get data from text and parse them in order to normalize the quantities back to base unit. If I have the following unit: 10 g * km / s and I want to transform it to base unit (kg * m / s). I'm currently iterating each element of the product and converting element by element and elevating at the power defined by the dimensions and combining them case by case, but it's kind of a mess. Do you know if there is an easy way? Any suggestions? (there is no 'clarification' as type of jira ticket) |
Comments |
Comment by keilw [ 17/Feb/16 ] |
The exact requirement/acceptance criteria may be a bit specific for a user story, but it seems like a good idea also using those. A few JSRs (mainly 375) did that already in a very early stage. This could be refined and moved to a task under a more general story, but you'll find such tasks here. |
[UNITSOFMEASUREMENT-181] Refine quantities included in API Created: 02/Feb/16 Updated: 16/Mar/16 Resolved: 16/Mar/16 | |
Status: | Resolved |
Project: | unitsofmeasurement |
Component/s: | API |
Affects Version/s: | 0.8 |
Fix Version/s: | 0.9 |
Type: | Improvement | Priority: | Major |
Reporter: | keilw | Assignee: | keilw |
Resolution: | Fixed | Votes: | 0 |
Labels: | None | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Issue Links: |
| ||||||||
Tags: | design, quantity, question | ||||||||
Epic Link: | Design | ||||||||
Sprint: | Final Draft |
Description |
TCK showed, we have e.g. ElectricPermittivity in javax.measure.quantity, but it's from Table 4 (http://www.bipm.org/en/publications/si-brochure/table4.html) which we won't include in the API. So ElectricPermittivity should go away into si-units or a similar module. From Table 2 (http://www.bipm.org/en/publications/si-brochure/section2-2-1.html) we included e.g.
Are these 2 critical to the most basic fields of use, or could we stick to just the "top 4"
|
[UNITSOFMEASUREMENT-180] Code Coverage Created: 26/Jan/16 Updated: 02/Jul/16 Resolved: 02/Jul/16 | |
Status: | Resolved |
Project: | unitsofmeasurement |
Component/s: | API, RI |
Affects Version/s: | 0.8 |
Fix Version/s: | 0.9 |
Type: | Improvement | Priority: | Critical |
Reporter: | keilw | Assignee: | keilw |
Resolution: | Fixed | Votes: | 0 |
Labels: | None | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Tags: | coverage, test, testing |
Epic Link: | Test |
Sprint: | Final Draft |
Description |
As suggested by LJC we should increase the code coverage of RI and by that where possible API (mostly instantiated through RI, so where feasible those coverage reports should also take "javax.measure" into consideration) |
Comments |
Comment by keilw [ 08/Feb/16 ] |
Similar to JSR 354 (https://github.com/JavaMoney/jsr354-api and https://github.com/JavaMoney/jsr354-ri) the build chain should propagate JaCoCo findings to a Coveralls service for JSR 363. |
Comment by keilw [ 11/Feb/16 ] |
Set up for https://github.com/unitsofmeasurement/unit-api. The coverage only includes classes (as other tools like Cobertura also seem to do) so the API project includes just 6 concrete classes. Mostly exceptions are never thrown by API level unit tests, so we should add more tests to increase coverage rather easily. Whether or not other free and open tests also would cover interfaces, we could see, but generally these are primarily tested by the TCK. |
Comment by keilw [ 02/Jul/16 ] |
If RI could reach more than 60% it would be nice, but it's a good result so far (e.g. other JSRs like 354 are at 65% till now) |
[UNITSOFMEASUREMENT-179] Code formatting Created: 25/Jan/16 Updated: 23/Mar/16 Resolved: 23/Mar/16 | |
Status: | Resolved |
Project: | unitsofmeasurement |
Component/s: | None |
Affects Version/s: | 0.8 |
Fix Version/s: | 0.9 |
Type: | Improvement | Priority: | Major |
Reporter: | leomrlima | Assignee: | keilw |
Resolution: | Fixed | Votes: | 0 |
Labels: | None | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Epic Link: | Infrastructure |
Sprint: | Final Draft |
Description |
As reported by LJC, we should improve our code formatting to be more consistent. What tool/plugin could we use to check this? |
Comments |
Comment by keilw [ 26/Jan/16 ] |
This looks like a plausible solution: |
Comment by keilw [ 23/Mar/16 ] |
Plugin applied to API and RI |
[UNITSOFMEASUREMENT-178] Github Website does not link to project resources Created: 24/Jan/16 Updated: 01/May/16 Resolved: 01/May/16 | |
Status: | Resolved |
Project: | unitsofmeasurement |
Component/s: | Documentation |
Affects Version/s: | None |
Fix Version/s: | None |
Type: | Bug | Priority: | Minor |
Reporter: | kittylyst | Assignee: | leomrlima |
Resolution: | Won't Fix | Votes: | 0 |
Labels: | None | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Sprint: | Final Draft |
Description |
The project website does not link to key resources (including this issue tracker). Navigating the project without help is very difficult. The primary github.io website for this project should be refactored to directly point to all available & useful materials. |
Comments |
Comment by keilw [ 01/May/16 ] |
As java.net is being shut down and the existence or possible future location of e.g. this issue tracker is completely open, we rather not point to a soon dead link. |
[UNITSOFMEASUREMENT-177] Should Quantity extend Comparable? Created: 30/Dec/15 Updated: 15/Jul/16 Resolved: 15/Jul/16 | |
Status: | Resolved |
Project: | unitsofmeasurement |
Component/s: | API |
Affects Version/s: | 0.8 |
Fix Version/s: | 0.9 |
Type: | Improvement | Priority: | Major |
Reporter: | keilw | Assignee: | keilw |
Resolution: | Won't Fix | Votes: | 0 |
Labels: | None | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Issue Links: |
| ||||||||||||
Tags: | design, question, sort, vote | ||||||||||||
Epic Link: | Design | ||||||||||||
Sprint: | Final Release |
Description |
At the moment AbstractQuantity implements Comparable.
|
Comments |
Comment by leomrlima [ 11/Jul/16 ] |
I don't like the idea of implementing Comparable, but I'd leave the AbstractQuantity in the RI implementing it. Reason being that the interface is broad enough to for it being comparable. Just my opinion, just not see anything in favor. |
Comment by keilw [ 11/Jul/16 ] |
Thanks for the input. I agree. Let's see, if there are any strong
preferences otherwise. JSR 354 did it on both, but even
java.util.Currency does not implement Comparable and
doing so with CurrencyUnit means, the theoretical option of using
an Enum for currencies in a particular implementations won't
work. The reason seems an inspiration by http://www.joda.org/joda-money/apidocs/org/joda/money/CurrencyUnit.html.
That's a concrete class, one of JodaMoney's weaknesses, but since we
adopted one or two names for the JSR 354 API that usage of
Comparable must have "creeped" into the API. The same "Joda
Stephen" or Roger at Oracle did however only apply it to concrete classes
in JSR 310 so let's do so here, too |
Comment by desruisseaux [ 15/Jul/16 ] |
I would also be in favor of not extending Comparable and let this choice to implementations. |
Comment by keilw [ 15/Jul/16 ] |
Will leave this to RI or other implementations then. |
Create
TCK (UNITSOFMEASUREMENT-101)
| |
Status: | Resolved |
Project: | unitsofmeasurement |
Component/s: | TCK |
Affects Version/s: | 0.8 |
Fix Version/s: | 0.9 |
Type: | Sub-task | Priority: | Minor |
Reporter: | keilw | Assignee: | keilw |
Resolution: | Won't Fix | Votes: | 0 |
Labels: | None | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Issue Links: |
| ||||||||
Tags: | profile, test, testing | ||||||||
Sprint: | Q1/15, Final Draft |
Description |
It seems, the "spi" profile for the TCK has more or less the same effect as "full". So we might consider dropping it for the sake of simplicity. |
Comments |
Comment by keilw [ 03/Apr/16 ] |
Actually SPI covers "core", "format" and "spi" groups, but does not require a full or partial set of quantities. Therefore it makes sense to keep both. |
[UNITSOFMEASUREMENT-175] AbstractQuantity.compareTo should also compare other Unit Created: 23/Dec/15 Updated: 30/Dec/15 Resolved: 30/Dec/15 | |
Status: | Resolved |
Project: | unitsofmeasurement |
Component/s: | RI |
Affects Version/s: | 0.8 |
Fix Version/s: | 0.9 |
Type: | Bug | Priority: | Major |
Reporter: | keilw | Assignee: | keilw |
Resolution: | Fixed | Votes: | 0 |
Labels: | None | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Issue Links: |
| ||||||||||||
Tags: | conversion | ||||||||||||
Sprint: | Final Draft |
Description |
AbstractQuantity.compareTo() takes the value into
consideration, but ignores unit of other Quantity. Unit<Q> unit = getUnit(); It should probably just use Unit<Q> unit = that.getUnit(); So the unit-based doubleValue() takes the other unit into consideration. If units don't match, we may have to check for ArithmeticException or allow throwing it here. |
Comments |
Comment by keilw [ 23/Dec/15 ] |
Since Java ME 8 Embedded supports Comparator we may simply use the NaturalOrder class like in uom-se. |
Create
TCK (UNITSOFMEASUREMENT-101)
| |
Status: | Resolved |
Project: | unitsofmeasurement |
Component/s: | None |
Affects Version/s: | None |
Fix Version/s: | None |
Type: | Sub-task | Priority: | Major |
Reporter: | keilw | Assignee: | keilw |
Resolution: | Fixed | Votes: | 0 |
Labels: | test | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Issue Links: |
| ||||||||
Tags: | test, utils | ||||||||
Sprint: | Q1/15, Final Draft |
Description |
Instead of low level reflection some of the TCK could use Reflections.org (https://github.com/ronmamo/reflections) especially its ReflectionUtils or similar helper classes. |
Create
TCK (UNITSOFMEASUREMENT-101)
| |
Status: | Resolved |
Project: | unitsofmeasurement |
Component/s: | TCK |
Affects Version/s: | 0.8 |
Fix Version/s: | 0.9 |
Type: | Sub-task | Priority: | Minor |
Reporter: | keilw | Assignee: | keilw |
Resolution: | Won't Fix | Votes: | 0 |
Labels: | None | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Issue Links: |
| ||||||||
Tags: | java, jvm, version | ||||||||
Sprint: | Q1/15, Final Draft |
Description |
As of now the TCK builds against Java 7. TestNG itself is backward-compatible with even Java 5, so unless there are other components with a minimum version of 7, we should try to also make the TCK run on Java SE 6 as a minimal JVM version. |
Comments |
Comment by keilw [ 22/Dec/15 ] |
There are aspects of the TCK like Serialization tests dependent on Java 7. While it could be possible to back-port it, running tools against the same (minimum) Java version as runtime does not seem essential. |
[UNITSOFMEASUREMENT-172] Units.KILOMETRES_PER_HOUR should be rendered "km/h" Created: 02/Dec/15 Updated: 30/Dec/15 Resolved: 30/Dec/15 | |
Status: | Resolved |
Project: | unitsofmeasurement |
Component/s: | RI |
Affects Version/s: | 0.8 |
Fix Version/s: | 0.9 |
Type: | Improvement | Priority: | Major |
Reporter: | keilw | Assignee: | keilw |
Resolution: | Fixed | Votes: | 0 |
Labels: | None | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Issue Links: |
| ||||||||
Tags: | format, ui | ||||||||
Epic Link: | View | ||||||||
Sprint: | Final Draft |
Description |
Right now, SimpleUnitFormat labels Units.KILOMETRES_PER_HOUR like this DEFAULT.label(Units.KILOMETRES_PER_HOUR, "kph");
Based on https://en.wikipedia.org/wiki/Kilometres_per_hour#Kilometres_per_hour_as_an_abbreviation it seems better to use "km/h" as default. |
[UNITSOFMEASUREMENT-171] Clarify JavaDoc of UnitFormat.parse() Created: 25/Nov/15 Updated: 30/Dec/15 Resolved: 30/Dec/15 | |
Status: | Resolved |
Project: | unitsofmeasurement |
Component/s: | API |
Affects Version/s: | 0.8 |
Fix Version/s: | 0.9 |
Type: | Improvement | Priority: | Major |
Reporter: | keilw | Assignee: | keilw |
Resolution: | Fixed | Votes: | 0 |
Labels: | None | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Tags: | format, parse |
Epic Link: | View |
Sprint: | Final Draft |
Description |
At the moment UnitFormat documents the parse() method
as follows: > If there is no unit to parse the unitary unit (dimensionless) is
returned At least SimpleUnitFormat currently does return null under certain circumstances (e.g. a malformed or unknown string) while other implemetations (mostly on the Java SE or unit system extensions) like EBNFUnitFormat throw exceptions like those documented in the interface. UnitFormat should get an improved JavaDoc, probably along the lines of JSR 354 MonetaryAmountFormat.parse() which state, the return value should not be null but throw exceptions instead. |
Comments |
Comment by keilw [ 25/Nov/15 ] |
It seems primarily parseProductUnit() of SimpleUnitFormat should be modified to behave similar as parseSingleUnit() already does. There a null value or similar unknown conditions trigger a ParseException. |
[UNITSOFMEASUREMENT-170] Serializable support Created: 24/Nov/15 Updated: 11/Mar/16 Resolved: 24/Nov/15 | |
Status: | Resolved |
Project: | unitsofmeasurement |
Component/s: | API |
Affects Version/s: | 0.8 |
Fix Version/s: | 0.9 |
Type: | Improvement | Priority: | Major |
Reporter: | snakesvx | Assignee: | keilw |
Resolution: | Won't Fix | Votes: | 0 |
Labels: | None | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Issue Links: |
|
Description |
While trying out the measurements API we noticed that most of the interfaces/classes don't seem to support serialization. Would it possible to add this support where needed/possible? This would help a lot in cases where an object that (for example) includes a quantity that needs to be either transmited (rmi, ...) or stored (caches, ...). |
Comments |
Comment by keilw [ 24/Nov/15 ] |
Thanks for pointing this out. There's been at least one ticket for the SE port (and proposed possible contribution to an appropriate OpenJDK module for IoT/Java SE embedded) https://github.com/unitsofmeasurement/uom-se/issues/98 following an already solved ticket. On the API level we won't and can't address that, because Java ME Embedded does not know Serializable. Looking at comparable (value-related) JSRs like 354 or 310, despite some of them aiming only at Java SE, their API or API-like interfaces, e.g. MonetaryAmount or Temporal do not extend Serializable either, but implementing classes like Money or LocalDateTime do. For Java SE we follow the same pattern. If you face problems with serialization not yet addressed in uom-se, please don't hesitate to file further GitHub tickets for that project. On an API level I'm closing this as it's out of scope. |
Comment by ceefour [ 10/Mar/16 ] |
+1 for making SE port / RI have Serializable support. If the APIs can't have Serializable well I guess we have to live with it, but please make abstracts Serializable. |
Comment by keilw [ 11/Mar/16 ] |
For the SE port, see https://github.com/unitsofmeasurement/uom-se/issues/98 |
Create
TCK (UNITSOFMEASUREMENT-101)
| |
Status: | Resolved |
Project: | unitsofmeasurement |
Component/s: | TCK |
Affects Version/s: | 0.8 |
Fix Version/s: | 0.9 |
Type: | Sub-task | Priority: | Major |
Reporter: | keilw | Assignee: | keilw |
Resolution: | Fixed | Votes: | 0 |
Labels: | test | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Issue Links: |
| ||||||||||||||||
Tags: | profile, test | ||||||||||||||||
Sprint: | Q1/15, Final Draft |
Description |
Given at least some Embedded solutions in need of JSR 363 expressed they have dependencies as far back as Java 5, not just 6, as well as being more flexible on smaller devices, we should consider adding another profile or two. "spi" includes the Bootstrap class which uses Java ServiceLoader (also on ME 8 Embedded a standard, hence it's available even on smaller ME devices) a feature introduced with Java 6. Thus, if a Java 5 "backport" of the RI wants to use the API without changing or porting it, too, all other packages except "spi" seem compatible with that. Hence combining "format" and "quantity" (if also doing so for "base_quantity" is necessary, please share your thoughts) into at least one more profile sounds like a good idea. Chaining profiles similar to say Maven would be an alternative, but it would complicate calling the TCK, so while groups inside a profile are flexible, I'd rather keep the selected profile as one (also similar to e.g. Java SE or EE) |
Comments |
Comment by keilw [ 24/Nov/15 ] |
The issue also refers to Java 5/6 compatibility. Especially Java 5 won't support SPI/ServiceLoader, therefore a combination of "format" and other optional packages than "spi" makes sense for such environments. |
[UNITSOFMEASUREMENT-168] Shall we add more Angle units to Units class? Created: 15/Nov/15 Updated: 23/Nov/15 Resolved: 23/Nov/15 | |
Status: | Resolved |
Project: | unitsofmeasurement |
Component/s: | RI |
Affects Version/s: | 0.8 |
Fix Version/s: | 0.9 |
Type: | Improvement | Priority: | Minor |
Reporter: | keilw | Assignee: | Unassigned |
Resolution: | Won't Fix | Votes: | 0 |
Labels: | None | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Tags: | design, question, vote |
Sprint: | Final Draft |
Description |
RI Units class contains the SI standard type RADIAN, while the SE port also provides DEGREE_ANGLE, MINUTE_ANGLE and SECOND_ANGLE. These are not mandatory SI units, but "accepted for use with SI units". If it's not too much overhead and useful in an embedded context, we may add them to the RI, too. |
Comments |
Comment by leomrlima [ 23/Nov/15 ] |
I think we already defined what's to be included, no? I think we don't need to add more as it would contradict that definition. |
Comment by keilw [ 23/Nov/15 ] |
We may leave it in the SE port (or think about other places like uom-systems), so for RI, let's leave them out. |
Comment by keilw [ 23/Nov/15 ] |
Stick to the only standard unit in RI for footprint reasons. |
[UNITSOFMEASUREMENT-167] Add Comparable to AbstractUnit Created: 15/Nov/15 Updated: 19/Mar/16 Resolved: 19/Mar/16 | |
Status: | Resolved |
Project: | unitsofmeasurement |
Component/s: | RI |
Affects Version/s: | 0.8 |
Fix Version/s: | 0.9 |
Type: | Improvement | Priority: | Major |
Reporter: | keilw | Assignee: | keilw |
Resolution: | Fixed | Votes: | 0 |
Labels: | None | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Issue Links: |
| ||||||||||||
Epic Link: | Design | ||||||||||||
Sprint: | Final Draft |
Description |
Unlike the SE port, AbstractUnit in the RI does not implement Comparable. As it is available in CLDC8, it should be added there, too. |
Comments |
Comment by keilw [ 14/Mar/16 ] |
As Unit can often be implemented by enums, the interface must not extend Comparable, otherwise it would prevent using it by Enum types. For Quantity we normally don't expect it to be implemented by enums. |
[UNITSOFMEASUREMENT-166] Multiples of units need to be explicitely labeled, too Created: 20/Oct/15 Updated: 28/Sep/16 | |
Status: | Open |
Project: | unitsofmeasurement |
Component/s: | RI |
Affects Version/s: | 0.8-RC3 |
Fix Version/s: | 1.x |
Type: | Improvement | Priority: | Minor |
Reporter: | keilw | Assignee: | Unassigned |
Resolution: | Unresolved | Votes: | 0 |
Labels: | None | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Issue Links: |
| ||||||||
Tags: | format, ui | ||||||||
Epic Link: | View | ||||||||
Sprint: | Maintenance Release |
Description |
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. |
[UNITSOFMEASUREMENT-165] Add getSystemUnit() method to QuantityFactory Created: 27/Sep/15 Updated: 27/Sep/15 Resolved: 27/Sep/15 | |
Status: | Resolved |
Project: | unitsofmeasurement |
Component/s: | API |
Affects Version/s: | 0.8-RC3 |
Fix Version/s: | 0.8 |
Type: | Improvement | Priority: | Major |
Reporter: | keilw | Assignee: | keilw |
Resolution: | Fixed | Votes: | 0 |
Labels: | None | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Tags: | api, design, factory |
Epic Link: | Design |
Sprint: | Public Draft |
Description |
QuantityFactory should expose the method getSystemUnit() similar to Unit. |
Resolve License
issue with Eclipse (UNITSOFMEASUREMENT-156)
| |
Status: | Resolved |
Project: | unitsofmeasurement |
Component/s: | API |
Affects Version/s: | None |
Fix Version/s: | None |
Type: | Sub-task | Priority: | Minor |
Reporter: | keilw | Assignee: | keilw |
Resolution: | Fixed | Votes: | 0 |
Labels: | None | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Issue Links: |
| ||||||||
Tags: | license | ||||||||
Sprint: | Maintenance Release |
Description |
This is of lower priority, since every license header refers to LICENCE.txt anyway, but if the license in the API repo was changed, we could simply unify all licence headers and quote the full (BSD) license there, too. |
Resolve License
issue with Eclipse (UNITSOFMEASUREMENT-156)
| |
Status: | Resolved |
Project: | unitsofmeasurement |
Component/s: | API |
Affects Version/s: | 0.8-RC3 |
Fix Version/s: | 0.8 |
Type: | Sub-task | Priority: | Major |
Reporter: | keilw | Assignee: | keilw |
Resolution: | Fixed | Votes: | 0 |
Labels: | unplanned | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Issue Links: |
| ||||||||
Tags: | license | ||||||||
Sprint: | Maintenance Release |
Description |
Will first confirm with Eclipse reps, and others, that they're happy and see no reason against adding JSR 363 into public repositories like (Eclipse) Orbit if this was done. |
Resolve License
issue with Eclipse (UNITSOFMEASUREMENT-156)
| |
Status: | Resolved |
Project: | unitsofmeasurement |
Component/s: | Spec |
Affects Version/s: | 0.8-RC3 |
Fix Version/s: | 0.8 |
Type: | Sub-task | Priority: | Major |
Reporter: | keilw | Assignee: | keilw |
Resolution: | Fixed | Votes: | 0 |
Labels: | None | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Sprint: | Maintenance Release |
[UNITSOFMEASUREMENT-161] Do we also want UnitFormat.alias()? Created: 14/Sep/15 Updated: 03/Dec/15 Resolved: 03/Dec/15 | |
Status: | Resolved |
Project: | unitsofmeasurement |
Component/s: | API |
Affects Version/s: | 0.8-RC3 |
Fix Version/s: | None |
Type: | Bug | Priority: | Minor |
Reporter: | keilw | Assignee: | Unassigned |
Resolution: | Incomplete | Votes: | 0 |
Labels: | None | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Issue Links: |
| ||||||||||||||||||||
Tags: | format, i18n/l10n, question, vote | ||||||||||||||||||||
Epic Link: | View | ||||||||||||||||||||
Sprint: | Public Draft, Final Draft |
Description |
Right now, UnitFormat got a label() method similar to those in JSR-275 or 108. UnitFormat.getLocaleInstance().alias(METRE.multiply(0.3048), "foot"); UnitFormat.getLocaleInstance().alias(METRE.multiply(0.3048), "feet"); UnitFormat.getLocaleInstance().alias(METRE, "meter"); UnitFormat.getLocaleInstance().alias(METRE, "metre"); To help formatting beyond resources or where those are not available
(especially locale and resource-neutral environments). |
Comments |
Comment by leomrlima [ 26/Oct/15 ] |
While I see this being useful on some cases, this is better left to implementations. |
Comment by keilw [ 27/Oct/15 ] |
Leaving to implementations for now. May revisit in a later version if necessary. |
Comment by keilw [ 02/Dec/15 ] |
I want to revisit this method for possible consideration. A question in one of our forums was about parsing a unit like Units.KILOMETRES_PER_HOUR from a string like "km/h". It seems the established default by SI, EU and other bodies is in fact "km/h", so we should also address this in the RI which uses: DEFAULT.label(Units.KILOMETRES_PER_HOUR, "kph");
as of now (separate ticket). However, while UnitFormat.label() is meant to change the "default" representation for all instances of that particular format, UnitFormat.alias() would allow to add alternate representations to be used at least by UnitFormat.parse() in addition to the default. So applied properly, both "km/h" and "kph" or "kmph" (was also widely used especially in the UK) could all provide a similar result. WDYT? |
Comment by leomrlima [ 03/Dec/15 ] |
I understand that's useful, but it'll add complication for some use cases only. I stand by my "leave it to implementations" comment as before. |
Comment by keilw [ 03/Dec/15 ] |
Then let's defer it to a later version. I believe some implementations may use it now. Should there be major demand (for alternatives e.g. when parsing) in feedbacks, the later version could be until 1.0, otherwise it's worth keeping it in mind for further versions of the spec/API. JIRA has no "deferred", so I'll abuse "Incomplete", we should certainly not "close" such tickets unlike the ones entirely finished. |
Portability of
TCK (UNITSOFMEASUREMENT-153)
| |
Status: | Resolved |
Project: | unitsofmeasurement |
Component/s: | TCK |
Affects Version/s: | None |
Fix Version/s: | 0.8 |
Type: | Sub-task | Priority: | Major |
Reporter: | keilw | Assignee: | keilw |
Resolution: | Fixed | Votes: | 0 |
Labels: | None | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Tags: | portability, profile, test, testing |
Sprint: | Public Draft |
Description |
Similar to Java EE or ME, the TCK should allow to execute only parts
that apply to a certain profile.
CDI deals with this via TestNG groups: Either doing that or in combination with system properties (and where Maven is used likely its profiles) we should be able to configure which tests in the TCK shall be executed for which profile. Also see |
Comments |
Comment by keilw [ 04/Sep/15 ] |
At the moment, passing a wrong or unknown profile name (e.g. "minime" instead of "minimal") as system property causes an exception in TCKRunner -------------------------------------------------------
T E S T S
-------------------------------------------------------
Running tec.units.tck.TCKRunnerTest
Configuring TestNG with: TestNG652Configurator
Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.601 sec <<< FAILURE! - in tec.units.tck.TCKRunnerTest
testTCKRunner(tec.units.tck.TCKRunnerTest) Time elapsed: 0.024 sec <<< FAILURE!
java.lang.IllegalArgumentException: No enum constant tec.units.tck.util.TestGroups.Profile.minime
at java.lang.Enum.valueOf(Enum.java:236)
at tec.units.tck.util.TestGroups$Profile.valueOf(TestGroups.java:72)
at tec.units.tck.TCKRunner.<init>(TCKRunner.java:81)
at tec.units.tck.TCKRunnerTest.testTCKRunner(TCKRunnerTest.java:41)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:84)
at org.testng.internal.Invoker.invokeMethod(Invoker.java:714)
at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901)
at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231)
at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)
at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
at org.testng.TestRunner.privateRun(TestRunner.java:767)
at org.testng.TestRunner.run(TestRunner.java:617)
at org.testng.SuiteRunner.runTest(SuiteRunner.java:334)
at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:329)
at org.testng.SuiteRunner.privateRun(SuiteRunner.java:291)
at org.testng.SuiteRunner.run(SuiteRunner.java:240)
at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
at org.testng.TestNG.runSuitesSequentially(TestNG.java:1224)
at org.testng.TestNG.runSuitesLocally(TestNG.java:1149)
at org.testng.TestNG.run(TestNG.java:1057)
at org.apache.maven.surefire.testng.TestNGExecutor.run(TestNGExecutor.java:69)
at org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.executeSingleClass(TestNGDirectoryTestSuite.java:120)
at org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.execute(TestNGDirectoryTestSuite.java:104)
at org.apache.maven.surefire.testng.TestNGProvider.invoke(TestNGProvider.java:113)
at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
This seems acceptable, the exception tells what's wrong, or should we rather override it with no profile ("full")? |
Create
TCK (UNITSOFMEASUREMENT-101)
| |
Status: | Resolved |
Project: | unitsofmeasurement |
Component/s: | TCK |
Affects Version/s: | None |
Fix Version/s: | None |
Type: | Sub-task | Priority: | Minor |
Reporter: | keilw | Assignee: | keilw |
Resolution: | Fixed | Votes: | 0 |
Labels: | None | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Issue Links: |
| ||||||||
Tags: | file, layout, test, testing | ||||||||
Sprint: | Q1/15, Final Draft |
Description |
Similar to CDI, the test-audit.xml file should move from the project root folder to src/main/resources. |
Create
TCK (UNITSOFMEASUREMENT-101)
| |
Status: | Resolved |
Project: | unitsofmeasurement |
Component/s: | TCK |
Affects Version/s: | None |
Fix Version/s: | None |
Type: | Sub-task | Priority: | Critical |
Reporter: | keilw | Assignee: | keilw |
Resolution: | Fixed | Votes: | 0 |
Labels: | None | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Tags: | spec, spi, test, testing |
Sprint: | Q1/15, Final Draft |
Description |
Add tests for SPI |
[UNITSOFMEASUREMENT-157] Shall we keep the name MetricPrefix? Created: 26/Aug/15 Updated: 01/Sep/15 Resolved: 01/Sep/15 | |
Status: | Resolved |
Project: | unitsofmeasurement |
Component/s: | RI |
Affects Version/s: | 0.8-RC3 |
Fix Version/s: | 0.8 |
Type: | Improvement | Priority: | Minor |
Reporter: | keilw | Assignee: | Unassigned |
Resolution: | Won't Fix | Votes: | 0 |
Labels: | None | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Issue Links: |
| ||||||||
Tags: | design, naming, prefix | ||||||||
Epic Link: | Design | ||||||||
Sprint: | Public Draft |
Description |
The BIPM chapter on prefixes http://www.bipm.org/en/publications/si-brochure/chapter3.html explicitely calls the section SI prefixes. SIPrefix was renamed to MetricPrefix mainly to avoid misconception between the RI where these prefixes are offered for convenience and a dedicated *SI* module (https://github.com/unitsofmeasurement/si-units) The term "Metric" was also recommended by a few EC members before JSR 275 was stopped, though the vast majority of libraries prefer the term SI at least for the actual unit system. WDYT? |
Comments |
Comment by keilw [ 01/Sep/15 ] |
Based on https://en.wikipedia.org/wiki/Metric_prefix also mentioned in the class, let's stick to MetricPrefix. While SI standardized it, there are other systems or catalogues like ISQ (related to ISO80k) or UCUM all using the same prefix here, so not tying the name to SI (like the SI module) probably isn't a bad idea. |
[UNITSOFMEASUREMENT-156] Resolve License issue with Eclipse Created: 23/Aug/15 Updated: 07/Mar/17 Resolved: 07/Mar/17 | |
Status: | Resolved |
Project: | unitsofmeasurement |
Component/s: | None |
Affects Version/s: | None |
Fix Version/s: | 1.x |
Type: | Task | Priority: | Minor |
Reporter: | keilw | Assignee: | keilw |
Resolution: | Fixed | Votes: | 0 |
Labels: | unplanned | ||
Σ Remaining Estimate: | Not Specified | Remaining Estimate: | Not Specified |
Σ Time Spent: | Not Specified | Time Spent: | Not Specified |
Σ Original Estimate: | Not Specified | Original Estimate: | Not Specified |
Sub-Tasks: |
| ||||||||||||||||||||
Tags: | eclipse, external, library, license | ||||||||||||||||||||
Epic Link: | Infrastructure | ||||||||||||||||||||
Sprint: | Maintenance Release |
Description |
Due to a different understanding of what API vs.
Implementation are by Eclipse Foundation, there's a blocking issue
based on the current LICENSE.txt file in Unit-API see https://java.net/jira/browse/UNITSOFMEASUREMENT-64 Note, this is a blocker mainly for Eclipse and downstream projects like SmartHome. |
Comments |
Comment by keilw [ 23/Sep/15 ] |
So based on what was mentioned in a discussion with Jean-Marie, Eclipse and PMO reps, we would propose a change by putting the full Spec License text into the Specification document (https://docs.google.com/document/d/12KhosAFriGCczBs6gwtJJDfg_QlANT92_lhxUWO2gCY/edit#heading=h.ejfpuk6yf28c) instead of a short version like JSR 354 did plus putting a LICENSE.txt that matches the BSD 3 clause license here https://github.com/unitsofmeasurement/unit-api/blob/master/LICENSE.txt make Eclipse "happy" without violating any mandatory requirements for JSRs from a JCP/PMO point of view? |
Comment by keilw [ 23/Oct/15 ] |
This (based on a note from JSR 375) pretty much captures the understanding by Eclipse and others on spec vs. software: // This source code implements specifications defined by the Java // Community Process. In order to remain compliant with the specification // DO NOT add / change / or delete method signatures! |
Comment by keilw [ 28/Sep/16 ] |
SmartHome plans another CQ or update of existing ones for 1.0. This may take a while, but not in our control. Will close if the actual CQs are resolved. |
Comment by keilw [ 07/Mar/17 ] |
The CQs for Unit-API https://dev.eclipse.org/ipzilla/show_bug.cgi?id=12206 |
[UNITSOFMEASUREMENT-155] Create separate RI documentation Created: 28/Jul/15 Updated: 24/Nov/15 Resolved: 03/Sep/15 | |
Status: | Resolved |
Project: | unitsofmeasurement |
Component/s: | RI |
Affects Version/s: | 0.8-RC3 |
Fix Version/s: | None |
Type: | Task | Priority: | Major |
Reporter: | keilw | Assignee: | keilw |
Resolution: | Fixed | Votes: | 0 |
Labels: | None | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Issue Links: |
| ||||||||
Tags: | documentation, implementation, tutorial | ||||||||
Epic Link: | Documents | ||||||||
Sprint: | Public Draft |
Description |
Similar to JSR 354 (https://github.com/JavaMoney/jsr354-ri/blob/master/src/main/asciidoc/userguide.adoc) we may want to create a separate RI guide in the most convenient form
Please suggest and feel free to help if we come to a conclusion regarding the best format. As soon as a "working skeleton" for this new document exists, those willing to help with it can copy over relevant parts of the Spec Document (mostly those under "Implementation") and we may factor them out of the spec. A bit similar to JSR 354, it does mention RI elements, but some especially those specific to the RI alone are mostly found in the RI guide. |
Comments |
Comment by keilw [ 03/Sep/15 ] |
Done, the RI User Guide is now here https://github.com/unitsofmeasurement/unit-ri-userguide |
[UNITSOFMEASUREMENT-154] How to tell, if UnitFormat is locale-sensitive? Created: 28/Jul/15 Updated: 20/Sep/15 Resolved: 20/Sep/15 | |
Status: | Resolved |
Project: | unitsofmeasurement |
Component/s: | API, RI |
Affects Version/s: | 0.8-RC3 |
Fix Version/s: | None |
Type: | Improvement | Priority: | Major |
Reporter: | keilw | Assignee: | keilw |
Resolution: | Fixed | Votes: | 0 |
Labels: | None | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Issue Links: |
| ||||||||||||
Tags: | format, i18n, i18n/l10n, question, vote | ||||||||||||
Epic Link: | View | ||||||||||||
Sprint: | Public Draft |
Description |
While direct references to Locale or ResourceBundle are a no-go in the API or SPI, do we plan to tell users of UnitFormat whether or not the format is locale-agnostic or locale-sensitive? At the moment, the enum FormatBehavior (https://github.com/unitsofmeasurement/unit-ri/blob/master/src/main/java/tec/units/ri/format/FormatBehavior.java) lives on an implementation level only. It is so far just used by QuantityFormat in the RI (not based on an API/SPI level interface, whether we want to change that or not is another question) There would be several options, one could be adding
FormatBehavior or a similar enum to the API (enums are a bit
bigger than interfaces, but it would not cause significant growth of the
optional "format" package) Should we plan to support this in the API, then adding something similar to JSR354 AmountFormatQueryBuilder (https://github.com/JavaMoney/jsr354-api/blob/master/src/main/java/javax/money/format/AmountFormatQueryBuilder.java) along the lines of QuantityFactory would be a necessary addition to the API. Without passing Locale explicitely, we may need to do this more sensitive, e.g. with a Class reference similar to the way ServiceProvider already does that for types the API does not need to know. Otherwise it would be implementation-specific, and users who need
localized formatting other than the default locale, would have to call
methods directly at a class like LocalUnitFormat in UOM-SE: WDYT? |
[UNITSOFMEASUREMENT-153] Portability of TCK Created: 27/Jul/15 Updated: 04/Sep/15 Resolved: 04/Sep/15 | |
Status: | Resolved |
Project: | unitsofmeasurement |
Component/s: | TCK |
Affects Version/s: | None |
Fix Version/s: | 0.8 |
Type: | Task | Priority: | Major |
Reporter: | keilw | Assignee: | keilw |
Resolution: | Fixed | Votes: | 0 |
Labels: | None | ||
Σ Remaining Estimate: | Not Specified | Remaining Estimate: | Not Specified |
Σ Time Spent: | Not Specified | Time Spent: | Not Specified |
Σ Original Estimate: | Not Specified | Original Estimate: | Not Specified |
Issue Links: |
| ||||||||||
Sub-Tasks: |
| ||||||||||
Tags: | embedded, portability, test, testing | ||||||||||
Epic Link: | Test | ||||||||||
Sprint: | Public Draft |
Description |
At least some utility classes in the initial TCK codebase use BigDecimal. If possible this should be avoided, given the API also does not use types that would be incompatible with target platforms like Java ME. |
Comments |
Comment by keilw [ 04/Sep/15 ] |
TestUtils was modified to avoid BigDecimal or other elements of java.math. However, since the TCK itself is not meant to run on Java ME Embedded, there are crucial parts including TCKRunner dependent on reflection. These dependencies are OK since the TCK won't have to run on an Embedded VM, it just has to test artifacts that do in a platform-neutral way. |
[UNITSOFMEASUREMENT-152] Refactoring SPI Created: 27/Jul/15 Updated: 15/Jun/16 Resolved: 15/Jun/16 | |
Status: | Resolved |
Project: | unitsofmeasurement |
Component/s: | API |
Affects Version/s: | 0.8-RC3 |
Fix Version/s: | 0.9 |
Type: | Story | Priority: | Major |
Reporter: | keilw | Assignee: | keilw |
Resolution: | Fixed | Votes: | 0 |
Labels: | None | ||
Σ Remaining Estimate: | Not Specified | Remaining Estimate: | Not Specified |
Σ Time Spent: | Not Specified | Time Spent: | Not Specified |
Σ Original Estimate: | Not Specified | Original Estimate: | Not Specified |
Issue Links: |
| ||||||||||||||||||||||||||||
Sub-Tasks: |
| ||||||||||||||||||||||||||||
Tags: | question, vote | ||||||||||||||||||||||||||||
Epic Link: | Design | ||||||||||||||||||||||||||||
Sprint: | Final Draft |
Description |
A task to clarify, if we're happy with the Bootstrap class as JSR 354 also defined it? An important difference is, that 354 added several API level facade classes like Monetary or MonetaryRounding which we probably would like to avoid here with Embedded in mind. Where we have similar needs, the RI or other implementations would usually meet that, see Units or Quantities. Good examples are JSRs from 107 to 349 (Bean Validation) or 365 (CDI 2)
Please suggest names, I don't want to propose too much in this
case. Thanks, |
Comments |
Comment by keilw [ 27/Jul/15 ] |
Also see JPA Bootstrap class http://docs.oracle.com/javaee/7/api/javax/persistence/Persistence.html |
Comment by keilw [ 30/Sep/15 ] |
Meeting @desruisseaux at ApacheCon, it seems, with pretty much the same
lines of code, calling ServiceLoader directly offers a similar value, so
we seemingly won't need Bootstrap. |
Comment by keilw [ 05/Oct/15 ] |
See https://java.net/projects/unitsofmeasurement/lists/experts/archive/2015-10/message/0 other JSRs from 107 to 354 or 365 (CDI 2, already had this kind of "bootstrap" class ever since 1.1) give strong evidence, this kind of class adds value to the JSR, especially by making it more independent of either Java class loading deficits or completely different service loading mechanisms along the lines of OSGi. So the goal is to decide, if Bootstrap was a proper name for the class or we should find another name. |
Comment by keilw [ 17/Mar/16 ] |
Created a Doodle poll http://doodle.com/poll/rgwqcdz6u9c3rp7pgue9d9mw/admin#table (it should only be open to EG members) |
Comment by desruisseaux [ 17/Mar/16 ] |
An alternative could be:
This would simplify a little bit the API (one less method) and avoid the difficulty to find a name for Bootstrap. |
Comment by keilw [ 18/Mar/16 ] |
Try if you want in a branch: https://github.com/unitsofmeasurement/unit-api/tree/simplify_bootstrap
Both JSR 354 and CDI use one or multiple interfaces, only the accessor singleton (like Bootstrap) is an abstract class offering to replace SPI providers. Give it a try. While they do not offer the same level of runtime pluggability, either java.util.Currency or the unit type of ICU4J are abstract classes with some static helpers and factories like "getAll" or "getAvailable...". |
Comment by desruisseaux [ 19/Mar/16 ] |
Thanks. Just one question: Bootstrap looks for a single instance of ServiceProvider, which in turn returns a List of each services. Isn't ServiceProvider expected to be provided by Unit API implementation (in which case I would expect a list of ServiceProvider, and the service provider returning only one instance of each service), or do we expect implementations to rely on DefaultServiceProvider on not provide their own ServiceProvider (which would explain the current API)? |
Comment by keilw [ 19/Mar/16 ] |
DefaultServiceProvider is just a fallback. You need different implementations and modules (e.g. SI, UCUM or similar) on top, but tests we got there so far show, they're all available and provided. |
Comment by desruisseaux [ 19/Mar/16 ] |
I think that my question was not clear. Current Bootstrap implementation searches for the first ServiceProvider found on the classpath, ignoring all other instances (the ServiceProvider.getPriority() method is apparently ignored). Then ServiceProvider has the following method:
My comment was: if ServiceProvider is expected to be provided by Unit implementations, then:
|
Comment by keilw [ 20/Mar/16 ] |
The inspiration of Bootstrap (and its name) was based on
JSR354: You'll notice a somewhat strange behavior, that it sorts only by
<b>name</b> of services there which is something we removed
earlier. PriorityAwareServiceProvider (also in UoM-SE: https://github.com/unitsofmeasurement/uom-se/blob/master/src/main/java/tec/uom/se/internal/PriorityAwareServiceProvider.java) brought the notion of Priority via the Common Annotations API ({{ @ Priority}}) and also uses it. getPriority() of the actual provider is something to look into using. ServiceProvider now extends Comparable and Bootstrap (only in master) sorts by priority when selecting the default. As for a list of services in a modular setting, it's crucial, that
multiple modules can provide the same service. e.g. https://github.com/unitsofmeasurement/si-units and
several modules under https://github.com/unitsofmeasurement/uom-systems. JSR 107 while there is just one provider type CachingProvider also returns a collection of different providers in its singleton: http://ignite.apache.org/jcache/1.0.0/javadoc/javax/cache/Caching.html (the equivalent to Bootstrap in the JSR 363 SPI) |
Comment by desruisseaux [ 21/Mar/16 ] |
I do not question that we can have many service providers in a modular environment. What I find surprising is where this multiplicity is handled: in the ServiceProvider class which, in my understanding of your reply above, is provided by each Unit API implementors. If ServiceProvider is provided by an implementor, then I would expect it to care only about the implementations of that particular implementors (so no List in that interface). If we want to have a different Unit API implementation, then I would expect to have a different ServiceProvider (so a List in Bootstrap instead than in ServiceProvider). |
Comment by keilw [ 21/Mar/16 ] |
There is only one ServiceProvider per implementation. So e.g.
the RI has one, while UOM-SE comes with another (currently more powerful)
one, but there is no concept of mixing RI and SE port in the same JVM
runtime (other JSRs like JSF face pretty much the same constraints) So
Bootstrap allows the flexibility to switch to another
ServiceProvider. In theory an implementation may offer multiple
service providers, e.g. one using Java ServiceLoader and another
one using OSGi or in future maybe Jigsaw, but not one
ServiceProvider for each service. Therefore the only active
ServiceProvider at a given time has to offer a list of services
if multiple modules like SI, ISO, UCUM, etc. add multiple services. I'm
not totally against the idea of merging Bootstrap and
ServiceProvider but all "modern" and even a few "refurbished"
(like 107 which started even before 108 CDI https://docs.jboss.org/cdi/api/1.1/javax/enterprise/inject/spi/CDI.html while its current() method returns an instance of itself still exposes a BeanManager where most of the somewhat comparable methods like getBeans() reside, but it also allows static re-configuration via setCDIProvider() and although multiple providers could be found, only one is the currently used one. Almost every SPI element in CDI requires sub-classing the CDI class to access protected methods like setCDIProvider(). I am not sure, if we gained value from doing that, or it would be more complicated to implement and use. So Bootstrap.getServices() is a convenience method for getServiceProvider().getServices() and same with getService(). They could be removed from Bootstrap if you always wanted to go via the getServiceProvider() but allowing multiple modules to be loaded on top of an implementation you need them in ServiceProvider. Again, the list seems more necessary, the single result method is the default where more than one service of the same type is defined in one module. Very common for formatting services, less common but also applied to others like SystemOfUnitsService. |
Comment by desruisseaux [ 22/Mar/16 ] |
I would like to clarify the purpose of each class. Would it be possible to answer by "Yes" or "No" to the following questions please?
If the answer is "yes" to all the above questions, then it seems to me that what we need is List of ServiceProvider, not ServiceProvider methods returning List. |
Comment by keilw [ 22/Mar/16 ] |
Why would we need a list of ServiceProvider implementations? In practice, simply because they build on multiple incompatible JVMs (JavaME 8 vs. Java SE 8 or maybe SE 6/7 for other implementations) it is impossible right now to use unit-ri and uom-se in at least the same ClassLoader. Having "Bootstrap" (or whatever name we feel was best in the end?) return a list of multiple ServiceProvider might be an option, see https://docs.jboss.org/cdi/api/1.1/javax/enterprise/inject/spi/CDI.html, but CDI also returns the "default" one. Which matches our getServiceProvider() method. The one active, configured and in use. Thus if you have Bootstrap.getServiceProvider() you get the "current" ServiceProvider which is per implementation. In almost every case especially on ME (on Java SE we might see more than one, same for CDI, the enterprise features may not even make their way into the SE profile of CDI 2 or at least return just one CDIProvider) there is just one implementation. Hence ServiceProvider which acts as a stub for either JDK ServiceLoader or alternatives like OSGi must return a List of services. There is no need of an overhead of forcing each module to create something like SISystemServiceProvider because ServiceProvider is incapable of providing more than one service of type SystemOfUnitsService for each module plue UCUMPrintFormatServiceProvider, ImperialSystemServiceProvider vs. USSystemServiceProvider etc. you get the idea. Offering a list of service providers similar to CDI could be an option,
but it is a possible add-on and should only be for power-users. Ideally
similar to the way CDI does it, having to sub-class an abstract base class
to use it, but I would not even see that as a prio for V1, it is hardly
the case that you mix implementations. Also for most other JSRs. Servlet
or JSP make it possible to swap a WAR between 2 or more app servers, but
nobody would seriously run Glassfish, Tomcat or TomEE in the same JVM at
the same time |
Comment by desruisseaux [ 22/Mar/16 ] |
I have no problem with Bootstrap.getServiceProvider() returning a default provider. What I'm trying to clarify is why the List is in the ServiceProvider interface. To repeat my previous questions: do we agree that there is one ServiceProvider per implementation, and that each ServiceProvider instance do not need to know about other implementations? |
Comment by keilw [ 22/Mar/16 ] |
I'd say there should be one ServiceProvider per "kind of service retrieval". As the RI and SE port use java.util.ServiceLoader by default unless you re-configure it in Bootstrap that way of service-retrieval speaks for one ServiceProvider per implementation. In the rare event that somebody introduced RI and SE port into the same class-loader and an application calls either ServiceProvider it would get all matching services via java.util.ServiceLoader. Even some that may not work in that environment, but e.g. carefully separating calls to RI and SE components without trying a direct cast would work under SE, but not under ME where any call to the SE service causes an immediate failure. There could and will be other implementations of ServiceProvider e.g. for OSGi (as soon as Eclipse was finally able to resolve https://java.net/jira/browse/UNITSOFMEASUREMENT-156 on its end, then UOMo may implement JSR 363) or probably in future versions of the SE port an optimized ServiceProvider calling the Jigsaw module system directly instead of ServiceLoader. That is why IMHO I would prefer to keep the singleton (or even abstract) facade "Bootstrap" and ServiceProvider separate, though in theory one could also have more than one sub-class of such abstract singleton/provider, but it feels cleaner and has almost no real overhead in JAR size by 2 SPI elements instead of 1. |
Comment by keilw [ 22/Mar/16 ] |
Although many implementations should be fine with just one
ServiceProvider adding Comparable to it now so that
getPriority makes sense looks like a logical step. |
Comment by leomrlima [ 24/Mar/16 ] |
I agree with desruisseaux's comment with 4 questions. I think we have yes for all questions and we wouldn't need a list. And the name Bootstrap is fine, but I don't think this is about the name anymore. |
Comment by keilw [ 24/Mar/16 ] |
Thanks for voting. "Something else" suggests you like a different name, but if it's about shifting methods like discussed here' that would also be OK, but someone must make a proposal either in their own Github space or a branch. After I fixed the formatting issue, I deleted the branch which would have too many conflicts, but anybody should be able to create a branch or fork it in their own GitHub repo and offer a PR. Voting "something else" does not state you are fine with keeping the name Bootstrap that would be option 1 (there are not too many and if someone voted on all it would still get to a preference which is currently "Something else". I hope we agree on the flexible approach to setting a new "provider" since it is crucial to making the API flexible yet small. Relying entirely on java.util.ServiceLoader would lock out OSGi and cause fragmentation. The TCK might work, but say an implementation needs dynamic service retrieval via something like OSGi, the API will not offer any of that and make different implementors use proprietary solutions. Not to mention that whatever Jigsaw offers in terms of access to the module system, our API will not support that unless some sort of backward-compatible "bridge" was offered via the only solution java.util.ServiceLoader. IMHO I don't care if it's called Bootstrap, UoM or ServiceProvider as long as the flexibility say CDI offers in its abstract accessor class is not lost. If that was a protected or public methods, those are details, first everyone who voted against sticking to Bootstrap must make a working proposal. That works across all the existing modules without breaking its Unit tests each of them has for service retrieval. If Bootstrap got another name or methods were removed (adding them won't break anything) then of course every module must be adjusted to prove the alternativ works. As well as the TCK which must run with all existing tests (and feel free to add more, but that "singleton" is currently key to how the TCK works in a platform neutral way. Which "4 questions" by @desruisseaux do you mean? There is a post with 3 bullet points suggesting to merge Bootstrap and ServiceProvider into a single abstract base class. As long as it offers some flexibility like CDI, even if it was only accessible to sub-classes if you want to swap the default provider, I am not against that approach. Making it work and demonstrating, all modules (some with more than one service like USSystemService vs. ImperialSystemService, if we restricted that to force a new ServiceProvider per module, not just imlementation, make it work and it could also be OK. A bit more complex, we'd move into CDI-like terrain, but if that's what a majority wants, why not. I'll leave the doodle open till after the Easter weekend. So some might vote if they are away. Then we have to see what the preference is and if it is "refactor", please do refactor. I could also do such thing, but the ones who feel an alternative was better for the API should present a PoC of this idea. JSRs like 354 or 310 have also undergone quite a few changes even after a Public Draft. If you (especially all Spec Leads please) believe, doing another Public Draft Review with a changed API was better than a Proposed Final Draft, please also say so. Harold/PMO offered both, we should tell them which one we do next. |
Comment by keilw [ 24/Mar/16 ] |
Please also see https://java.net/jira/browse/UNITSOFMEASUREMENT-189. "Bootstrap" is in quotes for a good reason, since the ticket is about any approach that involves an abstract class like in CDI or (with the mentioned limitations) JSON-P. To not "spam" this list, please post matching ideas or questions there, too. |
Comment by desruisseaux [ 25/Mar/16 ] |
Hello Werner.
|
Comment by keilw [ 25/Mar/16 ] |
Hello Martin/all, Thanks for pulling those out from the thread. There were other (3) numbered items earlier, so these did not stick out so much. Glad everyone agrees on supporting different module or service
infrastructures. It's not just OSGi or Jigsaw, there have been questions
about Android support which has yet another concept of services and every
few weeks we see a new "Microservices Framework" by vendor XYZ aiming to
be the "ultimate solution" and "Java EE killer" We also agreed that the RI must work under Java ME 8 as a "minimal
platform" and made it work around JavaOne last year. That must remain
possible. So any approach in a branch, please either test it in the Java
ME 8 SDK or ask others (especially @leomrlima or myself used it on several
occasion) to test them. This means, the RI is restricted to "small"
numeric types and e.g. BigDecimal for very fine-grained numeric
precision is not available. Members of the community already pointed that
out and I explained why we decided for leaving BD out of the RI. As the SE
port anomg other possible implementations (JScience.next, UOMo,...) offers
BigDecimal support they just have to pick the implementation of
their choice. So although you get services defined by the RI if you run 2 or more implementations in the same class loader, at most you might pick one and avoid mixing it with the other. All implementations must be independent, so as you won't see Coherence use Ehcache or the RI of JSR 107, I guess that explains if we need at least one ServiceProvider implementation per JSR implementation. The answer can only be "Yes" as long as the implementation uses the Full Profile of JSR 363 (remember, SPI is optional, so very small implementations may avoid it and e.g. use an enum for units instead, see the POC https://github.com/unitsofmeasurement/uom-impl-enum) Looking forward to your working proposal. |
Comment by desruisseaux [ 29/Mar/16 ] |
I committed a proposal on https://github.com/desruisseaux/unit-api.git
|
Comment by keilw [ 29/Mar/16 ] |
No time to test now, should actually be asleep, but the merge itself (aside from return values we might think about method names if get* is necessary, see other JSRs like JSON-P) Guess a clone of your fork locally should work. I don't know yet how the list-less approach will work in all the cases with several services of the same type, e.g. UnitFormatService in a single module. Possible that the service list can handle all cases, but unit tests and other code has to be tweaked significantly to test if everything works. Probably easier locally. Whoever can, please give it a try. Either also forking them (RI, SI and Systems at least the RI based ones) or making local modifications, but please don't push anything to master yet. If I see this right, getAvailables() doing a clone() might run into an NPE if during initialization the providers array was not set due to an underlying error. That is a reason, why e.g. a List or similar could be more secure if we set it to an empty collection which can be safely cloned and fill it on succesful init. |
Comment by desruisseaux [ 29/Mar/16 ] |
Indeed, this patch assumes that each implementation would provide at most one UnitFormatService. If an implementation really wants to provide more than one UnitFormatService)} (but I would be curious to know why), it can provide more than one {{ServiceProvider. The clone() call in getAvailables() should not throw a NPE, since if the array was null and can not be built, then another exception will have been thrown in the getProviders() private method. |
Comment by keilw [ 29/Mar/16 ] |
That assumption is insufficient I'm afraid. As mentioned, the merge as such sounds like a viable option and could simplify the API a little bit (merging 2 elements into one, not many JSRs do this, but we could live with a JSON-P like scenario as long as we allow to swap providers) but modularity and extensibility is absolutely crucial to the success of the JSR. Nobody can or wants to define every possible unit system or quantities in the RI or even other implementations. So unless the ServiceProvider extension based on 3 MANIFEST/services entries across 3 modules could expose all the necessary unit systems through just one service, I'm afraid we need one SystemOfUnitsService per module. Will take a look at it, please feel free to tweak the fork/patch if you
sense it cannot accomplish that. |
Comment by desruisseaux [ 29/Mar/16 ] |
You can have multiple system of units. The SystemOfUnitsService interface already has getAvailableSystemsOfUnits() and getSystemOfUnits(String) methods for this purpose. No need for lists in ServiceProvider for this use case. |
Comment by keilw [ 29/Mar/16 ] |
That's what I plan to try against existing modules like SI and "uom-systems". |
Comment by keilw [ 30/Mar/16 ] |
As I feared, it doesn't work for all required cases. The "convenience methods" feel a bit redundant as the only way to make service discovery work is via @Override public SystemOfUnitsService getSystemOfUnitsService() { return getService(SystemOfUnitsService.class); } We'll need the low level methods, otherwise you're immediately forced to declare yet another ServiceProvider in every module. UnitFormatService returns 2 formats, because
SimpleUnitFormat has 2 flavors "Standard" and "ASCII" both
exposed by the service. assertEquals(2, systems.size()); // we'd expect SI and Units here
in SystemOfUnitsServiceTest.testOtherUnitSystems() fails because only 1 SystemOfUnits can be discovered here. Since that's the case, the value of having a getAvailableSystemsOfUnits() method becomes questionable. The nature of java.util.ServiceLoader is to return an Iterable of services for a given service type class. If you simply take the first occurance, you end up replacing the default (if a new module like SI defines it in META-INF/services but SI can't manipulate or access those previously defined in the RI or vice versa. ServiceProvider.getAvailables() also would return only more than one, if you declare another ServiceProvider on top of the first one in a new module. Having to to through java.util.ServiceLoader every time seems unproblematic, but we'd have to explore it for use cases like OSGi without META-INF/services. Please feel free to propose a fix for https://github.com/keilw/si-units in a new fork. It looks like especially UnitFormatService and SystemOfUnitsService have to be revisited in what we return. We only cripple what at least the JDK ServiceLoader offers if we restrict that to a single item where multiple are offered. Unless somebody offers a good solution to really "merge" those, the only solution could be to have at least SystemOfUnitsService return exactly ONE system per service but be able to return multiple services (the natural offer for every service, even if the collection may just contain a single service) |
Comment by desruisseaux [ 30/Mar/16 ] |
I do expect every module to provide their own ServiceProvider implementation. Those implementations should not rely on a getService(Class) method, because:
So I expect ServiceProvider to be implemented like below by all modules: public MyServiceProvider extends ServiceProvider { @Override public SystemOfUnitsService getSystemOfUnitsService() { return new MySystemOfUnitsService(); // NO ServiceLoader usage here. } } I have not yet looked at SystemOfUnitsServiceTest.testOtherUnitSystems(), but I would expect exactly one SystemOfUnitsService implementation for a given module, and the getAvailableSystemsOfUnits() method of that implementation to return 2 system of units. How your SystemOfUnitsService implementation discover those 2 system of units is an implementation detail; only the discovery of the initial ServiceProvider would be done by the META-INF/services mechanism (or OSGi or whatever). You can rely on the META-INF/services mechanism for discovering your SystemOfUnitsService implementation if you want, but you don't have to (I would not, for avoiding unexpected mixing of implementations). |
Comment by keilw [ 30/Mar/16 ] |
Could you give it a try for a fork of https://github.com/keilw/si-units then? Note, as it was so far, you could simply have module A declare a
SystemOfUnitsService and module B declare a
UnitFormatService implementation. While
QuantityFactoryService is almost exclusively up to the RI or
another implementation. We have to question its need in every module. As
long as new SI custom types like Action or Density (or
any quantity defined by other 3rd party modules) properly extend
Quantity there has been no need to create your own
QuantityFactory and service in a module like SI to use them. IMHO for some or all of these, we should provide defaults (either returning null or a safe "stub") in the abstract base class and not force every sub-class to override EVERY method. That might do and still allow each module to extend/override what they really use. WDYT? |
[UNITSOFMEASUREMENT-151] Define QuantityFactoryService in API Created: 25/Jul/15 Updated: 14/Sep/15 Resolved: 14/Sep/15 | |
Status: | Resolved |
Project: | unitsofmeasurement |
Component/s: | API, RI |
Affects Version/s: | 0.8-RC3 |
Fix Version/s: | None |
Type: | Improvement | Priority: | Major |
Reporter: | keilw | Assignee: | keilw |
Resolution: | Fixed | Votes: | 0 |
Labels: | None | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Issue Links: |
| ||||||||
Tags: | factory, service, spi | ||||||||
Epic Link: | Design | ||||||||
Sprint: | Public Draft |
Description |
The interface QuantityFactoryService currently in SPI part of the RI should ideally be part of the API's SPI, too. |
[UNITSOFMEASUREMENT-150] Move DimensionalModel to "spi" package Created: 23/Jul/15 Updated: 23/Jul/15 Resolved: 23/Jul/15 | |
Status: | Resolved |
Project: | unitsofmeasurement |
Component/s: | RI |
Affects Version/s: | 0.8-RC3 |
Fix Version/s: | None |
Type: | Task | Priority: | Major |
Reporter: | keilw | Assignee: | keilw |
Resolution: | Fixed | Votes: | 0 |
Labels: | None | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Tags: | design, spi |
Epic Link: | Design |
Sprint: | Public Draft |
Description |
The DimensionalModel class feels more like an SPI component (probably better in the RI, but if handled via Service loading mechanism there could be use for it in the API/SPI, see CDI and other JSRs) should be moved into "spi" package of the RI. |
[UNITSOFMEASUREMENT-149] Create UnitFormat.format() method with a single Unit argument Created: 13/Jul/15 Updated: 14/Sep/15 Resolved: 14/Sep/15 | |
Status: | Resolved |
Project: | unitsofmeasurement |
Component/s: | API |
Affects Version/s: | None |
Fix Version/s: | None |
Type: | Improvement | Priority: | Major |
Reporter: | keilw | Assignee: | keilw |
Resolution: | Fixed | Votes: | 0 |
Labels: | None | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Issue Links: |
| ||||||||||||
Tags: | format | ||||||||||||
Epic Link: | Design | ||||||||||||
Sprint: | Public Draft |
Description |
Right now UnitFormat defines one format() method with arguments and return values inspired by format(Object obj, StringBuffer toAppendTo, FieldPosition pos) in java.text.Format but without depending on it (ME 8 does not contain java.text) java.text.Format contains another more simplified method format(Object obj) while other JSRs like 354 or 310 also define similar format(<JSRType>) methods with arguments specific to that JSR, e.g. MonetaryAmount for JSR 354. Both these JSRs also deviate from java.text.Format) as to defining the {{Appendable variant of the format() method as void with no return value. Whether or not we could also do this, maybe subject to a follow-up ticket, let's first try to add the simple method. |
[UNITSOFMEASUREMENT-148] Fix JavaDoc in Units Created: 12/Jul/15 Updated: 09/Nov/15 Resolved: 09/Nov/15 | |
Status: | Resolved |
Project: | unitsofmeasurement |
Component/s: | RI |
Affects Version/s: | 0.8-RC3 |
Fix Version/s: | 0.8 |
Type: | Bug | Priority: | Minor |
Reporter: | keilw | Assignee: | keilw |
Resolution: | Fixed | Votes: | 0 |
Labels: | None | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Tags: | javadoc |
Epic Link: | View |
Sprint: | Public Draft |
Description |
Some constants in the Units system class contain a JavaDoc
flaw. |
Comments |
Comment by keilw [ 28/Jul/15 ] |
Also seems to exist in other classes. |
[UNITSOFMEASUREMENT-147] Unit.asType() does not throw ClassCastException where required Created: 11/Jul/15 Updated: 12/Jul/15 Resolved: 12/Jul/15 | |
Status: | Resolved |
Project: | unitsofmeasurement |
Component/s: | RI |
Affects Version/s: | 0.8-RC3 |
Fix Version/s: | 0.8-RC3 |
Type: | Bug | Priority: | Major |
Reporter: | keilw | Assignee: | keilw |
Resolution: | Fixed | Votes: | 0 |
Labels: | None | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Tags: | class, conversion |
Epic Link: | Portability |
Sprint: | Public Draft |
Description |
A method call like METRE.asType(Dimensionless.class); should throw a ClassCastException but currently that does not
happen. |
Comments |
Comment by keilw [ 12/Jul/15 ] |
Still got this into 0.8-RC3 of RI. Key was, to expose Dimensionless constant ONE from the Units class, too like JScience5 did in its SI system class. |
[UNITSOFMEASUREMENT-146] Create a single "internal" package and sub-packages Created: 10/Jul/15 Updated: 11/Jul/15 Resolved: 11/Jul/15 | |
Status: | Resolved |
Project: | unitsofmeasurement |
Component/s: | RI |
Affects Version/s: | 0.8-RC2 |
Fix Version/s: | 0.8-RC3 |
Type: | Task | Priority: | Major |
Reporter: | keilw | Assignee: | keilw |
Resolution: | Fixed | Votes: | 0 |
Labels: | None | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Tags: | design |
Epic Link: | Design |
Sprint: | Q2/15 |
Description |
Similar to JSR 354 RI "Moneta" or "Hibernate Validator" (RI for JSR 349: Bean Validation) it seems a good practice to structure internal implementation details under a single "internal" package. So changing e.g. tec.units.ri.format.internal to tec.units.ri.internal.format and similar. |
[UNITSOFMEASUREMENT-145] Move Bootstrap mechanism into API Created: 10/Jul/15 Updated: 10/Aug/15 Resolved: 10/Aug/15 | |
Status: | Resolved |
Project: | unitsofmeasurement |
Component/s: | API, RI |
Affects Version/s: | 0.8-RC3 |
Fix Version/s: | 0.8 |
Type: | Task | Priority: | Major |
Reporter: | keilw | Assignee: | keilw |
Resolution: | Fixed | Votes: | 0 |
Labels: | None | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Issue Links: |
| ||||||||||||||||||||||||
Tags: | osgi, services, spi | ||||||||||||||||||||||||
Epic Link: | Design | ||||||||||||||||||||||||
Sprint: | Public Draft |
Description |
Similar to the likes of JSR 354 (the actual class is so far heavily inspired by it) or others, e.g. 365 (CDI 2 and before) or 349 (Bean Validation 1.1) we shall offer a small simple Bootstrap mechanism in the actual JSR. ServiceProvider already exists in the SPI, so the
Bootstrap class should be moved from RI to API. Whether under
that name or something better comes up, please have a look. |
Comments |
Comment by keilw [ 23/Jul/15 ] |
JSR 107 offers one of the most basic ServiceLoader approaches with a single https://github.com/jsr107/jsr107spec/blob/master/src/main/java/javax/cache/spi/CachingProvider.java (though it has some form of optionality on the implementation side, but there is just 1 service, not 2 or more) |
Comment by keilw [ 26/Jul/15 ] |
Using ServiceLoader means, the minimum Java version has to be 1.6 for API, since it wasn't introduced till Java 6. We already mention it in the Spec, and should someone really still use Java 5, they can use either JSR 275 or Unit-API "Legacy" 0.6 instead. |
[UNITSOFMEASUREMENT-144] Failure to arithmetic operation Created: 07/Jul/15 Updated: 11/Jul/15 Resolved: 11/Jul/15 | |
Status: | Resolved |
Project: | unitsofmeasurement |
Component/s: | None |
Affects Version/s: | 0.7.1, 0.8-RC2 |
Fix Version/s: | 0.8-RC3 |
Type: | Bug | Priority: | Critical |
Reporter: | leomrlima | Assignee: | keilw |
Resolution: | Fixed | Votes: | 0 |
Labels: | None | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Sprint: | Q2/15 |
Description |
This very basic code fails to do arithmetic add: Quantity<Length> km = Quantities.getQuantity(1000, SI.METRE);
Quantity<Length> mile = Quantities.getQuantity(1, US.MILE);
System.out.println(km.add(mile));
this results in 1001 m, which is wrong. It should either convert automatically or throw some kind of exception of incompatible units. |
Comments |
Comment by keilw [ 07/Jul/15 ] |
Most *Quantity implementations in both RI and the SE port contain code like Quantity<Q> converted = that.to(getUnit());
return Quantities.getQuantity(value + that.getValue().doubleValue(), getUnit());
in methods like add() Quantity<Q> converted = that.to(getUnit());
return Quantities.getQuantity(value + converted.getValue().doubleValue(), getUnit());
|
Comment by keilw [ 08/Jul/15 ] |
Should be mostly fixed in RI. As both "Full SI" and all non SI systems are no longer part of the RI (mainly for size reasons and to provide modularity in the spirit of "Jigsaw" or OSGi and other module systems) this can't be tested directly with the RI, thus https://github.com/unitsofmeasurement/uom-systems/issues/6 was created to test the fix for this problem. |
[UNITSOFMEASUREMENT-143] Multiples of HERTZ wrongly formatted Created: 03/Jul/15 Updated: 20/Oct/15 Resolved: 20/Oct/15 | |
Status: | Resolved |
Project: | unitsofmeasurement |
Component/s: | RI |
Affects Version/s: | 0.8-RC2 |
Fix Version/s: | None |
Type: | Bug | Priority: | Major |
Reporter: | keilw | Assignee: | keilw |
Resolution: | Duplicate | Votes: | 0 |
Labels: | None | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Issue Links: |
| ||||||||||||||||||||||||
Tags: | format | ||||||||||||||||||||||||
Epic Link: | View | ||||||||||||||||||||||||
Sprint: | Public Draft |
Description |
At least 2 tests in https://github.com/unitsofmeasurement/unit-ri/blob/master/src/test/java/tec/units/ri/format/UnitFormatTest.java
involving the unit HERTZ do not correctly show the symbol "Hz" or
multiples like "MHz", but "1/s" and similar (e.g. "M1/s",...) Verify for other AlternateUnit usages, if they are equally affected. |
Comments |
Comment by keilw [ 20/Oct/15 ] |
The new ticket is more general and related to UnitFormat or implementing classes. |
Define our
criterion for inclusion / exclusion of quantity types
(UNITSOFMEASUREMENT-100)
| |
Status: | Resolved |
Project: | unitsofmeasurement |
Component/s: | Spec |
Affects Version/s: | None |
Fix Version/s: | 0.8 |
Type: | Sub-task | Priority: | Major |
Reporter: | keilw | Assignee: | keilw |
Resolution: | Fixed | Votes: | 0 |
Labels: | None | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Tags: | design, document, documentation |
Sprint: | Q1/15, Public Draft |
Description |
Sub-task for documenting changes in Spec or other relevent documents |
Define our
criterion for inclusion / exclusion of quantity types
(UNITSOFMEASUREMENT-100)
| |
Status: | Resolved |
Project: | unitsofmeasurement |
Component/s: | API, RI |
Affects Version/s: | None |
Fix Version/s: | 0.8-RC3 |
Type: | Sub-task | Priority: | Major |
Reporter: | keilw | Assignee: | keilw |
Resolution: | Fixed | Votes: | 0 |
Labels: | None | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Tags: | design |
Sprint: | Q1/15, Public Draft |
Description |
Sub-task to implement changes based on parent. |
[UNITSOFMEASUREMENT-140] Unit HERTZ wrongly formatted Created: 25/Jun/15 Updated: 04/Jul/15 Resolved: 04/Jul/15 | |
Status: | Resolved |
Project: | unitsofmeasurement |
Component/s: | RI |
Affects Version/s: | 0.8-RC2 |
Fix Version/s: | 0.8-RC3 |
Type: | Bug | Priority: | Critical |
Reporter: | keilw | Assignee: | keilw |
Resolution: | Fixed | Votes: | 0 |
Labels: | None | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Issue Links: |
| ||||||||
Tags: | format | ||||||||
Epic Link: | View | ||||||||
Sprint: | Q2/15 |
Description |
At least 2 tests in https://github.com/unitsofmeasurement/unit-ri/blob/master/src/test/java/tec/units/ri/format/UnitFormatTest.java
involving the unit HERTZ do not correctly show the symbol "Hz" or
multiples like "MHz", but "1/s" and similar (e.g. "M1/s",...) Verify for other AlternateUnit usages, if they are equally affected. |
[UNITSOFMEASUREMENT-139] Special GRAM format problem with sub-multiples Created: 25/Jun/15 Updated: 10/Jul/15 Resolved: 10/Jul/15 | |
Status: | Resolved |
Project: | unitsofmeasurement |
Component/s: | RI |
Affects Version/s: | 0.8-RC2 |
Fix Version/s: | 0.8-RC3 |
Type: | Bug | Priority: | Critical |
Reporter: | keilw | Assignee: | keilw |
Resolution: | Fixed | Votes: | 0 |
Labels: | None | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Issue Links: |
| ||||||||||||||||
Tags: | format | ||||||||||||||||
Epic Link: | View | ||||||||||||||||
Sprint: | Q2/15 |
Description |
SimpleUnitFormat and related UnitFormat implementations contain a special format handling of KILOGRAM vs. GRAM (since different unit systems consider each of them the Mass base unit) This does not work for most sub-multiples of GRAM, taking the following examples (also in various PrefixTest cases) Quantity<Mass> m1 = Quantities.getQuantity(1.0, GRAM); System.out.println(m1.toString()); Quantity<Mass> m2 = m1.to(MICRO(GRAM)); System.out.println(m2.toString()); gives 1.0 g 1000000.0 ng The latter should be "µg". Similar results for NANO etc. Also see https://github.com/unitsofmeasurement/si-units/issues/4 This only seems to affect Mass based on GRAM or KILOGRAM, other quantities/units are generally unaffected. |
Comments |
Comment by keilw [ 06/Jul/15 ] |
The best approach to this problem so far was to forward-engineer what JSR-275/JScience 4.3 did about it. They offered both UnitFormat.label() and UnitFormat.alias on an API level. Whether we require both is to be seen, but at least one way to tweak and improve formatting sounds like a good idea. |
Portability of
RI (UNITSOFMEASUREMENT-3)
| |
Status: | Resolved |
Project: | unitsofmeasurement |
Component/s: | RI |
Affects Version/s: | None |
Fix Version/s: | 0.8 |
Type: | Sub-task | Priority: | Major |
Reporter: | leomrlima | Assignee: | leomrlima |
Resolution: | Fixed | Votes: | 0 |
Labels: | None | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Sprint: | Q1/15, Public Draft |
Description |
java.util.logging.Logger in Java ME has no "shortcut methods" like warning() and info() |
Comments |
Comment by leomrlima [ 25/Jun/15 ] |
I guess we can close this, as it was already merged in master? |
[UNITSOFMEASUREMENT-137] dzone refcardz Created: 22/Jun/15 Updated: 02/Oct/16 | |
Status: | Open |
Project: | unitsofmeasurement |
Component/s: | Documentation |
Affects Version/s: | None |
Fix Version/s: | None |
Type: | New Feature | Priority: | Trivial |
Reporter: | Rajmahendra Hegde | Assignee: | Unassigned |
Resolution: | Unresolved | Votes: | 0 |
Labels: | documentation | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified | ||
Environment: |
Documentation |
Epic Link: | Documents |
Sprint: | Maintenance Release |
Description |
dzone refcardz May be it is too early now but just for a backlog item. Its good to have a refcardz once the JSR goes live. |
[UNITSOFMEASUREMENT-136] Porting Spec on GitBook.com Created: 22/Jun/15 Updated: 17/Mar/16 Resolved: 17/Mar/16 | |
Status: | Resolved |
Project: | unitsofmeasurement |
Component/s: | Documentation, Spec |
Affects Version/s: | None |
Fix Version/s: | None |
Type: | Improvement | Priority: | Trivial |
Reporter: | Rajmahendra Hegde | Assignee: | Unassigned |
Resolution: | Won't Fix | Votes: | 0 |
Labels: | documentation | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified | ||
Environment: |
Documentation |
Tags: | question, vote |
Epic Link: | Documents |
Description |
I am sending there is big demand for collaborated documentation using GitBook.com It provides markdown and asciidoc, download options with export pdf, epub, mobi or on-line view. Some sample docs are : |
Comments |
Comment by keilw [ 17/Mar/16 ] |
I think we should defer that to a future version of the JSR. Starting a new version (likely under a new JSR) we could look at either GitBooks or Asciidoc, etc. At the moment, all EC members who actively participate by writing or commenting are comfortable with Google Docs, so I would not change that now. |
Website
(UNITSOFMEASUREMENT-36)
| |
Status: | Resolved |
Project: | unitsofmeasurement |
Component/s: | Documentation |
Affects Version/s: | None |
Fix Version/s: | None |
Type: | Sub-task | Priority: | Major |
Reporter: | keilw | Assignee: | desruisseaux |
Resolution: | Fixed | Votes: | 0 |
Labels: | None | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Tags: | Maven, website |
Sprint: | August, Q1/15, Final Release |
Description |
As Jean-Marie is likely to stop registering the legacy domain "unitsofmeasurement.org" content now deployed there needs to be relocated. GitHub has a set of plugins for Maven site or other forms of deployment: https://github.com/github/maven-plugins The content in question had to be published to https://github.com/unitsofmeasurement/unitsofmeasurement.github.io
similar to e.g. JavaDocs should ideally be generated into a similar folder resulting
in Similar for Maven site if we also want to generate it there. |
Comments |
Comment by keilw [ 20/Sep/15 ] |
It's http://unitsofmeasurement.github.io/unit-api/site/apidocs/index.html now. Maven site is tweaked to use Maven GitHub plugins. Both worked for me locally. Either Martin should do the same for the
GeoAPI Jenkins build allowing updates of the GitHub pages. |
Comment by keilw [ 21/Sep/15 ] |
It seems, like a single build command mvn clean install deploy site
site:deploy --show-version --batch-mode |
Comment by desruisseaux [ 05/Oct/15 ] |
Now that JSR-363 has its own Continuous Integration server, the JSR-363 job on http://jenkins.geotoolkit.org/ and the http://www.unitsofmeasurement.org/ web pages have been deleted. |
Comment by keilw [ 05/Oct/15 ] |
At the moment the final site-deploy step is hindered by GitHub's insufficient "abuse detection" or some kind of quota, but we can live with API JavaDoc uploaded manually when important structural changes took place. Everything else, especially snapshot deployment is automated. As soon as a new Maven Site with updated CI server info can be pushed to GitHub, I guess we can close this. |
Comment by keilw [ 09/Nov/15 ] |
While the site generation is currently manual (due to Github flaw in "abuse detection" everything else worked properly and is now using the new github.io pages. |
[UNITSOFMEASUREMENT-134] Updating pom file(s) to use latest felix plugin Created: 29/May/15 Updated: 28/Sep/16 Resolved: 28/Sep/16 | |
Status: | Resolved |
Project: | unitsofmeasurement |
Component/s: | API, RI, TCK |
Affects Version/s: | 0.7.1 |
Fix Version/s: | None |
Type: | Task | Priority: | Minor |
Reporter: | keilw | Assignee: | keilw |
Resolution: | Fixed | Votes: | 0 |
Labels: | None | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Tags: | Maven, osgi |
Epic Link: | Infrastructure |
Sprint: | Final Release |
Description |
As seen in https://issues.jboss.org/browse/CDI-509 for CDI 2 EDR 1, there's a new Apache Felix plugin version. We should leverage that, and while version numbers of individual packages are probably not so different in our case, also adjust OSGi export-package similar to: <Export-Package> javax.decorator;version=1.1, javax.enterprise.*;version=1.1, javax.decorator;version=2.0, [...] </Export-Package> |
Comments |
Comment by keilw [ 28/Jun/15 ] |
Actually we are using Felix 2.5.3 plugin already, so further adjustments can be done for PDR |
[UNITSOFMEASUREMENT-133] GeoAPI Maven Snapshot repo is not updated when Site is Created: 19/Apr/15 Updated: 29/May/15 Resolved: 19/Apr/15 | |
Status: | Resolved |
Project: | unitsofmeasurement |
Component/s: | API |
Affects Version/s: | None |
Fix Version/s: | None |
Type: | Bug | Priority: | Major |
Reporter: | keilw | Assignee: | desruisseaux |
Resolution: | Fixed | Votes: | 0 |
Labels: | maven | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Tags: | maven, repository |
Epic Link: | Infrastructure |
Sprint: | Q2/15 |
Description |
When Jenkins on GeoAPI builds the API, the site (http://www.unitsofmeasurement.org/jsr-363/index.html) gets updated, but since March 23 it seems to have stopped deploying to Maven. |
Comments |
Comment by desruisseaux [ 19/Apr/15 ] |
Deployment was temporarily disabled when the JSR-363 version was set to 0.8-RC1 because the Jekins server can not deploy on non-snapshot repositories. But since JSR-363 switched back on 0.8-SNAPSHOT on April 14, we can re-enable the deployment. I made the change and verified that the JAR files has been deployed. |
Comment by keilw [ 29/May/15 ] |
The only time when API will be either 0.8 or 0.8-RCx is right before a version is tagged, but we can ensure, the version is always moved back to -SNAPSHOT until the JSR is final. |
[UNITSOFMEASUREMENT-132] Could we rename SIPrefix to MetricPrefix? Created: 13/Apr/15 Updated: 26/Aug/15 Resolved: 09/Jun/15 | |
Status: | Resolved |
Project: | unitsofmeasurement |
Component/s: | RI |
Affects Version/s: | None |
Fix Version/s: | None |
Type: | Improvement | Priority: | Major |
Reporter: | keilw | Assignee: | keilw |
Resolution: | Fixed | Votes: | 0 |
Labels: | None | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Issue Links: |
| ||||||||||||||||
Tags: | design, naming | ||||||||||||||||
Epic Link: | Design | ||||||||||||||||
Sprint: | Q2/15 |
Description |
As per Wikipedia http://en.wikipedia.org/wiki/Metric_prefix the page is called MetricPrefix, so where prefixes remain in the RI (bound to ME-compatible arithmetics it would make sense) using this term does not contradict the SI system, but keeps the name independent of it. |
[UNITSOFMEASUREMENT-131] Current DimensionalModel gets cleaned up erroneously Created: 09/Apr/15 Updated: 08/Jun/15 Resolved: 08/Jun/15 | |
Status: | Resolved |
Project: | unitsofmeasurement |
Component/s: | RI |
Affects Version/s: | 0.8 |
Fix Version/s: | None |
Type: | Bug | Priority: | Major |
Reporter: | sebster | Assignee: | keilw |
Resolution: | Fixed | Votes: | 0 |
Labels: | None | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Sprint: | Q2/15 |
Description |
The Current static (should it be CURRENT to comply with standard Java conventions?) DimensionalModel in the DimensionalModel class is held by a WeakReference. When there are no more references to the value held by the WeakReference, it is garbage collected and the DimensionalModel.current() method will return null subsequently. This will cause methods such as AbstractUnit.getConverterToAny(...) to fail with a NullPointerException. Depending on the JDK and memory availability, the weak reference is garbage collected more or less aggressively (on my Oracle JDK6 it worked fine, but the IBM JDK failed consistently). The patch I currently used is as follows (I don't really understand the need for a WeakReference here): @ -25,8 +25,6 @@ -import java.lang.ref.Reference; import javax.measure.Dimension;
/**
// /** |
Comments |
Comment by keilw [ 13/Apr/15 ] |
Will check it out. If the patch works within the boundaries of Java ME 8, it should work. As for current() if the worry was why it's not getCurrent() this was simply modeled after a central CDI class: http://docs.jboss.org/cdi/api/1.1/javax/enterprise/inject/spi/CDI.html |
Comment by keilw [ 08/Jun/15 ] |
The reference was closest to JScience contexts being used there, but simply returning a constant value like your patch suggested works, so it should solve the problem. |
[UNITSOFMEASUREMENT-130] Infinite recursion in AbstractConverter Created: 09/Apr/15 Updated: 09/Jun/15 Resolved: 09/Jun/15 | |
Status: | Resolved |
Project: | unitsofmeasurement |
Component/s: | RI |
Affects Version/s: | 0.8 |
Fix Version/s: | None |
Type: | Bug | Priority: | Major |
Reporter: | sebster | Assignee: | keilw |
Resolution: | Fixed | Votes: | 1 |
Labels: | None | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Sprint: | Q2/15 |
Description |
Problem: convert(Number) calls itself. Patch: @@ -100,7 +100,7 @@ public abstract class AbstractConverter implements UnitConverter { @Override public abstract double convert(double value); |
[UNITSOFMEASUREMENT-129] JDK6 compatibility for unit-ri Created: 09/Apr/15 Updated: 02/Dec/15 Resolved: 02/Dec/15 | |
Status: | Resolved |
Project: | unitsofmeasurement |
Component/s: | RI |
Affects Version/s: | 0.8 |
Fix Version/s: | 0.9 |
Type: | Improvement | Priority: | Minor |
Reporter: | sebster | Assignee: | keilw |
Resolution: | Fixed | Votes: | 0 |
Labels: | None | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Attachments: | ![]() | ||||||||||||||||
Issue Links: |
| ||||||||||||||||
Sprint: | Final Draft |
Description |
I've made RI compatible with Java SE 6 (mvn clean install runs against 1.6.0u45). I've made the minimum number of possible changes to keep the patch as clean as possible. I've chosen to "inline" the references to the Objects utility class instead of making an own Objects utility class with only the needed methods. The only real impact is the readability of Objects.equals but I believe the readability is not too bad as is. |
Comments |
Comment by keilw [ 09/Apr/15 ] |
Great, do you have a patch/diff to see changes? |
Comment by sebster [ 09/Apr/15 ] |
For lack of a better method at the moment, patch at: https://www.sebster.com/~sebster/java-se6.patch |
Comment by keilw [ 09/Apr/15 ] |
Thanks. Will check it out, and if you don't mind, I'd merge it over to this JIRA ticket, too (strange even the reporter of a ticket can't attach anything, will explore with Java.net crew why) |
Comment by sebster [ 09/Apr/15 ] |
Yeah, no problem. I'm happy if I can contribute. |
Comment by keilw [ 10/Apr/15 ] |
Patch provided by reporter. |
Comment by keilw [ 11/Jul/15 ] |
I'm afraid, after sometimes massive refactoring the patch will no
longer be of much use. |
Comment by keilw [ 23/Nov/15 ] |
Objects.equals() seems pretty much a one-liner, so
substituting it looks very easy. Not even sure, why they took the trouble
to add that to the JDK? |
Comment by sebster [ 23/Nov/15 ] |
I have a new patch (done today) based on the 0.8 tag. I've provided it here: http://www.sebster.com/~sebster/0001-Java-6-compatibility.patch We (you won't believe this) also need to port it to Java 5, and that's exactly the same as porting it to Java 6 except that the ServiceLoader class does not exist in Java 5 (used once). I still have to figure out how I can replace that. |
Comment by keilw [ 23/Nov/15 ] |
Thanks, will check it out. @otaviojava added a few "diamond" cases that
need to be built back recently, but other than that it should be pretty
Java 6 compliant. It depends what if anything you'd need from the SPI: http://unitsofmeasurement.github.io/unit-api/site/apidocs/javax/measure/spi/package-frame.html |
Comment by keilw [ 24/Nov/15 ] |
Ok, I was able to undo all the Diamond stuff and apply the patch. The RI builds against Java 6 now by default, too. The API got some profiles, on one hand to override the default JDK (for some plugins it's Java 7 for the API, but the CI build uses 6) allowing in theory to build with Java 5 to 8 compatibility. The problem is, I installed the latest Java 5 SDK (1.5_u22) available and Eclipse could still handle it, but Maven has more than one plugin that simply won't work below Java 6 (for that I had to down-grade the Surefire plugin by default) So while everything other than SPI/Service Loader functionality should be Java 5 compatible from all we know (JSR-275 and Unit-API 0.6 both still built Java 5 compatible) for build tools you're on your own. Not sure, if Gradle ever supported such an old Java version at all? Otherwise please try Ant, it will of course work,, but for those build scripts you're on your own when it comes to building the API (core or other JARs) with Java 5 for Java 5. Same for a Java 5 compliant fork of the RI. Most of it should work, but we can't provide it out of the box any more I'm afraid. |
Comment by sebster [ 24/Nov/15 ] |
Thanks for applying the patch. Do you use the maven toolchains plugin? Because from maven 3.3 onward I believe that maven even won't compile projects with jdk6 without it. With the maven toolchains plugin it's possible to compile projects even with jdk5 (that's what I'm doing now). However that wouldn't solve the ServiceProvider issue. |
Comment by keilw [ 24/Nov/15 ] |
No, but I know, Apache Tamaya where at least 2 EG members including
myself also @otaviojava) are committers, does. If it adds a benefit and
does not break anything, we might explore that for the Final Draft
iteration/API. The maven-jar-plugin with qualifiers like "core" is a compromise. In an
early version of the API I actually grouped them into real Maven modules
for "core", "format",..., then putting the whole API in a single JAR via
maven-shade-plugin but some EG members felt a bit uneasy about it, so we
changed the structure. Mostly to test the TCK and smaller implementations
(e.g. https://github.com/unitsofmeasurement/uom-impl-enum
currently implements "format" + "base_quantity", we may extend it to a new
"format+quantity" profile) module JARs are also good to have, but as of
now, we probably won't deploy them to Maven repositories. I think the
maven-jar-plugin (or rather maven-compile-plugin) compiles everything and
then only puts selected packages to a smaller archive, thus compiling
against Java 5 may be tricky, but as mentioned in the JSR 354 list, could
you try compiling with Java 6 using the "jdk5" option? The JDK option, not
the JDK running it should make the JARs compatible with a minimum Java
version. As long as you avoid using the "spi" JAR under Java 5, the others
should work. |
Comment by keilw [ 24/Nov/15 ] |
P.s.: Do you have a GitHub user, too? Would be happy to add you as "Observer" or "Adopter" (that sounds more appropriate, also gives commit rights to most repos except the core JSR artifacts like API, RI or TCK which require EG membership) |
Comment by sebster [ 24/Nov/15 ] |
Yes, my github user is sebster as well. I think it's already added to many of the projects. Regarding the toolchains plugin: it adds a benefit that it actually compiles with the JDK of the required source level, but it also requires you to specify the jdk locations in a settings.xml, so it makes it harder for someone to build the software. I don't know what maven version you are using, but currently, maven 3.3+ does not support building with JDK6 anymore, so to officially support JDK6 I think the toolchains plugin is required. This is also currently a problem with the maven artifacts in the maven repositories for unit-api and unit-ri: they are compiled with JDK7 even if they have source level JDK6, and as such, when trying to use them in a JDK6 project, you get a class version error: Unsupported major.minor version 51.0. (Note: unit-api compiles in JDK6 without any source changes, but the current repo artifact is compiled with JDK7 and therefore not usable with JDK6). I have attached the diffs for the toolchains plugin though I am having a bit of a fight with the javadoc plugin because it's calling the proper javadoc but passing it a JDK8 option (-Xdoclint:none) since maven is running under JDK8 and thinks that javadoc supports it; I haven't fixed that problem yet. (http://www.sebster.com/~sebster/0001-Make-api-java-6-compatible-and-use-toolchains-plugin.patch) As for JDK5, I got it working by basically removing the non-compiling
stuff from the spi package. I understand Java 5 is fully unsupported and
end of life, and I agree with you that it's probably not a good idea for
you guys to go to the effort of supporting it. I'm going to maintain my
own fork for this, mainly it's just throwing some stuff out, so it should
be easy for me to pull in upstream changes for new releases. I'm unhappy
that I need to support Java 5 and hopefully it's not for more than a year
or two, but for now that's life. |
Comment by keilw [ 24/Nov/15 ] |
Will check, somehow it wasn't found, but maybe you are already in a
team (Adopters, so you can contribute to all the mentioned projects If the JDK location for the toolchain plugin must be set in the
settings.xlm that sounds very hard to comply with the DevOps/Docker style
CI tools like Circle-CI we use everywhere (some repos have others as
fall-back, but all of them build on Circle now at UoM) In theory something
like that could be available via CIRCLE_... variables, but in most cases
that's up to the container and build job, all you want to chose is the JVM
version. |
Comment by keilw [ 02/Dec/15 ] |
RI now runs properly against Java SE 6 |
[UNITSOFMEASUREMENT-128] Add ServiceProvider interface Created: 09/Apr/15 Updated: 09/Jun/15 Resolved: 09/Jun/15 | |
Status: | Resolved |
Project: | unitsofmeasurement |
Component/s: | API |
Affects Version/s: | None |
Fix Version/s: | None |
Type: | New Feature | Priority: | Major |
Reporter: | keilw | Assignee: | keilw |
Resolution: | Fixed | Votes: | 0 |
Labels: | None | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Issue Links: |
| ||||||||
Tags: | api, design, spi | ||||||||
Epic Link: | Design | ||||||||
Sprint: | Q2/15 |
Description |
Similar to JSR 354 (using the BP https://github.com/JavaMoney/jsr354-api-bp/blob/master/src/main/java/javax/money/spi/ServiceProvider.java
as it's Java 6/7 compliant) it seems good to have a
ServiceProvider interface. That may be the only "Provider" for
the SPI, sticking to the "*Service" naming convention for other
components, since ServiceProvider then literally provides
services rather than again providers |
Comments |
Comment by keilw [ 09/Apr/15 ] |
Changing all names from *Service to *Provider wouldn't make sense if
ServiceProvider in a way 354 applies it was introduced. Since it
provides those *Service elements |
[UNITSOFMEASUREMENT-127] Simplify unit systems in RI Created: 08/Apr/15 Updated: 01/Jul/15 Resolved: 01/Jul/15 | |
Status: | Resolved |
Project: | unitsofmeasurement |
Component/s: | RI |
Affects Version/s: | None |
Fix Version/s: | 0.8-RC3 |
Type: | Improvement | Priority: | Major |
Reporter: | keilw | Assignee: | keilw |
Resolution: | Fixed | Votes: | 0 |
Labels: | None | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Issue Links: |
| ||||||||||||||||||||||||
Tags: | design, unit | ||||||||||||||||||||||||
Epic Link: | Design | ||||||||||||||||||||||||
Sprint: | Q2/15 |
Description |
To clarify the SI-compliant, but "simplified" scope of API quantities,
and align naming also a bit with the Quantities accessor class, I
suggest we simplify and combine unit systems in the RI into a single
Units class. (which implements SystemOfUnits or whatever
the final name for it) ICU4J or JSR 256 have static accessors to known
units in the actual type like |
Comments |
Comment by keilw [ 08/Apr/15 ] |
This is more a follow-up than duplicate, but related to changing the names of unit systems in the RI. |
Comment by keilw [ 19/Apr/15 ] |
Effectively renaming CommonUnits to Units and merging other systems into it. |
[UNITSOFMEASUREMENT-126] Should we rename SI to Metric? Created: 02/Apr/15 Updated: 15/Apr/15 Resolved: 07/Apr/15 | |
Status: | Resolved |
Project: | unitsofmeasurement |
Component/s: | RI |
Affects Version/s: | 0.7.1 |
Fix Version/s: | None |
Type: | Improvement | Priority: | Minor |
Reporter: | keilw | Assignee: | Unassigned |
Resolution: | Won't Fix | Votes: | 0 |
Labels: | None | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Issue Links: |
| ||||||||||||||||||||||||
Tags: | design, naming | ||||||||||||||||||||||||
Epic Link: | Design | ||||||||||||||||||||||||
Sprint: | Q2/15 |
Description |
At least JScience 5 called the SI unit system Metric
since end of JSR 275. ICU4J on one hand has at least one internal class
calling it "SI", too (a reason why e.g. UOMo stuck to that name, but the
underlying Unicode CLDR calls the system "Metric" again, see: A side-effect could be improved browsability by IDEs like Eclipse. A class name that's only 2 or 3 characters long is assumed a camelcase short-cut, and it usually gets confused when trying to browse a type "SI". If we made any change, I'd stick exactly to the 3 standard names in CLDR. WDYT? |
Comments |
Comment by keilw [ 07/Apr/15 ] |
Actually Wikipedia under "SI Units" http://en.wikipedia.org/wiki/International_System_of_Units claims SI is the modern form of the http://en.wikipedia.org/wiki/Metric_system so "Metric System" is a whole variety of standardization efforts, while "SI" marks its latest stage. So let's keep SI unless you really want to change it? |
[UNITSOFMEASUREMENT-125] Some API JUnit tests won't work under Java 6 Created: 22/Mar/15 Updated: 20/Sep/15 Resolved: 20/Sep/15 | |
Status: | Resolved |
Project: | unitsofmeasurement |
Component/s: | API |
Affects Version/s: | None |
Fix Version/s: | None |
Type: | Bug | Priority: | Minor |
Reporter: | keilw | Assignee: | keilw |
Resolution: | Fixed | Votes: | 0 |
Labels: | None | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Issue Links: |
| ||||||||
Tags: | junit, test_issue | ||||||||
Epic Link: | Test | ||||||||
Sprint: | Public Draft |
Description |
This came up when running the API on drone.io against Java 6 (officially the minimum version) see https://drone.io/github.com/unitsofmeasurement/unit-api/9 At least some JUnit tests don't seem to run under SE 6 as they do on 7 or above. Not the highest priority, especially since SE 6 is no longer officially supported by Oracle. Nor looking like a problem of the actual API deliverables, but if someone has time and wants to look into it, feel free. $ mvn install -q -DskipTests=true [ERROR] COMPILATION ERROR : [ERROR] /home/ubuntu/src/github.com/unitsofmeasurement/unit-api/src/test/java/javax/measure/test/quantity/DistanceQuantity.java:[162,38] inconvertible types found : javax.measure.test.quantity.DistanceQuantity required: javax.measure.Quantity<T> [ERROR] /home/ubuntu/src/github.com/unitsofmeasurement/unit-api/src/test/java/javax/measure/test/quantity/AreaQuantity.java:[151,38] inconvertible types found : javax.measure.test.quantity.AreaQuantity required: javax.measure.Quantity<T> [ERROR] /home/ubuntu/src/github.com/unitsofmeasurement/unit-api/src/test/java/javax/measure/test/quantity/VolumeQuantity.java:[150,38] inconvertible types found : javax.measure.test.quantity.VolumeQuantity required: javax.measure.Quantity<T> [ERROR] /home/ubuntu/src/github.com/unitsofmeasurement/unit-api/src/test/java/javax/measure/test/quantity/TimeQuantity.java:[136,38] inconvertible types found : javax.measure.test.quantity.TimeQuantity required: javax.measure.Quantity<T> [ERROR] /home/ubuntu/src/github.com/unitsofmeasurement/unit-api/src/test/java/javax/measure/test/quantity/BitQuantity.java:[159,38] inconvertible types found : javax.measure.test.quantity.BitQuantity required: javax.measure.Quantity<T> [ERROR] /home/ubuntu/src/github.com/unitsofmeasurement/unit-api/src/test/java/javax/measure/test/quantity/BitRateQuantity.java:[145,38] inconvertible types found : javax.measure.test.quantity.BitRateQuantity required: javax.measure.Quantity<T> [ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.1:testCompile (default-testCompile) on project unit-api: Compilation failure: Compilation failure: [ERROR] /home/ubuntu/src/github.com/unitsofmeasurement/unit-api/src/test/java/javax/measure/test/quantity/DistanceQuantity.java:[162,38] inconvertible types [ERROR] found : javax.measure.test.quantity.DistanceQuantity [ERROR] required: javax.measure.Quantity<T> [ERROR] /home/ubuntu/src/github.com/unitsofmeasurement/unit-api/src/test/java/javax/measure/test/quantity/AreaQuantity.java:[151,38] inconvertible types [ERROR] found : javax.measure.test.quantity.AreaQuantity [ERROR] required: javax.measure.Quantity<T> [ERROR] /home/ubuntu/src/github.com/unitsofmeasurement/unit-api/src/test/java/javax/measure/test/quantity/VolumeQuantity.java:[150,38] inconvertible types [ERROR] found : javax.measure.test.quantity.VolumeQuantity [ERROR] required: javax.measure.Quantity<T> [ERROR] /home/ubuntu/src/github.com/unitsofmeasurement/unit-api/src/test/java/javax/measure/test/quantity/TimeQuantity.java:[136,38] inconvertible types [ERROR] found : javax.measure.test.quantity.TimeQuantity [ERROR] required: javax.measure.Quantity<T> [ERROR] /home/ubuntu/src/github.com/unitsofmeasurement/unit-api/src/test/java/javax/measure/test/quantity/BitQuantity.java:[159,38] inconvertible types [ERROR] found : javax.measure.test.quantity.BitQuantity [ERROR] required: javax.measure.Quantity<T> [ERROR] /home/ubuntu/src/github.com/unitsofmeasurement/unit-api/src/test/java/javax/measure/test/quantity/BitRateQuantity.java:[145,38] inconvertible types [ERROR] found : javax.measure.test.quantity.BitRateQuantity [ERROR] required: javax.measure.Quantity<T> [ERROR] -> [Help 1] |
Comments |
Comment by keilw [ 20/Sep/15 ] |
Circle-CI https://circleci.com/gh/unitsofmeasurement/unit-api now runs with Java 6 |
[UNITSOFMEASUREMENT-124] Introduce a Unit "DB" Created: 04/Mar/15 Updated: 30/Dec/15 Resolved: 30/Dec/15 | |
Status: | Resolved |
Project: | unitsofmeasurement |
Component/s: | API |
Affects Version/s: | 0.7.1 |
Fix Version/s: | None |
Type: | Improvement | Priority: | Minor |
Reporter: | keilw | Assignee: | keilw |
Resolution: | Won't Fix | Votes: | 0 |
Labels: | None | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Issue Links: |
| ||||||||||||||||||||||||
Tags: | design, question, vote | ||||||||||||||||||||||||
Epic Link: | Design | ||||||||||||||||||||||||
Sprint: | Q1/15 |
Description |
Similar to UCAR Units (derived from JSR 108 lead by UCAR) it may help to introduce a sort of unit "database" like its UnitSystem https://www.unidata.ucar.edu/software/thredds/v4.3/netcdf-java/v4.0/javadocAll/ucar/units/UnitSystem.html returns. UnitDB (the name is questionable, some suggestions below) provides access to certain groups of units, UCAR has a choice of Base Units and All Units of a system, that also goes along issues (links -88 and -89) raised before. The name UnitDB suggests it is a (relational) database, which often is not the case. Some possible names are
Feel free to suggest a better name you may think of. Please vote if
you care with a +1 and (optionally) the name you think is best. Thanks, |
Comments |
Comment by keilw [ 04/Mar/15 ] |
Methods like label() or alias() in UnitFormat meet a similar goal, but at most those would be specific to a particular format or (where formats are created by Locale) locale. Otherwise apply to the whole instance of the VM, not a particular unit system or source. |
Comment by keilw [ 30/Dec/15 ] |
May pick this idea up later, but for 1.0 it is out of scope. |
Make RI and
related libraries available to public Maven repositories
(UNITSOFMEASUREMENT-35)
| |
Status: | Closed |
Project: | unitsofmeasurement |
Component/s: | Lib |
Affects Version/s: | 0.4 |
Fix Version/s: | 0.8-RC3 |
Type: | Sub-task | Priority: | Major |
Reporter: | keilw | Assignee: | keilw |
Resolution: | Fixed | Votes: | 0 |
Labels: | None | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Issue Links: |
| ||||||||
Tags: | deployment, maven | ||||||||
Sprint: | Q1/15, Q2/15 |
Comments |
Comment by keilw [ 25/Jun/15 ] |
uom-lib is already available on JCenter, closing this as it will be tracked further on GitHub, e.g. https://github.com/unitsofmeasurement/uom-lib/issues/9 |
[UNITSOFMEASUREMENT-122] Should we rename SystemOfUnits? Created: 02/Mar/15 Updated: 09/Jun/15 Resolved: 26/Apr/15 | |
Status: | Closed |
Project: | unitsofmeasurement |
Component/s: | API |
Affects Version/s: | 0.7.1 |
Fix Version/s: | 0.8 |
Type: | Improvement | Priority: | Minor |
Reporter: | keilw | Assignee: | keilw |
Resolution: | Won't Fix | Votes: | 0 |
Labels: | None | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Issue Links: |
| ||||||||||||||||||||||||||||
Tags: | design, naming, question, vote | ||||||||||||||||||||||||||||
Epic Link: | Design | ||||||||||||||||||||||||||||
Sprint: | Q1/15, Q2/15 |
Description |
Going over an abstraction similar to DataSource > Connection if you want in SQL terms, allowing easier and more dynamic unit definitions, the question also comes up, if we want to keep the name SystemOfUnits or consider alternatives like
For providing services like (currently named) SystemOfUnitsService as opposed to UnitFormatService names like UnitSystem and UnitSystemService also sound more harmonically. Please advise below with a simple +1 for an option you prefer. |
Comments |
Comment by anakarparida [ 02/Mar/15 ] |
+1 UnitSystemService |
Comment by keilw [ 02/Mar/15 ] |
I guess you mean UnitSystem? (the *Service would come naturally for
related classes) |
Comment by anakarparida [ 02/Mar/15 ] |
Yes UnitSystem is the preferred choice. |
Comment by keilw [ 04/Mar/15 ] |
+1 SystemOfUnits (on behalf of dautelle) |
Comment by leomrlima [ 20/Apr/15 ] |
I like SystemOfUnits better, no scientific point; but UnitSystem sounds "more right". It's hard to know if it's right because I'm no native english speaker,
and System of Units translates directly to Portuguese |
Comment by keilw [ 20/Apr/15 ] |
So you "abstain" or prefer a "0" vote? I know it is tricky, Wikipedia actually calls it "System of
Measurement" http://en.wikipedia.org/wiki/System_of_measurement |
Comment by leomrlima [ 20/Apr/15 ] |
I vote on SystemOfUnits, unless it's wrong Engrish |
Comment by leomrlima [ 20/Apr/15 ] |
Well, while browsing for the SI x Metric, I found that SI is International System of Units. So I stick to my vote! |
Comment by keilw [ 20/Apr/15 ] |
No it's not. Thanks for your vote. I'll simply abstain/0 to
respect the votes by 2 other Spec Leads (against one other vote for
"UnitSystem") Thanks, |
Comment by keilw [ 26/Apr/15 ] |
Vote concluded to keep it SystemOfUnits |
[UNITSOFMEASUREMENT-121] Introduce "Pluggable" Unit Systems and data sources Created: 20/Feb/15 Updated: 23/Feb/16 Resolved: 23/Feb/16 | |
Status: | Resolved |
Project: | unitsofmeasurement |
Component/s: | API, Lib, RI |
Affects Version/s: | 0.7.1 |
Fix Version/s: | None |
Type: | Improvement | Priority: | Major |
Reporter: | keilw | Assignee: | keilw |
Resolution: | Won't Fix | Votes: | 0 |
Labels: | None | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Attachments: | ![]() | ||||||||||||||||||||||||||||||||||||||||||||
Issue Links: |
| ||||||||||||||||||||||||||||||||||||||||||||
Tags: | data, i18n/l10n, spi | ||||||||||||||||||||||||||||||||||||||||||||
Epic Link: | Design | ||||||||||||||||||||||||||||||||||||||||||||
Sprint: | Q1/15 |
Description |
To overcome problems with different unit systems or data sources for unit definitions (e.g. UCUM vs. SI, etc.) we should try to make this somewhat pluggable, see i18n enhancements by Java 8 using CLDR among other sources: http://docs.oracle.com/javase/8/docs/technotes/guides/intl/enhancements.8.html Allowing something like: "javax.measure.unitsystemproviders=NIST,SPI,SI,CLDR,UCUM"
The default behavior is equivalent to the following setting: "javax.measure.unitsystemproviders=NIST,SPI"
Not sure, if we'd call the default "NIST" or something else (like "DEFAULT") that's up to working on this item. |
Comments |
Comment by keilw [ 02/Mar/15 ] |
Not a real show-stopper, the type works with either name, but if we feel there's a better name, it can be changed more easily prior to Public Draft. |
Comment by keilw [ 24/Jun/15 ] |
This is an overview of possible dependencies between API, implementations, libraries (especially Unit Systems or similar) and applications consuming them |
Comment by leomrlima [ 23/Feb/16 ] |
Not sure how to make this in Java ME... |
Comment by keilw [ 23/Feb/16 ] |
Unlike JSR 354 where Conversion providers were included with the very core of the RI (similar to Date/Time in Java 8 or ever since) we pretty much decoupled this into "extension modules" so I think other than maybe Bootstrap helping to retrieve certain implementations (e.g. UCUMFormat in the UCUM module (currently for SE only) we don't seem to have such a strong requirement here any more. If the Liblets concept works similar to Java SE service loaders, it should work under ME, but the core API and SPI are rather small now. |
Comment by keilw [ 23/Feb/16 ] |
Most of this was deferred into extension modules like https://github.com/unitsofmeasurement/si-units or https://github.com/unitsofmeasurement/uom-systems Mostly via the Bootstrap class and services it provides, codes like "UCUM" or similar may be used, and methods like getAvailableFormatNames() in UnitFormatService provide a list of services that are available/loaded. It does not seem necessary to define any other loading mechanism than what's used by an implementation, either Java Service Loaders, (ME) LibLets, OSGi or in future maybe Jigsaw. |
[UNITSOFMEASUREMENT-120] Sync Unit Systems with oBIX Created: 16/Feb/15 Updated: 07/Apr/15 Resolved: 07/Apr/15 | |
Status: | Resolved |
Project: | unitsofmeasurement |
Component/s: | RI |
Affects Version/s: | 0.7.1 |
Fix Version/s: | None |
Type: | Task | Priority: | Major |
Reporter: | keilw | Assignee: | keilw |
Resolution: | Won't Fix | Votes: | 0 |
Labels: | None | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Issue Links: |
| ||||||||||||||||||||||||
Tags: | resources, unit | ||||||||||||||||||||||||
Epic Link: | View | ||||||||||||||||||||||||
Sprint: | Q1/15, Q2/15 |
Description |
Especially for Smart Home and Smart Buildings the OASIS standard oBIX
(http://www.obix.org/) is quite important for
communications between vendors and devices. |
Comments |
Comment by keilw [ 16/Feb/15 ] |
Both are possible sources to tap into. |
Comment by keilw [ 25/Mar/15 ] |
oBIX where fully supported may change the number of quantities. |
Comment by keilw [ 07/Apr/15 ] |
At least for the RI oBIX contains too many non-SI quantities (see files attached to https://java.net/jira/browse/UNITSOFMEASUREMENT-100), so we won't support it here. Subject to UOM-SE, or Tools: https://github.com/unitsofmeasurement/uom-tools/issues |
Portability of
RI (UNITSOFMEASUREMENT-3)
| |
Status: | Resolved |
Project: | unitsofmeasurement |
Component/s: | RI |
Affects Version/s: | 0.7.1 |
Fix Version/s: | 0.8 |
Type: | Sub-task | Priority: | Major |
Reporter: | keilw | Assignee: | leomrlima |
Resolution: | Won't Fix | Votes: | 0 |
Labels: | None | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Tags: | embedded, i18n/l10n, l10n, portability |
Sprint: | Q1/15, Public Draft |
Description |
To get independent of SE ResourceBundle/Locale a small interface
L10nBundle is implemented by 2 classes. One works,
MapResourceBundle is inspired by Nokia suggestions (see
attachments/comments of If there's no performance or size penalty, using properties would be nice, otherwise we may have to select the one that works. |
Comments |
Comment by keilw [ 11/Jun/15 ] |
As of now the class-based L10nResources work, so L10nPropertyResources is not really neccessary. |
Create
TCK (UNITSOFMEASUREMENT-101)
| |
Status: | Resolved |
Project: | unitsofmeasurement |
Component/s: | TCK |
Affects Version/s: | 0.7.1 |
Fix Version/s: | 0.9 |
Type: | Sub-task | Priority: | Critical |
Reporter: | keilw | Assignee: | keilw |
Resolution: | Fixed | Votes: | 0 |
Labels: | None | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Issue Links: |
| ||||||||
Tags: | api, spec, tck-red, test, testing | ||||||||
Sprint: | Q1/15, Final Draft |
Description |
Spec Chapter 4 (API) requires TCK Tests
|
Comments |
Comment by keilw [ 03/Apr/16 ] |
This looks pretty complete |
Create
TCK (UNITSOFMEASUREMENT-101)
| |
Status: | Resolved |
Project: | unitsofmeasurement |
Component/s: | TCK |
Affects Version/s: | 0.7.1 |
Fix Version/s: | None |
Type: | Sub-task | Priority: | Major |
Reporter: | keilw | Assignee: | keilw |
Resolution: | Won't Fix | Votes: | 0 |
Labels: | None | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Tags: | tck-red, test, testing |
Sprint: | Q1/15, Final Draft |
Description |
Spec Chapter 2 (Definitions) could require TCK Tests
|
Comments |
Comment by keilw [ 20/Sep/15 ] |
As of now only Chapter 4 and 5 seem TCK relevant |
Remove UCUM
from RI (UNITSOFMEASUREMENT-114)
| |
Status: | Resolved |
Project: | unitsofmeasurement |
Component/s: | RI |
Affects Version/s: | 0.7.1 |
Fix Version/s: | None |
Type: | Sub-task | Priority: | Major |
Reporter: | keilw | Assignee: | keilw |
Resolution: | Fixed | Votes: | 0 |
Labels: | None | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Issue Links: |
| ||||||||||||||||||||||||
Tags: | format, i18n/l10n | ||||||||||||||||||||||||
Sprint: | Q1/15, Q2/15 |
Description |
UCUMFormat and supporting helper classes (mostly in format.internal) shall be refactored into a locale-neutral format like SimpleUnitFormat. |
Comments |
Comment by keilw [ 23/Jan/15 ] |
Getting this format Locale and ResourceBundle agnostic should help further ME integration |
Remove UCUM
from RI (UNITSOFMEASUREMENT-114)
| |
Status: | Resolved |
Project: | unitsofmeasurement |
Component/s: | RI |
Affects Version/s: | 0.7.1 |
Fix Version/s: | 0.8 |
Type: | Sub-task | Priority: | Major |
Reporter: | keilw | Assignee: | keilw |
Resolution: | Fixed | Votes: | 0 |
Labels: | None | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Tags: | unit, utils |
Sprint: | Q1/15, Q2/15 |
Description |
Remove the UCUM class |
[UNITSOFMEASUREMENT-114] Remove UCUM from RI Created: 22/Jan/15 Updated: 09/Jun/15 Resolved: 09/Jun/15 | |
Status: | Resolved |
Project: | unitsofmeasurement |
Component/s: | RI |
Affects Version/s: | 0.7.1 |
Fix Version/s: | 0.8-RC3 |
Type: | Task | Priority: | Critical |
Reporter: | keilw | Assignee: | keilw |
Resolution: | Fixed | Votes: | 0 |
Labels: | None | ||
Σ Remaining Estimate: | Not Specified | Remaining Estimate: | Not Specified |
Σ Time Spent: | Not Specified | Time Spent: | Not Specified |
Σ Original Estimate: | Not Specified | Original Estimate: | Not Specified |
Issue Links: |
| ||||||||||||||||
Sub-Tasks: |
| ||||||||||||||||
Tags: | refactoring | ||||||||||||||||
Epic Link: | Portability | ||||||||||||||||
Sprint: | Q1/15, Q2/15 |
Description |
As discussed, UCUM support shall be removed from the RI to solve discrepancies between some elements in the UCUM system and more importantly get the size of the RI down. The SE port or other implementations should cover that. If UCUM support for ME Embedded is desired, it may done so but it does not have to be part of the RI. This task will likely be split into smaller sub-tasks. |
[UNITSOFMEASUREMENT-113] Set up CI for key repositories Created: 19/Jan/15 Updated: 12/Jun/15 Resolved: 12/Jun/15 | |
Status: | Resolved |
Project: | unitsofmeasurement |
Component/s: | API, RI, TCK |
Affects Version/s: | 0.7.1 |
Fix Version/s: | None |
Type: | Task | Priority: | Major |
Reporter: | keilw | Assignee: | keilw |
Resolution: | Fixed | Votes: | 0 |
Labels: | None | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Tags: | automation, testing |
Epic Link: | Infrastructure |
Sprint: | Q1/15, Q2/15 |
Description |
At least the most important artifacts other than the API (which is already built on GeoAPI) should be compiled and monitored by a CI server. Options/evaluated are:
|
Comments |
Comment by keilw [ 12/Jun/15 ] |
Single module projects like API, RI or SE-port mostly use drone.io. |
[UNITSOFMEASUREMENT-112] Refactor "internal" elements of RI format Created: 19/Jan/15 Updated: 27/Jan/15 Resolved: 27/Jan/15 | |
Status: | Resolved |
Project: | unitsofmeasurement |
Component/s: | RI |
Affects Version/s: | 0.7.1 |
Fix Version/s: | None |
Type: | Task | Priority: | Minor |
Reporter: | keilw | Assignee: | keilw |
Resolution: | Duplicate | Votes: | 0 |
Labels: | None | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Issue Links: |
| ||||||||
Tags: | format, refactor | ||||||||
Epic Link: | View | ||||||||
Sprint: | Q1/15 |
Description |
To distinguish from a dedicated UCUM parser against a
ucum-essense.xml file some classes in "*.format.internal" should be
renamed see |
Comments |
Comment by keilw [ 27/Jan/15 ] |
This partly duplicates the removal of UCUMFormat. Most of becomes irrelevant if the corresponding format is removed. |
[UNITSOFMEASUREMENT-111] Test-related items like TCK or JUnit Tests, etc. Created: 19/Jan/15 Updated: 28/Sep/16 Resolved: 28/Sep/16 | |
Status: | Resolved |
Project: | unitsofmeasurement |
Component/s: | None |
Affects Version/s: | None |
Fix Version/s: | 1.0 |
Type: | Epic | Priority: | Major |
Reporter: | keilw | Assignee: | keilw |
Resolution: | Fixed | Votes: | 0 |
Labels: | None | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Epic Name: | Test |
[UNITSOFMEASUREMENT-110] Presentation and UI aspects including i18n, Formatting, Parsing Created: 18/Jan/15 Updated: 22/Oct/16 Resolved: 22/Oct/16 | |
Status: | Resolved |
Project: | unitsofmeasurement |
Component/s: | None |
Affects Version/s: | None |
Fix Version/s: | 1.x |
Type: | Epic | Priority: | Minor |
Reporter: | keilw | Assignee: | keilw |
Resolution: | Fixed | Votes: | 0 |
Labels: | None | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Epic Name: | View |
[UNITSOFMEASUREMENT-109] Clarify behavior of getSymbol() by a TransformedUnit Created: 17/Jan/15 Updated: 20/Oct/15 Resolved: 20/Oct/15 | |
Status: | Resolved |
Project: | unitsofmeasurement |
Component/s: | RI |
Affects Version/s: | None |
Fix Version/s: | 0.8 |
Type: | Improvement | Priority: | Major |
Reporter: | keilw | Assignee: | keilw |
Resolution: | Fixed | Votes: | 0 |
Labels: | None | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Issue Links: |
| ||||||||||||||||||||
Tags: | i18n/l10n, string, ui | ||||||||||||||||||||
Epic Link: | View | ||||||||||||||||||||
Sprint: | Q1/15, Public Draft |
Description |
At least the concrete class TransformedUnit receives its symbol (returned by getSymbol() via the parent unit from which it is derived. To a certain extent this may affect every derived unit. While formatting and output via toString() works as designed for the cases tested and other output, e.g. via UnitFormat also have the same result, the getSymbol() method of derived types like GRAM, POUND etc. all show the symbol of the base unit being KILOGRAM in this case, but similar examples for other quanties should produce a similar outcome. Some users feel this was a bug. As of now TransformedUnit is designed like that so it "workes as designed". Either we may want to tweak the behavior or clarify in JavaDoc and where necessary in the spec, why this method returns e.g. "kg" while toString() returns "g", "oz", "lb" or similar. |
Comments |
Comment by keilw [ 19/Jan/15 ] |
The API JavaDoc http://www.unitsofmeasurement.org/jsr-363/apidocs/javax/measure/Unit.html#getSymbol() suggests, null would be returned in cases like product of units. Which is why either JavaDoc of concrete classes need further clarification or the implementation should change to reflect that. |
Comment by keilw [ 20/Oct/15 ] |
As of now, most issues related to a TransformedUnit not holding a symbol can be solved by using UnitFormat.label() |
[UNITSOFMEASUREMENT-108] getSymbol() and toString() differ for several Mass units Created: 15/Jan/15 Updated: 06/Jul/15 Resolved: 19/Feb/15 | |
Status: | Closed |
Project: | unitsofmeasurement |
Component/s: | RI |
Affects Version/s: | 0.7.1 |
Fix Version/s: | None |
Type: | Bug | Priority: | Critical |
Reporter: | keilw | Assignee: | keilw |
Resolution: | Duplicate | Votes: | 0 |
Labels: | None | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Issue Links: |
| ||||||||||||||||
Tags: | i18n, symbol | ||||||||||||||||
Epic Link: | View | ||||||||||||||||
Sprint: | Q1/15 |
Description |
As UnitsTest.testGetSymbol() shows, the result of getSymbol() differs from toString() which returns the expected value. Most Mass units have only the SI base symbol "kg" rather than their expected symbol. The string representation however is correct. This also seems very similar for the SE port |
Comments |
Comment by keilw [ 19/Feb/15 ] |
This was more generalized by #109 |
Comment by keilw [ 19/Feb/15 ] |
Closed as duplicate |
[UNITSOFMEASUREMENT-107] Move some elements to a package "spi" Created: 12/Jan/15 Updated: 19/Apr/15 Resolved: 19/Apr/15 | |
Status: | Resolved |
Project: | unitsofmeasurement |
Component/s: | RI |
Affects Version/s: | 0.7.1 |
Fix Version/s: | None |
Type: | Improvement | Priority: | Minor |
Reporter: | keilw | Assignee: | keilw |
Resolution: | Fixed | Votes: | 0 |
Labels: | None | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Issue Links: |
| ||||||||
Tags: | naming, package | ||||||||
Epic Link: | Design | ||||||||
Sprint: | Q1/15, Q2/15 |
Description |
Similar to the API some elements currently in "util" like SystemOfUnits implementations (SI, UCUM,...) could be moved into a new package "spi". Making the package name more consistent with the API. |
[UNITSOFMEASUREMENT-106] Try to declare members of Units as Unit, not concrete classes Created: 12/Jan/15 Updated: 03/Nov/15 Resolved: 03/Nov/15 | |
Status: | Resolved |
Project: | unitsofmeasurement |
Component/s: | RI |
Affects Version/s: | 0.7.1 |
Fix Version/s: | 0.8 |
Type: | Improvement | Priority: | Major |
Reporter: | keilw | Assignee: | keilw |
Resolution: | Fixed | Votes: | 0 |
Labels: | None | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Issue Links: |
| ||||||||||||||||
Tags: | design, implementation | ||||||||||||||||
Epic Link: | Design | ||||||||||||||||
Sprint: | Q1/15, Public Draft |
Description |
Some member variables in Units are declared as concrete types like BaseUnit at the moment. This not only affected formatting (see bug reference) it makes the idea of an API level class backed by SPI hard. Where nothing is broken the external declaration of all member variables should be changed to Unit<Q> |
[UNITSOFMEASUREMENT-105] KILO(GRAM) misformatted as Mg Created: 12/Jan/15 Updated: 18/Jan/15 Resolved: 12/Jan/15 | |
Status: | Resolved |
Project: | unitsofmeasurement |
Component/s: | RI |
Affects Version/s: | 0.7.1 |
Fix Version/s: | None |
Type: | Bug | Priority: | Critical |
Reporter: | keilw | Assignee: | keilw |
Resolution: | Fixed | Votes: | 0 |
Labels: | None | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Issue Links: |
| ||||||||
Tags: | format, i18n | ||||||||
Epic Link: | View | ||||||||
Sprint: | Q1/15 |
Description |
See uom-se does not show a similar problem when running the same unit test or demo code. |
[UNITSOFMEASUREMENT-104] UCUM prefix unit misspelled TRIILLIONS Created: 11/Jan/15 Updated: 18/Jan/15 Resolved: 12/Jan/15 | |
Status: | Resolved |
Project: | unitsofmeasurement |
Component/s: | RI |
Affects Version/s: | 0.7.1 |
Fix Version/s: | 0.8 |
Type: | Bug | Priority: | Major |
Reporter: | keilw | Assignee: | keilw |
Resolution: | Fixed | Votes: | 0 |
Labels: | None | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Tags: | typo |
Epic Link: | View |
Sprint: | Q1/15 |
Description |
The UCUM system class contains a typo, |
[UNITSOFMEASUREMENT-103] Look into Unicode CLDR Created: 24/Dec/14 Updated: 10/Aug/15 Resolved: 10/Aug/15 | |
Status: | Resolved |
Project: | unitsofmeasurement |
Component/s: | RI |
Affects Version/s: | 0.7 |
Fix Version/s: | None |
Type: | Task | Priority: | Minor |
Reporter: | keilw | Assignee: | keilw |
Resolution: | Won't Fix | Votes: | 0 |
Labels: | None | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Issue Links: |
| ||||||||||||||||||||||||||||||||||||||||
Epic Link: | View | ||||||||||||||||||||||||||||||||||||||||
Sprint: | Q1/15, Public Draft |
Description |
OpenJDK declared at least 2 JEPs related to CLDR: The whole CLDR is likely too big at least for the RI, but where selective access and usage of CLDR data was possible, it is clearly worth exploring. |
Comments |
Comment by keilw [ 19/Jan/15 ] |
Using the CLDR might improve some of that although getSymbol() is supposed to be locale-neutral while toString() isn't necessarily. |
Comment by keilw [ 08/Feb/15 ] |
Will try to use some of CLDR especially where locale-neutral |
Comment by keilw [ 25/Mar/15 ] |
Where units provided by CLDR are to be supported this may change the number of quanties (or unit "type" as CLDR/ICU calls them) |
Comment by keilw [ 10/Aug/15 ] |
Descoping this from RI (where the locale-neutral SimpleUnitFormat and similar classes should be the default) |
[UNITSOFMEASUREMENT-102] Wrong conversion factor of RI UnitConverter Created: 23/Dec/14 Updated: 24/Dec/14 Resolved: 24/Dec/14 | |
Status: | Resolved |
Project: | unitsofmeasurement |
Component/s: | RI |
Affects Version/s: | 0.7 |
Fix Version/s: | 0.7.1 |
Type: | Bug | Priority: | Blocker |
Reporter: | keilw | Assignee: | keilw |
Resolution: | Fixed | Votes: | 0 |
Labels: | unplanned | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Tags: | conversion, converter |
Epic Link: | Portability |
Sprint: | Q1/15 |
Description |
As a side-effect when running a real life example derived from the Spec
for the performance discussion I stumbled over a much more severe problem.
A bug in the RI (the SE port though both are derived from the same
codebase seems unaffected) causing UnitConverter to
misbehave. Unit<Length> sourceUnit = METRE; Unit<Length> targetUnit = CENTI(METRE); UnitConverter converter = sourceUnit.getConverterTo(targetUnit); the RI returns a RationalConverter with a 1/8 ratio, thus 4 m would become just 32 cm!!! The Quantity.to() conversion acts the same way, so the problem has a common cause and it does not matter, if you use Quantity or not, the result stays the same. The SE port "uom-se" does it correctly. Anybody who has a chance to look into that over the holidays, please do, it's the biggest issue at the moment. |
Comments |
Comment by keilw [ 23/Dec/14 ] |
Starting to analyze the problem. The necessary downsizing of RationalConverter from BigInteger to long seems a main part of the problem. |
Comment by keilw [ 23/Dec/14 ] |
OK, now I was able to narrow it down before UnitConverter as such was constructed in above example. Unit<Length> targetUnit = CENTI(METRE); creates a TransformedUnit with converter=RationalConverter(100,1) for SE, while the same for the RI says converter=RationalConverter(1,8). |
Comment by keilw [ 23/Dec/14 ] |
When downsizing the SIPrefix I converted the RationalConverter with
BigInteger.TEN.pow(something) to a simple primitive arithmetic,
but unfortunately Java isn't a functional language, so "10^3", etc. works
perfectly fine, compiles and everything About to fix it in the RI. We'll simply release a new version of the RI. If PMO can attach a new RI like "0.7.1" it'll also be addressed there before they put it online after Christmas. It is not an issue of the Spec or API. |
Comment by keilw [ 24/Dec/14 ] |
It's a little more complicated. |
[UNITSOFMEASUREMENT-101] Create TCK Created: 20/Dec/14 Updated: 02/Jul/16 Resolved: 02/Jul/16 | |
Status: | Resolved |
Project: | unitsofmeasurement |
Component/s: | TCK |
Affects Version/s: | 0.7 |
Fix Version/s: | None |
Type: | Task | Priority: | Major |
Reporter: | keilw | Assignee: | keilw |
Resolution: | Fixed | Votes: | 0 |
Labels: | None | ||
Σ Remaining Estimate: | Not Specified | Remaining Estimate: | Not Specified |
Σ Time Spent: | Not Specified | Time Spent: | Not Specified |
Σ Original Estimate: | Not Specified | Original Estimate: | Not Specified |
Issue Links: |
| |||||||||||||||||||||||||||||||||||||||||||||
Sub-Tasks: |
| |||||||||||||||||||||||||||||||||||||||||||||
Tags: | tck-red, test, testing | |||||||||||||||||||||||||||||||||||||||||||||
Epic Link: | Test | |||||||||||||||||||||||||||||||||||||||||||||
Sprint: | Q1/15, Final Draft |
Description |
Following Early Draft, for any subsequent stage we shall start a
TCK. There should be sub-tasks, others are extremely welcome to help. |
[UNITSOFMEASUREMENT-100] Define our criterion for inclusion / exclusion of quantity types Created: 19/Dec/14 Updated: 02/Feb/16 Resolved: 20/Sep/15 | |
Status: | Resolved |
Project: | unitsofmeasurement |
Component/s: | Spec |
Affects Version/s: | None |
Fix Version/s: | None |
Type: | Task | Priority: | Critical |
Reporter: | desruisseaux | Assignee: | keilw |
Resolution: | Fixed | Votes: | 0 |
Labels: | None | ||
Σ Remaining Estimate: | Not Specified | Remaining Estimate: | Not Specified |
Σ Time Spent: | Not Specified | Time Spent: | Not Specified |
Σ Original Estimate: | Not Specified | Original Estimate: | Not Specified |
Attachments: | ![]() ![]() ![]() ![]() | ||||||||||||||||||||||||||||||||||||||||||||
Issue Links: |
| ||||||||||||||||||||||||||||||||||||||||||||
Sub-Tasks: |
| ||||||||||||||||||||||||||||||||||||||||||||
Tags: | design, document, question, spec, vote | ||||||||||||||||||||||||||||||||||||||||||||
Epic Link: | Documents | ||||||||||||||||||||||||||||||||||||||||||||
Sprint: | Q1/15, Public Draft |
Description |
Comments |
Comment by keilw [ 19/Dec/14 ] |
There are 2 chapters, "Supported Units" refers to BIPM and others, but I guess we should probably merge these two chapters in the Spec and add further documentation into a "package-info" of the "quantity" bundle. |
Comment by desruisseaux [ 22/Dec/14 ] |
Actually this task is also for checking if the current quantity types comply with the chosen definition. I though that the JSR-275 specification was compliant with BIPM, and we see that there is a mismatch between the specification and JSR-363. I think we should add a column in the table that document the provenance of each quantity type. Ideally, that provenance should be in the javadoc too. |
Comment by keilw [ 22/Dec/14 ] |
This part is based on the JSR-275 contributions to the spec. There is nothing that changed with 363 except a few names like Speed vs. Velocity or Radioactivity. If a mismatch existed, it was always there. |
Comment by desruisseaux [ 22/Dec/14 ] |
This is not what I mean. A lot of new types have been added compared to JSR-275, and I don't know on which criterion those new types were added (e.g. from which standards they come from). |
Comment by keilw [ 22/Dec/14 ] |
Well they are practically identical to: http://www.unitsofmeasurement.org/apidocs/index.html So many that were not in 275 have been part of the 0.6 API that's out
and used. E.g. that's where Action came from. We can't wait for the 26th
'General Conference on Weights and Measures' in 2018 since at least Java 9
(or even 10 If the actual submission in 2018 brings critical changes, we may take it into consideration with either a MR or V 1.x/2.x of the Spec by then. |
Comment by desruisseaux [ 22/Dec/14 ] |
The above link is interesting, but it is about improving the definition of the current 7 base units - it does not introduce any new quantity. Maybe the link that you wanted to paste was an other one? |
Comment by keilw [ 22/Dec/14 ] |
No it was correct, as some of the contents like Action are related to
http://en.wikipedia.org/wiki/Proposed_redefinition_of_SI_base_units#Physical_constants_used_in_the_new_definitions_and_other_physical_constants Aside from that a significant number of quantities that do not directly refer to a constant like those mentioned were added to represent all types in the UCUM system. There Bit, Byte, etc. exist, while e.g. the US system in the RI seems to exceed some of the typical "US Customary" units, e.g. OCTET (a unit of Information) does not seem to show up in "traditional" US Customary, but UCUM contains it all: http://unitsofmeasure.org/ucum.html#section-Tables-of-Terminal-Symbols There you'll also find the source for the Action quantity and
almost every other (e.g. Information as short form for "Amount of
Information") |
Comment by desruisseaux [ 23/Dec/14 ] |
In my understanding the "Physical constants used in the new definitions" link does not add new quantities. It explains the relationship between physical constants and the new definitions of the 7 base units. So is there somewhere a link about new quantities that would be added by the International Committee for Weights and Measures (CIPM)? I still don't see any. UCUM can help us, but I don't think that it can be cited as an authoritative source. Recognized standard organizations are CIPM and the like, not UCUM (even if widely used). Governments for example, in my understanding, would not officially accept UCUM as a source of standards (even if some departments may adopt is unofficially). They tend to accept only international standards of recognized bodies like ISO. |
Comment by keilw [ 20/Feb/15 ] |
If the sources for unit systems was pluggable, that could mean additional quantities. If type-safety is required, this means additional modules defining such quantities will be needed by certain "unit sources", as the most common denominator, javax.measure.quantity should contain e.g. the key units in the SI system. |
Comment by keilw [ 04/Apr/15 ] |
CLDR/oBIX/JSR363 (UCUM-inspired) comparison |
Comment by keilw [ 04/Apr/15 ] |
PDF export of the comparison sheet |
Comment by keilw [ 04/Apr/15 ] |
If we use the CLDR definitions and (where CLDR was missing any of them) units listed here: http://www.npl.co.uk/reference/measurement-units/ we might reduce the number of quantity types in the API. Leaving others to implementations (like uom-se) or library modules. WDYT? |
Comment by keilw [ 07/Apr/15 ] |
Here's a selection by NIST structured into nice 4 table groups:
http://physics.nist.gov/cuu/Units/units.html |
Comment by keilw [ 15/Apr/15 ] |
Table of types used by the GeoAPI V3 standard: http://www.opengeospatial.org/standards/geoapi Except for AngularSpeed they all match the scope mentioned here, but to provide backward-compatibility with JSR-275 and existing GeoAPI standards, we should support these in the "quantity" package of the API rather than forcing additional dependencies. |
Comment by keilw [ 16/Apr/15 ] |
One more data source and unit catalog came to my attention. Especially Geo and Climate projects refer to UDUNITS as alternative to UCUM. Essentially it is a close counterpart to UCAR Units written in C. What makes it interesting are several XML files, similar to oBIX or UCUM, see https://github.com/Unidata/UDUNITS-2/tree/master/lib As UCAR lacks typesafe generic quantities the quantity is not mentioned but https://github.com/Unidata/UDUNITS-2/blob/master/lib/udunits2-derived.xml in addition to https://github.com/Unidata/UDUNITS-2/blob/master/lib/udunits2-base.xml may help gather the desired quantities for JSR 363. |
Comment by leomrlima [ 20/Apr/15 ] |
Hi. I can't open the NIST pages; don't know what's the problem. I think the issue is more of scope than of size. As Jean-Marie said before, if there's a NIST standard, let's stick to it. |
Comment by keilw [ 20/Apr/15 ] |
Maybe it's some proxy or firewall issue...? There are one or two we should try to include for GeoAPI compatibility, as mentioned, otherwise I'd say we have a consensus on all 7 base quantities from table 1. All "named units/quantities" from table 3. About table 2, allow me to list only the more questionable or seemingly "exotic" ones, and please +1 for each that you think the core API should contain (mainly the Quantity) Quantity; Unit; Symbol wave number; reciprocal meter; m-1 mass density; kilogram per cubic meter; kg/m3 specific volume; cubic meter per kilogram; m3/kg current density; ampere per square meter; A/m2 magnetic field strength; ampere per meter; A/m amount-of-substance concentration; mole per cubic meter; mol/m3 luminance; candela per square meter; cd/m2 mass fraction; kilogram per kilogram, which may be represented by the number 1; kg/kg = 1 Thanks, |
Comment by keilw [ 15/May/15 ] |
3 Tables of NIST Units compared to quantity types in API |
Comment by keilw [ 20/May/15 ] |
Updated NIST Units compared with API |
Comment by keilw [ 16/Jun/15 ] |
While quantities to be pruned and removed from the API get a @Deprecated JavaDoc tag pointing to this ticket, I started using some new JavaDoc tags from Java 8 (see http://www.javacodegeeks.com/2015/01/new-javadoc-tags-apinote-implspec-and-implnote.html) for the others, mainly
Except for Dimensionless which is a special case (not a real base unit though essential) all quantity types should carry this meta-information. It is not rendered unless you run JavaDoc for SE 8 and above, but it does not hurt Java 7 or ME 8 since those are just JavaDoc annotations. |
[UNITSOFMEASUREMENT-99] Rename javax.measure.spi.*Service as *Provider Created: 19/Dec/14 Updated: 23/Jul/15 Resolved: 23/Jul/15 | |
Status: | Resolved |
Project: | unitsofmeasurement |
Component/s: | API |
Affects Version/s: | None |
Fix Version/s: | None |
Type: | Task | Priority: | Minor |
Reporter: | desruisseaux | Assignee: | Unassigned |
Resolution: | Won't Fix | Votes: | 0 |
Labels: | None | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Issue Links: |
|
Description |
Comments |
Comment by keilw [ 19/Dec/14 ] |
While odd I don't think OSGi (which so far is the more common usage for
this API and its precursors) would die if we had to implement a
UnitFormatProvider either as UnitFormatProviderImpl or
(that might even be an appealing side-effect One caveat is, that Java ME 8 puts a very strong emphasis on
"service-enabled", see http://www.oracle.com/technetwork/java/embedded/overview/javame/java-embedded-system-requirements-359229.html |
Comment by keilw [ 23/Jul/15 ] |
See https://java.net/jira/browse/UNITSOFMEASUREMENT-128 As we introduced a ServiceProvider what it provides should be called *Service in most cases. |
[UNITSOFMEASUREMENT-98] Consider providing the "Units" class in the API Created: 19/Dec/14 Updated: 23/Feb/16 Resolved: 23/Feb/16 | |
Status: | Resolved |
Project: | unitsofmeasurement |
Component/s: | API, RI |
Affects Version/s: | None |
Fix Version/s: | None |
Type: | Task | Priority: | Trivial |
Reporter: | desruisseaux | Assignee: | keilw |
Resolution: | Won't Fix | Votes: | 0 |
Labels: | None | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Issue Links: |
|
Description |
The Units class is currently provided in the reference implementation. It is technically possible to provide that class in the API part. However there is open questions:
|
Comments |
Comment by keilw [ 19/Dec/14 ] |
Java 8 and Oracle/JCP are clear on optionality, so along the lines of other JSRs like CDI we are most likely to define it in the spi package, see the CDI class defined by CDI 1.1 and above (or if we don't mind extra complexity it could be its own package like system) The dependency currently only spi depends on format aside from the core "root" package, would have to be further explained, at least the quantity package is a mandatory requirement for such SI class and until some "Stripped Implementation" guideline and approach is permitted, the class must contain all methods/constants/SI types we chose to expose. |
Comment by keilw [ 19/Jan/15 ] |
As "Stripped Implementations" are off the table, a package like
spi for a possible SI class on API level sounds best,
that's where underlying interfaces are also declared. There is a
dependency on format already, hence, if SI or similar
systems could be added to the API it would also require the
optional{{quantity}} module as dependency. |
Comment by keilw [ 29/May/15 ] |
As we tend to reduce the number of quantities to a reasonable number (not every single one in scope for SI, but the most commonly used ones) there won't be a SI class in the RI any more soon. However, the planned replacement (a class called Units) and ideally also a similar factory Quantities could be explored to make them available in the API. (similar to JSR-354) |
Comment by leomrlima [ 23/Feb/16 ] |
I don't think this is necessary, and adds more complexity than value in my opinion! |
Comment by keilw [ 23/Feb/16 ] |
Thanks for the input. I agree, and since we have a SystemOfUnitsService offered by Bootstrap (or a different name should we prefer) one can query all available unit systems, not just SI (which we only cover to some extent in the API/RI) but also UCUM, ISO80k or others. |
Non-functional
Requirements (mostly for RI) (UNITSOFMEASUREMENT-185)
| |
Status: | Resolved |
Project: | unitsofmeasurement |
Component/s: | Documentation |
Affects Version/s: | None |
Fix Version/s: | None |
Type: | Sub-task | Priority: | Minor |
Reporter: |