felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Watson <tjw...@gmail.com>
Subject Re: Some ideas for improvements in resolver
Date Wed, 11 May 2016 13:45:55 GMT
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.

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.

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?

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'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".

Tom

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message