Some more comments inline. On 8 September 2016 at 20:00, David Leangen <o...@leangen.net> wrote:
> “new” (or static) for non OSGi code, the usual service acquisition for > OSGi environments. The basic idea was to separate API from Implementation. > Is that no longer the objective? > I can definitely see this point but whether you use a factory method org.osgi.converter.ConverterFactory.standardConverter() or new org.osgi.converter.StandardConverter() you would still have to replace one class in the API. You can avoid this by using the ServiceLoader or by using OSGi Services but in this case the feedback received was that just doing 'new StandardConverter()' is nice and simple. There are other places in the OSGi specs where this is done this way too, the Deferred class in the Promises API is an example [1] [2]. > Or, if things start to get messy, OSGi only? Why the sudden desire to take > a turn away from OSGi? > We're not turning away from OSGi at all, but most of the specifications that OSGi defines have some dependencies on other OSGi APIs or the services model. So they don't make much sense without a framework. The converter started out as a service but since it really has no dependency on any other OSGi API and seems to be a very useful thing in general the desire was to make it useable in any kind of context. > > Or maybe this project should not even be part of OSGi? > The main benefit of it being part of OSGi is that it is goes through the whole specification process. This means that it will go through the scrutiny of many people, OSGi members and non-members, there will be a Conformance Test Suite and a spec document in the end. This is a valuable thing to do to ensure that it can do what everybody needs, ensure quality and most importantly portability. > > I just find it a bit confusing. Am I missing something? Maybe OSGi is > starting to lose its way?? > > I certainly hope not. I will definitely bring your feedback to the discussion at OSGi, and to be honest, I had similar feedback myself. One of the main goals in OSGi is to have patterns that are common across the API. The Promises API, which also can be used outside of a framework, uses this mechanism to obtain an instance so the thinking is that this API should follow the same pattern. Cheers, David [1] https://osgi.org/javadoc/r6/enterprise/org/osgi/util/promise/Deferred.html [2] https://svn.apache.org/viewvc/aries/trunk/async/promise-api/src/main/java/org/osgi/util/promise/Deferred.java?view=markup
