Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Andre Lanouette
    @lanouettea
    Hum. Apparently, this artifact comes from the parenthesis in RationalConverter.java convert(double) method. Doing 500.5 (double) 1.0 / (double) 100000.0 gives 0.005005. Doing 500.5 ((double) 1.0 / (double) 100000.0) gives 0.005005000000000001. This is weird.
    This is probably caused by a loss of precision in the double representation of 1.0/100000.0. I don't see why these extra parenthesis are necessary. I would simply remove them in your API if I were you.
    Andre Lanouette
    @lanouettea
    And one last thing: how does one get the SI.PERCENT unit from a parser call. Apparently, AbstractUnit.parse("%") does not return the unit and throws an exception
    Werner Keil
    @keilw
    Showing 0.005005000000000001 as either 0.005, 0.005005 or even just 0 is subject to the format part of the API and implementations. Especially for the RI there are some changes to get rid of java.text and other elements that are incompatible with Java ME Embedded. In UOM-SE those are possible as is using "plain old" ResourceBundle or BigDecimal. Which is why there could be different precision in SE or ME due to that.
    Btw, almost every issue you mentioned here is RI-specific, did you know there's another room https://gitter.im/unitsofmeasurement/unit-ri here, too? ;-)
    Henning Bredel
    @ridoo
    hey there .. just found jsr363 and your contributions on github ... nice work so far. I do have external data source(s) which describe UOM in a non-standard way. I'd like to have UCUM symbols instead which are required to be set by OGC standards. I could not find similar use cases/tests in the uom-api code. Is the librabry/implementation capable in converting UOM symbols?
    Werner Keil
    @keilw
    Hi, Thanks for your interest and suggestions. About OGC standards, probably best talk to @desruisseaux since he also leads the GeoAPI standard. UCUM and other systems would mostly be under https://github.com/unitsofmeasurement/uom-systems.
    HTH? I am not sure, what you mean by "converting UOM symbols"? The API and JSR provides means of converting quantities from one unit into other compatible units, but not "convert" the symbols as such. Maybe you can explain further what you would like to archive, unless you find it in above system libraries anyway.
    Henning Bredel
    @ridoo

    @keilw thanks for your response. I will have a focus on uom-systems to see if it fits.

    by "converting UOM symbols" I mean to convert to UOM symbols. that is having arbitrary uom strings (used by a domain which are not standard), parse it into a known unit (very likly via some mapping config) and then get out the actual UCUM symbol from it.

    Currently I do have org.geotools:gt-opengis:14 on my classpath which ships with jsr-275 beta jar which provides a UnitFormatter via `UnitFormat.getUCUMInstance(). However, JSR-275 was rejected by the EC.

    Werner Keil
    @keilw
    @ridoo Thanks for the clarification. As this is usually domain- and sometimes also locale-specific, it's not something we expect to be integral part of UoM libraries or systems. These offer say different systems like UCUM, SI or ISO80000, but trying to convert a string like "kilom" into "km" just as an example before parsing "km" via UnitFormat instances should be done by an application or framework first. While JSR 275 was rejected at PR stage, OCG did not bother and made it part of their GeoAPI 3 standard. Hence, it is "embedded" in another standard and used widely. Until now, usage stats of common repositories like Sonatype/MavenCentral or Bintray/JCenter show higher demand for JSR 275, mostly due to GeoAPI and projects using or implementing it. JSR 363 is in Public Review as we speak. And with IoT, BigData and other areas showing a big need for this kind of standard (both inside the JVM and via neutral formats like JSON, XML and UCUM also outside) plus corporate partners and interest, we are rather optimistic it should pass this time. However, you won't see it in GeoAPI or LocationTech, etc. until OGC releases a new version of GeoAPI using JSR 363 instead ;-)
    Henning Bredel
    @ridoo
    @keilw okay, thanks for your comments. I agree with you, that converting arbitrary units is certainly a domain related task. I wanted to be sure that there is no integration point for custom user configuration in your API before creating my own one. However, I think that it should not be that big deal though :)
    Petar Tahchiev
    @ptahchiev
    hello, I'm having a hard time finding the EA (each) unit. If you google it you will see such a unit of measure is quite common: https://www.google.bg/?gfe_rd=cr&ei=atkLWMHJIojY8AeikL_gDQ&gws_rd=ssl#q=each+unit+of+measure and even the top hit points to the oracle website.. is this something included in the API?
    Werner Keil
    @keilw
    This is not subject to the API. Please check https://github.com/unitsofmeasurement/uom-domain/tree/master/retail, we might cover something similar there, units like CRATE were already started. Happy to use your help on that if you want to contribute.
    Chris Hennick
    @Pr0methean
    Hi! One of the complaints about JSR 275 was that it didn't integrate with
    JSR-310, which became the Java 8 date/time API
    In the next few days, I could create and pull-request methods for converting a java.time.Duration to Quantity<Time> and vice-versa, plus reference implementations. Do you folks agree this would be useful?
    Werner Keil
    @keilw
    Hi, JSR 310 was started long after 275 and took at least 3 more years after 275 was stopped (310 had been completely stalled at the time, so it played no role in the EC's decision to reject 275) before it was usable to Java SE 8. There is no API relevance by Java SE 8 or JSR 310, but please see https://gitter.im/unitsofmeasurement/uom-se and the respective implementation for Date/Time integration. It's all been done there already, using TemporalQuantity. So no PRs in the API project please, but if you want to help uom-se to improve the quantity.time package and its elements, please feel free to do so.
    Kyle Falconer
    @Kyle-Falconer

    Is there a reason Unit doesn't have a method that returns Q?
    Something like:

    public Q getUnit(){...}

    It would be helpful because we create Quantities and pass in some Unit type such as LITER (which is Q in this case) but there's no way to get LITER back out of Unit

    Werner Keil
    @keilw
    Because Q is not available at runtime. It's lost until Java allows reified types ;-/
    Werner Keil
    @keilw
    Looks odd. AbstractUnit already tries to return the actual type via reflection. I created a task unitsofmeasurement/indriya#8 in the new Indriya prototype.
    The constructor of BaseUnit has an additional argument Q, but I see no realistic way to pass that when constructing the class, nor to retrieve it later. Using the Class maybe, that's already done in other places like unit systems.
    Werner Keil
    @keilw
    JSR 385 was approved earlier this week: https://jcp.org/en/jsr/detail?id=385
    Thodoris Bais
    @thodorisbais
    Hello!
    it's the first try I try to clean install and I'm getting this failure:
    Fatal error compiling: invalid flag: --release
    Has anybody experienced it in the past? Or shall I indeed spend time on it cuz it should compile as is
    ?
    Thodoris Bais
    @thodorisbais
    (I have also not used any jdk>8 till now)
    Werner Keil
    @keilw
    Which JDK did you use here? It works with 9 and above but the API is backward compatible with at least Java 8 in V2.
    Thodoris Bais
    @thodorisbais
    That's what I also thought, that I should download jdk 9
    But in the oracle page I only see jdk 11 (when it comes to jdk downloads above 8). Am I left that behind? :P
    Thodoris Bais
    @thodorisbais
    It wasn't only my old JDK (8). After upgrading to JDK 11, I had to also update my IntelliJ to the latest (2018.2.5) in order to have a successful build. My tests are still failing, but I will investigate this further soon (probably not next weekend, since we have the Glbal Day of Coderetreat here in Utrecht :) )
    Daniel Dias
    @Daniel-Dos
    Hi ,
    How strange that. here in my is working good with JDK 11.
    Thodoris Bais
    @thodorisbais
    So, @Daniel-Dos , mvn clean install is running successfully for you?
    Daniel Dias
    @Daniel-Dos

    Hi @thodorisbais , sorry for delay in response.

    I forgot to update the unit-api jacoco, so it is not compiled with jdk11.

    Thodoris Bais
    @thodorisbais
    Hey Daniel, I'd like to help there, so that I can learn faster ;)
    is it just about updating the dependency's version
    ?
    Daniel Dias
    @Daniel-Dos
    You can still compile with mvn clean install, but you will have 1 or 2 unit tests failing.
    @thodorisbais yes, just update from 0.8.1 to 0.8.2 .
    in this you will find other issues with javadoc to update, same as the last PR of indriya.
    Thodoris Bais
    @thodorisbais
    @Daniel-Dos oh, you're right, no JVM issues at all after updating the dependency! I'll commit it right now like that, and then we can close #148 !
    Daniel Dias
    @Daniel-Dos
    wonderful : )
    Thodoris Bais
    @thodorisbais
    wow, it's great to see it green after quite a bit of struggle, I learned something today, thanks @Daniel-Dos !
    #149 ready!
    Daniel Dias
    @Daniel-Dos
    How wonderful, how good I was able to help. : )
    Thodoris Bais
    @thodorisbais
    All, could someone help me on my JCP membership? It's been pending for more than 2 months now
    I've also been in touch with the admin mail group of jcp, but they also stopped responding to my mails after some time