I have cloned RSKj from the official repo and trying to run the test folder on IntelliJ. I am running the last Java version on an M1 MAC.
I'm having the following error when running the tests on the master branch.
Unable to make private static int[]
java.math.BigInteger.add(int[],int[])
accessible: module java.base does not "opens java.math"
to unnamed module #b1a58a3
What can be the problem here?
How did you run them? Your IDE may use non-local Gradle, so you should run it via
./gradlew clean build
Make sure Gradle is properly configured via the ./configure.sh command (one-time operation).
Also, check the Java version. It should work properly on versions 8 (e.g. JVM temurin-1.8) and 11 on M1
Materialised fully functional Spring Boot application code from repository and working fine with java 1.8. While upgrading to Java 11 got errors like some packages is accessible from more than one module
1.The package javax.xml.parsers is accessible from more than one module: <unnamed>, java.xml
2.The package org.xml.sax is accessible from more than one module: <unnamed>, java.xml
Tried to resolve the issue by restrict dependency using methods provided in the below links but not helped.
Eclipse can't find XML related classes after switching build path to JDK 10
https://www.eclipse.org/eclipse/news/4.8/jdt.php#Java9
Setting Eclipse JRE
Setting Java Version in POM
Setting Sping Version
Archiva dependency integrated to Spring Boot as rootParent
Error While upgrading to java 11
Build path of migrated project
Reason : Conflict between xml.apis and java.xml.due to the modularity concept in java
Solution : Excluded xml.apis dependency in maven pom file.
I'm trying to add a JDBC connector module to my project with Java 11. I downloaded the MSSqlServer JDBC driver 7.2 for Java 11
https://www.microsoft.com/en-us/download/details.aspx?id=57782
I added the module :
requires com.microsoft.sqlserver.jdbc;
Yet when I try to clean+build, NetBeans tells me:
Error: automatic module cannot be used with jlink: com.microsoft.sqlserver.jdbc from file: /sqljdbc_7.2/enu/mssql-jdbc-7.2.2.jre11.jar
I'm pretty sure this is because the jar doesn't have a compiled module-info.java. However, I was wondering if there is a way to inject one in there?
Getting a class not found error at runtime due to maven sub dependency issue:
I am working on integrating twilio sdk ( com.twilio.sdk:twilio:7.35.0 ) into a multi module maven(3.x)/java(java8) project.
I firstly added the twilio maven dependency to the corresponding module
And I am getting a class not found exception at runtime on org.apache.http.conn.HttpClientConnectionManager.
I looked into it and found out that this class is part of org.apache.httpcomponents:httpclient (which is a subdependency in the twilio sdk ) and that an earlier version of this dependency is in my project.
And this earlier version does not have the HttpClientConnectionManager class.
So from this point, I tried to exclude the old version of the dependency with exclude tag first then with maven enforcer plugin and in the same time importing the dependency directly but nothing worked.
I tried to import the dependency in the parent pom and in the other modules that are using my twilio module as well.
I am using twilio 7.35 which uses org.apache.httpcomponents:4.5.6 but in my multi-module project I am using org.apache.cassandra:cassandra-thrift:3.0.0 which is using thrift:0.9.2 which contains the old version of httpclient(4.2.5).
The latest version of this cassandra module does not support the latest version of httpClient, so I need to make sure this httpclient older dependency does not mess up the twilio one.
I also analysed the output of mvn dependency:tree -Dverbose and it seems that the 4.5.6 is getting picked up correclty. And when I tried adding it to the parent module or the calling module, I can see that the old version is getting overwritten by the twilio one but it does not solve my issue.
I am starting to wonder if it is even possible to have two versions of the dependencies in the same maven project.
It sounds like you are experiencing something similar to a related question dealing with Jar Hell: Jar hell: how to use a classloader to replace one jar library version with another at runtime
In this case you need to use a separate classloader from the default one in your project. Perhaps you could use the URL Classloader and load some or all of your newer dependencies from the filesystem.
We use maven and have artifacts that in turn depend on other internal artifacts. I am in the process of migrating to java-9, and intend to migrate everything to Java 9 first without modularizing the code (i.e. in the unnamed module).
The problem I run into is that we depend on java.xml.bind, which is now not included in the default modules. Is there a "correct" way to express this dependency on java.xml.bind with Maven?
The Module System speaks of the way the unnamed modules as in your case of loading the application from classpath constructs the module graph. Further, from the documentation itself:-
When the compiler compiles code in the unnamed module, or the java
launcher is invoked and the main class of the application is loaded
from the class path into the unnamed module of the application class
loader, then the default set of root modules for the unnamed module is
computed as follows:
The java.se module is a root, if it exists. If it does not exist then
every java.* module on the upgrade module path or among the system
modules that exports at least one package, without qualification, is a
root.
Every non-java.* module on the upgrade module path or among the system
modules that exports at least one package, without qualification, is
also a root.
Otherwise, the default set of root modules depends upon the phase:
At compile time it is usually the set of modules being compiled (more
on this below);
At link time it is empty; and
At run time it is the application's main module, as specified via the
--module (or -m for short) launcher option.
It is occasionally necessary to add modules to the default root set in
order to ensure that specific platform, library, or service-provider
modules will be present in the module graph. In any phase the option
--add-modules <module>(,<module>)* where <module> is a module name, adds the named modules to the default set of root modules.
Similar issue was faced in jetty.project where a thread from jdk mailing list discussed over the same and the fix was to use:
--add-modules java.se.ee
which provided them access to all Java SE modules and in your case shall simply be:
--add-modules java.xml.bind
To use this in maven, you can embed the same to the maven-compiler-plugin
using
<compilerArgs>
<arg>--add-modules</arg>
<arg>java.xml.bind</arg>
</compilerArgs>
as suggested by ZhekaKozlov here.
An important point to note is that marking deprecation of an API also means you might probably want to get away from using it. To adapt to this way you can probably start consuming the dependency on jaxb-api:2.3.0 which can now be loaded as a module and can be executed from the classpath as well. The change you need to make is to add the following to your dependencies list:
<dependency>
<groupId>javax.xml.bind</groupId>
<artifactId>jaxb-api</artifactId>
<version>2.3.0</version>
</dependency>
Update:- Eventually, with Java-10 already out and JDK/11 up next, one should ideally follow the link to JEP 320: Remove the Java EE and CORBA Modules and further replace such dependencies with their standalone libraries instead.
Yes, you have to pass --add-modules to Java compiler:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.7.0</version>
<configuration>
<release>9</release>
<compilerArgs>
<arg>--add-modules</arg>
<arg>javax.xml.bind</arg>
</compilerArgs>
</configuration>
</plugin>
Then your project should compile fine.
JAXB, along with the other APIs shared with Java EE (JAX-WS, JAF, JTA, and the so-called "Common Annotations") are deprecated in Java SE 9 and are proposed to be removed in a future release of Java SE and the JDK. Each of these APIs has a standalone version/download. Each API has its own JSR that maintains it too. Transitioning from the APIs included in the JDK to the standalone versions will of course be a bit disruptive.
A first step towards dropping these APIs from Java SE and the JDK is to not resolve the modules containing these APIs by default. When you compile or run code on the class path with JDK 9 then it will initially appear that the APIs do not exist. A quick workaround, as noted in another answer, is to compile or run with --add-modules java.xml.bind. That CLI option adds the "java.xml.bind" module to the set of root modules to resolve at startup and it works with JDK 9 because this module is included in the JDK run-time image.
Beyond the quick workaround, applications or libraries using JAXB will need to move to using the standalone version of the API/implementation. JAXB 2.3.0 is due to be published to Maven Central soon and it includes the changes to work with JDK 9 and beyond. The standalone version can be deployed on the class path like other JAR files. It will eventually be possible to deploy the standalone version on the (upgrade) module path and use it as a module too. The JDK 9 Migration Guide will have more information on the options for migrating code that uses JAXB or the other APIs shared with Java EE.
Okay I hope this helps someone. If you, per chance, have installed Java 9 or 10 and find that you can't get past this javax.xml.bind error, perhaps you are using Java 8 by way of jenv per folder (really I am sorry to be so vague, but, that's all I have time for at the moment)?
But adding in a correct setting for JAVA_HOME fixed my problem: export JAVA_HOME="$(/usr/libexec/java_home -v 1.8)" on MacOS.