Adam Warski

12 Mar 2013

Veripacks 0.3: importing packages (transitively, of course)


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):

package {
  class A { ... }
  class B { ... } 

package {
  class Test1 {
    new A(); // OK, p1 is imported and A is exported
    new B(); // illegal, B is not exported

package {
  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:

Have fun!


comments powered by Disqus

Any questions?

Can’t find the answer you’re looking for?