Class scanning

The core of the Void Framework is based on the scanning of different paths to discover elements to load. 5 types of elements are recognised during the scan:

  • Classes implementing or extending
  • Classes annotated with Bindable familly annotation
  • Classes implementing defined interface
  • Classes annotated with Aspect annotation
  • Interfaces annotated with Proxyable annotation

Guice module

Guice modules that extend the abstract class AbstractModule are automatically detected and loaded when the application starts. Unless the module is explicitly disabled by the voidframework.core.disabledModules configuration.


@Bindable is a specific annotation that allows annotated classes to be considered as candidates for auto-detection during classpath scan. Other class-level specialized annotations can also be considered as identifying a bindable and provide a clearer identification of the purpose of the class.

@ControllerIndicates that an annotated class is a “Controller”
@RepositoryIndicates that an annotated class is a “Repository”
@ServiceIndicates that an annotated class is a “Service”

Defined interface

The configuration key voidframework.core.bindExtraInterfaces is used to define a set of interfaces for which to bind the found implementations. For example, converters are automatically detected in this way via the TypeConverter interface.

Aspect Oriented Programming

Aspect Oriented Programming (AOP) can be used with Void Framework, see chapter “Advanced / Aspect Oriented Programming” section for more information.

Proxyable interface

The @Proxyable annotation indicates that the implementation of the annotated interface is a proxy that will be configured by one of the modules that will be loaded when the application starts. The module can retrieve the interface(s) it is interested in via the ScannedClassesToLoad variable provided in the module constructor.

Bootstrap file generator

Scanning classes can, for several reasons, drastically increase the start-up time of the application. To mitigate this phenomenon, it is possible to use a bootstrap file, generated in advance, containing the useful classes detected during the scan. At compile time, the file resources/classpath.bootstrap will be created.

To activate the generator, simply add the following lines to the pom.xml file.