I'm building an android chat app using rabbitmq and the project builds without any issue. However, I'm having an issue in creating ConnectionFactory object. It gives me the following error
E/AndroidRuntime: FATAL EXCEPTION: main
Process: com.zabu.kyimoecho.mosaic, PID: 9002
java.lang.NoClassDefFoundError: com.rabbitmq.client.impl.nio.-$$Lambda$NioParams$NrSUEb8m8wLfH2ztzTBNKyBN8fA
at com.rabbitmq.client.impl.nio.NioParams.<clinit>(NioParams.java:37)
at com.rabbitmq.client.ConnectionFactory.<init>(ConnectionFactory.java:153)
at com.zabu.kyimoecho.mosaic.GenericIdentity.<init>(GenericIdentity.kt:11)
at com.zabu.kyimoecho.mosaic.Admin.<init>(Admin.kt:9)
at com.zabu.kyimoecho.mosaic.MainActivity.<init>(MainActivity.kt:10)
at java.lang.Class.newInstance(Native Method)
at android.app.Instrumentation.newActivity(Instrumentation.java:1067)
at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2317)
at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2476)
at android.app.ActivityThread.-wrap11(ActivityThread.java)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1344)
at android.os.Handler.dispatchMessage(Handler.java:102)
at android.os.Looper.loop(Looper.java:148)
at android.app.ActivityThread.main(ActivityThread.java:5417)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:726)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:616)
I've looked online and the suggestions I came across didn't resolve this issue.
I'm using Android 3.3.2, JDK 8 and Rabbitmq 5.6.0.
build.gradle :
....
compileOptions {
sourceCompatibility JavaVersion.VERSION_1_8
targetCompatibility JavaVersion.VERSION_1_8
}
...
dependencies {
implementation 'com.rabbitmq:amqp-client:5.6.0'
.....
}
Just for the sake of reference (if anybody runs into similar issue), I resolved this issue by changing targetSdkVersion to 27 from 24 in build.gradle.
I've faced this same issue. If you see the documentation on this page RabbitMQ Documentation, it says that amqp-client:5.x series library is meant for Android 7 (Nougat) and above. If you are using any Android version below Android 7 then you can use the amqp-client:4.x series library.
I wanted to use both so I got one of the amqp-client:4.x series library source code and recompiled it with a slightly different package name and use the jar file so that I could use both the updated 5.x series for newer Android versions and 4.x series for lower Android versions.
Related
I'm using Micronaut 3.1.3 together with Gradle 7.2 to build my project.
After switching to Gradle 7.3, built breaks emitting some context-free error message:
$ ./gradlew clean build
Executed by Gradle 7.3
- using Java 11.0.13
- using Kotlin 1.5.31
- using Groovy 3.0.9
FAILURE: Build failed with an exception.
* What went wrong:
A problem occurred configuring root project '[PROJECT]'.
> The value for this property is final and cannot be changed any further.
With --stacktrace a very long trace appears. The following excerpt makes me guess
that the problem might lay in the Micronaut plugin:
* Exception is:
org.gradle.api.ProjectConfigurationException: A problem occurred configuring root project '[PROJECT]'.
at org.gradle.configuration.project.LifecycleProjectEvaluator.wrapException(LifecycleProjectEvaluator.java:75)
at org.gradle.configuration.project.LifecycleProjectEvaluator.addConfigurationFailure(LifecycleProjectEvaluator.java:68)
at org.gradle.configuration.project.LifecycleProjectEvaluator.access$400(LifecycleProjectEvaluator.java:51)
[...]
at org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:61)
Caused by: java.lang.IllegalStateException: The value for this property is final and cannot be changed any further.
at org.gradle.api.internal.provider.AbstractProperty$FinalizedValue.beforeMutate(AbstractProperty.java:489)
at org.gradle.api.internal.provider.AbstractProperty.assertCanMutate(AbstractProperty.java:263)
at org.gradle.api.internal.provider.AbstractProperty.setSupplier(AbstractProperty.java:212)
at org.gradle.api.internal.provider.DefaultProperty.set(DefaultProperty.java:71)
at org.gradle.api.tasks.testing.Test.useTestFramework(Test.java:979)
at org.gradle.api.tasks.testing.Test.useJUnitPlatform(Test.java:1049)
at org.gradle.api.tasks.testing.Test.useJUnitPlatform(Test.java:1032)
at io.micronaut.gradle.MicronautLibraryPlugin.lambda$null$1(MicronautLibraryPlugin.java:103)
at org.gradle.configuration.internal.DefaultUserCodeApplicationContext$CurrentApplication$1.execute(DefaultUserCodeApplicationContext.java:123)
[...]
at org.gradle.api.internal.DefaultDomainObjectCollection.withType(DefaultDomainObjectCollection.java:201)
at io.micronaut.gradle.MicronautLibraryPlugin.lambda$apply$4(MicronautLibraryPlugin.java:101)
at org.gradle.configuration.internal.DefaultUserCodeApplicationContext$CurrentApplication$1.execute(DefaultUserCodeApplicationContext.java:123)
[...]
at org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:61)
Cause "problem occurred configuring root project" I'm not sure which part of my
build.gradle raises the problem. So following my first guess regarding Micronaut
plugin, here is an excerpt telling you the list of plugins in use and config of this plugin:
plugins {
id('org.jetbrains.kotlin.jvm') version "${kotlinVersion}"
id('groovy')
id('org.jetbrains.kotlin.kapt') version "${kotlinVersion}"
id('com.github.johnrengelman.shadow') version '7.+'
id('io.micronaut.application') version '2.+'
id('org.jetbrains.kotlin.plugin.allopen') version "${kotlinVersion}"
id('com.google.cloud.tools.jib') version '3.+'
id('org.openapi.generator') version '5.+'
id('com.heroku.sdk.heroku-gradle') version '2.+'
}
[...]
micronaut {
runtime('netty')
testRuntime('spock2')
processing {
incremental(true)
annotations('[PACKAGE]')
}
}
Maybe this gives enough information to tackle down the cause of the problem?
If not please let me know.
Regards
I hit the same issue with my Java build and asked for help on gradle slack channel. It found to be a change in Gradle 7.3 behavior.
This issue contains an explanation of the cause and how to fix it.
It helped me to solve the issue with my build: I had options defined in one of the test tasks and then useJUnitPlatform was applied across all test tasks afterwards using this snippet:
tasks.withType(Test).configureEach {
useJUnitPlatform() // <-- this line was breaking the build
}
This broke the build after migrating to Gradle 7.3. Removing options solved the problem for me.
Here's an issue requesting to convert this breaking behavior to a warning in Gradle 7.3 and make it a breaking change in 8.0.
FYI: Upgrade to Gradle 7.3.1 brings back successful builds.
I'm developing a spring cloud kafka app with kafka streams binder. I have two #Input and one #Output as the following:
internal interface OfferChannel {
companion object {
const val CREATE_OFFER = "create-offer"
const val CREATE_OFFER_COUNTER = "create-offer-counter"
const val OFFER_CREATED = "offer-created"
}
#Input(OFFER_CREATED)
fun offerCreatedChannel(): SubscribableChannel
#Input(CREATE_OFFER_COUNTER)
fun createOfferAdminChannel(): SubscribableChannel
#Output(CREATE_OFFER)
fun createOfferChannel(): MessageChannel
}
During application startup I am getting the following error:
org.springframework.cloud.stream.binder.BinderException: Exception thrown while starting consumer:
at org.springframework.cloud.stream.binder.AbstractMessageChannelBinder.doBindConsumer(AbstractMessageChannelBinder.java:455)
at org.springframework.cloud.stream.binder.AbstractMessageChannelBinder.doBindConsumer(AbstractMessageChannelBinder.java:99)
at org.springframework.cloud.stream.binder.AbstractBinder.bindConsumer(AbstractBinder.java:144)
at org.springframework.cloud.stream.binding.BindingService.lambda$rescheduleConsumerBinding$0(BindingService.java:171)
at org.springframework.scheduling.support.DelegatingErrorHandlingRunnable.run(DelegatingErrorHandlingRunnable.java:54)
at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:834)
Caused by: java.lang.IllegalStateException: Only one LastSubscriberMessageHandler is allowed
at org.springframework.cloud.stream.binder.BinderErrorChannel.subscribe(BinderErrorChannel.java:44)
at org.springframework.cloud.stream.binder.AbstractMessageChannelBinder.registerErrorInfrastructure(AbstractMessageChannelBinder.java:704)
at org.springframework.cloud.stream.binder.AbstractMessageChannelBinder.registerErrorInfrastructure(AbstractMessageChannelBinder.java:627)
at org.springframework.cloud.stream.binder.kafka.KafkaMessageChannelBinder.createConsumerEndpoint(KafkaMessageChannelBinder.java:578)
at org.springframework.cloud.stream.binder.kafka.KafkaMessageChannelBinder.createConsumerEndpoint(KafkaMessageChannelBinder.java:135)
at org.springframework.cloud.stream.binder.AbstractMessageChannelBinder.doBindConsumer(AbstractMessageChannelBinder.java:402)
... 10 common frames omitted
Additionally, if I remove one of the #Input declarations the application starts successfully. Any suggestions what it going wrong here ?
Something is related to the version of the libraries.
For example my task was to switch to 2.4 kafka client with org.springframework.boot version 2.2.3.RELEASE. Firstly I updated to the latest 2.2.10.RELEASE version, you would say it's not a big deal since it's minor version change, well it appears that 2.2.10.RELEASE caused this bug and I had to revert it to 2.2.9.RELEASE.
Next step for my kafka version increase was to follow this tutorial:
https://docs.spring.io/spring-kafka/reference/html/#update-deps
So I set implementation "org.springframework.kafka:spring-kafka:2.4.9.RELEASE", well guess what? 2.4.9.RELEASE also caused the same problem, so I downgraded it to 2.4.8.RELEASE.
My working config (not using latest minor versions):
plugins {
id 'org.springframework.boot' version '2.2.9.RELEASE'
}
ext {
springKafkaVersion = '2.4.8.RELEASE'
kafkaVersion = '2.4.1'
}
dependencies {
implementation "org.springframework.kafka:spring-kafka:$springKafkaVersion"
implementation "org.apache.kafka:kafka-clients:$kafkaVersion"
implementation "org.apache.kafka:kafka-streams:$kafkaVersion"
testImplementation "org.springframework.kafka:spring-kafka-test:$springKafkaVersion"
testImplementation "org.apache.kafka:kafka-clients:$kafkaVersion:test"
}
So the suggestion is to look at your library versions and try to upgrade/downgrade accordingly.
I have the same error when updating spring boot version from 2.2.9 to 2.2.10, current work around is to use the old version. You can check your spring boot version and have a try
I'm using SonarLint 4.1.1.3345 with IntelliJ Community 2019.2 version by binding project to our SonarQube (with SonarJava 5.3 (build 13828)installed) server. However, I got error with below stack trace from SonarLint log:
Java Main Files AST scan
60 source files to be analyzed
Unable to create symbol table for : C:\Users\username\SomeFile.java
java.lang.IllegalArgumentException: Unsupported class file major version 55
at org.objectweb.asm.ClassReader.<init>(ClassReader.java:166)
at org.objectweb.asm.ClassReader.<init>(ClassReader.java:148)
at org.objectweb.asm.ClassReader.<init>(ClassReader.java:136)
at org.sonar.java.resolve.BytecodeCompleter.loadClass(BytecodeCompleter.java:204)
at org.sonar.java.resolve.Symbols.<init>(Symbols.java:176)
at org.sonar.java.resolve.SemanticModel.createFor(SemanticModel.java:59)
at org.sonar.java.model.VisitorsBridge.visitFile(VisitorsBridge.java:110)
at org.sonar.java.ast.JavaAstScanner.simpleScan(JavaAstScanner.java:96)
at org.sonar.java.ast.JavaAstScanner.scan(JavaAstScanner.java:68)
at org.sonar.java.JavaSquid.scanSources(JavaSquid.java:116)
at org.sonar.java.JavaSquid.scan(JavaSquid.java:110)
at org.sonar.plugins.java.JavaSquidSensor.execute(JavaSquidSensor.java:93)
at org.sonarsource.sonarlint.core.analyzer.sensor.SensorsExecutor.executeSensor(SensorsExecutor.java:81)
at org.sonarsource.sonarlint.core.analyzer.sensor.SensorsExecutor.execute(SensorsExecutor.java:72)
at org.sonarsource.sonarlint.core.container.analysis.AnalysisContainer.doAfterStart(AnalysisContainer.java:132)
at org.sonarsource.sonarlint.core.container.ComponentContainer.startComponents(ComponentContainer.java:125)
at org.sonarsource.sonarlint.core.container.ComponentContainer.execute(ComponentContainer.java:110)
at org.sonarsource.sonarlint.core.container.storage.StorageAnalyzer.analyze(StorageAnalyzer.java:75)
at org.sonarsource.sonarlint.core.container.storage.StorageContainerHandler.analyze(StorageContainerHandler.java:82)
at org.sonarsource.sonarlint.core.ConnectedSonarLintEngineImpl.lambda$analyze$0(ConnectedSonarLintEngineImpl.java:152)
at org.sonarsource.sonarlint.core.ConnectedSonarLintEngineImpl.withReadLock(ConnectedSonarLintEngineImpl.java:344)
at org.sonarsource.sonarlint.core.ConnectedSonarLintEngineImpl.withReadLock(ConnectedSonarLintEngineImpl.java:334)
at org.sonarsource.sonarlint.core.ConnectedSonarLintEngineImpl.analyze(ConnectedSonarLintEngineImpl.java:149)
at org.sonarlint.intellij.core.ConnectedSonarLintFacade.analyze(ConnectedSonarLintFacade.java:74)
at org.sonarlint.intellij.core.SonarLintFacade.startAnalysis(SonarLintFacade.java:63)
at org.sonarlint.intellij.analysis.SonarLintAnalyzer.analyzeModule(SonarLintAnalyzer.java:97)
at org.sonarlint.intellij.analysis.SonarLintTask.analyze(SonarLintTask.java:176)
at org.sonarlint.intellij.analysis.SonarLintTask.run(SonarLintTask.java:100)
at org.sonarlint.intellij.analysis.SonarLintUserTask.run(SonarLintUserTask.java:39)
at org.sonarlint.intellij.analysis.SonarLintJobManager.lambda$runTask$1(SonarLintJobManager.java:120)
at com.intellij.openapi.progress.impl.CoreProgressManager.lambda$runProcess$2(CoreProgressManager.java:169)
at com.intellij.openapi.progress.impl.CoreProgressManager.registerIndicatorAndRun(CoreProgressManager.java:591)
at com.intellij.openapi.progress.impl.CoreProgressManager.executeProcessUnderProgress(CoreProgressManager.java:537)
at com.intellij.openapi.progress.impl.ProgressManagerImpl.executeProcessUnderProgress(ProgressManagerImpl.java:59)
at com.intellij.openapi.progress.impl.CoreProgressManager.runProcess(CoreProgressManager.java:156)
at org.sonarlint.intellij.analysis.SonarLintJobManager.lambda$runTask$2(SonarLintJobManager.java:120)
at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:834)
"Unsupported class file major version 55" tells me that the class file Sonar used for code analysis is for java 11 version whereas my class was compiled with java 7 (I took the same class and ran it with javap it showed major version 51), and I don't even have java 11 installed on my system.
Because it works for my teammates. The only difference is they have lower version of IntelliJ installed. So I downloaded IntelliJ 2019.1.4 and it started working.
Could someone explain why it doesn't work with later version of IntelliJ and why the above error occurred? Thanks in advance!
This is a known limitation about classloaders in the IDE/sonarlint/plugin:
https://community.sonarsource.com/t/sonarlint-analysis-fails-on-intellij-2019-2-with-java-11-runtime/12905/3
https://jira.sonarsource.com/browse/SONARJAVA-3056
Example with SonarLint
In SonarLint IntelliJ running environment, this is more or less the
classpath hierarchy:
JDK -> IntelliJ classes -> SonarLint (+deps) [child-first] -> Java
plugin (+packaged deps) [child-first] -> Squid [parent-first]. So
imagine we analyze a class that is using a class X. If IntelliJ's
classloader happens to also use class X (same fully qualified name),
this will be used instead of the X provided in the analysis classpath,
even if they are to different copies of the class (different versions,
for example).
What modules do I have to exclude in my build.gradle file in order to get rid of the following error:
java.lang.VerifyError: Verifier rejected class dji.keysdk.CameraKey due to bad method void dji.keysdk.CameraKey.<init>(dji.sdksharedlib.keycatalog.DJISDKCacheKey) (declaration of 'dji.keysdk.CameraKey' appears in /data/app/pl.company.dev.test-1/base.apk:classes3.dex)
at dji.ux.widget.FPVOverlayWidget.<clinit>(Unknown Source)
at java.lang.reflect.Constructor.newInstance(Native Method)
at java.lang.reflect.Constructor.newInstance(Constructor.java:288)
at android.view.LayoutInflater.createView(LayoutInflater.java:607)
at android.view.LayoutInflater.createViewFromTag(LayoutInflater.java:743)
at android.view.LayoutInflater.rInflate(LayoutInflater.java:806)
at android.view.LayoutInflater.rInflate(LayoutInflater.java:809)
My build.gradle file contains the following DJI dependencies:
implementation 'com.dji:dji-uxsdk:4.9'
compileOnly 'com.dji:dji-sdk-provided:4.9'
androidTestImplementation 'com.dji:dji-uxsdk:4.9'
I want to write some Espresso tests for the activity that uses the DJI UX SDK
What I already tried and didn't work:
rebuild app
invalidate caches and restart in Android Studio
delete folders: build, .idea, .gradle
the whole process on another PC
exclude some unneeded dependencies from the DJI SDK
You should not include the same dependency in the app and the tests.
Everything in the app is already in the classpath of the instrumentation tests.
In your specific case, remove
androidTestImplementation 'com.dji:dji-uxsdk:4.9'
I'm running Gluon/charm version 3.0.0. I added a Java8-compiled library into my JavaFX project (created via the IntelliJ plugin) and on iOS it works and builds as expected, but when executing the gradle tasks android or androidInstall I get this error back:
[ant:java] Java Result: 1
:createMainDexList FAILED
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':createMainDexList'.
> Exception in thread "main" com.android.dx.cf.iface.ParseException: InvokeDynamic not supported
at com.android.dx.cf.cst.ConstantPoolParser.determineOffsets(ConstantPoolParser.java:226)
at com.android.dx.cf.cst.ConstantPoolParser.parse(ConstantPoolParser.java:132)
at com.android.dx.cf.cst.ConstantPoolParser.parseIfNecessary(ConstantPoolParser.java:124)
at com.android.dx.cf.cst.ConstantPoolParser.getPool(ConstantPoolParser.java:115)
at com.android.dx.cf.direct.DirectClassFile.parse0(DirectClassFile.java:491)
at com.android.dx.cf.direct.DirectClassFile.parse(DirectClassFile.java:406)
at com.android.dx.cf.direct.DirectClassFile.parseToEndIfNecessary(DirectClassFile.java:397)
at com.android.dx.cf.direct.DirectClassFile.getAttributes(DirectClassFile.java:311)
at com.android.multidex.MainDexListBuilder.hasRuntimeVisibleAnnotation(MainDexListBuilder.java:191)
at com.android.multidex.MainDexListBuilder.keepAnnotated(MainDexListBuilder.java:167)
at com.android.multidex.MainDexListBuilder.<init>(MainDexListBuilder.java:121)
at com.android.multidex.MainDexListBuilder.main(MainDexListBuilder.java:91)
at com.android.multidex.ClassReferenceListBuilder.main(ClassReferenceListBuilder.java:58)
...while preparsing cst 0002 at offset 0000000f
...while parsing de/<removed>/traffic_light/library/Test.class
What I find a bit weird is that I don't even have a Test class for traffic_light, not even in the library. Searching for the error I found that it probably needs Java 8 to invokeDynamic/Support Lambdas, but for example Gluon's Presenter itself uses Lambdas.
Also, googling I find this hit about the same issue but sadly Gluon removed their forum and the page isn't cached anywhere.
Typically this error happens when you add some third party dependencies to the project that use lambda expressions, since currently the retrolambda plugin is applied to the source code of your project only.
You can try:
Remove that dependency and add its source code instead.
Apply retrolambda to the original dependency, and then add it to your project.
Or use the most recent jfxmobile plugin: the 1.0.10-SNAPSHOT will apply retrolambda to both the source code and the third party dependencies (even if no source code is provided).
For the last option, just change the jfxmobile plugin version on top of your build.gradle file:
buildscript {
repositories {
jcenter()
maven {
url "https://oss.sonatype.org/content/repositories/snapshots/"
}
}
dependencies {
classpath 'org.javafxports:jfxmobile-plugin:1.0.10-SNAPSHOT'
}
}