Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

javax.transaction:javax.transaction-api-1.2 not compatible with Java 6 #2347

Closed
thomseno opened this issue Jan 13, 2015 · 12 comments
Closed
Assignees
Labels
type: documentation A documentation update
Milestone

Comments

@thomseno
Copy link

Updating JPA spring boot project to 1.2.1-RELEASE will cause a java.lang.UnsupportedClassVersionError when running with Java 6:

Caused by: java.lang.UnsupportedClassVersionError: javax/transaction/SystemException : Unsupported major.minor version 51.0
    at java.lang.ClassLoader.defineClass1(Native Method)
    at java.lang.ClassLoader.defineClassCond(ClassLoader.java:637)
    at java.lang.ClassLoader.defineClass(ClassLoader.java:621)
    at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141)
    at java.net.URLClassLoader.defineClass(URLClassLoader.java:283)
    at java.net.URLClassLoader.access$000(URLClassLoader.java:58)
    at java.net.URLClassLoader$1.run(URLClassLoader.java:197)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
    at java.lang.Class.forName0(Native Method)
    at java.lang.Class.forName(Class.java:249)
    at org.jboss.logging.Logger$1.run(Logger.java:2252)
    at java.security.AccessController.doPrivileged(Native Method)
    at org.jboss.logging.Logger.getMessageLogger(Logger.java:2227)
    at org.jboss.logging.Logger.getMessageLogger(Logger.java:2214)
    at org.hibernate.jpa.internal.HEMLogging.messageLogger(HEMLogging.java:45)
    at org.hibernate.jpa.internal.HEMLogging.messageLogger(HEMLogging.java:41)
    at org.hibernate.ejb.HibernatePersistence.<clinit>(HibernatePersistence.java:46)
    at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
    at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
    at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
    at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
    at java.lang.Class.newInstance0(Class.java:357)
    at java.lang.Class.newInstance(Class.java:310)
    at javax.persistence.spi.PersistenceProviderResolverHolder$PersistenceProviderResolverPerClassLoader$CachingPersistenceProviderResolver.getPersistenceProviders(PersistenceProviderResolverHolder.java:177)
    at javax.persistence.spi.PersistenceProviderResolverHolder$PersistenceProviderResolverPerClassLoader.getPersistenceProviders(PersistenceProviderResolverHolder.java:84)
    at javax.persistence.Persistence.getProviders(Persistence.java:69)
    at javax.persistence.Persistence.access$000(Persistence.java:23)
    at javax.persistence.Persistence$1.isLoaded(Persistence.java:109)
    at org.hibernate.validator.internal.engine.resolver.JPATraversableResolver.isReachable(JPATraversableResolver.java:56)
    at org.hibernate.validator.internal.engine.resolver.DefaultTraversableResolver.isReachable(DefaultTraversableResolver.java:137)
    at org.hibernate.validator.internal.engine.resolver.CachingTraversableResolverForSingleValidation.isReachable(CachingTraversableResolverForSingleValidation.java:46)
    at org.hibernate.validator.internal.engine.ValidatorImpl.isReachable(ValidatorImpl.java:1396)
    at org.hibernate.validator.internal.engine.ValidatorImpl.isValidationRequired(ValidatorImpl.java:1381)
    at org.hibernate.validator.internal.engine.ValidatorImpl.validateConstraint(ValidatorImpl.java:542)
    at org.hibernate.validator.internal.engine.ValidatorImpl.validateConstraintsForDefaultGroup(ValidatorImpl.java:487)
    at org.hibernate.validator.internal.engine.ValidatorImpl.validateConstraintsForCurrentGroup(ValidatorImpl.java:451)
    at org.hibernate.validator.internal.engine.ValidatorImpl.validateInContext(ValidatorImpl.java:403)
    at org.hibernate.validator.internal.engine.ValidatorImpl.validate(ValidatorImpl.java:206)
    at org.springframework.validation.beanvalidation.SpringValidatorAdapter.validate(SpringValidatorAdapter.java:92)
    at org.springframework.validation.DataBinder.validate(DataBinder.java:767)
    at org.springframework.boot.bind.PropertiesConfigurationFactory.validate(PropertiesConfigurationFactory.java:284)
    at org.springframework.boot.bind.PropertiesConfigurationFactory.doBindPropertiesToTarget(PropertiesConfigurationFactory.java:253)
    at org.springframework.boot.bind.PropertiesConfigurationFactory.bindPropertiesToTarget(PropertiesConfigurationFactory.java:225)
    at org.springframework.boot.context.properties.ConfigurationPropertiesBindingPostProcessor.postProcessBeforeInitialization(ConfigurationPropertiesBindingPostProcessor.java:296)
    at org.springframework.boot.context.properties.ConfigurationPropertiesBindingPostProcessor.postProcessBeforeInitialization(ConfigurationPropertiesBindingPostProcessor.java:250)
    at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyBeanPostProcessorsBeforeInitialization(AbstractAutowireCapableBeanFactory.java:408)
    at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1558)
    at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:539)
    ... 47 common frames omitted

@snicoll
Copy link
Member

snicoll commented Jan 13, 2015

wonderful 👎 - Thanks for the report!

@snicoll snicoll added this to the 1.2.2 milestone Jan 13, 2015
@snicoll snicoll added type: bug A general bug type: regression A regression from a previous release labels Jan 13, 2015
@philwebb
Copy link
Member

Can you downgrade to JTA 1.1? We aim to keep Spring Boot Java 6 compatible but we have a few third-party libraries like this where, if you want to use them, you will need to upgrade to a later JDK.

@snicoll snicoll added status: waiting-for-feedback We need additional information before we can continue and removed type: bug A general bug type: regression A regression from a previous release labels Jan 14, 2015
@snicoll snicoll removed this from the 1.2.2 milestone Jan 14, 2015
@snicoll
Copy link
Member

snicoll commented Jan 14, 2015

Wait a minute here. Hibernate 4.3 claims to be compatible with Java6 and it uses internally JTA 1.2

Maybe your project had an exclude on org.jboss.spec.javax.transaction:jboss-transaction-api_1.2_spec and it does not apply it anymore?

It's not obvious looking at the JTA spec what JDK it requires but if that does work with the dependency above then something must be wrong in either of those two jars (we use javax.transactio:javax.transaction-api

@thomseno
Copy link
Author

The exclude of org.jboss.spec.javax.transaction:jboss-transaction-api_1.2_spec was introduced in commit cdbc0c7 ... I've just changed the Spring Boot version to 1.2.1-RELEASE in my project. The Java Transaction API 1.2 (javax.transaction:javax.transaction-api) is part of JavaEE 7 and the release notes (http://www.oracle.com/technetwork/java/javaee/documentation/javaee7sdk-readme-1957703.html) say:

Java EE 7 SDK Update 1 distributions require JDK 7 Update 65 or above or JDK 8 Update 20 or above.

My project's pom looks like this:

...
    <parent>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-parent</artifactId>
        <version>1.2.1.RELEASE</version>
    </parent>
    <properties>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
        <project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>

        <java.version>1.6</java.version>
        <tomcat.version>7.0.56</tomcat.version>
        <servlet-api.version>3.0.1</servlet-api.version>

        <maven.build.timestamp.format>yyyy-MM-dd_HH:mm:ss</maven.build.timestamp.format>
        <build.timestamp>${maven.build.timestamp}</build.timestamp>
    </properties>
    <dependencies>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-data-jpa</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-actuator</artifactId>
        </dependency>
...
    </dependencies>
...

@snicoll
Copy link
Member

snicoll commented Jan 14, 2015

That's not my point. My point is that without the exclude, Hibernate brings the JTA 1.2 API anyway so I am not sure to understand what would be the difference with the "regular" JTA 1.2 API.

@thomseno
Copy link
Author

Apparently the difference is that javax.transaction:javax.transaction-api requires at least Java 7 and org.jboss.spec.javax.transaction:jboss-transaction-api_1.2_spec does not 😄. So the "wrong" jar was chosen when "Harmonizing JTA dependencies" cdbc0c7, right? Using the JBoss JTA jar instead of the "regular" JTA jar would solve the problem, correct?

@philwebb
Copy link
Member

What a pain. I prefer using the standard javax.transaction:javax.transaction-api co-ordinates.

@snicoll
Copy link
Member

snicoll commented Jan 14, 2015

What a mess. I don't think we've chosen the wrong coordinates. The JBoss jar is really specific to hibernate.

Not sure how we could fix that though.

@thomseno
Copy link
Author

I understand... the standard jar usually is the better choice... In my case the following workaround will do the trick:

...
    <dependencies>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-data-jpa</artifactId>
            <exclusions>
                <exclusion>
                    <groupId>javax.transaction</groupId>
                    <artifactId>javax.transaction-api</artifactId>
                </exclusion>
            </exclusions>
        </dependency>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-actuator</artifactId>
        </dependency>
        <dependency>
            <groupId>org.jboss.spec.javax.transaction</groupId>
            <artifactId>jboss-transaction-api_1.2_spec</artifactId>
            <version>1.0.0.Final</version>
        </dependency>
...

Not a pretty solution, but at least I'm able to use the latest version of Spring Boot.

@philwebb
Copy link
Member

We'll at least add something to docs for this. Thanks for raising the issue.

@philwebb philwebb added type: documentation A documentation update and removed status: waiting-for-feedback We need additional information before we can continue labels Jan 14, 2015
@philwebb philwebb added this to the 1.2.2 milestone Jan 14, 2015
@izeye
Copy link
Contributor

izeye commented Jan 15, 2015

Is it possible to request to use Java 6 for 'javax.transaction:javax.transaction-api:1.2' to its maintainer

if it doesn't use any Java 7 specific syntax?

@wilkinsona wilkinsona self-assigned this Jan 22, 2015
@kiview
Copy link

kiview commented Jun 24, 2016

If someone stumbles upon this problem by chance, this is how you can configure your JTA dependencies with Gradle:

dependencies {
  compile ("org.springframework.boot:spring-boot-starter-data-jpa") {
    exclude group: "javax.transaction", module: "javax.transaction-api"   
  }

  compile "org.jboss.spec.javax.transaction:jboss-transaction-api_1.2_spec:1.0.0.Final"
}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: documentation A documentation update
Projects
None yet
Development

No branches or pull requests

6 participants