Use Advanced Search to search the entire archive.
[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 |