When using Java, with say, jib and skaffold, when a change is detected the image is rebuilt with some fairly smart cacheing being done to minimize the build time.
> Spring Loaded goes a little further in that it can reload class definitions with changes in the method signatures. With some customization it can force an ApplicationContext to refresh itself (but there is no general mechanism to ensure that would be safe for a running application anyway, so it would only ever be a development time trick probably).
And this way, the container can remain the same with the class files being changed underneath it.
It depends what you need to do. If you build a golang binary in a container and run go mod tidy, you get hit by it. If you build a java app with, say, maven, you will pull deps into a volume mount and you get hit by it. Of course, you can mount a host dir to avoid the problem to a certain extent.
In more interesting setups, the class files aren't in the image but rather mapped in - much the same way one would with dynamic and then a hot reload - https://docs.spring.io/spring-boot/docs/1.3.8.RELEASE/refere...
> Spring Loaded goes a little further in that it can reload class definitions with changes in the method signatures. With some customization it can force an ApplicationContext to refresh itself (but there is no general mechanism to ensure that would be safe for a running application anyway, so it would only ever be a development time trick probably).
And this way, the container can remain the same with the class files being changed underneath it.
https://github.com/spring-projects/spring-loaded