Veripacks 0.1 allowed to specify which classes should be exported from a package hierarchy, by using a simple @Export annotation, and later verify that the specification is met. Version 0.2 extends this by allowing to export subpackages as well, using the @ExportSubpackages package annotation.

When exporting a subpackage, only the classes exported by the subpackage will be re-exported (same holds for sub-subpackages). This is in line with Veripacks respecting the hierarchical structure of packages.

(Previously, either all subpackages and all classes where exported – when no @Export annotations were present, or no subpackages were exported, if at least one @Export annotation was present.)

There are also two new convenience package annotations, @ExportAllClasses and @ExportAllSubpackages, which have pretty self-explaining names.

How does this work? An example will illustrate it best, using some imaginary syntax:

package foo.bar.p1.sub_p1 {
   @Export
   class Sub1 { ... }
}

package foo.bar.p1.sub_p2 {
   @Export
   class Sub2 { ... }

   class Sub3 { ... }
}

// Normally the annotation would go to package-info.java
@ExportSubpackages("sub_p1") 
package foo.bar.p1 {
   @Export
   class A { ... 
      // Legal, Sub1 is exported by sub_p1
      new sub_p1.Sub1() 
      // Legal, Sub2 is exported by sub_p2
      new sub_p2.Sub2() 

      // Illegal, Sub3 is not exported by sub_p2
      new sub_p2.Sub3() 
   }
}
  
package foo.bar {
   class B {
      // Legal, A is exported by p1
      new p1.A() 
 
      // Legal, sub_p1 is exported by p1, and Sub1 is exported by sub_p1 
      new p1.sub_p1.Sub1() 
 
      // Illegal, sub_p2 is not exported by p1 
      new p1.sub_p2.Sub2() 
   }
}

How can this be useful? Veripacks goes beyond what can be achieved with normal Java access modifiers (especially public and package-private), by extending the meaning of packages to a hierarchical structure. It also aims to replace, in some cases, the need for separate build modules.

What’s next? As mentioned in the README, the plans are to add a possibility to require an explicit import of a package, to be able to use its classes. And of course, some IDE support to be able to quickly see what is exported and where would be great.

The release is available in SoftwareMill’s maven repository, and the code is available under the Apache2 license on GitHub.

Have fun!
Adam