Replies: 1 comment 1 reply
-
When compiling your application's source code, the compiler only checks things directly referenced by your application's source code. Your application's source code most likely does not directly reference
Your application is using logstash-logback-encoder 6.6, which was compiled against logback-core 1.2.3, which was compiled against slf4j 1.7.25, which defines Later, when the compiler compiles your application's source code against logstash-logback-encoder 6.6, logback-core 1.2.3, and slf4j 1.7.7, the compiler did not report any problems, because your application's source code did not reference However, at runtime, when your application runs with logstash-logback-encoder 6.6, logback-core 1.2.3, and slf4j 1.7.7 on the classpath, the jvm will throw the ClassNotFoundException because it loaded the bytecode for a class from logback-core 1.2.3 which requires |
Beta Was this translation helpful? Give feedback.
-
Hi, I am using
logstash-logback-encode
6.6, and my application throws the following runtime exception:I know it has to do with maven dependencies, and the exception goes away after doing the following upgrade:
"org.slf4j" & "slf4j-api" & "1.7.7" -> "org.slf4j" & "slf4j-api" & "1.7.36"
But I would like to know why this is a runtime exception, instead of just failing at the compile time?
From my understanding,
ClassNotFoundException
is thrown when the classloader cannot find it from the classpath.However, wouldn't this be something that a compiler checks, during some sort of linking process?
I am pretty new to Java and would appreciate any guidance / insights provided.
Thank you for your help!
Beta Was this translation helpful? Give feedback.
All reactions