Ok then. I pushed the quick hack with the bridge to awt.

I support @Braunch here and would vote for an exception for java.awt.geom.
Reasoning:

• The PdfAnnotationImporterImpl class analyzes pdf files and thus is correctly placed in the logic package (its the same as BibParser which analyzes bib files)
• awt.geom has no gui code but is a model class in our terminology (the only reference to gui is that the represented objects have a geometric interpretation)
• If the same code would be placed in a package with a different name, then there wouldn't be any problem... but names are no more than smoke and mirrors.
• The hack/workaround 31d975b is quite ugly. In the end, the code still depends on awt.geom, just that the dependency is indirect and thus our tests are not able to detect it.
• We will have the same problem with the JavaFX ObservableLists which provide a convenient implementation of the list interface (firing events upon update). But they are placed in javafx.collections and thus would not be allowed in logic (if we decide to ban javafx as we did with swing/awt.)

I would follow the argumentation by @tobiasdiez. As he says names are just hollow words. Add an exception for awt.geom. I took a quick look at the package api doc and it seems like it contains not any logic for drawing, but just proving a model

So we decided in the devcall that we will create an exception for the awt.geom package. So please modify the code of ArchitectureTests to exclude the package and I will have a look to see if I like the way in which you implemented it ;-)

Ok I will change that back and add the exception.

I added an exceptionStrings map that uses the first package as a key and a list of exceptions as value. When checking the imported packages I then filter for packages, that have the first package as key and are imported there. If they are exceptions, they are not added to the list of files. Adding more exceptions is easy. Just add them to the list in the map that belongs to the corresponding key.

Ok, the test works. In my honest opinion that is a good example that lambdas are hard to understand when they get big. So, could you perhaps just refactor the test a little bit to make it more easily understandable?

What I am thinking about is extracting the boolean parts of the lambda into predicates that you define at the start of the method and then just reusing that, i.e.:

Predicate<String> isExceptionPackage = (s) -> (exceptionStrings.get(firstPackage).stream()
                                .filter(exception -> s.startsWith("import " + exception)).findAny().isPresent()
                        );

and then you can call

...
 !(isExceptionPackage.test(s))
...

Please add and use this predicate and build at least one more nicely named one for another boolean condition. Then the lambda will be much more readable and I promise that I will be happy :-)

P.S.: The localization tests fail, so this needs to be fixed before merging as well.

That is a good idea. The filters are getting unreadable. But I think I have to rewrite the predicate a bit different, because the predicates are the parameters for the filter and the one you wrote is just one condition for the predicate of another filter so a boolean is expected. I put the whole predicate in it (still a big filter but already way better to read) and extract the isPackage predicate from the filter above too.

I just had a look at the ArchitectureTests and am happy with them. So, from my side this is good to go. Someone else should double check the main functionality, though.

Is this PR ready for review? (I saw a few "TODO" statements in the code, so I suspect it is not yet finished.)

No its not ready. I dint try the open pdf on an other setup than linux/acroread
So this is TODO.

@Braunch Any news? Any timeline?

The code is moved over to #2545 and this can be closed.