I'm trying to build a Java 5 system using Java 6. I have configured and with 1.5, but I also need to set to point at a Java 5 rt.jar to ensure there are no faulty linkages like using Java 6 APIs. Has anyone ever configured maven to somehow pull rt.jar from a repository and reference it this way?
You can verify your usage of external libraries - and implicitly of the Java core APIs - by using the Animal Sniffer Maven Plugin
The Animal Sniffer Plugin is used to build signatures of APIs and to check your classes against previously generated signatures.
The plugin website shows how to generate signatures for the Java runtime and how to check against generated signatures.
You can send the source and target options down to javac by configuring the default maven java compiler plugin. Take a look at this page for an example.
Related
I wrote a Maven application that I want to use in my Jmeter BeanShell script.
The Maven application is using Google Guice 4.2.2 for dependecy injection and it is calling an API at the end (Code needs to perform some other operations before calling the API and that's why I am not using the JMeter Plugin). I am creating the uber JAR (Fat JAR) with maven-shade-plugin. When I run the Jar from the command line the application run successfully!
However, When I load the JAR in my Jmeter test plan and call my application main method in the Jmeter BeanShell I am getting the following error:
java.lang.NoSuchMethodError: com.google.common.base.Preconditions.checkArgument(ZLjava/lang/String;Ljava/lang/Object;)V
at com.google.inject.Key.ensureRetainedAtRuntime(Key.java:341) ~[load-testing.jar:?]
.
.
.
Now lots of other threads mentioned that this can be because of older Google Guava version (20.x older) but from the dependency tree I see the Guava version is 25.1-android and I can run my JAR successfully from the command line!!
Also, I list the classes in the Uber JAR by running jar -tf command and I can see that the com.google.common.base.Preconditions class is there.
I would appreciate it if someone can shed some light on this matter and help me to resolve this?
It seems that your fat-jar contains multiple versions of Guava (which may be caused by the shade-plugin).
Make sure to lock it to single version by using Mavens dependency management in each maven module. (https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Management)
The Beanshell itself might be a problem, since JMeter 3.1 it's recommended to use JSR223 Test Elements and Groovy language for scripting, the reasons are in:
Groovy is more "modern" language which supports all modern Java features while with Beanshell you're stuck at Java 1.5 language level (no lambdas, no generics, no multi-catch etc.)
Groovy performance is much better comparing to Beanshell cause Grooovy engine implements Compilable interface and is capable of caching compiled scripts providing performance very close to native Java code
Groovy provides a lot of enhancements on top of standard Java SDK
Check out Apache Groovy - Why and How You Should Use It article for more details.
I have finally cofirmed my comment. The problem was my JAR Guava version was conflicting with Jmeter Guava version (which is 17.0) and Jmeter for some reason is picking up its own Guava version, after downgrading Guice version to 3.0 which does not depend on guava, I successfully ran my JAR through Jmeter.
There is still a mystery on why Jmeter is overriding my JAR Guava version with its own. I will create a ticket with Jmeter in order to find more about this mystery but this change solved my problem
https://github.com/openjsse/openjsse
"The OpenJSSE project was created to add support for TLS 1.3 to existing Java 8 applications without requiring code changes"
How to use this project exactly?
I'm currently using the AdoptOpenJDK build for Java 8.
As mentioned in the issue log for openjdk (Link):
OpenJSSE for OpenJDK can be installed in two possible ways:
add OpenJSSE provider in the list of security providers of java.security file
registered at runtime with Security.insertProviderAt method
However you'll better use Azul JDK8 builds as soon as it has preintegrated and fully tested support for OpenJSSE provider with -XX:+UseOpenJSSE
I am working in a new project that is going to use Java EE 7 with WildFly, but I am still confused about which maven dependencies I should use.
I have found these two groups that apparently I can use: org.wildfly.bom and org.jboss.spec
They have the following predefined artifact to use in the projects (searched in https://repository.jboss.org/nexus/index.html#welcome):
org.wildfly.bom:
jboss-javaee-7.0-with-all
jboss-javaee-7.0-with-hibernate
jboss-javaee-7.0-with-tools
jboss-bom-parent
jboss-javaee-7.0-with-transactions
jboss-javaee-7.0-with-security
jboss-javaee-7.0-with-resteasy
jboss-javaee-7.0-with-infinispan
jboss-javaee-7.0-with-hibernate3
org.jboss.spec:
jboss-javaee-all-7.0
jboss-javaee-web-7.0
jboss-javaee-7.0
Also I have realized that that I can see dependency Hierarchy using org.jboss.spec but not with wildfly.bom. So, my question is what is the difference?, which one do you suggest?
The org.wildfly.bom includes dependencies for the versions of Hibernate, RESTEasy, etc. as well as their dependencies that are used in WildFly. For if you use Jackson2 annotations the org.wildfly.bom:jboss-javaee-7.0-with-resteasy should include the correct version of the Jackson2 dependency.
The org.jboss.spec only include the Java EE 7 API's used.
If you're not using anything specific to WildFly then I would use the org.jboss.spec BOM. If you're using something specific that the server includes, like Jackson2, Infinispan, etc., then I'd use the org.wildfly.bom.
I have to develop a JAX-WS client which has to be deployed to WebSpehere 7.
WebSphere 7 uses a custom Axis2 implementation.
I've read on this guide (http://axis.apache.org/axis2/java/core/docs/jaxws-guide.html) to use wsimport to generate classes necessary for client.
But generated classes reference to com.sun.xml.ws.spi.ProviderImpl in jaxws-rt.jar (present in JRE6), while when client runs on Websphere they reference org.apache.axis2.jaxws.spi.Provider.
Is it correct? Using Oracle JDK wsimport is the correct way to follow also if clients will be use Axis2 implementation?
There should be a wsimport tool as part of your WAS installation. I found mine under /IBM/WebSphere/AppServer/bin
Try using that tool to generate your classes, instead of the one from Oracle. It should generate classes that are more compatible with WebSphere.
You could also go get Axis2 from Apache. I imagine that Apache's wsimport (or equivalent) will produce classes that are most server independent.
http://axis.apache.org/axis2/java/core/download.cgi
Use WebSphere's own wsimport. There's a script you can run, a WSDL2Java Ant task you can use, or if you have RAD, you can do it within that.
Artifacts generated by wsimport are portable, i.e. they don't contain references to implementation specific classes. The actual JAX-WS implementation is selected at runtime. Therefore, it doesn't matter whether you use Oracle's or IBM's wsimport.
I'm using Maven 3.0.4 and Axis2 1.5.1 plugin. I've a problem with the generation of a stub class using AXIS2 plugin on Maven.
Depending on the JDK currently configured on the build environment, AXIS2 plugin generates a different stub class source code. I've tried the generation using JDK 1.6 and then JDK 1.7.
Is there any way to "force" the JDK (i.e. 1.6) used by the AXIS2 plugin inside Maven (without changing environment)? (I would like to have a code generation independent from the environment)
Any help will be much appreciated.
I assume you select your JDK like described here :
http://maven.apache.org/plugins/maven-compiler-plugin/examples/compile-using-different-jdk.html
Then, I would generate the stub using a different profile, allowing you to override some configuration, but keeping the benefits of your overall conf.
Unfortunately, all my attempts are unsuccessful.
I have to resign myself to what I was shown in another post (http://maven.40175.n5.nabble.com/Maven-amp-Axis2-plugin-different-stub-code-generation-tc5730726.html ): if I really require this type of functionality, I may have to do this work yourself. Otherwise ask Axis2 devs if someone
will volunteer to do it.