You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, OvalBuilder invokes validation on build() directly resulting in significant performance loss due to reflection.
The first option is to leverage OVal's AspectJ validation using a guard annotation. Theoretically, this could be employed very quickly by disabling automatic validation (e.g. setInvariantsEnabled(false)) and then marking build() with @PreValidateThis. However, whether this works cleanly out of the box is largely unknown.
The more involved alternative would be to write a compile-time weaver much like we did for LogbackSteno's line and method injection. This should not be particularly onerous if we continue to rely on OVal for the annotations and validation logic. This is a more predictable solution but with only a modest amount of work.
The third alternative would be to remove OVal entirely and switch to JSR303 annotations with our own compile-time weaver. This is the most work, although it results in a solution that is entirely decoupled from OVal completely within our control.
The text was updated successfully, but these errors were encountered:
Currently, OvalBuilder invokes validation on build() directly resulting in significant performance loss due to reflection.
The first option is to leverage OVal's AspectJ validation using a guard annotation. Theoretically, this could be employed very quickly by disabling automatic validation (e.g. setInvariantsEnabled(false)) and then marking build() with @PreValidateThis. However, whether this works cleanly out of the box is largely unknown.
The more involved alternative would be to write a compile-time weaver much like we did for LogbackSteno's line and method injection. This should not be particularly onerous if we continue to rely on OVal for the annotations and validation logic. This is a more predictable solution but with only a modest amount of work.
The third alternative would be to remove OVal entirely and switch to JSR303 annotations with our own compile-time weaver. This is the most work, although it results in a solution that is entirely decoupled from OVal completely within our control.
The text was updated successfully, but these errors were encountered: