This appears to link to the C++ version of I2P. Not the original "Official" Java version which is more complex and has much more built-in features: https://geti2p.net
You are likely referring to awful enterprise frameworks like Spring that make a lot of noise. Some ten years ago it was JBoss giving a bad fame to Java. You won't be finding those enterprise frameworks being used by most open source projects.
For those cases Java is kept clean and fast, as it should.
Then, I started slinging C++ for the Google indexing system.
I still hope we get to a point where compiling to native code is as rare as hand-writing assembler is today. I hope we distribute code primarily in a format optimized for native translation, SafeTSA or similar. (Though, I'd hope we get install-time caching of native code generation, similar to AS/400 TIMI / current Android Runtime.)
However, until compilers get very good at statically inferring lifetimes and statically scheduling object collection, I hope garbage collection is optional and freely mixable with manually managed objects. (Yes, statically determining minimal lifetimes in the general case is equivalent to solving the halting problem, but we can be conservative and fall back on GC in the statically-unsolvable cases.)
The main drawback of Java for most applications is that with garbage collection there's a time-space tradeoff. As a rule of thumb in order to avoid frequent major collections, a Java program is going to use about twice as much memory as an equivalent C/C++ program.
When it really counts, we're still not at the point where Java is faster (even after warm-up) than expert-written hand-optimized C/C++ with profile-guided optimization.
Don't get me wrong. I understand the development velocity advantages of Java over C/C++ can often more than make up for performance differences, and good C/C++ developers (especially with domain-specific skills) are rather expensive to employ. I worked on equity trading systems in an interpreted language, where we replaced a lower latency system written in Java. The high-level interpreted language enabled a very rapid turnaround time and was easier for Statistics/Physics PhDs to implement models. The better models resulted in better average prices despite the system reacting more slowly to incoming data.
Ideally, I'd like to see something Elixir-like with good interoperability with something Rust-like for the parts that use a lot of CPU time and/or a lot of memory, all compiling down to a SafeTSA-like compressed control flow graph representation designed for fast native code generation.
Compiled as JVM bytecode the same app is around 16 MB. For my standards this is quite OK when considering the maintainability across the next centuries.