celix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pepijn Noltes <pepijnnol...@gmail.com>
Subject [DISCUSS] Celix Roadmap & Future Celix vs OSGi
Date Mon, 08 May 2017 20:13:17 GMT
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

Mime
View raw message