Recently I am working on container/helmg/k8s-ing a scala spark app.
I am having an issue:
Caused by: java.lang.RuntimeException: java.lang.ClassCastException:
when I have to use
It is a well-solved problem, if we are using maven to build the jar and make use of shaded jar.
Unfortunally we are using bazel to do the build, and we don’t have a good solution to shade a jar.
Before diving into details of the problem, let me briefly introduce how we are doing the build in bazel.
We currently make use
rules_jvm_external to manage all maven dependencies. We mark all spark related jars as
neverlink = True.
We also marked scala-library as neverlink
The WORKSPACE looks like this
You might ask why we have two maven repos - this is the our current solution to mimic maven provided scope.
You can think the
maven one is to provide only compile dependencies (we mark those we don’t want to appear in the uber/fat jar (we use uber jar and fat jar interchangeabley) as neverlink), and the
maven_runtime is to provide runtime dependencies only. In an environment that the dependencies are provided (jars are provided, and no need to packaged into the fatjar), we don’t have to do anything as these jars have been marked as
neverlink and are not in the jar. We mostly use the
maven_runtime deps only in test scenarios, when we need to provide the jars (package the jars in the fatjar).
In the BUILD file, we mix use bazel scala and java rules to do the build.
The build file is like this
On the java_binary target, we build uber jar by build on the implicit target
spark-app_deploy.jar, which is how bazel builds the fat jar.
Now I can finally talk about the problem.
We found by building fatjar in this way, if you unzip the fatjar, it always contains the scala-library.
like these you will see
While it is counter-intuitive as we have marked the ``org.scala-lang:scala-library:2.11.12` as neverlink, it shouldn’t be included in the uber jar.
At a second think, it might make senses, as the purpose of an uber jar is a self-contained jar that can execute without the need of anything else.
It seems like there is a special handling for the
scala-library when we build uber jar for scala. In order to make the jar can run by itself, the fatjar probably needs to include the scala-library.
It would be fine for most cases, if you don’t set
true as the spark app will always use the jars shipped with spark package in your enviroment first.
However, if you happen to have to useClassPathFirst, then you might run into the jar conflicting.
If the conflicting jar is a java jar, we could already solve it by the
Thing goes werid, when it happens to be the scala-library.
We are using the spark 2.4.5 as base container image, and I checked in the
/opt/spark/jars in the container file system, we have a jar named
scala-library-2.11.12.jar which is exactly the verion we are using. My understanding is in this case, even if we include the scala-library in the jar, it should be fine. But it was not. If someone knows why please let me know. Anyway, I am getting the
java.lang.ClassCastException error, which seems only happen, if our app jar includes a scala-library. It also seems we have scala-library conflicting even if it is the identical version.
The path I didn’t take is to NOT make use
I gave it a quick try by not using
userClassPathFirst, then I started to fall into another rabbit hole with many other jar conflicts like
fastxml etc. TBH, I still prefer we can use
userClassPathFirst, since we have the freedom to control what jars are packaged in our app and use them in priorities. We don’t need to change the provided jars in the spark app base images from time to time.
Given that we really want to stick with
userClassPathFirst, The main intuition of solution is to exclude the scala-library from deploy jar (the fatjar).
Normally, we can make use of either
deploy_env with bazel for this purpose.
I am guessing the the neverlink works on most of java/scala deps but not the scala-library as it is the standard library every scala app would need to run, so the neverlink is not hornored for scala-library. (need someone who is more faimilar with bazel build for scala to confirm this)
Then I have to try the other one which is
As the doc says:
A list of other java_binary targets which represent the deployment environment for this binary. Set this attribute when building a plugin which will be loaded by another java_binary.
Setting this attribute excludes all dependencies from the runtime classpath (and the deploy jar) of this binary that are shared between this binary and the targets specified in deploy_env.
deploy_env gives you a way to substract certain deps from you uber jar.
In order to make use of it, I need to make some changes to the build file.
- every place I use
scala_libraryI need to do a
java_importthen use the
like below to cut the tie to
Not knowing the why it works, my finding is that if the
java_binary deps on a
scala_library directly, if you build uber jar, it will always include the
deploy_envto substract whatever is conflicting. This can serve as a generic approach to address spark scala app jar dependencty confliction.
We have to use
"@maven//:org_scala_lang_scala_library" has been marked neverlink in our maven repo setup, so it will have no effect if i am using
"@maven//:org_scala_lang_scala_library" to do the substraction.
While our two-maven-repo-with-neverlink approach works really well before I encoutered this problem,
deploy_env seems not bad at all, need to spend more efforts to check can we get rid of the two maven repo appraoch and solve all our need of neverlink by
At last, the easies way to validate the fix is to unzip your deploy jar and it should NOT contain any class like these:
I have to admit this finding and solution is all trials and erros. I would like to know if this can be done better and knowing the details underneath. You can find me on twitter.