When Java first took off, and the web was made of Java content executed via plugin, Java was written by idiots who concatenated strings instead of using string builders, and similar abuses of common sense through ignorance and teaching materials that focused on results rather than good practice. Executables outside of plugins suffered the same deficiencies, although they were probably attempting loftier goals, and the performance was... what is the opposite of magnified, because it was slower than a sloth taking a crap?
This lasted a number of years, even as the Java interpreter became stable and work was made to increase its performance. Idiot coders learned or abandoned Java, and the runtime made even the remaining idiots look better, if not "good".
If you don't find this comment amusing, you either lack historical perspective, are a Java programmer, or should consult a medical professional to be diagnosed for your deficiency in some manner or other.
Security problems these days seem to be focused on the browser plugin, rather than locally executing native apps, so the security comments mostly don't apply. Visiting a random internet web page and allowing it to execute poorly sand-boxed arbitrary code is a bit like licking random strangers' genitals. In case that interests you, let me state that it should not be done as a general practice, and you should consult a medical professional.
Java examples in the real world and in most printed books are the most incestuous, groupthink-y, overly-architected piles of verbosity I have ever had the displeasure to read. I completely understand the need for default parameters, dependency injection, constructor and method chaining, and all kinds of modern best practice.
But I have never seen another language embrace the overbearance of best practice teachings without implementing some balance of solution soundness. Java examples and implementations (open source of course, because I have read them) seem to abound with overloaded methods under 5 lines of code, which initialize another parameter to call another overload. Now you have multiple functions to unit test, multiple code paths, multiple exception sources, and unless you are brainwashed in the spirit of Java, comprehension of the complete workings are complicated by scrolling off-screen with essentially purpose-free function declarations, whitespace between functions, and an essentially functional programming paradigm split over several different methods to give the appearance of flexibility, OOP, and conscious design.
It reads to me like someone wrote that no method should ever take more than one additional parameter that you were not already given, and coherence be damned. I would much rather see a single method with 5 non-optional parameters than 5 overloads which calculate and pass one new parameter each time.
The Java paradigm seems to be calculating things within the overloaded methods is preferable to factoring out these into unrelated functions. In a truly sane, OOP world, those calculations would be a part of the object, or if sufficiently general would be part of the object's base object.
In fact, the Java approach seems to be the Builder design pattern, which I have not seen adopted as frequently as it should be. Obligatory link here.
As sensible as the Builder pattern seems to be, I think it would still require a number of extra Set/Get property methods, which are function calls. Maybe Java has optimized this, but if you don't adopt it optimization can't help you. And the chained method calling slows down the operation of the program as the runtime tries to do slow things quickly.
Groupthink and ignorance are the only things that make Java slow. They just seem to be more common in Java. I assume that is because it is easier to shoot yourself in the foot with a compiled language, or the runtime supports other options for an interpreted language.
If the educational materials were burned and re-written, Java would have a number of things on its side. My point is, without sufficient education, they will still produce output slower than expected performance.