Hibernate Validator
  1. Hibernate Validator
  2. HV-644

Use Jandex for annotation discovery and repository

    Details

    • Type: New Feature New Feature
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: 5.x
    • Component/s: engine
    • Labels:
      None
    • Last commented by a user?:
      true

      Description

      Creating this issue as we spoke about the possibility to use Jandex a few times, so we have a one place for discussions.

      Pro:

      • Fast meta-data retrieval when using pre-existing index

      Con:

      • Additional dependency
      • Not so good documented

      Implementation-wise it would make sense to implement this in form of another MetaDataProvider.

      We could also make meta data providers more pluggable, so we don't have a strict dependeny to this. The Jandex provider would then be plugged in under AS while in other scenarios the normal annotation-based provider would be used.

        Activity

        Hide
        Hardy Ferentschik added a comment -

        For me definitely a post 5.0 thing. Generally I like the idea. Given that we use it in ORM and have gained some experience missing documentation should be no issue. Still not sure whether we want this additional dependency. Also how much do we really gain?

        Show
        Hardy Ferentschik added a comment - For me definitely a post 5.0 thing. Generally I like the idea. Given that we use it in ORM and have gained some experience missing documentation should be no issue. Still not sure whether we want this additional dependency. Also how much do we really gain?
        Hide
        Gunnar Morling added a comment -

        For me definitely a post 5.0 thing.

        For me, too. I mainly added this as hub for our discussions around this.

        Still not sure whether we want this additional dependency.

        I think we could make this optional. If meta data providers were pluggable (e.g. using java.util.ServiceLoader), the engine would just use those providers available. And only if the Jandex provider is around it would be used (and that module would have a dependency to the Jandex lib).

        Also how much do we really gain?

        I think it would only be worth if we could reuse the existing index from the container. In that case it should help performance-wise.

        Show
        Gunnar Morling added a comment - For me definitely a post 5.0 thing. For me, too. I mainly added this as hub for our discussions around this. Still not sure whether we want this additional dependency. I think we could make this optional. If meta data providers were pluggable (e.g. using java.util.ServiceLoader ), the engine would just use those providers available. And only if the Jandex provider is around it would be used (and that module would have a dependency to the Jandex lib). Also how much do we really gain? I think it would only be worth if we could reuse the existing index from the container. In that case it should help performance-wise.
        Hide
        Hardy Ferentschik added a comment -

        I think we could make this optional. If meta data providers were pluggable (e.g. using java.util.ServiceLoader), the engine would just use those providers available. And only if the Jandex provider is around it would be used (and that module would have a dependency to the Jandex lib).

        -1 or at least not a big fan of this. then we have to deal with two ways of processing annotations

        I think it would only be worth if we could reuse the existing index from the container. In that case it should help performance-wise.

        Performance is of course one reason. We don't have to rely on the container index either. In standalone mode we could safe the index ourselves and reload it. Performance is of course one thing, but I also like the API of Jandex and the clear separation of annotation discovery and annotation processing. Obviously we already have a good abstraction from the meta data source via MetaDataProvider.

        Show
        Hardy Ferentschik added a comment - I think we could make this optional. If meta data providers were pluggable (e.g. using java.util.ServiceLoader), the engine would just use those providers available. And only if the Jandex provider is around it would be used (and that module would have a dependency to the Jandex lib). -1 or at least not a big fan of this. then we have to deal with two ways of processing annotations I think it would only be worth if we could reuse the existing index from the container. In that case it should help performance-wise. Performance is of course one reason. We don't have to rely on the container index either. In standalone mode we could safe the index ourselves and reload it. Performance is of course one thing, but I also like the API of Jandex and the clear separation of annotation discovery and annotation processing. Obviously we already have a good abstraction from the meta data source via MetaDataProvider .
        Hide
        Gunnar Morling added a comment -

        Ok, but if we don't want to have two ways of annotation prcessing the Jandex dependency would be mandatory which I wouldn't find that good just for the sake of a nicer API. As you say we already have a separation of annotation (or meta data) discovery from processing due to the provider mechanism and the separate model.

        Show
        Gunnar Morling added a comment - Ok, but if we don't want to have two ways of annotation prcessing the Jandex dependency would be mandatory which I wouldn't find that good just for the sake of a nicer API. As you say we already have a separation of annotation (or meta data) discovery from processing due to the provider mechanism and the separate model.

          People

          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:

              Development