Skip to main content

[jsr363-experts] ApacheCon F2F

  • From: Werner Keil < >
  • To: " " < >, Anatole Tresch < >
  • Subject: [jsr363-experts] ApacheCon F2F
  • Date: Fri, 2 Oct 2015 20:27:13 +0200

Dear Experts,

Apache Big Data and ApacheCon Core Europe this week in Budapest was a great
opportunity to meet fellow experts (especially Martin for the first time in
my case) and discuss projects. The Units and Data Quality session had among
the largest audience for those I presented or co-presented (if you don't
count the Lightning Talk in the Big Ballroom;-)

I gave Martin an update of where the JSR stands with Public Draft pretty
near based on all deliverables.

We did some house-cleaning among CI servers, which now build exlusively in
the Cloud (CircleCI, in very few cases like the API with Drone.io as a
backup) All artifacts except demos deploy to JFrog Snapshot repositories.
We spoke about "RC" builds and unlike big milestones (EDR, Public or Final
Drafts) we probably won´t publish them to Bintray or MavenCentral from now
on. This was also before the Snapshot builds were all set up, now this does
not seem necessary for intermediary results.

Martin asked if we could move the Parser interface to another place, e.g.
implementations. As it ha  not strutural or functional impact on the API
(UnitFormat still needs a parse() method throwing ParserException if
something goes wrong) the interface now sits in the "format" package of the
RI, since a compound QuantityFormat is currently a class, not interface and
it implements that interface.

The other issue he raised about the Bootstrap class is something, I also
discussed with Anatole, (Star) Spec Lead of JSR 354 where a combination of
Bootstrap and ServiceProvider interface is used to abstract the sometimes
inappropriate JDK ServiceLoader or in other implementations of
ServiceProvider use something else, including OSGi.

EC Member IBM did honor this mechanism. Given their large stake in OSGi or
Eclipse, I guess they understand what it's meant for. The name is not so
much an issue, other JSRs have different names, e.g. CDI simply called an
abstract SPI level class with general accessors just  "CDI", but almost
every JSR does have at least one such public accessor class or facade.
Some have more than one.

The SPI in our case is optional, so nobody is forced to use it, but unlike
just using ServiceLoader which works but has shortcomings (especially if
multiple class-loaders are involved) this abstracts the various loading
mechanisms.
https://javaee-spec.java.net/nonav/javadocs/javax/enterprise/inject/spi/CDI.html
is a good example and via CDIProvider or BeanManager has 2 very similar
interfaces it provides access to or (via setCDIProvider) allows changing of.

What do you think? If we dropped it (optional anyway) it could make
interoperability harder. Even standalone SE facing JSRs like 107 (though
like 330 it should be  bundled with EE 8 after it missed the EE 7 train)
all have a similar "registry" or static accessor. In their case it's called
"Caching", again the name is not written in stone, let's figure out if we
want it in the SPI and what it's good for.
If you want to include Aatole, please do "reply to all", he is not
subscribed to that list, or ask him directly by mail if you have more
detailed questions about the rationale behind the Bootstrap class.

Regards,

Werner


[jsr363-experts] ApacheCon F2F

Werner Keil 10/02/2015

[jsr363-experts] Re: ApacheCon F2F

Martin Desruisseaux 10/04/2015

[jsr363-experts] Re: ApacheCon F2F

Werner Keil 10/05/2015

[jsr363-experts] Re: ApacheCon F2F

Martin Desruisseaux 10/05/2015

[jsr363-experts] Re: ApacheCon F2F

Werner Keil 10/05/2015

[jsr363-experts] Re: ApacheCon F2F

Werner Keil 10/05/2015

[jsr363-experts] Re: ApacheCon F2F

Martin Desruisseaux 10/05/2015

[jsr363-experts] Re: ApacheCon F2F

Werner Keil 10/05/2015

[jsr363-experts] Re: ApacheCon F2F

Martin Desruisseaux 10/05/2015

[jsr363-experts] Re: ApacheCon F2F

Werner Keil 10/05/2015
 
 
Close
loading
Please Confirm
Close