I'm using (or rather: tried using) Mockito 1.10.19 and springockito-annotatinos 1.0.9, but they don't agree with each other.
(I get a ClassNotFoundException: org.mockito.internal.MockitoInvocationHandler and have raised a bug with springockito.)
Does anyone have a list of what version of Mockito springockito-annotatinos works with? (Or is someone successfully using springockito-annotatinos and can share what version of Mockito they use?)
I'm expecting the compatibilities will be as confusing as those between PowerMock and Mockito for PowerMockito...
Related
All groovyconsole binary distros I have found don't support Java 14. The console complains if you try to specify a Jar file that has been compiled with Java 14, for example.
The obvious solution, I thought, was to build Groovy with Java 14. That seems non-trivial.
gradle.wrapper.properties files contain
distributionUrl=http://services.gradle.org/distributions/gradle-2.3-bin.zip
which is a broken URL. Change that to https and then it works, partially.
You then get
FAILURE: Build failed with an exception.
What went wrong:
Could not determine java version from '14.0.2'.
Reading the docs for gradle makes it clear that most (all?) versions of gradle do not support Java 14. Definitely version 2.3 does not. Why - I have no idea.
So... back to my original question. How can I get a groovy installation to support Java 14?
Thanks!
If the Jar cannot be loaded, it is most likely the asm lib, which is unable to read it. To read Java14 you need at least ASM 7.2 I think. ASM in Groovy is not provided as standalone library, because of possible conflicts with other jar dependencies it is shadowed (bytecode is transformed by renaming the packages and directly added to the Groovy jar). I see here 2 options:
compile Groovy yourself and change the dependencies to have at least ASM 7.2. It does not matter if you build Groovy with a lower version of the JDK, the JDK still allows to read "old" jars.
use at least Groovy 2.5.9, 3.0.0 or 2.4.19, as they include asm 7.2 or higher
Of course this does not mean it will change the Groovy Gradle is using easily. For that I would use Groovy 2.5 and read Bumping Groovy version in Gradle?
If this does not solve the problem or answer the question I would need more details.
I'm a contributor of Vert.x for Groovy (https://github.com/vert-x3/vertx-lang-groovy) and recently see a curious behaviour regarding AST Transformation.
Until Groovy 3.0.4 the VertxTransformation class (https://github.com/vert-x3/vertx-lang-groovy/blob/3.9/vertx-lang-groovy-gen/src/main/java/io/vertx/lang/groovy/VertxTransformation.java) was working just fine. When I tried to use Groovy 3.0.5 it started to appear some ConcurrentModificationException.
java.util.ConcurrentModificationException
at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:909)
at java.util.ArrayList$Itr.next(ArrayList.java:859)
at java.util.Collections$UnmodifiableCollection$1.next(Collections.java:1044)
at io.vertx.lang.groovy.VertxTransformation.visit(VertxTransformation.java:82)
at io.vertx.lang.groovy.VertxTransformation.visit(VertxTransformation.java:77)
at io.vertx.lang.groovy.VertxTransformation.lambda$visit$0(VertxTransformation.java:68)
at java.util.Spliterators$ArraySpliterator.forEachRemaining(Spliterators.java:948)
at java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:647)
at io.vertx.lang.groovy.VertxTransformation.visit(VertxTransformation.java:68)
Below there are two links: the first one shows the project building fine with 3.0.4 and the second one failing with 3.0.5. The only thing different is the Groovy version.
https://travis-ci.org/github/vert-x3/vertx-lang-groovy/builds/712642226 (3.0.4)
https://travis-ci.org/github/aaloise/vertx-lang-groovy/builds/712638741 (3.0.5, the exception appears from line 1818 onwards)
Don't know if something changed in 3.0.5 regarding AST. I even raised an issue (https://issues.apache.org/jira/projects/GROOVY/issues/GROOVY-9666). If is not a bug, but an improvement, would like some suggestions for an workaround.
difference between mockito-core and mockito-all? What would I not be able to do if I use only mockito-core for example?
mockito-core only contains mockito classes, while mockito-all contain mockito classes as well as some dependencies, one of them being hamcrest.
In fact mockito-all is discontinued according to the mockito website
“mockito-all” distribution has been discontinued in Mockito 2.*.
The two packages were/are equivalent but if you depend on mockito-core you'll need to add a specific dependency on the packages transitively included in mockito-all if you require them in your project.
I've personally experienced some issues when depending on a newer version some hamcrest matchers while at the same time having a dependency on mockito-all.
Recently, I had JUnit tests can't use the right matcher to match the method as we using hamcrest 1.3, the mockito-all includes the classes from hamcrest of version 1.1, as well as objenesis of 1.0. Changing to use mockito-core, then add objenesis 1.0 as dependency, with already included dependency for hamcrest 1.3 resolves the issue completely.
I believe this problem not to be related to module exclusions in JDK 9 (as with java.se.ee), but rather with the fact that JDK 9 includes a newer version of org.w3c.dom.ls in the java.xml module that does not have the DocumentLS class.
The important bit of the stack trace is this:
Caused by: org.springframework.beans.factory.BeanDefinitionStoreException: Unexpected exception parsing XML document from class path resource [spring-test/test-container.xml]; nested exception is java.lang.NoClassDefFoundError: org/w3c/dom/ls/DocumentLS
at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadBeanDefinitions(XmlBeanDefinitionReader.java:414)
at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:336)
at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:304)
at org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:181)
Even if I include a runtime dependency with this class, like xerces:xerces 2.4.0, the JDK java.xml module is preferred (I guess).
I am using Gradle 4.1. Is there any way to restrict the scope of a
JDK provided module?
As you have correctly analyzed, the package org.w3c.dom.ls is present in the platform module java.xml. Any class on the class path that is in the same package will be ignored. That's called a split package and several fixes exist - the following two might help you.
Patch java.xml
You can add the classes of the Xerxes JAR to the java.xml module with --patch-module:
java --patch-module java.xml=xerxes-4.0.0.jar ...
I've never tried that with a JAR that contains some of the same classes. As I understand it, the JDK classes will then be replaced with the Xerxes classes, which means they better be a fully binary compatible replacement.
Upgrade java.xml
Another hope is to replace java.xml with the upgrade module path:
The upgrade module path (--upgrade-module-path) contains compiled definitions of modules intended to be used in place of upgradeable modules built-in to the environment (compile time and run time).
You face two problems:
the upgrade module path is supposed to be used only for upgradable modules (which java.xml is not), but I think I've read somewhere that that's not enforced (yet?) - didn't try it
the artifact you replace java.xml with needs to be fully binary compatible update - would that be the case for Xerxes?
From what I can tell, DocumentLS is from a 2002 draft of the W3C API, it doesn't appear to have made it into a released version. It looks like xerces-2.4.0 (from 2006?) includes it but newer versions don't. So upgrading to a more recent Xerces may be needed here. If Spring really depends on DocumentLS then it will need to be updated too.
I am trying to generate Excel using Xssf API because its memory footprint is small.
It is working fine in my local machine which is having jdk1.7.
But when I try to run it on UNIX where java version is 1.6.0_75 it gives me the following error.
java.lang.NoClassDefFoundError: Could not initialize class org.apache.poi.openxml4j.opc.internal.marshallers.ZipPackagePropertiesMarshaller
I have following jars in my classpath
poi-3.11-20141221.jar
poi-excelant-3.11-20141221.jar
poi-ooxml-3.11-20141221.jar
poi-ooxml-schemas-3.11-20141221.jar
xmlbeans-2.6.0.jar
xercesImpl.jar
I have verified that poi-3.11-20141221.jar has the ZipPackagePropertiesMarshaller class.
Seems that some jar is missing.
Am I missing something?
I have found a solution to my own problem.
I replaced poi-3.11-20141221.jar with poi-ooxml-3.9.jar. That worked.
Java version 1.6.0_75 does not exists, I suppose you make a typo. The last update of Java 6 is the update 45 (6u45).
The class ZipPackagePropertiesMarshaller is loaded at run-time for sure. The exception NoClassDefFoundError occurs during the initialization phase; if the exception had been ClassNotFoundException, it would have been different...
The class ZipPackagePropertiesMarshaller is unaltered between the versions 3.11 and 3.9, but the class PackagePropertiesMarshaller extended by ZipPackagePropertiesMarshaller is changed: the main change regards the use of StAX in the newer version.
The distribution of StAX coming with Java 6, but the version of Java 6 update 18 (http://www.oracle.com/technetwork/java/javase/6u18-142093.html) introduces the StAX 1.2 API version.
Consider to use Java 6u18 or newer. This should solve your problem.
In the official FAQ there are some indications about a similar problem: https://poi.apache.org/faq.html#faq-N1017E.
Moreover, the workaround you found is not the best one, see the last FAQ of POI.