Eureka Discovery Client is not working with java 11 modules [duplicate] - spring-boot

With Java 9 on the close horizon I thought it would be a good learning exercise to port some of my projects over to Java 9. In one of my projects I have dependencies for rxjava and rxjavafx
dependencies {
compile 'io.reactivex:rxjava:1.2.6'
compile 'io.reactivex:rxjavafx:1.0.0'
...
}
I want to create this project as a named-module. To do this I need to create a module-info.java file and I need to specify the requirements for rxjava and rxjavafx here. However, these libs don't have any module info yet.
In order to work around this I've read that I need to create Automatic Modules. From what I understand, I need to rename the rxjava and rxjavafx jars to have a simple name and then list the jars in the --module-path parameter. I then add a requires directive in my module-info.java with the jar names.
module com.foo.bar {
requires rxjavafx;
requires rxjava;
}
I wrote a gradle task to edit the jar names for me, and it appears to be working in most cases. It takes all the jars that need to be compiled and renames them to not include version-info or slashes. The files are then concatenated into a : separated string:
tasks.withType(JavaCompile) {
delete { delete '/tmp/gradle' }
copy {
from configurations.compile + configurations.testCompile
into '/tmp/gradle'
rename '(.*)-[0-9]+\\..*.jar', '$1.jar'
rename { String fileName -> fileName.replace("-", "") }
}
options.compilerArgs += ['--module-path', fileTree(dir: '/tmp/gradle', include: '*.jar').getFiles().join(':')]
}
Naturally the rx libraries share some of their package names... this however causes the compiler to spit back errors such as:
error: module reads package rx.subscriptions from both rxjava and rxjavafx
error: module reads package rx.schedulers from both rxjava and rxjavafx
error: module reads package rx.observables from both rxjava and rxjavafx
error: module rxjava reads package rx.subscriptions from both rxjavafx and rxjava
error: module rxjava reads package rx.schedulers from both rxjavafx and rxjava
error: module rxjava reads package rx.observables from both rxjavafx and rxjava
error: module rxjavafx reads package rx.subscriptions from both rxjava and rxjavafx
error: module rxjavafx reads package rx.schedulers from both rxjava and rxjavafx
error: module rxjavafx reads package rx.observables from both rxjava and rxjavafx
It seems like the only way to get around this issue would be to re-package the contents of rxjava and rxjavafx into a single jar and add that as a single module. This doesn't seem like a good solution though...
So my questions are:
Am I using the new module system correctly?
What can I do about this error? and
Do these dependencies prevent me from updating, or should I just wait for rx to update their libs?
Note: I've tried running this with standard java/javac and they cause the same issues. Also here is my java version:
java version "9-ea"
Java(TM) SE Runtime Environment (build 9-ea+140)
Java HotSpot(TM) 64-Bit Server VM (build 9-ea+140, mixed mode)

Am I using the new module system correctly?
Yes. What you are seeing is intended behavior, and this is because JPMS modules do not allow split packages.
In case you are not familiar with the term "split packages" it essentially means two members of the same package coming from two different modules.
For example:
com.foo.A (from moduleA.jar)
com.foo.B (from moduleB.jar)
What can I do about this error?
You have two options:
(harder) "unsplit" the package dependencies. However this could be difficult or impossible if you are not familiar with the inner workings of the library
(easier) combine the two jars into a single jar (and therefore a single automatic module) as you mentioned above. I agree that it is not a "good" solution, but having split packages in the first place is generally not a good idea either.
Do these dependencies prevent me from updating, or should I just wait for rx to update their libs?
Hopefully rx will eventually update their libs to not have split packages at some point in the future. Until then, my recommendation would be to just smash the two jars together into a single jar (option #2).

I had simmiliar problem:
error: module flyway.core reads package javax.transaction.xa from both jboss.transaction.api.1.2.spec and java.sql
error: module slf4j.api reads package javax.transaction.xa from both jboss.transaction.api.1.2.spec and java.sql
error: module hibernate.core reads package javax.transaction.xa from both jboss.transaction.api.1.2.spec and java.sql
.../src/main/java/module-info.java:1: error: module eu.com.x reads package javax.transaction.xa from both java.sql and jboss.transaction.api.1.2.spec
I could get rid of split packages compilation problem by checking my project transitive dependencies ("gradle dependencies" or "mvn dependency:tree" could be helpful) and excluding by code simmiliar to:
configurations.all {
exclude group: 'org.jboss.spec.javax.transaction', module: 'jboss-transaction-api_1.2_spec'
}
or
<dependencies>
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-core</artifactId>
<version>5.2.10.Final</version>
<exclusions>
<exclusion>
<groupId>org.jboss.spec.javax.transaction</groupId>
<artifactId>jboss-transaction-api_1.2_spec</artifactId>
</exclusion>
</exclusions>
</dependency>
</dependencies>
No jar repackaging was needed im my problem. This problem have not occured on #JDK8. Probably excluding dependencies does not help in every project.

i have been facing the same issue with java.transaction.xa read package from both javaee and java.transaction.xa.
And i fixed it by adding this line to my modul-info.java
opens javax.transaction.xa;
It worked fine but a hint shown up saying the package javax.transaction.xa is empty or doesn't exists. however the source code compile correctly.

Related

import dependencies from another module

I think I am missing some point in how dependencies management works in gradle.
Let's say I have the following project structure:
project
---api
------api-commons
------api-v1
------api-v2
------api-v3
where all api* directories are modules. All api-v* need a particular dependency (let's say common-dependency).
My aim would be to import it in api-commons build.gradle file:
dependencies {
implementation 'common-dependency'
}
while in the build.gradle files of the other modules api-v* put:
dependencies{
implementation project(':api:api-commons')
}
I would expect this to work but it doesn't. The code in the api-v* modules simply acts like the dependency is not declared. Indeed, if I import the dependency in the single modules, the code works as expected.
Am I doing a wrong assumption? Doesn't the dependency inheritance work like that?
Declaring a dependency in the implementation configuration conceptually means it is internal to the module (it is used in the implementation but not part of the public API). Such a dependency will not be exposed to the compile classpath of consumers, though it will still be on the runtime classpath.
An advantage of this way of modelling dependencies is that you do not need to recompile consuming projects if an implementation dependency changes. Another is that by encapsulating them, it is less likely that a consumer will start depending on them directly and then breaking if you change them.
If you want to expose the dependency to consumers, you have to declare it as part of the API for the module. You do that by applying the java-library plugin and using the api configuration.
Example:
// api-commons/build.gradle
plugins {
id 'java-library'
}
dependencies {
api 'common-dependency'
}
Read more about it in the Gradle user guide
Let say, I have to moved below common code(*.java files) from below 2 service/modules to sharedprocessing-data which is present inside shared-libraries service/modules :
abc-service
xyz-servcie
Address.java
Employee.java
Department.java
Vaccation.java
Name.java
City.java
Order.java
Steps0:
In shared- service/modules folder create additional module inside existing shared-libraries module
Name it as sharedprocessing-data
Steps1:
Move(refactor) common code inside this module
Steps2:
In parent folder (root) update settings.gradle file
rootProject.name = "root"
include 'abc-service'
include 'xyz-service'
include 'shared-libraries:sharedprocessing-data'
Step3:
In each of abc-service and xyz-flow service modules, update build.gradle file
dependencies
{
implementation project(':shared-libraries:sharedprocessing-data')
}

Use Groovy app and test code in combination with jlink solution for bundling JavaFX

This follows on from this excellent solution to the question of how to get Gradle to bundle up JavaFX with your distributions.
NB specs: Linux Mint 18.3, Java 11, JavaFX 13.
That stuff, involving jlink and a module-info.java, is beyond my pay grade (although I'm trying to read up on these things).
I want to move to using Groovy in my app and test code (i.e. Spock) rather than Java. The trouble is, the minute I include the "normal" dependency in my build.gradle i.e.
implementation 'org.codehaus.groovy:groovy-all:2.5.9'
and try to build, I get multiple errors:
mike#M17A ~/IdeaProjects/TestProj $ ./gradlew build
> Configure project :
Found module name 'javafx.jlink.example.main'
> Task :compileTestJava FAILED
error: the unnamed module reads package org.codehaus.groovy.tools.shell.util from both org.codehaus.groovy.groovysh and org.codehaus.groovy
[...]
error: the unnamed module reads package groovy.xml from both org.codehaus.groovy and org.codehaus.groovy.xml
[...]
error: module org.codehaus.groovy.ant reads package groovy.lang from both org.codehaus.groovy and org.codehaus.groovy.test
error: module org.codehaus.groovy.ant reads package groovy.util from both org.codehaus.groovy.xml and org.codehaus.groovy.ant
100 errors
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':compileTestJava'.
Yes, 100 errors... probably more! By commenting out various things I think I've come to the conclusion that some Groovy dependency is being injected by the jlink stuff. Fine, I can live with that (although it'd be nice to know what version of Groovy it is).
The trouble is, even if I omit the Groovy dependency line, the same errors occur when I try to introduce the Spock dependency:
testImplementation 'org.spockframework:spock-core:1.2-groovy-2.5'
Has anyone got any idea what's going on here and what to do about it?
I searched for an answer. I didn't find a good solution.
According to this, it seems that Groovy is currently not really compatible with Java modules. It is due to the fact that some packages are contained by multiple jars of the library (not compatible with modules). You will have to wait for Groovy 4 for a compatible version.
I discovered that the JavaFX plugin use this plugin internally. This plugin seems to consider that all dependencies are modules (it is not the default Gradle behaviour).
To make your application works, it seems that you have to:
force Gradle to put Groovy in the classpath instead of the modulepath (it will not be considerered as a module, but seems impossible if you use the javafx plugin)
use the "patch-module" system: it allows Gradle to make a fusion of the library jars into a single module, to prevent the problem of packages that are in different jars
I searched the Groovy jars with IDEA (Project structure/Libraries), and I tried to use the syntax offered by the plugin to use "patch-module":
patchModules.config = [
"org.codehaus.groovy=groovy-ant-3.0.1.jar",
"org.codehaus.groovy=groovy-cli-picocli-3.0.1.jar",
"org.codehaus.groovy=groovy-console-3.0.1.jar",
"org.codehaus.groovy=groovy-datetime-3.0.1.jar",
"org.codehaus.groovy=groovy-docgenerator-3.0.1.jar",
"org.codehaus.groovy=groovy-groovydoc-3.0.1.jar",
"org.codehaus.groovy=groovy-groovysh-3.0.1.jar",
"org.codehaus.groovy=groovy-jmx-3.0.1.jar",
"org.codehaus.groovy=groovy-json-3.0.1.jar",
"org.codehaus.groovy=groovy-jsr-3.0.1.jar",
"org.codehaus.groovy=groovy-macro-3.0.1.jar",
"org.codehaus.groovy=groovy-nio-3.0.1.jar",
"org.codehaus.groovy=groovy-servlet-3.0.1.jar",
"org.codehaus.groovy=groovy-sql-3.0.1.jar",
"org.codehaus.groovy=groovy-swing-3.0.1.jar",
"org.codehaus.groovy=groovy-templates-3.0.1.jar",
"org.codehaus.groovy=groovy-test-junit-3.0.1.jar",
"org.codehaus.groovy=groovy-test-3.0.1.jar",
"org.codehaus.groovy=groovy-testng-3.0.1.jar",
"org.codehaus.groovy=groovy-xml-3.0.1.jar"
]
It only works with a single line "org.codehaus.groovy=X.jar", but a bug prevents it to work with all of the library jars (Look at this issue on Github).
So you have multiple choices:
Use Java instead of Groovy
Wait for a new Groovy release, or new releases of plugins (modules-plugin, and a version of javafx-plugin that use this one internally)
Use old javafx configuration: dependencies are not module by default, and you have to specify manually in build.gradle that JavaFX dependencies should be considered as a module (check my "obsolete" answer to this question)

Can't find ParameterizedTest and ValueSource

I had done a simple project, trying to understand how ParameterizedTest and ValueSource works.
From the below picture it finds the import path, but it throws an error when I try to run the code:
Also the gradle file:
Here is a link to the entire project.
You need to put junit-jupiter-params in the testCompile source set.
junit-jupiter-params exports types like #ParameterizedTest and #ValueSource that are needed at compile (and run~) time.
See also: Missing org.junit.jupiter.params from JUnit5
Starting with version 5.4.0-M1 JUnit Jupiter provides an aggregator artifact that bundles all available Jupiter-defining artifacts for easy consumption. See https://sormuras.github.io/blog/2018-12-26-junit-jupiter-aggregator.html for details.

Gradle build error with Simpleframework

I upload my library module to jcenter and I use this module with my application project.
I try to build my application it returns an error.
I searched this issue and This issue is due to be aware of what simpleframework.
I have to use this library both My library module and application module.
How can I solve this problem?
Gradle error msg is below
trouble processing "javax/xml/stream/events/StartElement.class":
Ill-advised or mistaken usage of a core class (java.* or javax.*) when
not building a core library. This is often due to inadvertently
including a core library file in your application's project, when
using an IDE (such as Eclipse). If you are sure you're not
intentionally defining a core class, then this is the most likely
explanation of what's going on. However, you might actually be trying
to define a class in a core namespace, the source of which you may
have taken, for example, from a non-Android virtual machine project.
This will most assuredly not work. At a minimum, it jeopardizes the
compatibility of your app with future versions of the platform. It is
also often of questionable legality. If you really intend to build a
core library -- which is only appropriate as part of creating a full
virtual machine distribution, as opposed to compiling an application
-- then use the "--core-library" option to suppress this error message. If you go ahead and use "--core-library" but are in fact
building an application, then be forewarned that your application will
still fail to build or run, at some point. Please be prepared for
angry customers who find, for example, that your application ceases to
function once they upgrade their operating system. You will be to
blame for this problem. If you are legitimately using some code that
happens to be in a core package, then the easiest safe alternative you
have is to repackage that code. That is, move the classes in question
into your own package namespace. This means that they will never be in
conflict with core system classes. JarJar is a tool that may help you
in this endeavor. If you find that you cannot do this, then that is an
indication that the path you are on will ultimately lead to pain,
suffering, grief, and lamentation. 1 error; aborting Error:Execution
failed for task ':app:preDexDebug'.
com.android.ide.common.process.ProcessException: org.gradle.process.internal.ExecException: Process 'command
'C:\jdk1.7.0\bin\java.exe'' finished with non-zero exit value 1
My library build.gradle dependencies are below.
dependencies {
compile fileTree(dir: 'libs', include: ['*.jar'])
compile 'com.mcxiaoke.volley:library:1.0.+'
compile 'com.google.code.gson:gson:2.2.4'
compile ('org.simpleframework:simple-xml:2.7.+') {
exclude module: 'stax'
exclude module: 'stax-api'
exclude module: 'xpp3'
}
}
My Application dependencies are below :
dependencies {
compile 'com.android.support:support-v4:19.+'
compile 'com.google.android.gms:play-services:5.+'
compile 'com.jakewharton:butterknife:5.1.2'
compile 'com.jakewharton.timber:timber:3.1.0'
compile 'commons-io:commons-io:2.4'
compile 'commons-net:commons-net:3.3'
compile 'org.apache.httpcomponents:httpmime:4.2.5'
/*compile 'com.mcxiaoke.volley:library:1.0.+'
compile 'com.google.code.gson:gson:2.2.4'
compile('org.simpleframework:simple-xml:2.7.+') {
exclude module: 'stax'
exclude module: 'stax-api'
exclude module: 'xpp3'
}*/
compile 'org.jsoup:jsoup:1.7.2+'
compile 'com.effectivelife:cokcok-support:1.0.0'
}
I solved this problem.
I add a configurations to my application project.
So my application build.gradle file is below.
configurations {
compile.exclude module: 'stax'
compile.exclude module: 'stax-api'
compile.exclude module: 'xpp3'
}
dependencies {
compile 'com.android.support:support-v4:19.+'
compile 'com.google.android.gms:play-services:5.+'
compile 'com.jakewharton:butterknife:5.1.2'
compile 'com.jakewharton.timber:timber:3.1.0'
compile 'commons-io:commons-io:2.4'
compile 'commons-net:commons-net:3.3'
compile 'org.apache.httpcomponents:httpmime:4.2.5'
compile 'org.jsoup:jsoup:1.7.2+'
compile 'com.effectivelife:cokcok-support:1.0.1'
}

Generated class by protoc generates compile errors

I created a simple .proto file and executed the compiler (protoc-2.5.0rc1-win32.zip). A java file was generated to the prescribed package. However, the generated file does not compile.
The .proto file is simple with a single message with a bunch of simple types optional fields (properly numbered).
The .java file does not compile, for example:
The constructor GeneratedMessage.FieldAccessorTable(Descriptors.Descriptor, String[]) is undefined
The method ensureFieldAccessorsInitialized(Class, Class) is undefined for the type GeneratedMessage.FieldAccessorTable
... and host of other errors along the same line (like trying to override a final method in superclass)
errors that hint at some mismatch at the level of the API version?
Any ideas?
Thanks
RESOLVED: found that the version of proto expected by the API I am using is 2.4.1 and I was using latest.
i have solved the same problem.
the answer:
1.show your protoc complier version
e.g.
D:\workspace2\monitor\src\main\resources>protoc --version
libprotoc 2.6.1
2.make the protoc jar coincident with your protoc complier version
e.g.
<dependency>
<groupId>com.google.protobuf</groupId>
<artifactId>protobuf-java</artifactId>
<version>2.6.1</version>
</dependency>
For me, I tracked this down to akka including an older prototype buffer version, and the versions conflicted.
Solution: Check all your libraries for older versions of prototype buffer, it may be included in something you have already.
My guess is that you first need to build a new protocol buf jar ( protobuf-java-2.5.0rc1.jar ) from the source distribution protobuf-2.5.0rc1.zip and make this a local "system" dependency of your maven pom.xml. I also get compile errors if i just produce new java stubs with the new compiler but have the old 2.4.1 jar dependency in my pom. I couldnt find a maven repository which hosts the 2.5.0rc1.jar already built. If you just take the source files from the source distribution , you miss some class files like com.google.protobuf.DescriptorProtos.*.

Resources