Unit testing the resolver was: Optional service dependencies only

[Paul Sandoz]

On Jun 23, 2012, at 2:00 PM, Jaroslav Tulach wrote:
> Dne Pá 22. června 2012 19:39:27, Paul Sandoz napsal(a):
>> Hi,
>>> If you want to get rid of the NP-Complete problem, remove "requires
>>> service xyz" concept and allow only "requires service optional xyz".
>> As i said i am shoving the NP-Complete problem under the rug for now.
>> Forgive me!
> 
> Paul, are you looking only for comments to your webrev? If so, then I am sorry 
> for taking much larger perspective.

No need to apologize! I think that larger perspective has been quite informative and useful (in addition to also helping find a bug in configuration ordering :-) ).


> I don't want to stop you integrating your 
> change at all.
> 

No problem. Mostly what i am looking for is agreement that service provider module dependencies should be resolved after the "Classpath"  dependences since it is:

- easier to report errors;

- easier for developers to understand; and

- has wider implications to help avoid, in part, NP-Complete problems.

Would you consider the above a fair assessment?


> The more low level comment I can provide: Is there a way to write simple unit 
> test? For example what would be the simplest way to simulate the erroneous 
> resolution described at [1] when the b service provider can't be found easily?
> 

The closest thing in the current tests is the _Configurator.java located in jdk/test/org/openjdk/jigsaw e.g.:

        new Test("diamond", true, "x at 1") {
            void init(MockLibrary mlib) {
                mlib.add(module("x at 1").requires("y at 2").requires("w at 4"))
                    .add(module("y at 2").requires("z@>=3"))
                    .add(module("z at 9"))
                    .add(module("z at 4"))
                    .add(module("z at 3"))
                    .add(module("w at 4").requires("z@<=4"));
            }
            void ref(ConfigurationBuilder cfbd) {
                cfbd.add(context("x at 1").remote("+w", "+y"))
                    .add(context("y at 2").remote("+z"))
                    .add(context("z at 4"))
                    .add(context("w at 4").remote("+z"));
            }
        };

        new Test("diamond-fail", false, "x at 1") {
            void init(MockLibrary mlib) {
                mlib.add(module("x at 1").requires("y at 2").requires("w at 4"))
                    .add(module("y at 2").requires("z@<=3"))
                    .add(module("z at 4"))
                    .add(module("z at 3"))
                    .add(module("z at 9"))
                    .add(module("w at 4").requires("z@>=4"));
            }
        };

It encompasses the process of resolving and linking. IMHO it looks quite reasonable, although i wish we could use TestNG to help out a bit :-) anyway....  the module and configuration builders need to be updated to support services.

It could easily be adapted to perform just resolving and check the resolution result.

Paul.

> -jt
> 
> [1] http://wiki.apidesign.org/wiki/JigsawServices
>