Javaだけに限ったことではないが、パフォーマンス上の障壁となる言語仕様や言語仕様の欠落がいくつか存在する。それは例えば配列境界チェックや実行時型チェック、非仮想メソッドの欠如などである。ただしコードの安全性と性能はトレードオフの関係にあるため、チェック機構が一概に悪とは言えない。また、コンパイル時の最適化やJVMの実装次第で解消できるものもある。そのほか、Javaは構造体（ユーザー定義の値型）および矩形配列（真の多次元配列）を持たず、それぞれクラス（参照型）およびジャグ配列（配列の配列）などで代替する必要がある。また、Javaではメソッドから複数の値を返すためにはクラスや配列といった参照型を使用する以外の方法がない。これらの制約によってJavaのプログラムコードは、他の言語で書かれたコードよりも頻繁にヒープを使用しなければならなくなっている。
Javaプログラムのパフォーマンスに関して一般論を述べることは不可能である。なぜなら、実行時の性能は、言語自身が持つ固有の特性よりも、JavaコンパイラやJava仮想マシンの品質に非常に大きく影響されるからである。Javaバイトコードの実行方法は、仮想マシンによって実行時に翻訳して実行する方法と、ロード時もしくは実行時に機械語にコンパイルしてハードウェアによって直接的に実行する方法がある。前者の翻訳実行する方法は機械語の実行よりも遅く、後者のロード時もしくは実行時にコンパイルして実行する方法は、最初のコンパイル時にパフォーマンスが犠牲になる。これはJavaにかぎらず、.NET Frameworkなど他の仮想マシンベースのプログラミング環境においても同様である。コンピュータハードウェア性能の向上と、Javaのバージョンアップに伴う最適化技術の進歩によって、Javaプログラムの初回起動時のオーバーヘッドなどは誤差の範囲内になりつつあるが、ヴィルトの法則が示すように、総じてソフトウェアの複雑化やシステム要求の上昇にハードウェアの性能向上が追い付いていないのが現状である。C/C++ではJavaよりも細やかな最適化を手動で施すことができるが、プログラマが手作業で施した最適化よりも、JITコンパイルによる自動最適化のほうが性能面で上回るケースもすでに存在する。C/C++でJavaの実行時最適化技術を真似することは困難である。
この問題は、開発者がJavaのバージョンを Java SE 6以降にアップグレードすることで解決する。Java SE 6になってからJavaのデスクトップまわり、GUI環境は一新され、開発効率は高まっているため、以前のバージョンよりも開発の手間はかからなくなっている。
Javaの浮動小数点演算は主にIEEE 754（二進化浮動小数点数演算標準）をベースとしているが、例えばIEEE 754に必須とされる例外フラグや方向指定の丸めなどの、いくつかの機能については"strictfp"修飾子を指定した場合でもサポートされない。Javaの仕様として知られているものはJava自体の問題ではないが、浮動小数点数演算を行う上で避けて通れない問題である。
Javaでは、内部クラス、ローカルクラス、匿名クラスを使用することで、基本的なクロージャに近い記述が実現できる。しかしこれは完全ではなく、ローカルクラス／匿名クラス外の変数に対する参照を、ローカルクラス／匿名クラスのフィールドとして暗黙キャプチャできるように、final修飾子付きで宣言する必要がある。これは、変数のスコープを抜けたときに削除できるような、様々な寿命に対応したスタックモデルをJVM実装者が選択できるようにするためである。Java 8では実質的にfinalとみなせる変数は明示的にfinal修飾する必要がなくなったが、依然として再代入は許可されない。また匿名クラスの構文も冗長であり、例えばRunnableインタフェースを要求する場面で、同インタフェースを実装する匿名クラスを定義する場合、単純なコードブロックとして定義することはできず、Runnable.run()メソッドを実装するようなクラスのブロックを定義する必要がある。Java 8ではラムダ式と関数型インタフェースによりこの問題を改善している。
JavaではC++でオプションとされていた例外処理の仕様を取り込んだが、この際チェック対象の例外に対応するthrows文を必須とした。例外のチェックは小規模なシステムにとっては役立つが、大規模なシステムについても有益であるかどうかについては統一的な見解には至っていない。特に上位のコードでは下位のコードから発生するエラーを意識したくない（例としては、名前解決例外であるNamingException）。名前クラスの作成者は名前解決例外をチェック対象の例外として上位コードに対応を強制するか、コンパイル時のチェックを使わずに下位のコードからの例外を連鎖的に通知するかを選択する必要がある。
Javaは主にオブジェクト指向の単一パラダイム言語である。すべてのデータと処理は必ず何らかのクラス内に記述しなければならないため、必要以上にコードが冗長になってしまうことがある。Java 5.0で追加された静的インポート (static imports) はこれまでのJavaよりも手続きパラダイムによりよく順応する。
夏の大三角という呼び名は、1950年代からイギリスの天文普及家サー・パトリック・ムーア (Sir Patrick Moore) が使うようになってから一般的にも知られるようになったものである。ただし、ムーアによって創案されたものではなく、オーストリアの天文学者オスヴァルト・トーマス (Oswald Thomas) によって1920年代に "Grosses Dreieck" （ドイツ語で「大きな三角形」の意）と記述されており、トーマスはまた1934年には "Sommerliches Dreieck" （ドイツ語で「夏の三角形」の意）と記述していた。それ以前にも、オーストリアの天文学者ヨセフ・リットロウ (Joseph Johann von Littrow) は、1866年に出版した星図の本文において 「よく目につく三角形」 と説明していた。また、3つの星を最初に繋いだのはドイツの天文学者ヨハン・ボーデで、1816年に出版した書物の中の星図においてであったとされる。ただしボーデは、星と星とをつないだものの、それに対してなんら名称は与えていなかった。1776年にフランスの球儀製作者ジャン・フォルタン (Jean Nicolas Fortin) がパリで出版した 『フラムスティード星図』 の第2版では、3星のうちベガとアルタイルしか結ばれていない。当時、デネブは「最も明るい一群の星」すなわち1等星にランクされていなかった。なお、『アルマゲスト』所収の「プトレマイオスの星表」では、アルタイルも2等星だった。