0

I'm currently working on a game API that is used as a Core dependency in a bunch of my other projects. The issue I'm having is IntelliJ is giving me all sorts warnings because the API's methods/classes/variables need to be public, have a different parameter value, are only used externally, etc. I would like to simply annotate these fields with @API instead of going through and adding @SupressWarning({(10 different checks)}) every time I add something to the API. I don't want to disable these checks entirely as they can be a helpful reminder, but I can't seem to figure out how to suppress a warning type for an @interface. There is an option for this with the unused warning where you "suppress for methods annotated by ...", but I can't find anything for the other warnings that pop up as a result of the implementation being situationally incorrect because the IDE can't see how it's being used in the other projects.

I tried annotating my API class with the @SuppressWarnings hoping that the annotated members would inherit it 

@SuppressWarnings({"WeakerAccess", "unused", "SameParameterValue", ...})
public @interface API{}

but that didn't work, and I've looked for ways to add my other projects as "downstream projects" but I haven't found anything yet. Is this even possible or is it just a limitation of IntelliJ?

Thanks in advance!

Josh Kugath
  • 1
  • Try `@SuppressWarnings("ALL")` or define a custom scope for your API classes and disable all the inspections for this scope in the profile. – CrazyCoder Apr 26 '17 at 01:41
  • Unfortunately pretty much every class has API methods in it, as the entire project is an API, and like I said, I would still like to have the checks so I don't want to just suppress everything. I could migrate the methods all into one class and then reference them from other locations, but that seems excessive to me. Maybe there's an @interface in java that already has this functionality? – Josh Kugath Apr 26 '17 at 14:42
  • IntelliJ IDEA 2017.2 will have some improvements in this regard, for instance, entry points will not be analyzed for unused/visibility/same return value. Keeping API in a separate package seems to be a good solution, or keeping implementation classes in `impl` subdirectories and using the inspection scope to analyze only classes in `impl`. – CrazyCoder Apr 26 '17 at 14:52
  • Thanks for the advice. For now I ended up just adding all of the methods as entry points, going through each warning to make sure they were all correct, and right clicking each section from the "analyze code" and batch adding the suppress warnings. It shouldn't be too much of a hassle if I do this before I push each major update, but I'm still looking for a simpler/cleaner solution. I took a brief glance over the the 2017.2 update summary, and it looks like you're right, hopefully it will be solved soon. – Josh Kugath Apr 26 '17 at 18:00
  • I honestly think the best solution would be a way to link the other projects to it. That way you could still have all of the checks work and you wouldn't have to label anything as being an API. Normally I would just add them as a module of the project, but it's a pain with Maven. – Josh Kugath Apr 26 '17 at 18:12
  • Maybe instead of using the API in a separate Jar, I'll just add it as a module to each dependent project. The only problem with that is if one project doesn't use all of the API it will still spit out warnings. – Josh Kugath Apr 26 '17 at 18:16

0 Answers0