support method and constructor parameter annotations

[codecholeric]

This will extend the domain model of ArchUnit by providing

• List<Parameter> JavaCodeUnit.getParameters()
• List<List<JavaAnnotation<Parameter>> JavaCodeUnit.getParameterAnnotations()

where Parameter also offers getParameterType(), getRawParameterType() and getAnnotations().

Furthermore parameter annotations are now part of JavaClass.directDependencies{From/To}Self.

On the contrary to the Java Reflection API the JavaCodeUnit.getParameters() will exactly mirror the (possibly generic) signature and not the raw types. This means that for generic signatures synthetic raw type parameter types (like name and ordinal for an enum constructor) will not be visible in the List<Parameter>. I think for ArchUnit this makes sense, as there is limited interest in synthetic parts of the code and users are only interested in the parameters that have really been introduced by source code. Unfortunately there are many cases where the bytecode does not contain the signature attribute (whenever the signature is non-generic, i.e. does not contain any parameterized types, type variables, etc.). In these cases the parameters will still mirror the raw types (including possible synthetic parameters), because there is no other source of information where the parameters could be derived from. It is also not i.g. possible to derive which parameters are synthetic and which are not, so ArchUnit does not attempt this at all at the moment.

Resolves: #404
Resolves: #373
Resolves: #113

[hankem]

I haven't read through ClassFileImporterAnnotationsTest and the last commit yet, but I thought that I'd definitely agree with your fixup! commits (both their content, and your intention to fixup!) until I read about your example

class Outer {
  private class InnerWithoutGenerics {
    InnerWithoutGenerics(Object param) {
      // will have 2 Parameters (first synthetic)
    }
    
    InnerWithGenerics(List<String> param) {
      // will have 1 Parameter
    }
  }
}

It's unfortunately too late for me to give a good statement on that.

[codecholeric]

@hankem thanks for the extensive review! 😄 Too bad that these synthetic parameters cause such a hassle. The only comfort is, that there is a vast amount of benevolent signatures out there where it doesn't make a difference 🤷‍♂️ (namely all method signatures AFAIS and all non-inner/non-enum constructors. And for enums it looks at least like the compiler always adds the signature, but that might just be my version 🤷‍♂️)
I wish there would be a compiler option like -parameters that could be added to always include the signature. Then users could decide to encode this additional information and every JavaCodeUnit would simply have the correct parameters parsed from the signature. (And I don't think this additional signature really makes a big difference in all typical modern scenarios, where the size of the class files is no real issue) But I couldn't find any such option 😞

[hankem]

Yes, you're right; I also figured that the annoying inconsistency might effectively not hurt so much as it's limited to inner class constructors and enums. (Even a compiler option wouldn't save you entirely, as the annoying byte code might be in a library you can't compile yourself.)

[hankem]

@codecholeric , if you want to reuse the PR description for the release notes, you may want to add a tiny disclaimer to this:

contrary to the Java Reflection API the JavaCodeUnit.getParameters() will exactly mirror the (possibly generic) signature and not the raw types

(Maybe replace exactly with usually?)