felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Schneider <ch...@die-schneider.net>
Subject Re: Some ideas for improvements in resolver
Date Wed, 11 May 2016 14:49:19 GMT
On 11.05.2016 15:45, Thomas Watson wrote:
> I want to keep a copy of the spec source in the project because we will be
> using the project to prototype OSGi R7.  It helps to keep the source in the
> project so we can get the very latest before the final spec is released.
> The felix resolver impl is going to be the RI again so we need the freedom
> to implement the proposed API before the spec is released and available in
> maven.
Having a preview of the spec is a good idea. I would prefer though to 
create this as a snapshot jar in the OSGi alliance and publish
it with the same coordinates as the current spec jar with a version of 
1.2.0-SNAPSHOT or whatever the spec version will be.
> Moving up to Java 6 is fine.  As you may guess I still have a vested
> interest in making sure the source still compiles with Java 6 for some time
> so please don't go beyond that.
Ok. I will create an issue and PR.
> I don't see a big issue with the Util class.  This should be completely
> internal to the implementation.  I do think we should avoid extra classes
> if we can.  I would even consider getting rid of the Util class completely
> and just moving the static methods to the ResolverImpl.  I mean we have
> tons of other static methods, why are some stuck on a Util class and some
> not?
The problem with a generic Util class is that over time it collects 
everything someone wants to share. So I prefer to make the classes a bit 
more focused so the cohesion between the
methods is better. Embedding all methods in the class that calls them is 
fine if the methods are not shared.

I think one advantage of having those targeted util classes compared to 
embedding is that they direct the focus of the e.g. ResolverImpl code to 
its actual core responsibility.
> I'm pretty sure ResolverSession can be static so it should be fine to move
> to a top level class if you want.  But this is all a matter of style.  Some
> like to keep the number top level classes low.  I don't really care one way
> or the other.
I tend to have more classes in the end but this is not a goal for me. I 
mainly try to spread the complexity over method, class and package 
evenly. The goal is that each level is easy to understand and ideally as 
self contained as possible. Currently the ResolverImpl class as well as 
some of its methods are too big to be understood easily.
> I'm more interested in investigating improvements to the Capabilities class
> (I would rename this to Permutation).  Here there was lots of work done by
> Guillaume to significantly reduce the cost of copying the Permutation and
> modifying it.  He added a bunch of special copy on write collections.  I
> would instead like to implement a capability selection collection that
> points to a constant list of capabilities and has an index to the currently
> selected candidate for that permutation.  That way there is no copying of
> the constant list, instead we have a super lightweight collection that
> points to the unmodifiable list of capabilities and just has an index.
> Changing a Permutation would only involve incrementing that index instead
> of removing from a copy on write list.  We can then get rid of duplicate
> capability lists since the list is unmodifiable it can be shared with
> multiple selection index lists.
> I also want to improve the the algorithm to ignore many permutations when
> the sheer number of permutations gets "too high".  Before moving to the
> Felix resolver in Equinox we had an algorithm that detected that number of
> permutations was "too high" and would start treating multiple requirements
> that point to the identical list of matching capabilities as a "single"
> requirement and would permute all the identical candidate lists at the same
> time instead of trying each one individually.  It is possible this would
> remove some valid permutations, but I had never found a real world scenario
> where this approach failed to find a valid solution if one existed.  The
> trick here is to come up with some policy that makes sense to determine the
> number of permutations is getting "too high".
That sounds like a very good improvement. At the moment I try to stay 
out of functional changes as I have not yet fully understood all of the 
inner workings. I hope that my changes make the current design more 
obvious so I and also other have an easier access to understanding the code.

I also wonder if we can improve the algorithm itself. What do you think 
about offering this for google summmer of code or directly to university 
for a master thesis?


Christian Schneider

Open Source Architect

View raw message