[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)

[UNITSOFMEASUREMENT-193] What about Dimension.getProductDimensions() ? Created: 21/Jun/16  Updated: 28/Jun/16  Resolved: 28/Jun/16

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:
Relates
relates to UNITSOFMEASUREMENT-183 getProductUnits should probably be re... Resolved
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
Referring to "Fundamental Dimensions" or also "Fundamental Units" (another synonym for "Base Units")

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)

[UNITSOFMEASUREMENT-191] Could QuantityFactoryService be merged into ServiceProvider, too? Created: 03/Apr/16  Updated: 08/Jun/16  Resolved: 08/Jun/16

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)

[UNITSOFMEASUREMENT-190] Create PoC for a refactored ServiceProvider Created: 30/Mar/16  Updated: 01/Apr/16  Resolved: 01/Apr/16

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.
To follow other JSRs like JSON-P in their SPI or some new libraries coming with Java 8 (like Streams) is it OK to call the 2 main static accessor methods of ServiceProvider default() and available()? For setDefault() I think this is OK, other options like init() or configure() (as used by either JSR 354 of CDI in similar SPI elements) probably mean a bit less, but keeping the 2 static methods shorter with only the actual "bean" methods of the instance itself called get...Service() feels a bit cleaner and more "fluent".
I would do the same with the DimensionalModel class in the RI level SPI which has a current() method, too, so these SPI classes provide a similar user experience.

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)

[UNITSOFMEASUREMENT-189] Should "Bootstrap" be final or abstract? Created: 22/Mar/16  Updated: 01/Apr/16  Resolved: 01/Apr/16

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:
Relates
relates to UNITSOFMEASUREMENT-152 Refactoring SPI Resolved
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.
If we require each module to define at least one ServiceProvider, then in most cases the implementation level ServiceProvider should be taken as super-class, not ServiceProvider itself. This way modules are free to decide what to extend/customize and what to leave up to the implementation, e.g. QuantityFactory or UnitFormat instances if they have no need to declare their own. Unlike the current tec.units.ri.internal.RIServiceProvider it should therefore simply move to tec.units.ri.spi allowing extension by modules. It was "internal" since only Bootstrap/ServiceLoader had to know about it, otherwise it would be opaque and an internal implementation detail. If we offer it to other modules, that has to change.

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)

[UNITSOFMEASUREMENT-186] Change ServiceProvider.available() to Collection Created: 19/Mar/16  Updated: 15/Jun/16  Resolved: 15/Jun/16

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:
Relates
relates to UNITSOFMEASUREMENT-152 Refactoring SPI Resolved
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:
Key
 Summary
 Type
 Status
 Assignee
UNITSOFMEASUREMENT-97 Add a chapter about performance Sub-task Resolved  
UNITSOFMEASUREMENT-184 Loss of precision by using double ins... Sub-task Resolved keilw  
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)

[UNITSOFMEASUREMENT-184] Loss of precision by using double instead of BigDecimal Created: 17/Mar/16  Updated: 04/Oct/16  Resolved: 04/Oct/16

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:
Relates
relates to UNITSOFMEASUREMENT-97 Add a chapter about performance Resolved
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.
The unit-ri classes are based on double primitives, which are still sensible of slight imprecision because of the way they are stored (see link below)

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:
1. add a convert(BigDecimal xy) in the UnitConverter interface
2. remove the method convert(Number xy) as it's hiding a conversion using double (which is already present).

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.
Now, as in the past months, the only limitation we had is to switch to Java 8.

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)

[UNITSOFMEASUREMENT-183] getProductUnits should probably be renamed Created: 02/Mar/16  Updated: 30/Jun/16  Resolved: 30/Jun/16

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:
Duplicate
duplicates UNITSOFMEASUREMENT-88 SystemOfUnits need to tell its base u... Resolved
Relates
relates to UNITSOFMEASUREMENT-193 What about Dimension.getProductDimens... Resolved
relates to UNITSOFMEASUREMENT-182 [Clarification] best way to convert P... Resolved
Tags: naming
Sprint: Final Draft

 Description   

Based on PR that as such was closed, but documented:
https://github.com/unitsofmeasurement/unit-ri/pull/33

It occured, that Unit method getProductUnits() could be misleading.
>I look at the issue 33 and indeed I believe that the name getProductUnit is >misleading, it should be getBaseUnits or getBaseUnitDecomposition since it >returns the canonical decomposition of the unit (mapping base unit -> >exponent). Indeed, such mapping exist for base units (single unit mapped >to 1) and should not return null

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".
JavaDoc states "Returns the base units and their exponent..." the Returns tag also says "the base units and their exponent making up this unit." so while "making up this unit" could somewhat justify the extra "Decomposition" bit, I would prefer getBaseUnits especially because it's plural and suggests a Map/collection is returned while getBaseUnitDecomposition sounds more like other single object getters such as getDimension etc.
So it feels cleaner from a naming point of view, but if everybody who has an opinion was to prefer it, I could live with both.

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:
Relates
relates to UNITSOFMEASUREMENT-183 getProductUnits should probably be re... Resolved
Sub-Tasks:
Key
 Summary
 Type
 Status
 Assignee
UNITSOFMEASUREMENT-183 getProductUnits should probably be re... Sub-task Resolved keilw  
UNITSOFMEASUREMENT-193 What about Dimension.getProductDimens... Sub-task Resolved keilw  
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:
Relates
relates to UNITSOFMEASUREMENT-100 Define our criterion for inclusion / ... Resolved
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.

  • MagneticFieldStrength
  • Luminance
    but not several others.

Are these 2 critical to the most basic fields of use, or could we stick to just the "top 4"

  • Area
  • Volume
  • Speed
  • Acceleration




[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:
Relates
relates to UNITSOFMEASUREMENT-175 AbstractQuantity.compareTo should als... Resolved
relates to UNITSOFMEASUREMENT-167 Add Comparable to AbstractUnit Resolved
Tags: design, question, sort, vote
Epic Link: Design
Sprint: Final Release

 Description   

At the moment AbstractQuantity implements Comparable.
https://github.com/unitsofmeasurement/unit-ri/blob/master/src/test/java/tec/units/ri/function/QuantitySortTest.java shows, at least for the RI sorting a list of quantities may therefore require them to be expressed as AbstractQuantity. Similar to JSR 354 (MonetaryAmount) we could also have Quantity extend 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)

[UNITSOFMEASUREMENT-176] Consider dropping SPI profile from TCK Created: 28/Dec/15  Updated: 03/Apr/16  Resolved: 03/Apr/16

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:
Blocks
blocks UNITSOFMEASUREMENT-101 Create TCK Resolved
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:
Relates
relates to UNITSOFMEASUREMENT-167 Add Comparable to AbstractUnit Resolved
relates to UNITSOFMEASUREMENT-177 Should Quantity extend Comparable? Resolved
Tags: conversion
Sprint: Final Draft

 Description   

AbstractQuantity.compareTo() takes the value into consideration, but ignores unit of other Quantity.
Instead of 

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)

[UNITSOFMEASUREMENT-174] Consider using Reflections.org for TCK Created: 21/Dec/15  Updated: 30/Mar/16  Resolved: 08/Feb/16

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:
Dependency
blocks UNITSOFMEASUREMENT-101 Create TCK Resolved
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)

[UNITSOFMEASUREMENT-173] Verify minimum Java version for TCK Created: 11/Dec/15  Updated: 30/Mar/16  Resolved: 22/Dec/15

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:
Blocks
blocks UNITSOFMEASUREMENT-101 Create TCK Resolved
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:
Relates
relates to UNITSOFMEASUREMENT-161 Do we also want UnitFormat.alias()? Resolved
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:
http://unitsofmeasurement.github.io/unit-api/site/apidocs/javax/measure/format/UnitFormat.html#parse(java.lang.CharSequence)

> If there is no unit to parse the unitary unit (dimensionless) is returned
and
>@throws ParserException if any problem occurs while parsing the specified character sequence (e.g. illegal syntax).
sound slightly contradictory, i.E. returning null is not explicitely outruled, although it's recommended, another constant like ONE would be returned instead.

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:
Relates
relates to UNITSOFMEASUREMENT-4 Getting rid of Serializable Resolved

 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)

[UNITSOFMEASUREMENT-169] Consider additional profile(s) for TCK Created: 24/Nov/15  Updated: 30/Mar/16  Resolved: 28/Dec/15

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:
Dependency
blocks UNITSOFMEASUREMENT-101 Create TCK Resolved
Related
is related to UNITSOFMEASUREMENT-129 JDK6 compatibility for unit-ri Resolved
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:
Relates
relates to UNITSOFMEASUREMENT-177 Should Quantity extend Comparable? Resolved
relates to UNITSOFMEASUREMENT-175 AbstractQuantity.compareTo should als... Resolved
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:
Duplicate
is duplicated by UNITSOFMEASUREMENT-143 Multiples of HERTZ wrongly formatted Resolved
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)

[UNITSOFMEASUREMENT-164] Change License headers in API Created: 24/Sep/15  Updated: 10/Oct/15  Resolved: 10/Oct/15

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:
Blocks
is blocked by UNITSOFMEASUREMENT-163 Change LICENSE.txt in API Repo Resolved
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)

[UNITSOFMEASUREMENT-163] Change LICENSE.txt in API Repo Created: 23/Sep/15  Updated: 08/Oct/15  Due: 23/Oct/15  Resolved: 08/Oct/15

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:
Blocks
blocks UNITSOFMEASUREMENT-164 Change License headers in API Resolved
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)

[UNITSOFMEASUREMENT-162] Put full Spec License into Specification Document Created: 23/Sep/15  Updated: 23/Sep/15  Resolved: 23/Sep/15

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:
Dependency
depends on UNITSOFMEASUREMENT-78 Can we improve Formatting by adding s... Resolved
Relates
relates to UNITSOFMEASUREMENT-124 Introduce a Unit "DB" Resolved
relates to UNITSOFMEASUREMENT-172 Units.KILOMETRES_PER_HOUR should be r... Resolved
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).
While label() addresses formatting and output, the alias() method as above examples show, also can be used for culture- or locale-specific, semantic interpretation, e.g. plural. However, simply knowing METRE.multiply(0.3048) can be both foot and feet does not answer the question of pluralization. That's also in a more extensive, but Locale sensitive way addressed by CLDR data. So while label() is a useful hint to most UnitFormat implementations, it is not entirely clear, if adding alias() without locale or similar semantic meta-information would be beneficial.



 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)

[UNITSOFMEASUREMENT-160] Configure Profiles for TCK Created: 03/Sep/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: 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.
Given the current optionality, the following profiles or groups look reasonable

  • Core
  • Format
  • Quantity
  • SPI (requires at least Format, too)

CDI deals with this via TestNG groups:
http://docs.jboss.org/cdi/tck/reference/latest/en-US/html/configuration.html#tck-properties

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
http://stackoverflow.com/questions/7150302/excluding-testng-groups-from-maven
http://stackoverflow.com/questions/4578971/appending-jvm-parameter-to-the-parameter-specified-explicitly-in-plugin-configur



 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)

[UNITSOFMEASUREMENT-159] Move test-audit.xml to main/resources Created: 31/Aug/15  Updated: 31/Aug/15  Resolved: 31/Aug/15

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:
Related
is related to UNITSOFMEASUREMENT-118 Add Tests according to Spec Chapter 4 Resolved
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)

[UNITSOFMEASUREMENT-158] Add Tests according to Spec Chapter 5 Created: 31/Aug/15  Updated: 02/Jul/16  Resolved: 02/Jul/16

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:
Relates
relates to UNITSOFMEASUREMENT-132 Could we rename SIPrefix to MetricPre... Resolved
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:
Key
 Summary
 Type
 Status
 Assignee
UNITSOFMEASUREMENT-162 Put full Spec License into Specificat... Sub-task Resolved keilw  
UNITSOFMEASUREMENT-163 Change LICENSE.txt in API Repo Sub-task Resolved keilw  
UNITSOFMEASUREMENT-164 Change License headers in API Sub-task Resolved keilw  
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
This Bugzilla ticket lines out the problem for a downstream Eclipse project (SmartHome) wanting to use JSR 363:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=434006

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
And UoM-SE https://dev.eclipse.org/ipzilla/show_bug.cgi?id=12610
were both approved by Eclipse IP team.




[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:
Relates
relates to UNITSOFMEASUREMENT-97 Add a chapter about performance Resolved
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

  • Asciidoc (lik 354)
  • Google Docs (like the Spec or also used by other JSRs e.g. 107)
  • Something else (GitBook was mentioned, haven't used it so far)

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:
Related
is related to UNITSOFMEASUREMENT-78 Can we improve Formatting by adding s... Resolved
is related to UNITSOFMEASUREMENT-149 Create UnitFormat.format() method wit... Resolved
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)
It is a bit strange in JSR 107 having an enum just for "STORE_BY_REFERENCE" but it seems, the idea is, other optional features may be added there and its only SPI element CachingProvider (
https://ignite.incubator.apache.org/jcache/1.0.0/javadoc/javax/cache/spi/CachingProvider.html) allows to check, whether it is supported or not. We could do something similar with an enum like FormatBehavior or as a smaller alternative simply offer a flag like isLocaleSensitive() or similar.
Two examples (both IBM products now ) show this, a Tivoli Workflow (http://www-01.ibm.com/support/knowledgecenter/SS2GNX_7.2.1/com.ibm.tivoli.tpm.soapjdoc.doc/com/ibm/tivoli/orchestrator/de/soap/Workflow.html)
or
iLog JViews IlvGraphic (http://docs.roguewave.com/jviews/8.9/jviews-framework89/doc/html/en-US/refjava/html/ilog/views/IlvGraphic.html)

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:
https://github.com/unitsofmeasurement/uom-se/blob/master/src/main/java/tec/uom/se/format/LocalUnitFormat.java

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:
Blocks
blocks UNITSOFMEASUREMENT-101 Create TCK Resolved
Sub-Tasks:
Key
 Summary
 Type
 Status
 Assignee
UNITSOFMEASUREMENT-160 Configure Profiles for TCK Sub-task Resolved keilw  
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:
Blocks
is blocked by UNITSOFMEASUREMENT-145 Move Bootstrap mechanism into API Resolved
Related
is related to UNITSOFMEASUREMENT-121 Introduce "Pluggable" Unit Systems an... Resolved
Relates
relates to UNITSOFMEASUREMENT-189 Should "Bootstrap" be final or abstract? Resolved
relates to UNITSOFMEASUREMENT-186 Change ServiceProvider.available() to... Resolved
Sub-Tasks:
Key
 Summary
 Type
 Status
 Assignee
UNITSOFMEASUREMENT-186 Change ServiceProvider.available() to... Sub-task Resolved keilw  
UNITSOFMEASUREMENT-189 Should "Bootstrap" be final or abstract? Sub-task Resolved keilw  
UNITSOFMEASUREMENT-190 Create PoC for a refactored ServicePr... Sub-task Resolved desruisseaux  
UNITSOFMEASUREMENT-191 Could QuantityFactoryService be merge... Sub-task Resolved keilw  
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)
They all have such API level central accessor classes. Named Caching, Validation or CDI. The latter in its "spi" package, simlar to our place for such a class. (since we cannot mandate it for devices without ServiceLoader or Liblet support)

Please suggest names, I don't want to propose too much in this case.
The only alternative to Bootstrap I could think of was a CDI inspired acronym like UOM (or UoM. Simply calling it Measure or Measuring (along the lines of JSR 107) were other options, but especially Measure would cause confusion with a similar class from JSR 275, so it is not my favorite

Thanks,
Werner



 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.
See https://github.com/unitsofmeasurement/uom-demos/blob/master/console/se/src/main/java/tec/uom/demo/se/FactoryDemo.java

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:

  1. Make ServiceProvider an abstract class instead than an interface (this is not a problem for java.util.ServiceLoader).
  2. Move the Bootstrap methods as static methods in ServiceProvider.
  3. Remove the Bootstrap class.

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
Aside from the Spec document and other examples, Bootstrap is referred to by many places like tests.

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:

  • <T> List<T> getServices(Class<T> serviceType);

My comment was: if ServiceProvider is expected to be provided by Unit implementations, then:

  • I don't see why ServiceProvider.getServices(Class) should return a list. Why a given implementation would want to expose many implementations of SystemOfUnitsService or QuantityFactoryService?
  • The fact that more than one implementation may exist on the classpath would have to be handled in Bootstrap.
Comment by keilw [ 20/Mar/16 ]

The inspiration of Bootstrap (and its name) was based on JSR354:
https://github.com/JavaMoney/jsr354-api-bp/blob/master/src/main/java/javax/money/spi/Bootstrap.java

You'll notice a somewhat strange behavior, that it sorts only by <b>name</b> of services there which is something we removed earlier.
It did not use the priority there either.

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.
The SystemOfUnitsService test in ISO80000 https://github.com/unitsofmeasurement/uom-systems/blob/master/iso80k/src/test/java/systems/uom/iso80k/internal/SystemOfUnitsServiceTest.java shows this rather well.

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 ) JSRs that went final in the last few years do not put everything in one abstract "uberclass". While APIs defined much earlier like ICU4J or the now pretty defunct JSR 256 (Sensor API) did. They both combine Unit with static factory methods for getting or even defining new units (both of them have no strict quantity type checking at compile time) which we got SystemOfUnits for.

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?

  1. Each Unit API implementation provides its own ServiceProvider. For example there is one ServiceProvider provided by RI and another ServiceProvider provided by UOM-SE.
  2. If we have many Unit API implementations on the classpath, then we have many ServiceProvider instances: one for each implementation.
  3. If I want RI services, I use the ServiceProvider provided by RI implementation. If I want UOM-SE services, I use the ServiceProvider implementation provided by UOM-SE implementation.
  4. The ServiceProvider provided by RI implementation does not know about UOM-SE services. Conversely the ServiceProvider provided by UOM-SE implementation does not know about RI services.

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.
So if an implementation offers one ServiceProvider using ServiceLoader and another one e.g. via OSGi or another service concept, it can give the highest priority to the one it wishes to use. If there were multiple implementations, an implementation compatible with others could also give a higher priority to its default/only ServiceProvider so it gets picked by Bootstrap without having to override it.

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.

  • We agree about allowing different providers, based on java.util.ServiceLoader, OSGi or whatever.
  • I suggest to defer the question about Bootstrap name until after we clarified what is ServiceProvider contract.
  • The 4 questions by @desruisseaux were those posted on March 22th (if I'm not misunderstanding @leomrlima intend):
    • Do we agree that each Unit API implementation provides its own ServiceProvider?
    • Do we agree that if we have many Unit API implementations on the classpath, then we have many ServiceProvider instances?
    • Do we agree that if I want RI services I use the ServiceProvider provided by RI implementation, and if I want UOM-SE services I use the ServiceProvider implementation provided by UOM-SE implementation?
    • Do we agree that the ServiceProvider provided by RI implementation does not know about UOM-SE services, and that conversely the ServiceProvider provided by UOM-SE implementation does not know about RI services?
  • The proposal is to simplify ServiceProvider rather than making it more complex by moving in CDI land.
  • I will try to do a working proposal in a branch during the next week.
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.
You actually do see multiple implementations of ServiceProvider in the same classpath, e.g. Eclipse discovers multiple implementations when you run apps or tests in a workspace that has both the RI and other implementations loaded. Under Java ME this will simply fail, any non-compliant code fails to execute in the emulator or device. Under Java SE one can have both the RI and other implementations in the same classpath, but mixing them e.g. trying to convert tec.units.ri.unit.BaseUnit to tec.uom.se.unit.BaseUnit will simply fail with a ClassCastException. Since we aim at Java ME 8 as well as SE 7 or 8 and above (e.g. for the whole Big Data space or other desktop and server solutions) multiple implementations are inevitable and highly encouraged. Look at JCache: https://jcp.org/aboutJava/communityprocess/implementations/jsr107/index.html. It has at least half a dozen implementations, but do you really think mixing Ehcache, Coherence and Hazelcast in the same classpath and single piece of application code will work???

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
There is two commits. The first one is only javadoc fixes (see commit message for details). The second commit:

  • Change ServiceProvider into an abstract class.
  • Remove all methods returning a List.
  • Replace the getService(Class<T> serviceType) method by three methods, one for each type of services. This is not the intend of this class to replace ServiceLoader or dependency injection frameworks.
  • Provide the following static methods getAvailables(), getDefault(), setDefault(ServiceProvider). Note that getAvailables() returns an array because it was convenient, but I'm neutral on whether it should return an array or an List. The important thing is that we can have an arbitrary amount of ServiceProvider, not an arbitrary amount of SystemOfUnitsService, UnitFormatService and QuantityFactoryService inside a given ServiceProvider.
  • Delete Bootstrap since its functionalities moved as ServiceProvider static methods.
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.
See the diagram in https://github.com/unitsofmeasurement/uom-systems, we have (for a good reason, each developer and user will need different combinations of standards and systems on top of an implementation) a chain of e.g. RI > SI > ISO80000, or any other system module like Common (US Customary, Imperial) or UCUM.
Therefore you need to handle more than one SystemOfUnitsService (3 in this case) while having just one ServiceProvider implementation is perfectly fine.

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.
In theory forcing yet another ServiceProvicer per module could work, but I would rather have a more flexible ServiceProvider offer more than one service instead of the overhead of having to declare an unneccessary amount of providers and modules.

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.
Implementing that approach in the RI works quite well: https://github.com/keilw/unit-ri
All JUnit tests pass.

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.
However, two crucial tests in https://github.com/keilw/si-units (fork of the SI extension module) fail.

	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:

  • ServiceProvider.getService(Class) duplicates java.util.ServiceLoader's work in a questionable way: no control on ClassLoader to use and lost deferred instantiation (all implementations of a given service are instantiated even if we do not need them).
  • ServiceProvider.getService(Class) returns an arbitrary implementation found on the class path. This is probably not what we want. A module providing an Unit implementation probably wants services of the same implementation.

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?
It's somewhat similar to the more "flat" provider structure of JSR 107 (see https://github.com/jsr107/RI/tree/master/cache-ri-impl) or JSON-P.
Guess it's doable, but will cause a bit of an overhead for extension modules, e.g. ServiceProvider enforcing 3 "get...Service" methods to be overriden by every module-specific provider, you must always return "something" even if the value might be null or an empty dummy object.

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.
We should not out-rule the possibility of such service, but if the method signature of ServiceProvider forces every module to return something even if they have no need for its own QuantityFactory we have to document that and it will cause redundant methods even if they just returned null.

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:
Blocks
is blocked by UNITSOFMEASUREMENT-145 Move Bootstrap mechanism into API Resolved
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:
Related
is related to UNITSOFMEASUREMENT-78 Can we improve Formatting by adding s... Resolved
is related to UNITSOFMEASUREMENT-154 How to tell, if UnitFormat is locale-... Resolved
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.
Instead of closing </code> it only says /code> resulting in weird/wrong display of the symbols affected.



 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.
It worked in prior implementations of JSR-275 or JScience 5.



 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:
Blocks
blocks UNITSOFMEASUREMENT-152 Refactoring SPI Resolved
blocks UNITSOFMEASUREMENT-98 Consider providing the "Units" class ... Resolved
blocks UNITSOFMEASUREMENT-151 Define QuantityFactoryService in API Resolved
Related
is related to UNITSOFMEASUREMENT-56 Could we move AbstractQuantity into A... Resolved
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.
The approach by Bean Validation with a single class javax.validation.Validation looks most appealing, but looking at CDI, its main accessor class is javax.enterprise.inject.spi.CDI so it's equally possible to locate it in the SPI package. Since this package is optional in JSR 363 it leaves users of mandatory elements and maybe quantity types free to use other service and module systems like OSGi.



 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()
but it should be something like

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:
Cloners
clones UNITSOFMEASUREMENT-140 Unit HERTZ wrongly formatted Resolved
Duplicate
duplicates UNITSOFMEASUREMENT-166 Multiples of units need to be explici... Open
Related
is related to UNITSOFMEASUREMENT-78 Can we improve Formatting by adding s... Resolved
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",...)
This is mathematically correct, but especially the AlternateUnit applied in this case shall prefer the given symbol.

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)

[UNITSOFMEASUREMENT-142] Document criterion for inclusion / exclusion of quantity types Created: 29/Jun/15  Updated: 20/Sep/15  Resolved: 20/Sep/15

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)

[UNITSOFMEASUREMENT-141] Apply criterion for inclusion / exclusion of quantity types Created: 29/Jun/15  Updated: 01/Jul/15  Resolved: 01/Jul/15

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:
Cloners
is cloned by UNITSOFMEASUREMENT-143 Multiples of HERTZ wrongly formatted Resolved
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",...)
This is mathematically correct, but especially the AlternateUnit applied in this case shall prefer the given symbol.

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:
Duplicate
duplicates UNITSOFMEASUREMENT-108 getSymbol() and toString() differ for... Closed
Related
is related to UNITSOFMEASUREMENT-78 Can we improve Formatting by adding s... Resolved
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)

[UNITSOFMEASUREMENT-138] Correct java.util.logging.Logger usages Created: 24/Jun/15  Updated: 30/Oct/15  Resolved: 30/Oct/15

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 :
https://www.gitbook.com/book/gitbookio/javascript/details
https://www.gitbook.com/book/gitbookio/documentation/details



 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)

[UNITSOFMEASUREMENT-135] Migrate from unitsofmeasurement.org Created: 11/Jun/15  Updated: 09/Nov/15  Resolved: 09/Nov/15

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.
https://github.com/unitsofmeasurement/unitsofmeasurement.github.io/tree/master/pages
resulting in
http://unitsofmeasurement.github.io/pages/about.html and similar pages.

JavaDocs should ideally be generated into a similar folder resulting in
http://unitsofmeasurement.github.io/apidocs (this does not exist now) as Maven build jobs related to JavaDoc now assume this to hold JavaDocs.

Similar for Maven site if we also want to generate it there.
It could be easier to try separate artifacts, so where under the old domain "jsr-363" is now generated, we could have a folder like
http://unitsofmeasurement.github.io/unit-api/apidocs (not existing) and others.



 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.
To deploy the site succesfully, one must add settings.xml with working GitHub credentials according to:
https://github.github.com/maven-plugins/site-plugin/authentication.html

Both worked for me locally. Either Martin should do the same for the GeoAPI Jenkins build allowing updates of the GitHub pages.
As an alternative, we could try building it on Circle-CI, similar to how all Snapshots are already published to Bintray (using a similar API Key/token)

Comment by keilw [ 21/Sep/15 ]

It seems, like a single build command mvn clean install deploy site site:deploy --show-version --batch-mode
as http://jenkins.geotoolkit.org/job/JSR-363/177/console suggests is too big. At least the new "site" replacement doesn't understand "deploy" at all, nor does it look relevant (AFAIK this pushes the artifacts to the snapshot repo) Ideally "install" and other steps like "site" or "deploy" should be chained, similar to e.g. Circle-CI does for the RI, see https://circleci.com/gh/unitsofmeasurement/unit-ri/17
Where necessary build steps or plugins that aren't compatible with each other should be separated into a different Maven profile.

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:
Related
is related to UNITSOFMEASUREMENT-126 Should we rename SI to Metric? Resolved
Relates
relates to UNITSOFMEASUREMENT-157 Shall we keep the name MetricPrefix? Resolved
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 @@
*/
package tec.units.ri;

-import java.lang.ref.Reference;
-import java.lang.ref.WeakReference;
import java.util.Map;

import javax.measure.Dimension;
@@ -81,7 +79,7 @@ public abstract class DimensionalModel {
/**

  • Holds the current model.
    */
  • private static Reference<DimensionalModel> Current = new WeakReference<DimensionalModel>(new StandardModel());
    + private static DimensionalModel CURRENT = new StandardModel();

/**

  • Returns the current dimensional model
    @@ -90,7 +88,7 @@ public abstract class DimensionalModel {
  • @return the current physical model.
    */
    public static DimensionalModel current() { - return DimensionalModel.Current.get(); + return DimensionalModel.CURRENT; }

// /**



 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 Number convert(Number value)

{ - return convert(Double.valueOf(value.doubleValue())); + return convert(value.doubleValue()); }

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: Text File java-se6.patch    
Issue Links:
Related
is related to UNITSOFMEASUREMENT-169 Consider additional profile(s) for TCK Resolved
Relates
relates to UNITSOFMEASUREMENT-125 Some API JUnit tests won't work under... Resolved
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.
I briefly tried to switch the JDK version to 6 and a main reason it does not work is the Objects class used in many places. Other J7 dependencies like "Diamond" seem to be gone pretty much all of them.

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.
As for Java 5, I don't know if we'd support that out of the box, given the API also uses ServiceLoader present from Java SE 6 on and also in CLDC8.

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
Everything except SystemOfUnits (we want to give people a choice to use other forms of organizing units in a "DB" or collection form) probably won't make too much sense without ServiceLoader, so you could leave the optional SPI package out and still be compliant with your own implementation

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.
Regarding ServiceProvider, if you don't need SystemOfUnits too badly (adding it to core would put a burden on those who e.g. want to declare a Unit as enum and don't need to implement it, that's why it's part of the SPI) you can stick to another profile like "base_quantity" or "quantity" plus "format" (we may not have the combination yet since they are independent, but that's probably something to add, at least for all of format+quantity, base_quantity requires to pick some quantities anyway, it's meant for very small devices as an option) and not use the "spi" package. Does that help? (you could simply fork or clone the SystemOfUnits interface in your own app if you need it, we'd rather not force everyone to use it if they only need Unit and Quantity or chose their own approach to grouping/storing units)

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.
The problem with Java 5, unlike 6-8, it's fully end of life, see: http://www.oracle.com/technetwork/java/eol-135779.html
Especially in the Embedded world taking at least "Extended Support" into consideration is more than fair. And Java 6 still falls into that till December 2018, 2 years after what we estimate to be our Final schedule (Q3 or Q4/16 sound reasonable, depending on how PR goes and what feedback we get) while this support for Java 5 has ended. If you want to suggest e.g. the Maven Toolchain, please feel free to do so (at least for API first), we have other proposals in the backlog, but some hints for tools or new formats (like Asciidoc, etc.) we cannot promise to cover all of them, e.g. if they only meet a very small niche.

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 )
As for 0.8 (PR) especially the RI was compiled with Java 7 compatibility, and it's possible I also did so for the API (which I have to sign on the local machine before deploying it to JCenter)
Have a look at https://oss.jfrog.org/oss-snapshot-local/tec/units/unit-ri/0.9-SNAPSHOT/ and https://oss.jfrog.org/artifactory/oss-snapshot-local/javax/measure/unit-api/0.9-SNAPSHOT/, they are all built against Java 6 only. Please try what you did before.

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.
If you can handle Java 5 the way you did (chosing the right profile, I'd say you may even be quite likely to pass the TCK for particular profiles other than SPI) that sounds good. If there is no clash with other environments, e.g. Java ME Embedded (there it currently works best to have API, RI and your solution all from the source, see https://github.com/unitsofmeasurement/uom-demos/tree/master/javame/medemo) we should be able to keep both API and RI binary compatible with Java SE 6.

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:
Blocks
blocks UNITSOFMEASUREMENT-99 Rename javax.measure.spi.*Service as ... Resolved
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 Implementing this unlike 354 might be up to RI or other implementations.



 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:
Blocks
blocks UNITSOFMEASUREMENT-121 Introduce "Pluggable" Unit Systems an... Resolved
Duplicate
is duplicated by UNITSOFMEASUREMENT-126 Should we rename SI to Metric? Resolved
Relates
relates to UNITSOFMEASUREMENT-100 Define our criterion for inclusion / ... Resolved
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
http://icu-project.org/apiref/icu4j/com/ibm/icu/util/MeasureUnit.html
We can't do that in Unit and it would be dirty, but a collecting class like Units sounds appropriate. Ideally merging the "unit" and "spi" package.



 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:
Duplicate
duplicates UNITSOFMEASUREMENT-127 Simplify unit systems in RI Resolved
Related
is related to UNITSOFMEASUREMENT-132 Could we rename SIPrefix to MetricPre... Resolved
Relates
relates to UNITSOFMEASUREMENT-103 Look into Unicode CLDR Resolved
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:
https://github.com/unicode-cldr/cldr-units-modern/blob/master/main/en/measurementSystemNames.json

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:
Relates
relates to UNITSOFMEASUREMENT-129 JDK6 compatibility for unit-ri Resolved
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:
Related
is related to UNITSOFMEASUREMENT-89 SystemOfUnits.getUnits() needs to def... Resolved
is related to UNITSOFMEASUREMENT-88 SystemOfUnits need to tell its base u... Resolved
Relates
relates to UNITSOFMEASUREMENT-78 Can we improve Formatting by adding s... Resolved
relates to UNITSOFMEASUREMENT-161 Do we also want UnitFormat.alias()? Resolved
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

  • UnitData
  • UnitGroup
  • UnitInfo
  • UnitRecord

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.
If you prefer a different approach and don't think, a "DB" layer is necessary below a unit system, please vote -1.

Thanks,
Werner



 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)

[UNITSOFMEASUREMENT-123] Make libraries available on MavenCentral Created: 04/Mar/15  Updated: 25/Jun/15  Resolved: 25/Jun/15

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:
Cloners
clones UNITSOFMEASUREMENT-84 Make RI available on MavenCentral Resolved
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:
Blocks
blocks UNITSOFMEASUREMENT-88 SystemOfUnits need to tell its base u... Resolved
Dependency
blocks UNITSOFMEASUREMENT-91 Add isSystemAvailable(), getAvailable... Resolved
blocks UNITSOFMEASUREMENT-121 Introduce "Pluggable" Unit Systems an... Resolved
Related
is related to UNITSOFMEASUREMENT-99 Rename javax.measure.spi.*Service as ... Resolved
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

  • UnitSystem (similar to UCAR, derived from JSR 108)
  • MeasurementSystem (used by ICU4J)

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)
Sorry if the list of classes below may be irritating, but I guess we get the choice you prefer.

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 so I tend to like it better.

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
See MeasurementSystem, by ICU4J. UCAR, the successor to work done at JSR-108 once now calls it UnitSystem. I guess the term SystemOfUnits came with JSR-275. And at least this scientific modelling library from Switzerland written in C (http://geant4.web.cern.ch/geant4/) has a C header file: http://geant4.web.cern.ch/geant4/reports/gallery/electromagnetic/units/SystemOfUnits.html. So far there are 2 +1 votes for each, I'll leave my vote to decide it if Leonardo abstains. Everyone should have an equal vote here, so please feel free to still chip in if you can

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")
We have somewhat big names in SPI like SystemOfUnitsService but tere are separate discussions to chang the *Service postfix to something else.
So let's discuss it there based on SystemOfUnits. Will leave it open till the end of the day and then close if there are no further significant changes.

Thanks,
Werner

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: PNG File dependencies.png    
Issue Links:
Blocks
is blocked by UNITSOFMEASUREMENT-127 Simplify unit systems in RI Resolved
Dependency
depends on UNITSOFMEASUREMENT-122 Should we rename SystemOfUnits? Closed
Related
is related to UNITSOFMEASUREMENT-152 Refactoring SPI Resolved
is related to UNITSOFMEASUREMENT-120 Sync Unit Systems with oBIX Resolved
is related to UNITSOFMEASUREMENT-103 Look into Unicode CLDR Resolved
is related to UNITSOFMEASUREMENT-98 Consider providing the "Units" class ... Resolved
is related to UNITSOFMEASUREMENT-100 Define our criterion for inclusion / ... Resolved
is related to UNITSOFMEASUREMENT-56 Could we move AbstractQuantity into A... Resolved
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:
Related
is related to UNITSOFMEASUREMENT-103 Look into Unicode CLDR Resolved
is related to UNITSOFMEASUREMENT-116 Refactor UCUMFormat into a locale neu... Resolved
is related to UNITSOFMEASUREMENT-121 Introduce "Pluggable" Unit Systems an... Resolved
Relates
relates to UNITSOFMEASUREMENT-100 Define our criterion for inclusion / ... Resolved
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.
oBIX has a very well-defined set of units based on at least 2 elements Unit and Dimension that pretty much reassemble those defined by JSR 363. Project Haystack (http://project-haystack.org/doc/Units) contains a simplified plain text format of these units based on the Fantom language (its co-creator Brian Frank was in the JSR 275 EG through Tridium, Inc, so the way Fantom supports these units is very much inspired and derived on JSR 275, too )



 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)

[UNITSOFMEASUREMENT-119] Fix L10nPropertyResources Created: 08/Feb/15  Updated: 11/Jun/15  Resolved: 11/Jun/15

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 UNITSOFMEASUREMENT-86), it uses the idea of holding resource data in classes like the JDK class resource bundle.
L10nResources largely based on an ME substitution for bundles backed by Properties files doesn't work.

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)

[UNITSOFMEASUREMENT-118] Add Tests according to Spec Chapter 4 Created: 27/Jan/15  Updated: 03/Apr/16  Resolved: 03/Apr/16

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:
Related
is related to UNITSOFMEASUREMENT-159 Move test-audit.xml to main/resources Resolved
Tags: api, spec, tck-red, test, testing
Sprint: Q1/15, Final Draft

 Description   

Spec Chapter 4 (API) requires TCK Tests

  • Assess if and which tests are required
  • Where necessary update test-audit.xml of the TCK project
  • Write tests for sections identified as relevant


 Comments   
Comment by keilw [ 03/Apr/16 ]

This looks pretty complete




Create TCK (UNITSOFMEASUREMENT-101)

[UNITSOFMEASUREMENT-117] Add Tests according to Spec Chapter 2 Created: 27/Jan/15  Updated: 20/Sep/15  Resolved: 20/Sep/15

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

  • Assess if and which tests are required
  • Where necessary update test-audit.xml of the TCK project
  • Write tests for sections identified as relevant


 Comments   
Comment by keilw [ 20/Sep/15 ]

As of now only Chapter 4 and 5 seem TCK relevant




Remove UCUM from RI (UNITSOFMEASUREMENT-114)

[UNITSOFMEASUREMENT-116] Refactor UCUMFormat into a locale neutral SimpleUnitFormat Created: 22/Jan/15  Updated: 11/Jul/15  Resolved: 11/Jul/15

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:
Duplicate
is duplicated by UNITSOFMEASUREMENT-112 Refactor "internal" elements of RI fo... Resolved
Related
is related to UNITSOFMEASUREMENT-86 Getting rid of java.util.Locale and R... Resolved
is related to UNITSOFMEASUREMENT-120 Sync Unit Systems with oBIX Resolved
is related to UNITSOFMEASUREMENT-103 Look into Unicode CLDR Resolved
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)

[UNITSOFMEASUREMENT-115] Remove UCUM system Created: 22/Jan/15  Updated: 22/Jan/15  Resolved: 22/Jan/15

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:
Related
is related to UNITSOFMEASUREMENT-109 Clarify behavior of getSymbol() by a ... Resolved
Relates
relates to UNITSOFMEASUREMENT-107 Move some elements to a package "spi" Resolved
Sub-Tasks:
Key
 Summary
 Type
 Status
 Assignee
UNITSOFMEASUREMENT-115 Remove UCUM system Sub-task Resolved keilw  
UNITSOFMEASUREMENT-116 Refactor UCUMFormat into a locale neu... Sub-task Resolved keilw  
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:

  • Travis-CI
  • drone.io


 Comments   
Comment by keilw [ 12/Jun/15 ]

Single module projects like API, RI or SE-port mostly use drone.io.
Due to insufficient Maven multi-project support (at least build results always show "failed" despite everything built properly) all other projects currently use Circle-CI, see https://github.com/unitsofmeasurement/uom-lib




[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:
Duplicate
duplicates UNITSOFMEASUREMENT-116 Refactor UCUMFormat into a locale neu... Resolved
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
https://github.com/unitsofmeasurement/uom-se/issues/55
https://github.com/unitsofmeasurement/uom-se/issues/56



 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:
Blocks
blocks UNITSOFMEASUREMENT-108 getSymbol() and toString() differ for... Closed
Related
is related to UNITSOFMEASUREMENT-114 Remove UCUM from RI Resolved
is related to UNITSOFMEASUREMENT-103 Look into Unicode CLDR Resolved
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:
Blocks
is blocked by UNITSOFMEASUREMENT-109 Clarify behavior of getSymbol() by a ... Resolved
Duplicate
is duplicated by UNITSOFMEASUREMENT-139 Special GRAM format problem with sub-... Resolved
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:
Relates
relates to UNITSOFMEASUREMENT-114 Remove UCUM from RI Resolved
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:
Blocks
blocks UNITSOFMEASUREMENT-98 Consider providing the "Units" class ... Resolved
Related
is related to UNITSOFMEASUREMENT-105 KILO(GRAM) misformatted as Mg Resolved
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:
Related
is related to UNITSOFMEASUREMENT-106 Try to declare members of Units as Un... Resolved
Tags: format, i18n
Epic Link: View
Sprint: Q1/15

 Description   

See
unit-ri
tec.units.ri.util.PrefixTest
testKg(tec.units.ri.util.PrefixTest)
org.junit.ComparisonFailure: expected:<[k]g> but was:<[M]g>

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,
TRIILLIONS should be spelled TRILLIONS





[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:
Related
is related to UNITSOFMEASUREMENT-86 Getting rid of java.util.Locale and R... Resolved
is related to UNITSOFMEASUREMENT-100 Define our criterion for inclusion / ... Resolved
is related to UNITSOFMEASUREMENT-109 Clarify behavior of getSymbol() by a ... Resolved
is related to UNITSOFMEASUREMENT-116 Refactor UCUMFormat into a locale neu... Resolved
is related to UNITSOFMEASUREMENT-120 Sync Unit Systems with oBIX Resolved
is related to UNITSOFMEASUREMENT-121 Introduce "Pluggable" Unit Systems an... Resolved
Relates
relates to UNITSOFMEASUREMENT-100 Define our criterion for inclusion / ... Resolved
relates to UNITSOFMEASUREMENT-126 Should we rename SI to Metric? Resolved
Epic Link: View
Sprint: Q1/15, Public Draft

 Description   

OpenJDK declared at least 2 JEPs related to CLDR:
This one's alread final (as of Java 8)
http://openjdk.java.net/jeps/127
This one's a draft for Java 9
http://openjdk.java.net/jeps/8043554

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)

See https://github.com/unitsofmeasurement/uom-se/issues/92




[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.
For a given code

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 but it does some strange "bitwise shift" instead, probably why 10 turned into 8 instead of 100

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.
Evidently, CLDC 8 did not get a Math.pow() method yet either (either for performance or other reasons, that seems among the classes unchanged from J2ME times) so the only alternative is to substitute it (similar to the gcd() method) or try using the explicit numbers. For 10^24 to 10^-24 that requires double as long is exceeded.




[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:
Blocks
is blocked by UNITSOFMEASUREMENT-173 Verify minimum Java version for TCK Resolved
is blocked by UNITSOFMEASUREMENT-176 Consider dropping SPI profile from TCK Resolved
is blocked by UNITSOFMEASUREMENT-153 Portability of TCK Resolved
Dependency
depends on UNITSOFMEASUREMENT-169 Consider additional profile(s) for TCK Resolved
depends on UNITSOFMEASUREMENT-174 Consider using Reflections.org for TCK Resolved
Sub-Tasks:
Key
 Summary
 Type
 Status
 Assignee
UNITSOFMEASUREMENT-117 Add Tests according to Spec Chapter 2 Sub-task Resolved keilw  
UNITSOFMEASUREMENT-118 Add Tests according to Spec Chapter 4 Sub-task Resolved keilw  
UNITSOFMEASUREMENT-158 Add Tests according to Spec Chapter 5 Sub-task Resolved keilw  
UNITSOFMEASUREMENT-159 Move test-audit.xml to main/resources Sub-task Resolved keilw  
UNITSOFMEASUREMENT-169 Consider additional profile(s) for TCK Sub-task Resolved keilw  
UNITSOFMEASUREMENT-173 Verify minimum Java version for TCK Sub-task Resolved keilw  
UNITSOFMEASUREMENT-174 Consider using Reflections.org for TCK Sub-task Resolved keilw  
UNITSOFMEASUREMENT-176 Consider dropping SPI profile from TCK Sub-task Resolved keilw  
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.
While using TestNG, not JUnit the TCK of JSR 354 looks like a good inspiration for those who want to learn what it shall look like: https://github.com/JavaMoney/jsr354-tck
JSR 107 is also a (currently) standalone JSR: https://github.com/jsr107/jsr107tck but adds some complexity by testing against various containers like Weld, Guice, Spring,... Something we will face in a slightly different form, becaus at least on Java ME and SE Embedded implementations are expected to run and be tested. JSR 361 (MEEP 8) was the first offering Optionality, but except to those among us in the EC its TCK is not Open Source or publicly visible.

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: Microsoft Excel geoapi.xlsx     Microsoft Excel nist_units.xlsx     PDF File quantities.pdf     Microsoft Excel quantities.xlsx    
Issue Links:
Blocks
is blocked by UNITSOFMEASUREMENT-20 Should we move Dimensionless into a (... Resolved
is blocked by UNITSOFMEASUREMENT-9 Mass Density Unit Resolved
Related
is related to UNITSOFMEASUREMENT-121 Introduce "Pluggable" Unit Systems an... Resolved
is related to UNITSOFMEASUREMENT-103 Look into Unicode CLDR Resolved
Relates
relates to UNITSOFMEASUREMENT-181 Refine quantities included in API Resolved
relates to UNITSOFMEASUREMENT-120 Sync Unit Systems with oBIX Resolved
relates to UNITSOFMEASUREMENT-103 Look into Unicode CLDR Resolved
relates to UNITSOFMEASUREMENT-127 Simplify unit systems in RI Resolved
Sub-Tasks:
Key
 Summary
 Type
 Status
 Assignee
UNITSOFMEASUREMENT-141 Apply criterion for inclusion / exclu... Sub-task Resolved keilw  
UNITSOFMEASUREMENT-142 Document criterion for inclusion / ex... Sub-task Resolved keilw  
Tags: design, document, question, spec, vote
Epic Link: Documents
Sprint: Q1/15, Public Draft

 Description   

The javax.measure.quantity package has a large number of quantity types, but the criterion for accepting or rejecting a quantity in this list is unclear. Given that the amount of possible quantities is very large and we do not want to include all of them, we should probably define our criterion.

Mismatch between specification and API

Maybe as an effect of the criterion not being explicitly defined, the table provided in the "Supported quantities" section of the specification is missing the following types compared to the current Javadoc / Spec:

  • Action
  • AngularAcceleration
  • AngularSpeed
  • Dimensionless
  • DynamicViscosity
  • ElectricPermittivity
  • Information
  • InformationRate
  • IonizingRadiation
  • KinematicViscosity
  • Luminance
  • MagneticFieldStrenght
  • MagneticPermeability
  • MassFlowRate
  • Torque
  • VolumetricDensity
  • VolumetricFlowRate
  • WaveNumber


 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.
This is actually the most interesting source: http://en.wikipedia.org/wiki/Proposed_redefinition_of_SI_base_units

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 are likely to be final before that, but it seems a good idea to refer to this Wikipedia page and the 2011 proposal (which was after JSR 275 ended, so a few of the Unit-API 0.6 contents must be based on that already)

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
E.g. it was meant to define the Planck Constant. Boltzmann is also there

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")
To cover UCUM in a strongly typed manner, all of these seem to make sense. Usually the UCUM doc also refers to where they came from.

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
A more detailed overview can be found in this 2008 publication: http://physics.nist.gov/Pubs/SP330/sp330.pdf

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...?
The thing with "standard" is, even Table 2 of the mentioned NIST site and PDF document (guess you can't open that either?) says "Examples of SI derived units". So it does not say "definitive list", but the 3rd table calls them "named units", so that is sort of a definition by NIST.

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,
Werner

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

  • @apiNote SI base unit
  • @apiNote SI derived unit with special names/symbols
  • @apiNote SI derived unit

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:
Blocks
is blocked by UNITSOFMEASUREMENT-128 Add ServiceProvider interface Resolved
Related
is related to UNITSOFMEASUREMENT-122 Should we rename SystemOfUnits? Closed

 Description   

The javax.measure.spi package defines the following interfaces:

  • SystemOfUnitsService
  • UnitFormatService

However the usage in the JDK seems to use the Provider suffix instead than Service, as we can find in the following packages:

  • java.nio.channels.spi
  • java.nio.charset.spi
  • java.nio.file.spi
  • java.text.spi
  • java.util.spi
  • javax.sound.midi.spi
  • javax.sound.sampled.spi
  • javax.sql.rowset.spi
  • javax.xml.ws.spi

Exceptions to the "Provider" suffix usage are below (but none of them use "Service"):

  • javax.imageio.spi
  • javax.naming.spi
  • javax.security.auth.spi

I suggest to comply to JDK usage are replace "Service" by "Provider" in above-cited interface names.

Note on semantic

Note that "Service" and "Provider" may not have the same meaning. Maybe we can see a service as something like a "Web Service": we send a request to the service, it performs some work, we get an answer, then we send a new request based on user action or previous request results, and so on. The Fowler's description of "Micro Service" seems to be similar.

By contrast, a provider seems to be a "one shut" action, like a connection to a database: we get a "connection" (in our case, just a reference to a Java object) to a service. Then, we can forget about the provider.

Indeed, "SPI" in the package name stands for "Service Provider Interface": both "Service" and "Provider" are in the name. Providers provide services. In JSR-363, I think that UnitFormat can be seen as a kind of service. Consequently UnitFormatProvider would be the interface that give me UnitFormat services.



 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 ) UnitFormatService in an implementing framework.

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
and especially on the ME side, the term "Service" is almost more common than on the SE/EE side, e.g.
http://docs.oracle.com/javame/config/cldc/opt-pkgs/api/security/satsa-api/jsr177/javax/microedition/securityservice/package-frame.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:
Blocks
is blocked by UNITSOFMEASUREMENT-145 Move Bootstrap mechanism into API Resolved
is blocked by UNITSOFMEASUREMENT-106 Try to declare members of Units as Un... Resolved
Dependency
depends on UNITSOFMEASUREMENT-96 Clarify if the optionality of quantit... Resolved
Duplicate
duplicates UNITSOFMEASUREMENT-56 Could we move AbstractQuantity into A... Resolved
Related
is related to UNITSOFMEASUREMENT-121 Introduce "Pluggable" Unit Systems an... Resolved

 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:

  • Optionality:
    • If this class is provided in javax.measure package, does it means that it can not be optional?
    • Do vendors have to provide every fields (is it all or nothing)?
  • The Units class would fetch the implementation using java.util.ServiceLoader. But what should we do if the service loader find no implementation? Or find more than one implementation?


 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.
Another alternative while adding further modules could be declaring a separate module and package like system or systems for such classes. It would make spi independent of quantity and require both spi and quantity aside from core types itself.

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)

[UNITSOFMEASUREMENT-97] Add a chapter about performance Created: 19/Dec/14  Updated: 28/Sep/16  Resolved: 28/Sep/16

Status: Resolved
Project: unitsofmeasurement
Component/s: Documentation
Affects Version/s: None
Fix Version/s: None

Type: Sub-task Priority: Minor
Reporter: