Develop Reference

JDK version updated, now Karate tests cannot be found [duplicate]

This question already has answers here:
karate.callSingle not found .feature file in karate-config.js
(2 answers)
Closed 1 year ago.
Today our IT department initialized an automatic uninstall of Java JDK 14 due to some security concern. I downloaded the latest, JDK 16, and updated all of my project settings using this as a guide: Error:java: invalid source release: 8 in Intellij. What does it mean?
I also updated the JAVA_HOME environment variable and the path variable. However, when attempting to run my Karate automation tests using IntelliJ like I normally do, I am getting an error that no tests were found. Here is the full system response when trying to run a test:
Exception in thread "main" java.lang.ExceptionInInitializerError
at com.intuit.karate.Runner$Builder.tagSelector(Runner.java:80)
at com.intuit.karate.Runner.parallel(Runner.java:309)
at com.intuit.karate.Runner$Builder.parallel(Runner.java:190)
at com.intuit.karate.cli.Main.main(Main.java:59)
at cucumber.api.cli.Main.main(Main.java:34)
Caused by: java.lang.NullPointerException: Cannot invoke "javax.script.ScriptEngine.createBindings()" because "com.intuit.karate.ScriptBindings.NASHORN" is null
at com.intuit.karate.ScriptBindings.createBindings(ScriptBindings.java:160)
at com.intuit.karate.core.Tags.<init>(Tags.java:158)
at com.intuit.karate.core.Tags.<clinit>(Tags.java:48)
... 5 more
Process finished with exit code 1
Apparently this is a problem with JDK versions above 14. I tried to troubleshoot with this video: https://www.youtube.com/watch?v=8bHeDl3tdoo
But after making that change to the pom.xml file, now I'm getting a new error:
SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in [jar:file:/C:/Users/allison_crenshaw/.m2/repository/ch/qos/logback/logback-classic/1.2.3/logback-classic-1.2.3.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in [jar:file:/C:/Users/allison_crenshaw/.m2/repository/org/apache/logging/log4j/log4j-slf4j-impl/2.14.0/log4j-slf4j-impl-2.14.0.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.
SLF4J: Actual binding is of type [ch.qos.logback.classic.util.ContextSelectorStaticBinder]
I visited the page it recommends (http://www.slf4j.org/codes.html#multiple_bindings) but I don't really understand how to proceed after reading the explanation. I tried adding in the exclusion it recommends but my pom.xml file is really long so I wasn't really sure where the exclusion code belonged in the grand scheme of things. I tried putting it just under the code recommended by the YouTube video to resolve the binding issue but I got the same error about the class path containing multiple SLF4J bindings.
Thanks in advance for any help.

Please upgrade to Karate 1.0 (1.1.0 is the latest as of now) because old versions don't support newer Java versions.
Note that you may need to make a few changes: https://github.com/intuit/karate/wiki/1.0-upgrade-guide

This SLF4J message is not an error but just a warning:
SLF4J API is designed to bind with one and only one underlying logging framework at a time. If more than one binding is present on the class path, SLF4J will emit a warning, listing the location of those bindings.
[...]
NOTE The warning emitted by SLF4J is just that, a warning. Even when multiple bindings are present, SLF4J will pick one logging framework/implementation and bind with it.
[Emphasis by me.]
If the logging framework that has been selected is fine for you, you don't have to worry. If you want to get rid of the message you can check with mvn dependency:tree on your project which dependency pulls in which logging framework and set <exclusions> in your POM for those you don't want.

Error during SonarScanner execution after executing SonarScanner.MSBuild.exe end command

Sonarqube Version -7.9.5
SonarQube Scanner - sonar-scanner-msbuild-5.0.4.24009-net46
Source code contains - C#, angular.js, html5, javascript.
Hi,
I executed the following commands and after executing the 3rd command I am getting execution failure error.
The command I executed in the CMD prompt are browsing to the path where solution is present are,
SonarScanner.MSBuild.exe begin /k:"Demo" /d:sonar.host.url="http://localhost:9000" /d:sonar.login="TokenID_ABC"
MsBuild.exe /t:Rebuild
SonarScanner.MSBuild.exe end /d:sonar.login="TokenID_ABC"
ERROR: Error during SonarScanner execution
org.sonar.java.AnalysisException: Please provide compiled classes of your project with sonar.java.binaries property
I found one similar kind of issue reported where it is said that due to .java file present in the code the issue occurs, in our code as well .java files are present, not sure the use of them. How can I exclude those .java files while SonarQube analysis is performed and in which file do I need to add exclusion code?
Also, if there is some another solution to resolve this issue, then please let me know as I have very limited knowledge of Sonar.
Link of similar issue -
https://community.sonarsource.com/t/error-while-running-sonar-scanner-please-provide-compiled-classes-of-your-project-with-sonar-java-binaries-property/30027/2

You can exclude arbitrary files by going to your project settings in SonarQube -> Analysis Scope -> Source File Exclusions. Use regex to match your java files, i.e. *.java.

How to fix undefined MqttChannelInitializer constructor in HiveMQ Client?

I was using HiveMQ Client version 1.0.1 but I decided to update to the recently released version 1.1. I completely started from scratch and imported the project as a Gradle project and tried to build. The build work only after ignoring a few failed tests. I'm getting 3 errors in 3 different classes. I realize this is likely related to the Dagger dependency injection tool and I had already successfully built the project and added the directory of build/generated/source/apt/main/ to my build path as noted by my previous stack post where I had issues with a DaggerSingletonComponent not being found: How to fix DaggerSingletonComponent not resolved in HiveMQ (MQTT protocol) . This seems to be a new issue and I'm not sure what's wrong. I tried rebuilding by project but the errors still persist. I've left some screenshot below as well as the specific errors.
HiveMQ:
https://github.com/hivemq/hivemq-community-edition
https://github.com/hivemq/hivemq-mqtt-client
Errors:
The constructor MqttChannelInitializer(MqttClientConfig, MqttConnAckFlow, MqttEncoder, MqttConnectHandler, MqttDisconnectHandler, MqttAuthHandler, Lazy) is undefined
The constructor MqttSession(MqttClientConfig, MqttSubscriptionHandler, MqttIncomingQosHandler, MqttOutgoingQosHandler) is undefined
The method provideBootstrap(NettyEventLoopProvider, MqttChannelInitializer) in the type ConnectionModule is not applicable for the arguments (MqttClientConfig, NettyEventLoopProvider, MqttChannelInitializer)
Screenshots:

Executing ./gradlew clean build on the command line will fix your error.
But I also think that the real solution for your use case is to create a new empty project (gradle or maven) and add the client library as a dependency, like described here: https://hivemq.github.io/hivemq-mqtt-client/docs/installation.html

The issue turned out to be caused by an issue with the source folder in the directory build/generated/source/apt/main/ not having the option “Update exclusion filters in other source folders to solve nesting” selected. Selecting that option solved all of the errors.

IntelliJ won't accept FileTypeFactory

I am attempting to follow the Language and File Type tutorial for JetBrains IntelliJ
It worked, once. Now (whatever I do) I receive an assertion failure stating that it was expecting an instance of FileTypeFactory and got my SimpleFileTypeFactory
My public class SimpleFileTypeFactory extends com.intellij.openapi.fileTypes.FileTypeFactory so I'm not sure how to react to this ...
Caused by: java.lang.AssertionError: Expected: class com.intellij.openapi.fileTypes.FileTypeFactory; Actual: class bengie.idea.SimpleFileTypeFactory
at com.intellij.openapi.extensions.impl.ExtensionPointImpl.assertClass(ExtensionPointImpl.java:408)
at com.intellij.openapi.extensions.impl.ExtensionPointImpl.processAdapters(ExtensionPointImpl.java:242)
at com.intellij.openapi.extensions.impl.ExtensionPointImpl.getExtensions(ExtensionPointImpl.java:185)
... especially when Google has no matches for "Expected: class com.intellij.openapi.fileTypes.FileTypeFactory; Actual"
Has anyone resolved this sort of thing?

I was depending on a Maven module (actually, two of them) The rest of my project is built with Maven so it seemed logical and looked like it would work. I didn't remember the build seizing up when I added them, so I had forgotten about it. Removing the dependency, starting a debug session, uninstalling the plugin, rinse, repeat and I eventually stopped seeing error messages.
I've since stuffed the maven modules into a jar-with-dependencies and told the IntelliJ plugin module to load the resulting .jar No problems so far - Yay!

Hudson's FindBugs plugin reports line number "-1" for bugs. Ideas?

Greetings,
I have a simple test project set up in Hudson and the project's build process (a batch file) generates a findbugs.xml file. This is processed by Hudson's FindBugs plugin but it shows the line number of the bugs as "-1" instead of their actual line number. A coworker suggested I enable debug info for the compiler. I used the -g "Generate all debugging info" option for javac but nothing seemed to change. My build command is:
javac -g -classpath C:\testWebApp1\src -d C:\testWebApp1\build C:\testWebApp1\src\*.java
The only other thing in the build.bat file is a call to the FindBug tool (text UI). Here is what the FindBugs Plugin says about the first bug:
File: GenerateHellos.java, Line: -1, Type: UUF_UNUSED_FIELD, Priority: Normal, Category: PERFORMANCE
Any ideas? Thanks a ton!

This is half of an answer:
You have an unused field declared in that class. FindBugs uses static analysis of byte code to find bugs; unfortunately, the byte code format does not store line numbers for class or member fields, so FindBugs can't actually report a line number. There's got to be some switch that will allow it to output more helpful information (i.e. the name of the field), but I have no idea.
Alternatively, you might try PMD, which is a lot noisier, but actually analyzes the source code and also integrates with Hudson.
Did a little more digging and it looks like this is probably a bug in the inspector for that bug pattern. Assuming that your FindBugs run is configured with a n appropriate source directory (i.e., using -sourcepath), the majority of the bugs found should have line numbers associated with them. To check this, open the outputted report. You should see elements like the following:
<!-- skipping a bit -->
<BugInstance type="...">
<Class classname="com.example.MyClass">
<!-- ... -->
</Class>
<!-- ... -->
<SourceLine classname="com.example.MyClass" start="5" end="5" sourcefile="MyClass.java"/>
</BugInstance>
The key there is the <SourceLine classname="..."/>, which reports the line number that the bug was found on. For numerous other inspections, including those for unread fields and a couple of other cases where their are no line numbers in the byte code, this line is filled in correctly, but not for UUF_UNUSED_FIELD. Hence, the Hudson plugin is doing the sensible thing and reporting line = -1.
The Eclipse plugin, however, which has access to Eclipse's rich metadata about the source code is able to locate the field by matching the field name, hence, it appearing to work in Eclipse (if you delete the field in question in Eclipse you should see the bug show up on the first line of the file; other bugs show up on the line number specified in the XML report).
No fix, but hopefully that clarifies what is happening.

You are almost there with the -g. Findbugs is based on bytecode analysis, and depends on the debugging information that is in the class files, your coworker is right about that.
You also need to clean out any previously generated class files, as the compiler is based on timestamps, and won't regenerate files that appear up-to-date.