Skip to main content

[jsr363-experts] Fwd: Digest for list issues@unitsofmeasurement.java.net

  • From: Werner Keil < >
  • To: " " < >
  • Subject: [jsr363-experts] Fwd: Digest for list
  • Date: Wed, 15 Jun 2016 10:09:37 +0200

Dear Experts,

Please have a look at the recent JIRA updates. Due to common practice to
expose collections (List, Set or just Iterable) rather than an array in
modern APIs I changed the available() method in ServiceProvider to a list
(since it's coming from a List by Java ServiceLoader, that list may also
contain duplicates so a Set would not be appropriate) on the public method
signature. And also removed the deprecated old services and their factory
methods.

Unit-API now feels pretty much ready for Final Draft Review. Please have a
careful look especially over the API signature. This should not change
between Final Draft and Final wherever possible. Given at least the Java SE
9 Umbrella and one Java EE 8 JSR (JSON-B) have Creation or Public Review
these days, we'll have to see how busy the PMO is, but for a "Code Freeze"
and having all materials ready to submit for Final Draft, I'd say the end
of June is realistic.

I came across this VMWare IoT framework in a mailing list:
https://github.com/vmware/liota

Some pseudo-code like

# Creating Metric
temperature = vrops.create_metric(temp,'Room Temperature', SI.Celsius,
sampling_interval=10)

(Python here, but the project plans to support C, C++, Java and Lua)
feels almost like the perfect match for JSR 363 on the Java side. And I
also proposed a handful of Python Unit libraries I came across in my talks
https://github.com/vmware/liota/issues/7 which was welcomed by Greg, the
author at VMWare. I guess for Java there's a good chance for synergies
(even uses BSD license;-) so anybody on GitHub who wishes to offer help to
liota, ask https://github.com/GregBollella directly.

Kind Regards,

Werner Keil | JCP Executive Committee Member, JSR 363 Co Spec Lead |
Eclipse UOMo Lead, Babel Language Champion | Apache Committer

Twitter @wernerkeil | @UnitAPI | @JSR354 | @AgoravaProj | @DeviceMap
| #DevOps | #EclipseUOMo
Skype werner.keil | Google+ gplus.to/wernerkeil



---------- Forwarded message ----------
From: 
< >
Date: Wed, Jun 15, 2016 at 2:14 AM
Subject: Digest for list 

To: 



Table of contents:

1. [JIRA] (UNITSOFMEASUREMENT-152) Refactoring SPI - "keilw (JIRA)" <
>
2. [JIRA] (UNITSOFMEASUREMENT-186) Change ServiceProvider.available() to
Collection - "keilw (JIRA)" 
< >



---------- Forwarded message ----------
From: "keilw (JIRA)" 
< >
To: 

Cc:
Date: Tue, 14 Jun 2016 23:32:57 +0000 (UTC)
Subject: [JIRA] (UNITSOFMEASUREMENT-152) Refactoring SPI

     [
https://java.net/jira/browse/UNITSOFMEASUREMENT-152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

keilw resolved UNITSOFMEASUREMENT-152.
--------------------------------------

    Fix Version/s: 0.9
       Resolution: Fixed

> Refactoring SPI
> ---------------
>
>                 Key: UNITSOFMEASUREMENT-152
>                 URL: https://java.net/jira/browse/UNITSOFMEASUREMENT-152
>             Project: unitsofmeasurement
>          Issue Type: Story
>          Components: API
>    Affects Versions: 0.8-RC3
>            Reporter: keilw
>            Assignee: keilw
>             Fix For: 0.9
>
>
> 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



--
This message was sent by Atlassian JIRA
(v6.2.3#6260)


---------- Forwarded message ----------
From: "keilw (JIRA)" 
< >
To: 

Cc:
Date: Tue, 14 Jun 2016 23:32:57 +0000 (UTC)
Subject: [JIRA] (UNITSOFMEASUREMENT-186) Change ServiceProvider.available()
to Collection

     [
https://java.net/jira/browse/UNITSOFMEASUREMENT-186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

keilw resolved UNITSOFMEASUREMENT-186.
--------------------------------------

    Fix Version/s: 0.9
       Resolution: Fixed

> Change ServiceProvider.available() to Collection
> ------------------------------------------------
>
>                 Key: UNITSOFMEASUREMENT-186
>                 URL: https://java.net/jira/browse/UNITSOFMEASUREMENT-186
>             Project: unitsofmeasurement
>          Issue Type: Sub-task
>          Components: API
>    Affects Versions: 0.8
>            Reporter: keilw
>            Assignee: keilw
>            Priority: Minor
>             Fix For: 0.9
>
>
> {{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).



--
This message was sent by Atlassian JIRA
(v6.2.3#6260)

End of digest for list 

 - Wed, 15 Jun 2016


[jsr363-experts] Fwd: Digest for list

Werner Keil 06/15/2016
 
 
Close
loading
Please Confirm
Close