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
