Bug 41606

Created attachment 14638 [details]
implementation

I'm asking for Fast Track Review. See attached diff. It contains also
unit test and documentation update.

I also measured impact of this change on performance. My testcase in
all measurements was: start IDE with clean userdir; open nb_all\ant
project; wait till all parserDBs are created; close IDE. I repeated
measurement at least twice. Here are results:
* there is no difference in the total amount of time spent in
MetaInfServicesLookup.search() method after this change. That is, no
regression.
* if ProjectClassPathProvider registered in java/project module has
position=1 then there is significant improvement. The
ClassPath.getClassPath() method is called about 5600 times and time
spent in this method drops from 8200ms to 5300ms.

MISL.insertItem looks clumsy; consider using a TreeSet and comparator
instead.

Need spec: are you allowed to position multiple impls in one file? E.g.

---%<--- META-INF/services/org.foo.Foo
org.bar.FooImpl1
org.bar.FooImpl2
#position=69
---%<---

What is the significance of the positioning of
ProjectClassPathProvider? Was it appearing after something slower? I
know apisupport/project installs global impls of some things (as a
provisional workaround for build products of a module going into
nbbuild) which should go after the generic multiplexing impls.

I was considering TreeSet, but it seems to me that current impl should
be better - most of the items are not sorted and so I add them to the
end and sort only the few which has position attr.

Re. Need spec: yes, that must be documented and it is allowed - each
item can be followed by its (optional) position attr.

Re. position of ProjectClassPathProvider: I'm adding Tomas on CC. I
think it was him or you who suggested that having PCPP first in the
lookup should improve performance because most of the time you are
asking for classpath of a project source. I think Tomas said that
usually the platform/library provider is asked first what makes it
slower because it is useless call. It was just an experiment to prove
that my impl works and that it has the benefit.

So I guess this is good to go tomorrow (Friday)?

Fixed. Tomas, please update J2SE Project registrations.

Implemented in:
Checking in openide-spec-vers.properties;
new revision: 1.142; previous revision: 1.141
Checking in api/doc/changes/apichanges.xml;
new revision: 1.198; previous revision: 1.197
Checking in api/doc/org/openide/doc-files/services-api.html;
new revision: 1.35; previous revision: 1.34
Checking in src/org/openide/util/lookup/MetaInfServicesLookup.java;
new revision: 1.7; previous revision: 1.6
Checking in test/unit/src/org/openide/util/MetaInfServicesLookupTest.java;
new revision: 1.7; previous revision: 1.6
Checking in
test/unit/src/org/openide/util/data/services-jar-1/META-INF/services/java.util.Comparator;
initial revision: 1.1
Checking in
test/unit/src/org/openide/util/data/services-jar-1/META-INF/services/java.util.Iterator;
initial revision: 1.1
Checking in
test/unit/src/org/openide/util/data/services-jar-1/org/foo/impl/Comparator1.java;
initial revision: 1.1
Checking in
test/unit/src/org/openide/util/data/services-jar-1/org/foo/impl/Iterator1.java;
initial revision: 1.1
Checking in
test/unit/src/org/openide/util/data/services-jar-2/META-INF/services/java.util.Comparator;
initial revision: 1.1
Checking in
test/unit/src/org/openide/util/data/services-jar-2/META-INF/services/java.util.Iterator;
initial revision: 1.1
Checking in
test/unit/src/org/openide/util/data/services-jar-2/org/bar/Comparator2.java;
initial revision: 1.1
Checking in
test/unit/src/org/openide/util/data/services-jar-2/org/bar/Iterator2.java;
initial revision: 1.1

.

Suggest for our queries: we use 100 as a standard position for the
simple impl in the project lookup. Probably no need to put any impls
below 100. j2seplatform can put its lib/platform impl at e.g. 150. I
will temporarily put apisupport/project's "unprojectized" stuff at 200
(though I think I know how to delete this stuff entirely later).