您似乎在问两个完全不同的问题：
Java真的很慢吗，如果是，为什么？为什么 Java 被认为是慢的，即使它比许多替代品都快？
其中第一个或多或少是一个“绳子有多长”的问题。这取决于您对“慢”的定义。与纯解释器相比，Java 速度极快。与（通常）编译为某种字节码，然后动态编译为机器代码（例如 C# 或 .NET 上的任何其他语言）的其他语言相比，Java 大致相当。与通常编译为纯机器代码的语言相比，并且有（通常很大）团队只在改进优化器（例如 C、C++、Fortran、Ada），Java 在一些方面做得很好，但总体而言往往至少会慢一些。
其中很多主要与实现有关——基本上，它归结为用户在动态/JIT 编译器运行时等待的事实，所以除非你有一个程序运行了很长时间，否则它是很难证明让编译器在困难的优化上花费大量时间是合理的。因此，大多数 Java（和 C# 等）编译器并没有在真正困难的优化上投入大量精力。在很多情况下，与其说是做了什么优化，不如说是应用在哪里。许多优化问题是 NP 完全的，因此它们所花费的时间会随着被攻击问题的规模而迅速增长。将时间保持在合理范围内的一种方法是一次仅将优化应用于单个函数之类的东西。当只有开发人员在等待编译器时，您可以承受更长的时间，并将相同的优化应用于更大的程序块。同样，一些优化的代码也很复杂（因此可能很大）。同样，由于用户在加载代码时正在等待（并且 JVM 启动时间通常是总时间中的一个重要因素），因此实现必须平衡在一个地方节省的时间与在另一个地方丢失的时间 - 并且考虑到代码是多么少从毛茸茸的优化中受益，保持 JVM 较小通常更有益。
第二个问题是，使用 Java，您经常会获得或多或少“一刀切”的解决方案。例如，对于许多 Java 开发人员来说，Swing 本质上是唯一可用的窗口库。在像 C++ 这样的东西中，实际上有几十个窗口库、应用程序框架等，每个都有自己的一套折衷方案，即易用性与快速执行、一致的外观和感觉与原生外观等等。唯一真正的症结是一些（例如Qt）可能非常昂贵（至少对于商业用途）。
第三，很多用 C++（甚至 C 更是如此）编写的代码更老、更成熟。其中很多都包含几十年前编写的例程核心，当时花额外的时间优化代码是正常的预期行为。这通常对更小更快的代码有真正的好处。C++（或C）因其代码小而快而受到赞誉，但它实际上更多是开发人员的产品以及编写代码的时间限制。在某种程度上，这导致了一个自我实现的预言——当人们关心速度时，他们经常选择 C++，因为它有这样的声誉。他们在优化上投入了额外的时间和精力，并编写了新一代的快速 C++ 代码。
总而言之，Java 的正常实现充其量使最大优化成为问题。更糟糕的是，在 Java可见的地方，诸如窗口工具包和 JVM 启动时间之类的东西通常比语言本身的执行速度发挥更大的作用。在很多情况下，C 和 C++ 也因为简单地努力优化的真正产物而受到赞誉。
至于第二个问题，我认为很大程度上是人性的问题。一些狂热者相当夸大地声称 Java 的速度快得令人眼花缭乱。有人尝试过，发现即使是一个微不足道的程序也需要几秒钟才能启动，并且在运行时感觉缓慢和笨拙。很少有人会费心去分析事情，以意识到其中很大一部分是 JVM 的启动时间，而且当他们第一次尝试时，还没有任何代码被编译——一些代码正在被解释，还有一些在他们等待的时候被编译。更糟糕的是，即使它运行得足够快，对于大多数用户来说，外观和感觉通常会显得陌生和笨拙，因此即使客观测量显示响应时间很快，它仍然会显得笨拙。
将它们加在一起会产生一个相当简单和自然的反应：Java 缓慢、丑陋和笨拙。鉴于炒作说它真的很快，人们倾向于反应过度并得出结论认为它非常慢，而不是（更准确的）“稍微慢一点，而且主要是在特定情况下”。对于使用该语言编写前几个程序的开发人员来说，这通常是最糟糕的。在大多数语言中，“hello world”程序的执行似乎是瞬间完成的，但在 Java 中，当 JVM 启动时有一个很容易察觉的停顿。即使是在紧密循环中运行速度要慢得多的纯解释器，对于这样的代码来说，它仍然通常会显得更快，这仅仅是因为它可以更快地加载并开始执行。