"today's server programs comprise tens of millions of lines of code, are worked on by hundreds or even thousands of programmers, and are updated literally every day. To make matters worse, build times, even on large compilation clusters, have stretched to many minutes, even hours."
A lot of go's compile speed comes from how simple it's syntax is besides the gains it gets from avoiding C++ dependency issues. Java's syntax while less complex than C++ is still complex compared to go's. And it won't have go's parse time savings.
If Go wanted to compete on compile speed, then dynamic loading would be a better idea than having a simplistic compiler that compiles fast into one monolithic executable.
The main reason the Go compiler is fast, is because it is simple and doesn't do many passes and optimizations.
Which is like advertising the fact that your company makes a fast car, but forgetting to mention that it can only carry a driver if he weights 10kg.
Go doesn't need to rely on dynamic loading because compiling a library is fast and statically linking the libraries is fast. The result is a monolithic executable true but it's still fast without dynamic loading. Go doesn't compile all the source that goes into a binary every time. Libraries get compiled into an archive and don't have to be compiled again unless they change. In that way it has the same benefit as jars for compilation speed.