Previous versions of Veripacks focused on defining what classes are visible outside of a package hierarchy (exporting). This release focuses on defining what classes can be used inside a package hierarchy (importing).

By default, no imports are required. As long as a class is visible (exported), it can be used. This can be now constrained using the @RequiresImport and @Import annotations.

If a package is annotated with @RequiresImport, exported classes from this package (and any child packages) can only be used if the package is imported using @Import. It is illegal to import a package, which doesn’t require importing. Note that only the package with the annotation can be imported (as a whole), not individual child packages.

As all annotations, the effects of @Import are transitive. That is, if a package (A) is imported in a package (B), its classes are also visible in all child packages (of B).

A simple example, combining the export and import features (which can be used separately as well):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

@RequiresImport
package foo.bar.p1 {
  @Export
  class A { ... }
  class B { ... } 
}
 
@Import("foo.bar.p1")
package foo.bar.p2 {
  class Test1 {
    new A(); // OK, p1 is imported and A is exported
    new B(); // illegal, B is not exported
  }
}
 
package foo.bar.p3 {
  class Test2 {
    new A(); // illegal, p1 is not imported
  }
}

Moreover, Veripacks is now available in Maven Central, so using Veripacks just got easier: no need to add a repository to your build definition. See the README for details.

As always the whole code is available on GitHub: https://github.com/adamw/veripacks.

Have fun!

Adam