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)

        Gliffy Diagrams

          Attachments

            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