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
