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...
> 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
signature.asc
Description: Message signed with OpenPGP
