celix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Willem Janssen <janwillem.jans...@luminis.eu>
Subject Re: [DISCUSS] Celix Roadmap & Future Celix vs OSGi
Date Fri, 30 Jun 2017 10:30:15 GMT
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 <pepijnnoltes@gmail.com> 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


Mime
View raw message