I'm trying to understand if Apache Groovy 2.5 (latest stable release) supports Java 13. As per System Requirements page it should be fine to use any JDK 1.7+.
However when I try to compile my Spock tests with Gradle 6 on Java 13 I get the following error:
Caused by: BUG! exception in phase 'semantic analysis'
in source unit '/home/myself/project/Test.groovy'
Unsupported class file major version 57
Could it be due to GROOVY-9020 or is Apache Groovy 2.5 not officially supporting Java 13?
Updating to Groovy 2.5.7 or newer solves the problem. In my case transitive Spock dependencies used an older version of Groovy.
The root cause was ASM library which was reported in GROOVY-9020 and GROOVY-9055 and fixed in upgraded ASM to 7.1, added Java 13 to CompilerConfiguration #887 pull request.
Reported the issue under Update Spock 1.3-groovy-2.5 to support Java 13 #1051.
Related
Recently migrated from commons-lang-2.6 to commons-lang3.12.0, getting below error: org.apache.commons.lang.exception.NestableException
How to resolve that?
Facing this issue as apache has taken support from Nestableexception in commons-lang3
moreover your java version might be older. They have used java 5 in lowest version of commons-lang3, and in version: commons-lang3.12.0.jar, they have used java 8+
So, if you want to update commons-lang, need to upgrade jdk also. Thats the only solution.
https://commons.apache.org/proper/commons-lang/article3_0.html
(see under nested exception)
https://commons.apache.org/proper/commons-lang/download_lang.cgi
I am successfully using Java 8 with JBehave. Now I would like to switch to Java 11, but find no information about the JBehave compatibility.
Using Cucumber instead would also be possible, but here I only found news from 2/2019 saying that Cucumber is only partially compatible.
Does anybody have experiences with Java 11 and one of these BDD tools?
JBehave 4.5.1 is fully compatible with Java 11.
I've successfully been using latest JBehave versions with Java 9, 10, 11. No Java-specific issues are found.
I have got jar compiled in java 1.8 from maximo dir and on my machine i have java 1.7 installed do i need to update my machine java before i run this jar. I can not run it before knowing this since it will get recorded in some logs and will update some server side files.
This is more of a Java question than a Maximo question, but no, it will not. You will get an "Unsupported major.minor version 52.0" if you do. This is not because of any features issue, this is simply because the bytecode is tagged as being from Java 8 and so earlier JREs will not run it.
Now this assumes you actually compiled the class files using Java 8, which probably only happened if you have custom code in there. If you are just using the out-of-the-box Maximo classes, those came pre-compiled (in I don't recall which version of Java) and so all you might have done was to bundle them into a jar, or more likely into the Maximo ear (since you don't run the businessobjects.jar). In that case, it doesn't matter what version of Java you used to created the jar/ear, it will run on any version of Java that is the same as or higher than whatever version IBM used to compile the code into classes.
I had the following issue recently in my code. The environment is:
Java(TM) SE Runtime Environment (build pap6470sr1-20120330_01(SR1))
IBM J9 VM (build 2.6, JRE 1.7.0 AIX ppc64-64 20120322_106209 (JIT enabled, AOT enabled))
J9VM - R26_Java726_SR1_20120322_1720_B106209
Throwable occurred: java.lang.ArrayIndexOutOfBoundsException: Array index out of range: -14
at com.sun.xml.bind.v2.util.CollisionCheckStack.findDuplicate(CollisionCheckStack.java:133)
at com.sun.xml.bind.v2.util.CollisionCheckStack.push(CollisionCheckStack.java:71)
at com.sun.xml.bind.v2.schemagen.XmlSchemaGenerator$Namespace.writeTypeRef(XmlSchemaGenerator.java:705)
at com.sun.xml.bind.v2.schemagen.XmlSchemaGenerator$Namespace.access$1900(XmlSchemaGenerator.java:429)
at com.sun.xml.bind.v2.schemagen.XmlSchemaGenerator$Namespace$ElementWithType.writeTo(XmlSchemaGenerator.java:1273)
at com.sun.xml.bind.v2.schemagen.XmlSchemaGenerator$Namespace.writeTo(XmlSchemaGenerator.java:583)
at com.sun.xml.bind.v2.schemagen.XmlSchemaGenerator$Namespace.access$600(XmlSchemaGenerator.java:429)
at com.sun.xml.bind.v2.schemagen.XmlSchemaGenerator.write(XmlSchemaGenerator.java:411)
at com.sun.xml.bind.v2.runtime.JAXBContextImpl.generateSchema(JAXBContextImpl.java:755)
at org.apache.cxf.jaxb.JAXBUtils.generateJaxbSchemas(JAXBUtils.java:760)
at org.apache.cxf.jaxb.JAXBDataBinding.generateJaxbSchemas(JAXBDataBinding.java:447)
at org.apache.cxf.jaxb.JAXBDataBinding.initialize(JAXBDataBinding.java:374)
at org.apache.cxf.service.factory.ReflectionServiceFactoryBean.buildServiceFromClass(ReflectionServiceFactoryBean.java:429)
at org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.buildServiceFromClass(JaxWsServiceFactoryBean.java:637)
at org.apache.cxf.service.factory.ReflectionServiceFactoryBean.initializeServiceModel(ReflectionServiceFactoryBean.java:492)
at org.apache.cxf.service.factory.ReflectionServiceFactoryBean.create(ReflectionServiceFactoryBean.java:240)
at org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.create(JaxWsServiceFactoryBean.java:180)
at org.apache.cxf.frontend.AbstractWSDLBasedEndpointFactory.createEndpoint(AbstractWSDLBasedEndpointFactory.java:99)
at org.apache.cxf.frontend.ClientFactoryBean.create(ClientFactoryBean.java:51)
at org.apache.cxf.frontend.ClientProxyFactoryBean.create(ClientProxyFactoryBean.java:102)
at org.apache.cxf.jaxws.JaxWsProxyFactoryBean.create(JaxWsProxyFactoryBean.java:121)
at org.apache.cxf.jaxws.ServiceImpl.createPort(ServiceImpl.java:458)
at org.apache.cxf.jaxws.ServiceImpl.getPort(ServiceImpl.java:330)
at org.apache.cxf.jaxws.ServiceImpl.getPort(ServiceImpl.java:317)
at javax.xml.ws.Service.getPort(Service.java:130)
This code worked fine on Linux server with Oracle Java 1.7. It also worked on AIX with IBM Java 1.6. But it throws these exceptions when using IBM Java 1.7.
I did a research of com.sun.xml.bind.v2.util.CollisionCheckStack.findDuplicate(CollisionCheckStack.java:133)
And found some looking similar issues/answers, such as:
http://mydevtoolbox.blogspot.com/2013/07/jaxb-marshaller-no-threadsafe-error.html, which recommends “Create a Marshaller and Unmarshaller per request”
I don’t explicitly use Marshaller/Unmarshaller – it looks like CXF/JAXB issue on Java 1.7.
Any thoughts, insights, opinions are greatly appreciated.
Can you try using JAXB 2.2.4 based jars for IBM Java 1.7 and see if that solves the issue?
We had this issue after upgrading JAVA version from 1.6 to 1.8, to fix
you need to upgrade JAXB version from 1.x to 2.x.
Just had this problem
I was using Openj9 JDK and switched over to HotSpot. I used the IntelliJ JDK manager to download the JDK from OpenJDK and made my environmental variables point to the downloaded file structure (JAVA_HOME variable).
It solved the problem
This is not "real" answer, just a workaround suggestion.
The stack trace indicates you have a problem with schema generation. Maybe you could overcome this by providing an XML Schema explicitly using #XmlSchema.location. You'd have to generate and make this schema available manually. Not so cool, but if everything else fails...
I am on a Linux Mint machine where I installed the latest version of Java (HotSpot VM 1.7.0_45) and using Gradle 1.8.
I also have Groovy installed, version 1.8.6, but I think that does not matter as Gradle has its own groovy-all.jar.
My problem is that I could not compile my Groovy project using gradle because the JavaFX classes do not seem to be in the classpath. The errors are like this:
unable to resolve class javafx.scene.Node
# line 3, column 1.
import javafx.scene.Node
I finally fixed this by adding the following horrible hard-coded path into my dependencies:
compile files( "/usr/lib/jvm/java-7-oracle/jre/lib/jfxrt.jar" )
Is there a better way to add JavaFX to Gradle's compilation classpath so that it is visible to all my projects without me having to add this to each one of them??
I have tried everything I could imagine:
added the jfxrt.jar to the standard JRE (I confirmed gradle is using my standard java to run) ext folder, so that I now can compile java classes with javac and run them with java (I know that in this version of Java the JavaFX jar should be already in the JDK's classpath, but I still couldn't RUN, as opposed to compile, my Java app before doing this).
also added a soft link to the same jar in the groovy classpath, so that I can do something like shown below from the groovy shell and it works:
import javafx.application.Application as A ; println A
This also works in the Groovy Console.
It only does not work in Gradle!
Thanks for any help.
Use the JavaFX Gradle Plugin.
The JavaFX Gradle Plugin should be able to work out where the JavaFX runtime is located without you having to perform manual, environment specific configuration.
For further information on JavaFX classpath resolution (not Gradle related), see:
Compile code using JavaFX 2.0 (using command line).
Also note, if you are using Oracle Java 8 or newer, JavaFX classes are now on the default runtime classpath for an Oracle Java implementation.
Incidentally, the build system for the entire JavaFX system is based on Gradle, so there is definitely no incompatibility between JavaFX and Gradle.