Hi Jan Willem, On Fri, Jun 30, 2017 at 12:30 PM Jan Willem Janssen < [email protected]> wrote:
> Hi, > > Just out of curiosity, what exactly do you envision with the new API? Do > you have some example on this. It makes the discussion perhaps a little > easier to get started on whether or not it is a good way forward... > I agree. I actually added a proposed API (in a single header) to the development branch a few days ago [1]. I have been tweaking and editing this proposal for quite a while and personally think it is very complete. I also think it is a big improvement on the current API. I wasn't sure how to bring this to the mailing list, because - as said - it is a very complete API proposal and as result fairly lengthy. So I was thinking about splitting it up a bit and removing some details, but since you asked ... :). The intro sums up a list of reasons why I think a API / design change is IMO needed and is a good starting point. The proposed header file also introduces some framework services near the end of the file. @all: Please feel free to look into this and comment on the proposal. By mailinglist or with use of pull requests. [1] https://github.com/apache/celix/tree/develop/documents/roadmap/api_v3 > > > On 8 May 2017, at 22:13, Pepijn Noltes <[email protected]> wrote: > > > > Hi All, > > > > I took the liberty to setup a roadmap [1] for Apache Celix based on > > the improvement ideas. This is just an initial setup and should > > considered an input for discussion not a final roadmap. > > > > [1] > https://github.com/apache/celix/blob/develop/documents/roadmap/roadmap.md > > > > > > In this roadmap I also added plans for changing the core API of Apache > > Celix (3.0.0 release). > > > > As most of you probably know, Apache Celix is heavily based on the > > OSGi specification. For Apache Celix we created a mapping between the > > Java API and C variant, and this really helped us getting Apache Celix > > up and running. > > But I also think that the OSGi API (note that OSGi started more than > > 15 years ago) is not really modern nor user friendly. More bluntly it > > is IMO overly complex; It leaks unnecessary details and requires more > > calls then really necessary. > > > > This has become more obvious for me in the last year, because I always > > prefer and refer to use the Apache Celix Dependency Manager instead of > > the ported OSGi API. This is also true when I program with Java > > (Apache Felix Dependency Manager). > > Now I know OSGi is a specification and in a way it would be wise to > > follow this, but honestly I think the Java API really needs an > > overhaul and for native (e.g. no garbage collect) languages I think > > the OSGi API is a mismatch. Changing the API will not only benefit the > > usability, but should also result in a smaller code base ... less > > complex, more maintainable, probably less bugs, etc. > > > > An example: If a service is removed in Apache Celix, it's allocated > > memory is also deallocated or worse reused for a different purpose. In > > my knowledge this is not the case for Java services (the garbage > > collector will keep the service intact even if the bundle is removed). > > Combine this behaviour with the "default" way of getting services > > (bundleContext.getServiceReference(s) -> bundleContext.getService) and > > with no support for locking this is a disaster waiting to happen. Now > > I know there are ways around (service trackers) and these are even the > > preferred way, but this IMO also means that there should be no support > > for getting services through the bundle context, nor should a user > > need to know about service references.This combined with an API with > > could be much cleaner has me leaning in the direction to refactor > > Apache Celix for "easy" use of dynamic services but without using the > > ported OSGi API. > > > > Note that I do not expect that we change Celix this drastically is the > > near future, so this is more to start the discussion where Celix > > should be headed in the future. > > And although I think this is not really possible without being a > > member of the OSGi alliance, maybe working on a more modern Native > > OSGi spec/API? > > > > > > Well that my 2 cents, please feel free to comment ... or agree ;) on > this. > > > > > > Greetings, > > Pepijn > > -- > Met vriendelijke groeten | Kind regards > > Jan Willem Janssen | Software Architect > +31 631 765 814 > > > My world is something with Amdatu and Apache > > Luminis Technologies > John F. Kennedylaan 32 > 7314 PS Apeldoorn > +31 88 586 46 25 > > https://www.luminis.eu > > KvK (CoC) 09 16 28 93 > BTW (VAT) NL8170.94.441.B.01 > >
