Details

    • Type: New Feature
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 5.2.0.Alpha1
    • Component/s: engine
    • Labels:
    • Last commented by a user?:
      true

      Description

      Creating this issue as hub for discussions around usage of Java 8 constructs in HV. The following possibilities come to my mind:

      • Retrieve parameter names via reflection to report parameter constraint violations (JEP #118)
      • Make @List constraints usable with facility for specifying the same annotation more than once (JEP #120)
      • Use method references to refer to properties in programmatic config API
      • Integrate engine and AP code base by using reflection-based implementation of the model API (JEP #119) (not part of Java 8)
      • Support new date/time datatypes (JEP #150, JSR 310)
      • Integrate with Optional, JavaFX types
      • Use type annotations to support List<@Email String> mails (JEP #104)

        Issue Links

          Activity

          Hide
          hardy.ferentschik Hardy Ferentschik added a comment -

          Yes, that'll be one of the challenges. It will be easier for some features (e.g. the parameter name provider) than for others (e.g. type annotations). For the latter I can't really see a good way how it could be done without a branch, but maybe someone has an idea for this.

          We could start for sure with the simpler ones and see how it goes. Once we hit a wall and have not yet any better idea, we can create a branch.

          Show
          hardy.ferentschik Hardy Ferentschik added a comment - Yes, that'll be one of the challenges. It will be easier for some features (e.g. the parameter name provider) than for others (e.g. type annotations). For the latter I can't really see a good way how it could be done without a branch, but maybe someone has an idea for this. We could start for sure with the simpler ones and see how it goes. Once we hit a wall and have not yet any better idea, we can create a branch.
          Hide
          hardy.ferentschik Hardy Ferentschik added a comment -

          Here is an idea which might work for the annotation processing for example. We already have a notion of MetaDataProvider and BeanConfiguration. If we support collection/iterable constraints in this abstraction we could then extract two (Maven) modules, something like a Java7AnnotationMetaDataProvider and Java8AnnotationMetaDataProvider. We could then maybe load the right provider depending on the Java runtime.

          Show
          hardy.ferentschik Hardy Ferentschik added a comment - Here is an idea which might work for the annotation processing for example. We already have a notion of MetaDataProvider and BeanConfiguration . If we support collection/iterable constraints in this abstraction we could then extract two (Maven) modules, something like a Java7AnnotationMetaDataProvider and Java8AnnotationMetaDataProvider . We could then maybe load the right provider depending on the Java runtime.
          Hide
          gunnar.morling Gunnar Morling added a comment -

          This sounds like a very good idea and probably should be the starting point. The meta model would have to be updated as well to express the constraints applying to the elements of a collection. I think this extension could be done in a non-breaking compatible manner, only the Java 8 based provider would "populate" the new model elements though based on Java 8 type annotations, while the Java 7 based provider simply never would discover any collection element constraints.

          Show
          gunnar.morling Gunnar Morling added a comment - This sounds like a very good idea and probably should be the starting point. The meta model would have to be updated as well to express the constraints applying to the elements of a collection. I think this extension could be done in a non-breaking compatible manner, only the Java 8 based provider would "populate" the new model elements though based on Java 8 type annotations, while the Java 7 based provider simply never would discover any collection element constraints.
          Hide
          hardy.ferentschik Hardy Ferentschik added a comment -

          This sounds like a very good idea and probably should be the starting point.

          Cool. I guess a plan is forming.

          The meta model would have to be updated as well to express the constraints applying to the elements of a collection.

          Sure

          I think this extension could be done in a non-breaking compatible manner, only the Java 8 based provider would "populate" the new model elements though based on Java 8 type annotations, while the Java 7 based provider simply never would discover any collection element constraints.

          Right, that was my thinking as well.

          Show
          hardy.ferentschik Hardy Ferentschik added a comment - This sounds like a very good idea and probably should be the starting point. Cool. I guess a plan is forming. The meta model would have to be updated as well to express the constraints applying to the elements of a collection. Sure I think this extension could be done in a non-breaking compatible manner, only the Java 8 based provider would "populate" the new model elements though based on Java 8 type annotations, while the Java 7 based provider simply never would discover any collection element constraints. Right, that was my thinking as well.
          Hide
          hardy.ferentschik Hardy Ferentschik added a comment -

          All sub tasks completed

          Show
          hardy.ferentschik Hardy Ferentschik added a comment - All sub tasks completed

            People

            • Votes:
              3 Vote for this issue
              Watchers:
              7 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development