celix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pepijn Noltes <pepijnnol...@gmail.com>
Subject Re: [DISCUSS] Celix Roadmap & Future Celix vs OSGi
Date Fri, 30 Jun 2017 14:38:05 GMT
Hi Jan Willem,

On Fri, Jun 30, 2017 at 12:30 PM Jan Willem Janssen <
janwillem.janssen@luminis.eu> 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 <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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message