JSR 385 - Reference Implementation
This implementation aims at Java 8 and above.
To use JPMS Java 11 or above is required.
JSR 385 - Reference Implementation
License: Other
JSR 385 - Reference Implementation
This implementation aims at Java 8 and above.
To use JPMS Java 11 or above is required.
The SI redefinition https://www.euramet.org/publications-media-centre/news/?tx_news_pi1%5Bnews%5D=637&tx_news_pi1%5Bcontroller%5D=News&tx_news_pi1%5Baction%5D=detail&cHash=d1b21b8e8a4522f5cfcf3b101a095f04 makes elementary constants like the Avogadro constant, Planck constant or Elementary charge more important than they already used to be.
Right now a few of them are defined internally in the NonSI class of the SI Units module.
Given their increased role, we could either:
It should return 1,001 mΩ on 1 Ω + 1 mΩ.
To be in better sync with the API the initial version should be 1.0. This version fully implements Unit-API 1.0 until the new version is created.
Java 10 just went Final: https://www.oracle.com/corporate/pressrelease/Java-10-032018.html
Let's test it with Indriya and the current JSR 385 snapshot to see, if there are any side-effects or issues.
Of the (very few) features introduced with Java 10, the local variables are certainly something we must evaluate against JSR 385 to ensure, units and quantities work well with the new var
declaration.
Not sure about Class-Data-Sharing, it could mean some performance-benefit, if e.g. JSR related classes are shared at the right time, but mabe a bit less crucial than local variables.
EBNFUnitFormat takes TransformedUnit into consideration, especially if a symbol was set. SimpleUnitFormat currently does not use the symbol unless the same string is also applied as label.
See unitsofmeasurement/uom-se#180
Rest under #7
The package-info contains old or badly formatted content like
Before the "tech" domain became available after March 2015 the RI and TCK used a "virtual" domain name units.tec
I registered instead. Since then units.tech
is also registered. While the "tec" domain is fairly cheap, it won't work as a URL, it is just virtual.
Should we use the 2.0 release and switch to units.tech
instead?
Depending on the choice for Indriya, the new TCK would also match its package namespace.
Currently to reuse it across different implementations, BinaryPrefix resides in uom-lib-common. While Indriya is likely to use much of that library also in 2.0 we could move BinaryPrefix
to the unit
package next to MetricPrefix
, too.
Right now the string representation of any Unit
based on AbstractUnit
uses SimpleUnitFormat
in its default variant.
There was an attempt to make this dynamically use the current UnitFormat
of the current ServiceProvider
, but it had unpredictable and unwanted side-effects that could lead to initialization of AbstractUnit being prevented. Since a chain of different modules may have a similar effect, it is not too likely to work here in the future either (if you feel you have a working, stable answer, please propose it)
However, it should be possible to offer a simple and easy tweak, e.g. via System properties to select e.g. between:
All of which are build in.
Right now AbstractQuantityFormat is a factory for package-local concrete implementations. This is less flexible for extensions outside the RI, so similar to UnitFormat implementations each concrete class should be able to instantiate itself.
Example (currently failing):
IntegerQuantity<ElectricResistance> oneIntOhm = new IntegerQuantity<ElectricResistance>(Integer.valueOf(1).intValue(), Units.OHM);
LongQuantity<ElectricResistance> oneLongOhm = new LongQuantity<ElectricResistance>(Long.valueOf(1).longValue(), Units.OHM);
Quantity<ElectricResistance> sum = oneIntOhm.add(oneLongOhm);
assertEquals(LongQuantity.class, sum.getClass());
IntegerQuantity + LongQuantity
should result in a LongQuantity
, just like LongQuantity + IntegerQuantity
currently results in a LongQuantity
.
The widening should probably be as follows (transitively):
byte → short → int → long → BigInteger
float → double → BigDecimal
any integer type → any decimal type
This behavior should apply to addition, subtraction, multiplication and division.
Add a BigIntegerQuantity
type for large integer numbers.
The helper class Calculus
is quite similar to e.g. NaturalQuantityComparator
which also resides in the function
package. The top level package is primarily for abstract base classes.
Should we add the Maven plugin for PIT, so we can use mutation testing to check unit test code coverage?
Info about PIT: http://pitest.org/
How to add the plugin: http://pitest.org/quickstart/maven/
If there is a large difference in the metric prefixes such that overflow becomes possible, the implementation of the addition and the subtraction is too naive.
Example using IntegerQuantity:
2 YΩ - 1 yΩ = 2 YΩ (correct)
2 yΩ - 1 YΩ = -2147483645 yΩ (incorrect, should have been -1 YΩ)
The implementations should cast the values to the largest metric prefix, not the metric prefix of the first element.
Right now all Unit
classes rely on UnitFormat.label()
if the string representation needs to be altered or overriden. TransformedUnit
also defines a symbol, but it does not seem used when formatting. Also see unitsofmeasurement/uom-se#188
Update headers for JSR 385.
Set up a CI instance for Indriya
To make Indriya backward-compatible with other Java versions (at least SE 8, maybe also 7) and explore new features in upcoming versions of the JDK, we plan to support the Java 9 Multi-Release JAR feature.
This blogpost by JSR 380 Spec Lead Gunnar http://in.relation.to/2017/02/13/building-multi-release-jars-with-maven/ may help. Seems either for Bean Validation or other Hibernate projects he already used that.
Also an interesting lead is this GitHub project: https://github.com/metlos/multi-release-jar-maven-plugin
Following its addition with #26 there should be more JUnit tests for BinaryPrefix.
Follow-up to unitsofmeasurement/uom-se#145
Both ComparableQuantity
and ComparableUnit
interfaces have an isEquivalentOf()
method. Should we keep that name or use a shorter version like:
According to Oxford English using "of" or "to" depend, if "equivalent" is used as adjective or noun. We should decide which one better applies here.
Please select from the following options:
The abstract base class QuantityFormat
should be renamed to AbstractQuantityFormat
Similar to https://github.com/unitsofmeasurement/unit-api/tree/gh-pages for the API
Currently SystemOfUnits
has a descriptive name and getName()
method. Although registered under a key and possible aliases (currently this is implementation-specific, using the getter in the SPI interface) the UnitFormat
implementation class only has a class name. Which may not always be a nice, human-readable string. Overriding toString()
can help, so this could be sufficient, but let's discuss the question of a descriptive string when new versions of the API arise.
I recently stumbled on some pretty nasty behavior that I think should probably be changed.
What does the following return?
public Quantity<Length> scale(Quantity<Length> q) {
return q.multiply(Math.sqrt(2));
}
Unfortunately, it depends. If you pass in an IntegerQuantity, you end up with exactly the same value you passed in, because IntegerQuantity truncates before multiplying: https://github.com/unitsofmeasurement/unit-ri/blob/master/src/main/java/tec/units/ri/quantity/IntegerQuantity.java#L91
But, Quantities.getQuantity(...) returns the same static type independent of the type of the number you pass in, which makes this behavior very surprising.
This seems very dangerous, especially for a library whose main point is to avoid silent calculation bugs due to unit mismatch...
To match the underlying SimpleUnitFormat, DefaultQuantityFormat should better be called SimpleQuantityFormat
The code coverage is currently 40%, see codecov badge. We should create more JUnit tests especially in packages with a very low coverage. At least 60% like the JSR 363 RI should be archived, if more, even better.
With JUnit 5 offering many new and advanced features, it seems a good idea to adopt the new version.
After AbstractQuantityFormat has its new name it should implement a QuantityFormat
interface from the API.
In this line, the hash is the sum of dividend
is added to itself. I think it should be the sum of dividend
added to divisor
.
Right now AnnotatedUnit
is not properly supported by SimpleUnitFormat
while it works in other UnitFormat
implementations like EBNFUnitFormat
.
The System class Units
returns WATT
as AlternateUnit
. it should be just a Unit
.
It should include:
Hi,
I did a bit of brush-up to Indriya over the holidays. And through JUnit tests for CompoundUnit
a problem occurred to me we should rethink the need for a CompoundUnit
as opposed to something like a CompoundQuantity
.
It is currently possible to create a compound chained across even multiple steps like HOUR.compound(MINUTE).compound(SECOND)
. However, trying to combine this type of Unit
into the current Quantity
, how to handle "1 hour: 5 minutes: 30 seconds"
, if only the unit part is multidimensional? We may need something along the lines of a CompoundQuantity
. JSR 310 TemporalAmount
could be a very vague inspiration, but we should ask ourselves questions like do we need a List
or Set
of units, because TemporalAmount
states
The list of units completely and uniquely represents the state of the object without omissions, overlaps or
duplication
Which would speak for a Set avoiding duplication.
Either way, it seems we have to think about that and come up with an idea how to best combine a "list" of Unit elements and numeric values attached. JSR 310 TemporalAmount
implementations are overly simplified, they do not allow more than 2 or 3 distinct units each. E.g. "Year, month, day" in case of the Period
. We need a more flexible approach for general purpose unit support.
This is related to unitsofmeasurement/unit-api#45 on the API level.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.