Skip to main content

[jsr363-experts] Re: Early Draft

  • From: Werner Keil < >
  • To: " " < >
  • Subject: [jsr363-experts] Re: Early Draft
  • Date: Fri, 19 Dec 2014 14:21:42 +0100

Again, only the content of "unit-api" is "The API".
Having Measurement separately in RI and the SE Port I created mostly helped
by Otavio and his OpenJDK experience means, the interface (or class, that
rarely matters, especially under SE 8 and above) can hold alternate
timestamps based on Java 8 Instant (which is the best type for a point in
time there)
If we put it into a separate library, there are currently no official
"reusable" libraries except small but growing libraries for Health, Fitness
and QS (Self-Monitoring or whatever you call it)

The RI is already outside the JSR-363 API/Spec, as the JCP knows these and
therefore neither alternate implementations (Apache SIS or GeoAPI seem like
"partial" implementations of JSR 275 as of now, thus if they just
implemented the "core" parts without format or SPI possibly with "quantity"
that would be fine;-) have to use everything "assisting" the RI nor
implement say Measurement. That would only be necessary if any of them
remained or went back into the "Spec" part of the JSR.

Werner






On Fri, Dec 19, 2014 at 2:11 PM, Martin Desruisseaux <
>
 wrote:
>
>  Hello Werner
>
> What worry me is that you seem to present the JSR-363 API and the
> "assisting" classes as one API. I have no problem in providing Measurement
> and Range classes in the RI as examples. But the RI interpretation of
> Measurement is one point of view, far from universal (restricted to scalar
> measurement, no information about measurement quality). The way Range is
> designed is also disputable. None of these classes are suitable for me, so
> Apache SIS would likely continue to have its own Measurement and Range
> implementation.
>
> Again, no problem with that if those classes are clearly flagged as
> outside the JSR-363 API - which I though it was...
>
>     Martin
>
>
> Le 19/12/14 21:49, Werner Keil a écrit :
>
>  Martin,
>
>  Referring to the JCP Process Document:
> https://jcp.org/en/procedures/jcp2
>
>  *Java Specification (Specification)*: A written specification for some
> aspect of the Java technology. This includes the language, virtual machine,
> Platform Editions, Profiles, and application programming interfaces.
>
>  Although it says "interfaces", the Spec is not the same as the Reference
> Implentation, while "soandso-api" is.
> A JSR "...produces a Specification, a Reference Implementation (to prove
> the Specification can be implemented,) and a Technology Compatibility Kit
> (a suite of tests, tools, and documentation that is used to test
> implementations for compliance with the Specification.) "
> as per JCP document, so the Reference Implementation is not part of the
> Spec, while the API is a code manifestation of the Spec.
>
>  You argued, types like Measurement or Range should not be in the Spec,
> which is why they are "assisting" parts of the RI. Much like
> MBeanServerRegistrationUtility in the RI of JSR 107 (it doesn't implement
> any of the Spec/API parts, but only helps wiring them with MBeans:
> https://github.com/jsr107/RI/blob/master/cache-ri-impl/src/main/java/org/jsr107/ri/management/MBeanServerRegistrationUtility.java
>
>  HTH,
> Werner
>
>
>
>


[jsr363-experts] Re: Early Draft

Werner Keil 12/19/2014

[jsr363-experts] Re: Early Draft

Martin Desruisseaux 12/19/2014

[jsr363-experts] Re: Early Draft

Werner Keil 12/19/2014
 
 
Close
loading
Please Confirm
Close