Details

    • Type: New Feature New Feature
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: 5.2.x
    • Component/s: engine
    • Labels:
      None
    • 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
          Gunnar Morling added a comment -

          The elephant in the room of course is lambda expressions, not sure though how we could benefit from that. In-promptu validations specified via the prog. API might be beneficial in some cases:

          ConstraintMapping mapping = ...;
          mapping.type( Order.class )
              .property( "code", FIELD )
                  .check( (String s) -> s.startsWith("ON" ) );
          
          Show
          Gunnar Morling added a comment - The elephant in the room of course is lambda expressions, not sure though how we could benefit from that. In-promptu validations specified via the prog. API might be beneficial in some cases: ConstraintMapping mapping = ...; mapping.type( Order.class ) .property( "code" , FIELD ) .check( ( String s) -> s.startsWith( "ON" ) );
          Hide
          Hardy Ferentschik added a comment -

          The elephant in the room of course is lambda expressions, not sure though how we could benefit from that

          I think we should focus on your initial list first. These points seems much more relevant for Validator. I don't think we will be able to leverage lambdas for our use.

          Show
          Hardy Ferentschik added a comment - The elephant in the room of course is lambda expressions, not sure though how we could benefit from that I think we should focus on your initial list first. These points seems much more relevant for Validator. I don't think we will be able to leverage lambdas for our use.
          Hide
          Gunnar Morling added a comment - - edited

          When running the build on Java 8, I'm seeing these issues:

          • TypeHelperTest doesn't compile as there is an anonymous implementation of an interface which has a new method in Java 8
          • BeanMetaDataManager runs much slower on my system
          • TCK test ConstraintDefinitionsTest fails; created HV-843 for this
          Show
          Gunnar Morling added a comment - - edited When running the build on Java 8, I'm seeing these issues: TypeHelperTest doesn't compile as there is an anonymous implementation of an interface which has a new method in Java 8 BeanMetaDataManager runs much slower on my system TCK test ConstraintDefinitionsTest fails; created HV-843 for this
          Hide
          Hardy Ferentschik added a comment -

          The big question I am having with implementing Java 8 support is, how we manage it project wise. Do we branch HV into a Java 7 and Java 8 branch ( a pain for bug fixes and other changes relevant for both branches) or can we build and use Java 8 features while still keeping Java 7 compatibly (at least at runtime and if so how do we ensure this?).

          Show
          Hardy Ferentschik added a comment - The big question I am having with implementing Java 8 support is, how we manage it project wise. Do we branch HV into a Java 7 and Java 8 branch ( a pain for bug fixes and other changes relevant for both branches) or can we build and use Java 8 features while still keeping Java 7 compatibly (at least at runtime and if so how do we ensure this?).
          Hide
          Gunnar Morling 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.

          Show
          Gunnar Morling 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.
          Hide
          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 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 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 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 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 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 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 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.

            People

            • Votes:
              1 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:

                Development