1

Is there a maven plugin that makes mvn verify of an aggregating project fail when its submodules or their transitive dependencies depend on things they oughtn't.

I'd like to be able to restrict uses of public APIs to express policies like

  1. Only classes or packages on a whitelist can invoke this public constructor/method.
  2. This public setter that was produced by a code generator should not be called -- it should really have been package-private.

Motivation & Caveats

I realize that there are ways to work around these requirements using reflection and deserialization. My end goal is to allow system-architects & tech-leads to set a policy like

  1. All uses of security-critical APIs should be in modules reviewed by security. Contact them if you need the whitelist expanded.
  2. These deprecated APIs are banned in favor of new ones. There's a whitelist for grandfathered code which should shrink over time.

The system architect treats trusts application developers but we want naive policy violations flagged with useful error messages, and we want developers who hack around the policy to not be able to plausibly deny that they did so.

Tricks like reflection and deserialization fall into that not-plausibly-deniable hacking.

This is kind of like some of the aims of Jigsaw, where a module (group of packages) can declare that its public interface is limited to just some packages, but jigsaw isn't widely available.

This question differs from "Make Java methods visible to only specific classes" because I'm not asking about ways to do this from within the Java language.

Community
  • 1
  • 1
Mike Samuel
  • 118,113
  • 30
  • 216
  • 245
  • 1
    Isn't that what code reviews and `Gerrit are for? – Shark Feb 04 '16 at 14:18
  • 1
    @Shark, On large projects, teams need to specialize. Security specialists need to work to make sure that security properties hold, designers need to work on the design, db admins need to make sure that the database is used in an efficient manner, and app devs need to make sure that the business logic is implemented properly. If every change that an application developer made had to be reviewed by every kind of specialist, development would grind to a halt. And application developers shouldn't have to be expert in all specialties before they can do a review of another app dev's work. – Mike Samuel Feb 04 '16 at 15:02
  • Much agreed, that's usually why team leads end up not coding at all and only managing their team and delegating tasks to proper people/underlings/teammates :/ But that's always the cost of following policies, isn't it. – Shark Feb 04 '16 at 15:07
  • @Shark, Yeah. There's an O(n²) problem when every team member needs to deal with every other. If a team lead can write a little bit of code that checks a policy and uses error messages to point individual contributors at the people who know how to approve exceptions to rules or explain how to work within the rules, then everyone doesn't need to be in everyone else's business, the team escapes the O(n²) problem, and can scale up to larger projects. – Mike Samuel Feb 04 '16 at 15:17
  • Very true; i mean i like the idea. Hence the upvote. But am not aware of any "simple solution" that works "out-of-the-box". If a script can do it, which can be evoked at build-time, that'd be great. I'd like to hear about and download one for sure :) So far, it sounds like a Gerrit/Jenkins combo. – Shark Feb 04 '16 at 15:19
  • @Shark, cool. Thanks for taking the time to think about it. – Mike Samuel Feb 04 '16 at 15:55

1 Answers1

3

You can use checkstyle to perform such checks, for your use case you could use import control:

It seems that this doesn't support fully-qualified imports, based on following answers:

Checkstyle rule to limit interactions between root packages (with ImportControl?)

How to prevent fully qualified names in Java code

As the second answer suggest you could work around that by forbidding fully qualified imports by using another tool - PMD.

As for JSPs, these are usually compiled in the servlet container, nevertheless there is a way to pre-compile these as well, using maven plugin.

Community
  • 1
  • 1
František Hartman
  • 14,436
  • 2
  • 40
  • 60
  • Thanks for the pointer. That looks great. Do you know whether *import control* look beyond literal `import ...;` declarations at uses of fully-qualified class names, and at uses of classes in generated code like Java sources generated from JSP files? – Mike Samuel Feb 04 '16 at 15:04
  • 1
    There are other SO answers that suggest that fully-qualified class names are not checked - http://stackoverflow.com/questions/16142898/checkstyle-rule-to-limit-interactions-between-root-packages-with-importcontrol JSP are usually compiled in the server, so by default these won't be checked. – František Hartman Feb 04 '16 at 15:12
  • Good point about JSPs. I'd forgotten about JIT compilation for JSPs. That may be one of many reasons Jigsaw has opted for classloader magic. – Mike Samuel Feb 04 '16 at 15:18