Skip to content
Fabian Depry edited this page Nov 9, 2018 · 1 revision

Transitioning from version 1.x to version 2.x

Version 2.0 came with API breaking changes (many of them). This page describes what needs to be fixed and how to fix it.

Validation engine is not static anymore

The biggest change is the ValidationEngine class not being a static class anymore. For most applications, it means every call to ValdiationEngine.something() needs to be replaced by ValidationEngine.getInstance().something().

Having a non-static engine will allow some applications to use multiple engines concurrently, or to use an engine in the scope of a single class or method (like in a unit test for example) and throw away the entire engine instance after that. But that is an advance technique and for most applications, using the static instance provided on the engine itself should be enough.

Validation engine initialization

Another change for the engine is that the old engine used to have a few static methods to change the initialization behavior (for example to set the number of threads to use to compile the rules). Those methods have been replaced by an optional InitializationOptions object that can be provided when calling the engine's initialize method.

Class name changes

The following classes got renamed:

  • XmlValidatorFactory -> ValidationXmlUtils
  • ValdiatorServices -> ValidationServices
  • ValidatorContextFunctions -> ValidationContextFunctions
  • ValidatorLookup -> ValidationLookup (package changed)
  • ValidatorLookupItem -> ValidationLookupItem (package changed)
  • ValidationEngineStats -> EngineStats
  • ValidationEngineInitializationStats -> InitializationStats
  • EditCodeVisitorSupport -> EditCodeVisitor (package changed)

Make sure that you are not accessing any class under com.imsweb.validation.internal package; those are not meant to be exposed and once the library is fully switched to Java modules, that package won't be accessible anymore.

Pre-compiled edits

The mechanism to find pre-compiled edits has been updated. The old mechanism was looking for a class named after a given Validator instance, in a very specific package. That forced multiple translated edits (maintained in different project) to use the same package. That requirement will start causing some issues with the new Java modules, and so it is now possible to register the runtime class along with the validator objects. The old mechanism is still working until all translated edits have been switched to the new one. This is an advanced mechanism and should not affect anybody.