Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Werner Keil
    @keilw
    Also created https://java.net/jira/browse/UNITSOFMEASUREMENT-171 to improve/further clarify the JavaDoc of UnitFormat and where necessary adjust implementing classes, too.
    Sebastiaan van Erk
    @sebster
    @keilw Thanks for the clarifications. In my view the dimensionless unit ONE is no more or less special than any other unit, and should only be returned if the string that is parsed is a valid representation of the dimensional unit, e.g. 1 or m/m. Personally I can see 3 different cases from a functional point of view: 1) an input string is a valid combination of known unit symbols and operators, and therefore there is no error, e.g., 1, mm, 1/m^2, s^-1, kg*m; 2) an input string is valid but contains an unknown unit symbol, e.g., 1/bla; 3) An input string is invalid, e.g. 1//m^--1. In my opinion only the first one should return a Unit, the second one should throw a special ParserException to indicate the unit symbol is unknown, and the third should throw a ParserException to indicate the syntax is invalid. In no case should the parse method return null; this puts an undesired burden on the client to check the result which 1) will be forgotten a lot resulting in a lot of NullPointerExceptions, 2) leads to ugly if-based error checking (e.g., if (format.parse("1/m") == null) { // do error handling } where it is hard to separate the happy-flow logic and error-logic leading to hard to read code, and 3) makes it impossible to know the reason or details of the error (was it an invalid symbol, and at what position did the parsing fail?).
    Werner Keil
    @keilw
    Thanks for the input. Unless others including EG members suggest different, it's a welcome part of the Public Review process (open to anybody, not only those in the EC who'll vote on the JSR in January after reviewing it) While keeping it locale neutral in the API, a (fairly similar to 354 since JodaTime/Money follow the same approach) documentation and definition like https://docs.oracle.com/javase/8/docs/api/java/time/format/DateTimeFormatter.html#parse-java.lang.CharSequence-, where necessary closer to JSR 354 is what I'd have in mind. Also making "value oriented" JSRs in- and outside the JDK behave as similar as possible in general purpose methods like parse(CharSequence) WDYT?
    Sebastiaan van Erk
    @sebster
    I agree, although I there is a lot of diversity/inconsistency even inside the JDK, so I would go for "correct" behavior over keeping things in line too much. For example, in my opinion using UnsupportedOperationException to indicate a parse error (as in JSR354) is incorrect: the requested operation (parsing the string) is supported, the input is just incorrect. My normal conclusion if I got an UnsupportedOperationException on a parse() call would be that either parsing is not (yet?) supported or supported only partially (e.g., a minimal parser with some missing features). I'm also not a fan of RuntimeExceptions for errors in user input (because RuntimeExceptions tend not to be handled), but it seems that the JDK does do this in almost all cases (e.g., Integer.parseInt, DateTimeFormatter.parse, etc).
    Sebastiaan van Erk
    @sebster
    I also looked at downgrading both uom-se or only the EBNFUnitFormat to Java 5/Java 6, but this looks like quite a lot of work in both cases since extensive use of JDK 8 features is made, and it'll be a big burden to maintain with so many required modifications and many upstream changes which are again hard to backport. So now I'm don't really know anymore what the best way is to get a fully-featured UnitFormat on Java 5/Java 6.
    Werner Keil
    @keilw
    You can say that, JSR 310 is probably among the worst examples of being inconsistent (and others like JavaFX themselves created a "parallel universe" with types like Duration existing in both ;-O ) As for RuntimeException, I'm afraid that ship sailed and not only 310 and its Spec Leads drove that into Java and OpenJDK. We have only one very particular checked exception in 363 that will remain as it is from all I can tell. All others derive from MeasurementException which like most other JSRs derives from RuntimeException.
    Java 8 and "Diamonds" are everywhere I'm afraid, and in uom-se contributors are free to use them. So other than looking e.g. at UCUMFormat in uom-systems (which may be less affected) or prior art like JScience 5 (unfinished work, but e.g. UnitFormat should be there) I can't think of a "perfect blueprint" for a backport either.
    Within the constraints of Java ME the RI probably won't offer everything you can do in SE also for size reasons, even 150k for the JAR is already quite big.
    Werner Keil
    @keilw
    Both JScience 5 and Eclipse UOMo implement Unit-API 0.6 (in our repos under "uom-legacy") UnitFormat, they are fully backward compatible to at least Java 6, so looking at the 2 flavors there you might find enough inspiration for a backport. Keep in mind, UOMo is under EPL, not BSD, but neither will e.g. force you to contribute back what you applied under Java 5/6 unless you want to.
    Werner Keil
    @keilw
    Taking both JScience and UOMo as examples, as soon as Eclipse is able to include JSR 363 into its Orbit library, there shall be an UOMo update implementing it rather soon, too. Take http://www.ehcache.org/ offering at least one more implementation to JSR 107. Some of them are closed source or commercial, hence certain unit systems or extensions to JSR 363 might follow a similar path ;-)
    Erol
    @FrEaKmAn
    hi.. are there any methods to compare quantities? I'm missing isLessThen, isGreaterThan methods...
    Werner Keil
    @keilw
    Both implementations provide AbstractQuantity.compareTo() so they implement Comparable. Methods like
    @Override
    public boolean isGreaterThanOrEqualTo(Quantity<Q> that) {
    return this.compareTo(that) >= 0;
    }
    are simply convenience methods as you see. We need to keep the RI small to fit into as many Java ME 8 apps and devices as possible, therefore such overhead does not exist in the RI. If needed, please add the extra lines in an app or solution. Both use the same standard Comparable interface.
    Andre Lanouette
    @lanouettea
    Hello, I'm looking for some help in a special case of unit conversion. I may be missing something, but I think the framework is actually not able to do what I need. I defined some spectral radiance units as W/(cm²·sr·cm^-1). I want to convert these values to another unit, W/(cm²·sr·um). Physically, to perform this unit conversion, I do not need only 1 number to convert (the radiance). I need 2 numbers the radiance (expressed in W/(cm²·sr·cm^-1), and the corresponding wavenumber value (expressed in cm^-1). I think at the moment, unitsofmeasurements only allow 1 number as input, right?
    Basically, the actual conversion equation should be [Ll = n^2 x Ln / 10000], where LI is the converted radiance in W/(cm²·sr·um), Ln is the radiance in W/(cm²·sr·cm^-1), and n is the wavenumber value, in cm^-1.
    Andre Lanouette
    @lanouettea
    DO you know how I could implement this using unitsofmeasurements?
    Werner Keil
    @keilw
    Hi, Thanks for your interest and input. First of all you'll need at least one of the unit system extension modules from: https://github.com/unitsofmeasurement/uom-systems. UCUM and ISO 80000 offer the most extensive set of units on top of either RI or SE 8+ implementation (UCUM is only available for Java SE 8+ right now) and the SI unit modules. Though the outcome won't be checked against a distinct quantity type, you can do almost every calculation with a "wildcard" (Quantity<?>) outcome. Is "W" Watt in your formulas or does it stand for something else? WaveNumber is already a defined quantity in the SI module. The SI standard is "1/m" (or m^-1) but combining that with CENTI should work. So you certainly need https://github.com/unitsofmeasurement/si-units. Please feel free to raise a GitHub ticket https://github.com/unitsofmeasurement/si-units/issues asking to add quantity and unit definitions for https://en.wikipedia.org/wiki/Radiance#Radiance). Though we may not include every single item in https://en.wikipedia.org/wiki/Radiance#SI_radiometry_units those with the highest usefulness are certainly welcome in the SI module. Everything else would be subject to UoM-Systems or custom unit modules of your own.
    Andre Lanouette
    @lanouettea
    Hello keilw, thanks for your support. Our project is already setup correctly to use the SI unit systems. Additionally, we added some units ourselves to express the units I described above. However, my problem is in the actual conversion. Standard conversion, such as converting a centimeter to a meter is very simple, since it only requires a single number (the value in cm) to convert to m. However, in the case of converting W/(cm²·sr·cm^-1) to W/(cm²·sr·um), I require 2 input values to perform the conversion (the radiance unit, in W/(cm²·sr·cm^-1), and the corresponding value in wavenumber (cm^-1). I do not see how to perform a unit conversion with 2 inputs instead of 1 in your API?
    Werner Keil
    @keilw
    Are you suggesting, you have a quantity with 2 units or 2 numeric values? ;-) Chaining conversions and operations works perfectly fine with almost unlimited number of arguments, see https://github.com/unitsofmeasurement/uom-demos/blob/master/domain/energy/src/main/java/tec/uom/demo/energy/SmartHomeDemo.java (based on http://www.dagego.de/info_waermebedarf.html it's only in German, but you should get an idea of the formulas involved) For example for Radiance "watt per steradian per square metre" should work via unit WATT.divide(STERADIAN).divide(SQUARE_METRE).
    Werner Keil
    @keilw
    OK, I also created unitsofmeasurement/si-units#11
    Petar Tahchiev
    @ptahchiev

    Hello, can someone tell me what this represents:

      /**
       * Holds the dimensionless unit <code>ONE</code>.
       * 
       * @deprecated consider moving it to {@link AbstractUnit} again for static constant usage reasons.
       */
      public static final Unit<Dimensionless> ONE = addUnit(new ProductUnit<Dimensionless>(), Dimensionless.class);

    it is from Units

    I don't understand what unit is ONE.. am I safe to assume these are pieces?
    For example if I add 3 products in my basket , can I use this UNIT to add 3 ONEs
    if I'm correct the name PIECES would make much more sense to me.. I would add 3 PIECES of this screwdriver for instance
    Werner Keil
    @keilw
    ONE is a constant similar to NONE for special purposes. It's not the same as PIECE or PERCENT, though both also exist in other unit systems. At least DROP or SPOON do in a medical context mostly (some might also apply to cooking and recipes)
    Werner Keil
    @keilw
    ONE is required for formulas and algorithms e.g. some of these (a bit scientific, but I hope it helps;-) https://en.wikipedia.org/wiki/Natural_units#Choosing_constants_to_normalize
    Petar Tahchiev
    @ptahchiev
    I see.. so do you have a PIECE unit? Because I couldn't find it and without it I'm not sure how to model my e-commerce website. Or if it's not there how can I add custom Units
    Werner Keil
    @keilw
    Please check out https://github.com/unitsofmeasurement/uom-systems for that. There are various unit system modules, e.g. UCUM (only for Java SE 8 as of now) or others for both the RI and SE implementation. For retail, https://github.com/unitsofmeasurement/uom-demos/tree/master/domain/retail-se shows how to define any unit, e.g. "SIXPACK". In this case using enums, but you may also define your own SystemOfUnits like https://github.com/unitsofmeasurement/uom-lib/tree/master/domain/health shows. It's up to you. Happy about suggestions or contributions to either. Note, to be more flexible uom-domain will likely get its own repo in the near future.
    Petar Tahchiev
    @ptahchiev
    thank you .. @keilw can I ask a JSR-354 question here? I couldn't find a chat for java-money. Do you think it would be a good idea to have a type TimeMonetaryAmount to represent things like "5$ per month", then there would be also an API to convert those, i.e. find price for a year, or 6 weeks, or find price in Japanese Yen for 2 weeks only. Does that make sense? If so I can open a request for a feature in the JIRA..
    we could also provide API for formatting too: "$5 per month" or so
    Petar Tahchiev
    @ptahchiev
    it can be a combination of java.time.Duration or java.time.Period + MonetaryAmount
    Werner Keil
    @keilw
    No there is https://gitter.im/JavaMoney. We haven't finalized the place (because Eclipse Foundation still lacks support of JSR 363 and 354 in the latter case it may take much longer) but "UOMo Business" has the idea of a "$5 per gallon fuel" or "$10 for 20 packages of cigarettes" etc. UOM-SE for Java SE 8 has a bridge for java.time, in Moneta (for Java SE 8) this is also possible or at least in an extension module.
    Please raise it in the JavaMoney gitter chat at least where only Monetary + Temporal are involved ;-)
    Erol
    @FrEaKmAn
    hi all.. how could I define a unit: kW/100cfm?
    Erol
    @FrEaKmAn
    this is the worst thing ever.. for some reason I cannot format BAR
    it always returns Pa*100000
    and it worked fine in previous versions
    Erol
    @FrEaKmAn
    somehow this works
    but when I try to parse and output m³, I get ㎥
    different units
    aha, this is intentional \u33A5
    but why?
    Werner Keil
    @keilw
    Using the Default SimpleUnitFormat you get UTF-8 support, so in some cases the available Unicode symbols are used. If you don't like it you may either override it with your own preference using UnitFormat.label(Unit, "String") e.g. SimpleUnitFormat.getInstance().label(). Although BAR should be formatted by default, this could also allow you to override and either temporarily or permanently format a unit differently. Note, that SimpleUnitFormat being the default format will also influence how parse() works.
    Werner Keil
    @keilw
    Where did you find BAR? It's not an official SI unit: https://en.wikipedia.org/wiki/Non-SI_units_mentioned_in_the_SI
    And therefore also not in Unicode CLDR/ICU4J.
    Werner Keil
    @keilw
    It's private and likely removed, but if you need BAR and want to define it in a unit system of your own, the latest RI supports a declaration like public static final Unit<Pressure> BAR = AbstractSystemOfUnits.Helper.addUnit(Units.PASCAL .multiply(100000), "Bar", "b");
    Your unit system should extend AbstractSystemOfUnits.
    Werner Keil
    @keilw
    Actually there's a small set of these units in NonSI. We were not sure, if this should remain in uom-systems, but covering e.g. https://en.wikipedia.org/wiki/Non-SI_units_mentioned_in_the_SI#Common_units_not_officially_sanctioned I think there's nothing wrong in keeping it.
    Werner Keil
    @keilw
    Please go to https://gitter.im/unitsofmeasurement/indriya now for the RI of JSR 385.