Add component type to dependencies to self

[codecholeric]

This is the reverse side of #428, i.e. it adds the component type of arrays to JavaClass.dependenciesToSelf. In other words it for the following example

class Target {}

class DependsOnComponentType {
    Target[] fieldDependency;
}

we will now see the dependency DependsOnComponentType -> Target for target.getDependenciesToSelf().

On the way I figured that the dependency resolution process, and in particular the reverse dependency resolution process, is meanwhile pretty convoluted. I have thus simplified this and at least on my machine increased the speed for the reverse dependency lookup by a factor 7 for ClassFileImporterSlowTest.importsClasspath().
In the end I figured that the process of adding new types of dependencies is pretty tedious, because we first add the "dependencies from self", then in a completely parallel process we add the "dependencies to self". With the refactoring now we will simply reuse the "dependencies from self" to create the "dependencies to self", thus making it a lot easier in the future to add both directions in one shot.

Issue: #257

[hankem]

I cannot claim (at all) that I had understood how all the AccessContext, TopProcess, CompletionProcess, MemberDependenciesByTarget worked before... 🙈
... but I definitely agree that the new concept of ReverseDependencies is much simpler! 👍
It would take me much more time to understand everything in detail, but IMO the Christmas release shouldn't be blocked by that.

Regarding the speedup: You were only looking at the reverse dependency lookup, right? (What did you measure exactly?)
For the entire import (or even execution) of the ClassFileImporterSlowTest, I didn't see a significant difference, nor for the class file import in some larger project.

[hankem]

I was initially wondering whether we could save some iterations by breaking the loop once we know that there are multiple matches:

Suggested change

	}
	if (matching.size() > 1) {
	break;
	}
	}

But it seems that there usually aren't that many matches anyways?

[codecholeric]

Yeah, this only occurs, if a method has been overridden several times in the hierarchy. E.g. if you have

class Base {
  void foo() {
    // some impl
  }
}

class Child extends Base {
  @Override
  void foo() {
    // also some impl
  }
}

class GrandChild extends Child {
  // not overridden here, otherwise it would be directly found
}

And then by accident you pick Base.foo() as the first candidate to find the target of a call to GrandChild.foo(). I'll still look into it 👍 (unfortunately the whole "start with any method in the hierarchy is pretty sub-optimal" 😞)

[codecholeric]

Hmm, I think I'll leave it out for now. I could not find any noticeable difference in performance. And the problem is, that the benefit is not completely clear for me. We are exchanging a couple of unnecessary loops in a rare case against an operation we have to execute in every single loop. Take the extreme case that we for example have no single method that has been overridden multiple times in the whole set of imported classes, then we would actually even perform worse than if we don't do the check.

[hankem]

I absolutely agree.
When I initially thought about it, I hadn't realized what containsExactlyOneMatch is actually used for...

[hankem]

According to the test coverage, this can – as well as getInstanceofChecksWithTypeOfSelf – just be simplified to:

return Collections.emptySet();

Maybe we should have some tests for those new methods...? 😜

[codecholeric]

Ah yes, now I remember that I wanted to add some additional test 🙈 In particular, because for the final state this method is not used anymore to create the reverse dependencies 😉

[codecholeric]

Okay, I added tests for the two new public API methods 😃

[codecholeric]

Thanks a lot for looking into it!! Yes, this is probably one of the most complicated parts 😉 If you understand the code after better than before, I would say mission accomplished 😂 I mean, there is IMHO a really good test coverage, so I'm not too scared that I have destroyed anything fundamental with this refactoring. But there can always be some subtle corner cases I've overlooked.

Regarding performance, yes, the dependency and reverse dependency creation is a lazy process. So what I did to measure the difference is to add the following to ClassFileImporterSlowTest.imports_the_classpath()

for (JavaClass clazz : classes) {
    clazz.getDirectDependenciesToSelf();
}

If you don't do anything like that, then all the changed code is not executed anyway 😉