Uploaded image for project: 'Jadira Framework'
  1. Jadira Framework
  2. JDF-72

Allow usage of JSR-310 user types without backport

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 3.1.0.CR10
    • Fix Version/s: 3.1.0.CR11
    • Component/s: Usertype
    • Labels:
      None

      Description

      I've been caught by surprise that the JSR-310 usertype implementation currently only seems to work with the backported version but not with plain Java 8. It would be cool if that support was added.

        Gliffy Diagrams

          Activity

          Hide
          oliver.gierke Oliver Gierke added a comment -

          That's weird. We have an example project using JDK 8 date time types and it builds fine on a JDK 8 running with Maven compiler settings to JDK 6 compatibility here.

          Show
          oliver.gierke Oliver Gierke added a comment - That's weird. We have an example project using JDK 8 date time types and it builds fine on a JDK 8 running with Maven compiler settings to JDK 6 compatibility here .
          Hide
          chrisphe Chris Pheby added a comment -

          Just took a look at this, but it wasn't clear to me where the compiler is being configured?

          Show
          chrisphe Chris Pheby added a comment - Just took a look at this, but it wasn't clear to me where the compiler is being configured?
          Hide
          oliver.gierke Oliver Gierke added a comment -

          The trick is, there is none. The parent's parent project pom.xml configures Maven to compile to Java 7. However the Java 8 project just compliles fine if you run Maven on a Java 8 JVM (as the types will be visible to the compiler then).

          Show
          oliver.gierke Oliver Gierke added a comment - The trick is, there is none. The parent's parent project pom.xml configures Maven to compile to Java 7. However the Java 8 project just compliles fine if you run Maven on a Java 8 JVM (as the types will be visible to the compiler then).
          Hide
          chrisphe Chris Pheby added a comment -

          Well I experimented with this using the Spring-data examples and after with Usertype.

          1) The trick works if you don't use the toolchains plugin.
          2) If you use toolchains you need to specify something like (from the Usertype-extended pom):

          <plugin>
          <groupId>org.apache.maven.plugins</groupId>
          <artifactId>maven-toolchains-plugin</artifactId>
          <version>1.0</version>
          <executions>
          <execution>
          <phase>validate</phase>
          <goals>
          <goal>toolchain</goal>
          </goals>
          </execution>
          </executions>
          <configuration>
          <toolchains>
          <jdk>
          <version>8.0</version>
          <vendor>oracle</vendor>
          </jdk>
          </toolchains>
          </configuration>
          </plugin>
          <plugin>
          <groupId>org.apache.maven.plugins</groupId>
          <artifactId>maven-compiler-plugin</artifactId>
          <version>3.1</version>
          <configuration>
          <verbose>true</verbose>
          <fork>true</fork>
          <source>1.8</source>
          <target>1.8</target>
          <compilerArgument>-g</compilerArgument>
          <encoding>$

          {project.build.sourceEncoding}</encoding>
          <charset>${project.build.sourceEncoding}

          </charset>
          <debug>true</debug>
          <optimize>true</optimize>
          <showDeprecations>true</showDeprecations>
          </configuration>
          </plugin>

          <!-- Process our byte codes to make them run on Java 7 -->
          <plugin>
          <groupId>org.apache.maven.plugins</groupId>
          <artifactId>maven-dependency-plugin</artifactId>
          <version>2.8</version>
          <executions>
          <execution>
          <id>copy-retrolambda</id>
          <phase>process-classes</phase>
          <goals>
          <goal>copy</goal>
          </goals>
          <configuration>
          <artifactItems>
          <artifactItem>
          <groupId>net.orfjackal.retrolambda</groupId>
          <artifactId>retrolambda</artifactId>
          <version>1.1.2</version>
          <overWrite>true</overWrite>
          <outputDirectory>$

          {project.build.directory}

          </outputDirectory>
          <destFileName>retrolambda.jar</destFileName>
          </artifactItem>
          </artifactItems>
          </configuration>
          </execution>
          </executions>
          </plugin>

          Why is this necessary. I don't know, but I prefer the toolchains approach because it contributes to a repeatable build. Still, its very interesting that the other approach works. I didn't dig into toolchains plugin to find out why the behaviour differs.

          Show
          chrisphe Chris Pheby added a comment - Well I experimented with this using the Spring-data examples and after with Usertype. 1) The trick works if you don't use the toolchains plugin. 2) If you use toolchains you need to specify something like (from the Usertype-extended pom): <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-toolchains-plugin</artifactId> <version>1.0</version> <executions> <execution> <phase>validate</phase> <goals> <goal>toolchain</goal> </goals> </execution> </executions> <configuration> <toolchains> <jdk> <version>8.0</version> <vendor>oracle</vendor> </jdk> </toolchains> </configuration> </plugin> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-compiler-plugin</artifactId> <version>3.1</version> <configuration> <verbose>true</verbose> <fork>true</fork> <source>1.8</source> <target>1.8</target> <compilerArgument>-g</compilerArgument> <encoding>$ {project.build.sourceEncoding}</encoding> <charset>${project.build.sourceEncoding} </charset> <debug>true</debug> <optimize>true</optimize> <showDeprecations>true</showDeprecations> </configuration> </plugin> <!-- Process our byte codes to make them run on Java 7 --> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-dependency-plugin</artifactId> <version>2.8</version> <executions> <execution> <id>copy-retrolambda</id> <phase>process-classes</phase> <goals> <goal>copy</goal> </goals> <configuration> <artifactItems> <artifactItem> <groupId>net.orfjackal.retrolambda</groupId> <artifactId>retrolambda</artifactId> <version>1.1.2</version> <overWrite>true</overWrite> <outputDirectory>$ {project.build.directory} </outputDirectory> <destFileName>retrolambda.jar</destFileName> </artifactItem> </artifactItems> </configuration> </execution> </executions> </plugin> Why is this necessary. I don't know, but I prefer the toolchains approach because it contributes to a repeatable build. Still, its very interesting that the other approach works. I didn't dig into toolchains plugin to find out why the behaviour differs.
          Hide
          chrisphe Chris Pheby added a comment -

          Next Candidate release should be syncing to Maven central so you can use this... let me know if you find any further issue.

          I will at some point update this to use JDBC 4.2 setObject() but this will come later, I think it is useful to stay with the older APIs until drivers are updated.

          Show
          chrisphe Chris Pheby added a comment - Next Candidate release should be syncing to Maven central so you can use this... let me know if you find any further issue. I will at some point update this to use JDBC 4.2 setObject() but this will come later, I think it is useful to stay with the older APIs until drivers are updated.

            People

            • Assignee:
              chrisphe Chris Pheby
              Reporter:
              oliver.gierke Oliver Gierke
            • Votes:
              1 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: