package-info should not be reported as dead code

[gehel]

deadcode4j reports that package-info as unused classes. Those should probably be excluded from analysis.

[sebastiankirsch]

What is in those classes?

Is it documentation only? Put it into package.html instead (though I admit that this is a matter of taste).
Annotations? deadcode4j considers common annotations (e.g. Hibernate) already. You can configure deadcode4j to mark classes annotated with a specific type as live or, if they're commonly used, file a PR to consider those as well.

I wouldn't ignore them by default; maybe provide a configuration parameter to ignore them...

[gehel]

In my specific case, those are used to specify JSR305 annotations at package level. Reading the JLS section 7.4.1 leads me to think that there is no valid use case having an actual class in a package-info.java file (a class named package-info would not be valid). But I might be lacking imagination...

I would not want to mark code annotated with JSR305 as live, as this is not the case.

[sebastiankirsch]

Ah, I see (using JSR305).

You're right in that deadcode4j may be misleading since it treats package-info.java files as classes (although I believe the compiler really creates a class for such files); the idea behind that is to determine if such files could be removed as well (no matter if they result in a class file or not). E.g. by applying a script that removes specific annotations (or similar automated file manipulations), one could end up with a leftover package-info.java file that no longer serves any purpose - and deadcode4j tries to identify such "unnecessary" files.

[gehel]

Ok, I see the point. I'm not sure what solution would make sense in that case... Using the JSR305 to tag them as live does not seem right, since "real" classes could also be tagged with JSR305 and be dead. I don't know enough about deadcode4j to propose a solution, I just know enough to see that there is a problem... sorry :)

[sebastiankirsch]

No worries, this is simply a scenario I didn't run into yet, but it is valid by its own right.

One could easily add an option to ignore package-info classes; or adapt the classesToIgnore parameter to accept regular expressions...
Oh, and one could add a routine that ignores JSR305 annotations only for package-info classes!