Well if applications of future are to be developed and delivered as it is today Java will very likely remain primary choice. But with containerized deployment Java solutions looks rather heavyweight. Oracle/IBM/SAP know this. I think that's why work on Java EE 8 is kind of stalled.
Java GC/ memory shortcomings become visible when companies like Netflix push it to limit e.g
> ... The decision to use Go was deliberate, because we needed something that had lower latency than Java (where garbage collection pauses are an issue) and is more productive for developers than C, while also handling tens of thousands of client connections. Go fits this space well.
Go's advantage when it comes to GC is very temporary. HotSpot's GCs are more advanced, and Go has the upper hand only thanks to value types, which are coming to Java. Go will not come close to catching up by then. I think that containerized deployment is likely to evolve and change at a much faster pace than development platforms, so it's really hard to tell which approaches would fit where.
Java release cycle is ~3yrs so Java 10 will be roughly expected in 2020/21 time frame. And at that point larger ecosystem like Apache etc will start taking advantage of value type. So it is like 6-8 years from now which I would not characterize as very temporary. Also this is assuming Go committer from now onwards just sit and do nothing about performance improvements which again seems quite unlikely.
Java has 15 year head start on Go and if a newer Go GC beats very mature hotspot GC it could either mean Hotspot advantage is largely in theory or it has reached its peak performance and there is not much scope to improve further.
Go's GC doesn't beat HotSpot's GCs. It just has less work to do, and this is being fixed in Java. In any event, I think the biggest potential threat to Java isn't Go (which has some fundamental issues that are very hard to fix) or .NET, but the JS ecosystem, which may become the universal VM.
Also Go's GC doesn't move objects, which makes the whole problem a lot easier as long as heap fragmentation doesn't end up biting you badly in the end.
Java GC/ memory shortcomings become visible when companies like Netflix push it to limit e.g
http://techblog.netflix.com/2016/05/application-data-caching...
They specifically mention:
> ... The decision to use Go was deliberate, because we needed something that had lower latency than Java (where garbage collection pauses are an issue) and is more productive for developers than C, while also handling tens of thousands of client connections. Go fits this space well.