Hi Yosuf,

I’ve opted for a more provocative and playful approach in order to spark conversation about everyone’s perception the future of Java. Would I have included all the nuances It would have likely been a bland read and you would have perhaps been less included to give your perspective.

I agree that recent initiatives clearly slow that Java is capable of change. But even with the recent improvements and writing non-blocking code with reactive programming to minimize the impact of its rather dated concurrency model, it’s just able to match other languages. It doesn’t beat them at anything. Python and Go have been around for long enough to be thoroughly battle tested in a wide array of context and their ecosystem is mature.

Research indicated that there is more interest in languages like Python and Go and there is not argument that I have for them to have a look at Java instead when looking to build robust, scalable cloud microservices.

Having a small footprint is not about building the smallest container possible, because that’s a bad way to scope microservices. It’s about being able to have robustness (multi-instance) and elasticity (elastic scaling) at competitive running cost.

While not part of the Java discussion, one thing stood out in your comment and that is the comment on smaller services and containers pushing Continuous Integration till later in the process. My experience is completely the opposite. It’s easy to do contract first (for both events and REST) due to clear service boundaries. These boundaries also help with writing clear integration tests and spinning up dependencies in containers is easy. Containers also provide a ton of flexibility when it comes to doing test automation as easy and as fast as possible:

• Spin up multiple testing environments in parallel instead of queueing test suites because there’s only one environment.

• It’s much easier to test non-happy flows where components are down in an automated fashion without impacting others by spinning up a dedicated environment, kill a dependency and asserts how the component under test handles it.

And it does this all with the benefit that these environments can be spun down when not used, which is way more cost effective.