Develop Reference

IntelliJ doesn't recognize TypeTag in Scala

I'm trying to compile these 2 lines of code in Scala (using Gradle):
import import scala.reflect.runtime.universe._
val typeInt = typeTag[Int]
It turns out somehow that IntelliJ mark the word runtime with the color red. and throw me this error: object runtime is not a member of package reflect one error found
Now, the weird thing for me, is when I'm using the Scala REPL, it finds this package without any issue.
scala> import scala.reflect.runtime.universe._
import scala.reflect.runtime.universe._
scala> val typeInt = typeTag[Int]
val typeInt: reflect.runtime.universe.TypeTag[Int] = TypeTag[Int]
Gradle's build.gradle file
plugins {
id 'java-library'
id 'scala'
id 'com.github.maiflai.scalatest' version '0.26'
}
repositories {
jcenter()
}
dependencies {
implementation 'org.scala-lang:scala-library:2.13.3'
implementation 'com.fasterxml.jackson.module:jackson-module-scala_2.13:2.9.9'
implementation 'com.typesafe:config:1.4.0'
testCompile 'org.scalamock:scalamock_2.13:4.4.0'
testCompile 'org.scalatest:scalatest_2.13:3.1.2'
testRuntimeOnly 'com.vladsch.flexmark:flexmark-all:0.35.10'
}
Versions
IntelliJ IDEA - Community - Version 2020.2.3
JDK - Version 14.0.1
macOS Catalina - Version 10.15.7
Scala - Version 2.13.3
Gradle - Version 6.7

According to your build.gradle you didn't add scala-reflect dependency
https://mvnrepository.com/artifact/org.scala-lang/scala-reflect/2.13.3
scala-library is not enough if you want to use Scala reflection.
Try to add scala-reflect
implementation 'org.scala-lang:scala-reflect:2.13.3'

Why does Kotlin JDK8 also include Kotlin JDK7 on the classpath?

I'm using Kotlin to build a web service and I stumbled upon what I consider to be a strange curiosity. With this build.gradle:
group 'com.example'
version '0.1.0'
buildscript {
ext.kotlinVersion = '1.2.71'
repositories {
mavenCentral()
}
dependencies {
classpath "org.jetbrains.kotlin:kotlin-gradle-plugin:$kotlinVersion"
}
}
apply plugin: 'kotlin'
sourceCompatibility = 1.8
repositories {
mavenCentral()
}
dependencies {
compile "org.jetbrains.kotlin:kotlin-stdlib-jdk8:$kotlinVersion"
compile 'com.fasterxml.jackson.module:jackson-module-kotlin:2.9.8'
}
compileKotlin {
kotlinOptions.jvmTarget = "1.8"
}
compileTestKotlin {
kotlinOptions.jvmTarget = "1.8"
}
I get this error during compilation:
w: Runtime JAR files in the classpath should have the same version. These files were found in the classpath:
.../kotlin-stdlib-jdk8-1.2.71.jar (version 1.2)
.../kotlin-stdlib-jdk7-1.2.71.jar (version 1.2)
.../kotlin-reflect-1.3.10.jar (version 1.3)
.../kotlin-stdlib-1.3.10.jar (version 1.3)
.../kotlin-stdlib-common-1.3.10.jar (version 1.3)
OK, no problem, jackson-module-kotlin is pulling in the kotlin 1.3 dependencies. I can exclude them. But the bit that caught my attention was the second line. kotlin-stdlib-jdk8 is also pulling in kotlin-stdlib-jdk7. In fact, I can exclude it and everything still runs as expected:
compile("org.jetbrains.kotlin:kotlin-stdlib-jdk8:$kotlinVersion") {
exclude group: "org.jetbrains.kotlin", module: "kotlin-stdlib-jdk7"
}
Why is kotlin-stdlib-jdk8 pulling onto my classpath the seemingly unnecessary kotlin-stdlib-jdk7?

The warning you see during the compilation happens because jackson-module-kotlin:2.9.8 dependency apparently brings kotlin-stdlib:1.3.10 into the classpath and that version overrides your declared dependency on 1.2.71. To avoid warning you should either migrate your project to Kotlin 1.3.x or downgrade jackson-module-kotlin dependency to some previous version which depends on Kotlin 1.2.x.
kotlin-stdlib-jdk8 is an addition on top of kotlin-stdlib-jdk7, and the latter is addition on top of kotlin-stdlib. You should not exclude these transitive dependencies, otherwise you might get runtime errors.

The kotlin-stdlib-common, kotlin-stdlib-jdk7, and kotlin-stdlib-jdk8 seem to be mutually exclusive from what I could see inside the jars. That's why you need the jdk7 artifact even if you use the jdk8.
The kotlin-stdlib-jdk7 jar only contains things that were added in JDK7 like AutoCloseable and other internal apis. This is not included in the JDK8 artifact, which only include things added in JDK8.
If you don't use the use or closeFinally global functions, your code should work fine without the jdk7 artifact, but there is no real reason to exclude this jar IMHO.

NoClassDefFoundError at Runtime with Gradle

I'm using gradle as the JavaFX plugin.
Everything works perfectly even after building and runnig the excecutable at distribution/, except with one class: CloseableHttpClient
For several purposes I create the following object like this:
CloseableHttpClient client = HttpClients.createDefault();
Running the program in the IDE is no problem, everything works fine. But if I build and try to run the .exe-File I get the following Throwable-StackTrace:
java.lang.NoClassDefFoundError: Could not initialize class org.apache.http.conn.ssl.SSLConnectionSocketFactory
at org.apache.http.impl.client.HttpClientBuilder.build(HttpClientBuilder.java:955)
at org.apache.http.impl.client.HttpClients.createDefault(HttpClients.java:58)
at ch.itcb.tools.lom.util.JsonSimpleUtil.http(JsonSimpleUtil.java:29)...
I really don't understand that. How can it be that just this class doesn't get found, but all my other classes do?
My build.gradle file:
apply plugin: 'java'
apply plugin: 'eclipse'
apply from: 'javafx.plugin'
sourceCompatibility = 1.8
version = '0.1'
jar {
manifest {
attributes 'Implementation-Title': 'LogoffManager',
'Implementation-Version': version
}
}
repositories {
mavenCentral()
}
dependencies {
compile fileTree(dir: 'lib', include: ['*.jar'])
compile 'ch.qos.logback:logback-classic:1.1.3'
compile 'org.apache.httpcomponents:httpclient:4.5.1'
compile 'com.googlecode.json-simple:json-simple:1.1'
compile group: 'commons-collections', name: 'commons-collections', version: '3.2'
testCompile group: 'junit', name: 'junit', version: '4.+'
}
test {
systemProperties 'property': 'value'
}
uploadArchives {
repositories {
flatDir {
dirs 'repos'
}
}
}
Please write a comment if you need more information. Thx.

it's a good question, which I came across just now while researching examples of the many ways Java developers can end up with class path fun :-)
I started with a minimal version of your build.gradle (including only what's directly relevant), specifically:
plugins {
id 'java'
}
sourceCompatibility = 1.8
repositories {
mavenCentral()
}
jar {
manifest {
attributes 'Main-Class': 'com.oliverlockwood.Main'
}
}
dependencies {
compile 'org.apache.httpcomponents:httpclient:4.5.1'
}
My 'Main' class, in this context, uses your code example, i.e.:
package com.oliverlockwood;
import org.apache.http.impl.client.CloseableHttpClient;
import org.apache.http.impl.client.HttpClients;
public class Main {
public static void main(String[] args) {
CloseableHttpClient client = HttpClients.createDefault();
}
}
At this stage, I can run gradle clean build followed by java -jar build/libs/33106520.jar (my project was named after this StackOverflow question) and I see this:
Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/http/impl/client/HttpClients
at com.oliverlockwood.Main.main(Main.java:8)
Caused by: java.lang.ClassNotFoundException: org.apache.http.impl.client.HttpClients
at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
This is subtly different from your error, but before we dig and reproduce that, let me emphasise something: both this error and the one you're seeing are caused at runtime when the classloader is unable to find a class that it needs. There's quite a good blog post here with some more details about the difference between compile-time classpath and runtime classpaths.
If I run gradle dependencies I can see the runtime dependencies for my project:
runtime - Runtime classpath for source set 'main'.
\--- org.apache.httpcomponents:httpclient:4.5.1
+--- org.apache.httpcomponents:httpcore:4.4.3
+--- commons-logging:commons-logging:1.2
\--- commons-codec:commons-codec:1.9
I added these manually one-by-one to my runtime classpath. (For the record, this isn't generally considered good practice; but for the sake of the experiment, I copied these jars to my build/libs folder and ran with java -cp build/libs/33106520.jar:build/libs/* com.oliverlockwood.Main. Interestingly enough, this wasn't able to reproduce your exact problem. To recap:
Without org.apache.httpcomponents:httpclient available at runtime, then we fail because the HttpClients jar is not found.
With org.apache.httpcomponents:httpclient:4.5.1 available at runtime, then your problem does not manifest - and I note that the class your build fails to find (org.apache.http.conn.ssl.SSLConnectionSocketFactory) is part of this same Apache library, which is very suspicious indeed.
My suspicion is then that your runtime classpath contains a different version of the Apache httpclient library. Since there's a whole lotta versions out there, I'm not going to test every single combination, so I will instead leave you with the following advice.
If you want to fully understand the root cause of your issue, then identify exactly which jars (including their versions) are present in your error-case runtime classpath, including any jars that are packaged inside yours if you're creating a fat jar (more on this in point 3). It'd be great if you shared these details here; root cause analysis usually helps everyone to understand better :-)
Where possible, avoid using dependencies in the manner of compile fileTree(dir: 'lib', include: ['*.jar']). Managed dependencies based on a repository such as Maven or JCenter are much easier to work with consistently than dependencies in a random directory. If these are internal libraries that you don't want to publish to an open-source artifact repository, then it may be worth setting up a local Nexus instance or similar.
Consider producing a "fat jar" instead of a "thin jar" - this means that all runtime dependencies are packaged in the jar that you build. There's a good Shadow plugin for Gradle that I'd recommend - with this in place in my build.gradle, and running gradle clean shadow, I was able to run java -jar just fine without needing to manually add anything to my classpath.

For Spring boot users, this can be solved with one line of code. I am using Gradle/Kotlin, so:
id("org.springframework.boot") version "2.5.5"
inside the plugins {} section of your build.gradle.kts
For more information visit the Spring Boot Gradle Plugin Reference Guide.

For my case, I turned on my InteliJ after 3 months, got some runtime errors like noclassdeffounderror. I have to *** refresh gradle ***, then the errors are gone.

Gradle: package com.parse does not exist

I am trying to add the Parse SDK into my app. Here is the steps I took:
Dragged all Parse files into my libs folder
Add the following lines to my code:
import com.parse.Parse;
import com.parse.ParseAnalytics;
Went to my build.gradle and added:
compile files('libs/Parse-1.4.1-javadoc/Parse-1.4.1.jar')
However I am still getting these errors:
Gradle: package com.parse does not exist
Gradle: package com.parse does not exist

Change compile files('libs/Parse-1.4.1-javadoc/Parse-1.4.1.jar') to compile files('libs/Parse-1.4.1.jar')

If you see your jar file in explorer on the left side, click right button of your mouse and then 'Add as Library'. It just helped me.

I added the Parse-SDK into my app as follows:
Dependency: Add this in your root build.gradle file (not your module build.gradle file):
allprojects {
repositories {
...
maven { url "https://jitpack.io" }
}
}
Then, add the library to your project build.gradle
dependencies {
implementation "com.github.parse-community.Parse-SDK-Android:parse:*latest.version.here*"
// for FCM Push support (optional)
implementation "com.github.parse-community.Parse-SDK-Android:fcm:*latest.version.here*"
// for Kotlin extensions support (optional)
implementation "com.github.parse-community.Parse-SDK-Android:ktx:*latest.version.here*"
}
replacing latest.version.here with the latest released version (in my case 1.18.5).
More details here: https://github.com/parse-community/Parse-SDK-Android/.
I am not to sure if that achieves the same purpose as what you wanted.

Why does Gradle's java compilation classpath not contain a specified dependency

I'm using gradle to build a groovy/java application.
This worked fine until I added a dependency to google guice 3.0.
Gradle does not add the guice jars to the compilation classpath, at least it seems so.
I get errors like these:
C:\dev\workspaces\initial>gradle -q compileJava
C:\dev\workspaces\initial\src\main\java\com\comp\test\solmon\di\GuiceDI.java:3: package com.google.inject does not exist
import com.google.inject.Guice;
^
C:\dev\workspaces\initial\src\main\java\com\comp\test\solmon\di\GuiceDI.java:4: package com.google.inject does not exist
import com.google.inject.Injector;
In my build.gradle file I have the following dependencies:
dependencies{
runtime 'com.beust:jcommander:1.27'
runtime "org.slf4j:slf4j-api:1.7.1"
runtime "ch.qos.logback:logback-classic:1.0.7"
runtime 'com.google.inject:guice:3.0'
testRuntime 'junit:junit:4+'
}
I'm developing the application in Springsource Tool Suite 2.9.2 with its gradle plugin and it uses gradles dependency management to get all dependencies. Sts manages to compile the code just fine, it's only gradle that fails.
I've tried to run the gradle compilation with the "--debug" parameter but I can not see which classpath gradle gives to the compiler.
Any ideas how to get gradle to compile my application?

You've added Guice to the runtime dependencies (i.e. the dependencies necessary to run the application, but not to compile it). Add it to the compile dependencies:
dependencies {
...
compile 'com.google.inject:guice:3.0'
}
A compile dependency is also a runtime dependency, obviously.