|
|
|
|
|
by _hilro
1737 days ago
|
|
from OP
> Could you clarify what you ran into? Why docker? Not sure I follow why you had to turn to docker > Some things might even surprise you and run for a while before a classloader can't find something and explodes in runtime. The JVM is deterministic - I don't follow this statement? |
|
I didn't, and OP could have stuck with Java8 since it's LTS. So I'm not sure either where Docker comes into play. It seems the parent was deploying fat jars, and now due to the complications of all the various deps, they opted to use Docker images as a new "fat jar". Perhaps it simplified their build process, but that's just a guess.
> The JVM is deterministic - I don't follow this statement?
Custom classloading simply requires a string path and FQN of the class to attempt to load it from disk. Compile time checking doesn't validate the actual existence of the class, which is the point of runtime custom class loaders.
A lot of plugin loaders are done this way, etc. So... your program might be humming along just fine until it classloads in a plugin (or whatever) that depends on Jaxb for example, then everything explodes since Jaxb is now a dep instead of built into the jdk.