[jsr361-observers] [jsr361-experts] Re: Re: JIRA Issues
- From: Werner Keil <
- Subject: [jsr361-observers] [jsr361-experts] Re: Re: JIRA Issues
- Date: Thu, 9 Jan 2014 16:11:24 +0100
- List-id: <jsr361-experts.jsr361.java.net>
Thanks a lot for the update and changing things I mentioned.
The whole "OPTIONAL" part of a JSR is interesting and found only in some,
probably earlier precursors on the J2ME side, e.g. MSA had entire JSRs like
256 that were optional to it.
Along those lines, please those of you who are interested in such
technologies on top, feel free to have a look and comment on an initial
Spec Lead Draft I composed together with proposed Co Spec Leads Jean-Marie
and Leonardo (V2COM) to be presented during the F2F later this month:
The notion of "OPTIONAL" is also used here, in particular all Maven modules
other than "core" are considered optional and devices with heavily
constrained resources may simply use the core API (~12kb) for things like a
minimalistic UCUM parser or generator to send measurement values across the
IoT, while other parts of the Sensor Web (including those based on Java SE
or EE) may leverage compile time unit type consistency or extensions like
this one SmartGrid thought leader Opower created on top of Unit-API (
unitsofmeasurement.org) for JSON Binding via Jackson
https://github.com/opower/jackson-module-unitsofmeasure Other supporters of
this JSR include CERN and a variety of the World's largest telco and mobile
We'll present an "executive overview" at the F2F accompanied by a few
selected live demos e.g. "Heart of Glass" with a "pacemaker" powered by
this new JSR if you want[?]
Of this EG Gemalto supports, it, too. Any other EG member would be welcome
to participate or at least support it. We won't officially file it until
after the F2F, so at least those in the EC are welcome to comment on site,
all others please tell me directly if you are interested or have comments
and suggestions for this proposal draft.
Werner Keil | JCP Executive Committee Member | Eclipse UOMo Lead, Babel
Language Champion | Agorava Cofounder
Twitter @wernerkeil | @JSR354 | #EclipseUOMo | #Java_Social | #DevOps
Skype werner.keil | Google+ gplus.to/wernerkeil
* Social Media Week Hamburg: 18 Feb 2014, Hamburg, Germany. Werner Keil,
Eclipse JCP EC Member, JSR 354 EG Member will present "Bitcoin, Payment
Instrument or Object of Speculation?", "Social 2.0 with Agorava"
On Mon, Jan 6, 2014 at 5:30 PM, Volker Bauche
> Hi Werner, all,
> happy new year to all of you also from my side.
> Werner, thanks for your comments.
> Pls. find answers inline below (for both of Werner's emails).
> Best regards -
> Am 31.12.2013 13:58, schrieb Werner Keil:
>> Dear Volker/all,
>> Thanks for the summary. As I was travelling during the call I appreciate
>> the update.
>> There is at least one detail I'd like to point out here, before creating
>> a JIRA ticket. EventManager.getSystemEvents() actually returns a String
>> array, so something like getSystemEventNames() could be more logical.
>> Agreed, will change the name.
>> The getCurrent() method is a bit short, but for an EventManager it sounds
>> understandable it'll return events, thus I don't mind the naming here.
>> Ok, keep it as is.
>> Happy New Year,
> Am 31.12.2013 14:01, schrieb Werner Keil:
>> Two more things, why is null for PowerManager.getInstance() not
>> necessary, is it always assumed to be present?
>> Yes, as the whole power management package is optional, in case it is
> implemented it can be assumed a power manager to be available.
>> And in the JavaDoc of e.g. EventManager schouldn't example package names
>> like "com.sun" be rephrased, or do we prefer to quote the original Java
>> specs here?;-)
>> Good point. ;-)
> Have changed the example, also at another place in the spec where I still
> found a "com.sun".
>> Kind Regards,
Description: GIF image