By: AT&T From: '80s Spec: アセンブラから機種依存性を排除した。
- 低レイヤを操作するのにほぼ必須
- 優秀なコンパイラが優秀に最適化をしてくれる
- 実行可能ファイルを生成する
- とにかくポインタがわかりにくい
- 配列を引数に渡せない (
Array<T>はT*として渡す必要がある)- というか、Cでは配列はオブジェクトじゃない
*(ポインター)と&がわかりにくい- 関数型だとかコレクションだとか例外だとかそんなモダンなものは存在しない
getsは絶対に使うな- お前のメモリ管理、大丈夫？
- モダン
- 渋谷ダンジョン
- なんでジェネリックな書き方のように見せかけて山カッコの中に式をいれる？？？？？？！！！！！！！！！！！！
- リフレクションが存在しない (しかし、それでも十分複雑である - 誰もC++の全容を把握しているものはいない)
- ラムダ式の文法が複雑
- 誰も全容を把握していない (- O'REILLYのC++ハンドブックがその辺のキングジムのファイルといい勝負している)
By: Sun, Oracle, OpenJDK contributors From: '90s
- だいたいどこでも動く (そう、
native宣言されたメソッドの実装を.soなり.dllなりで準備すればね) - 古いコードがぶっ壊れにくい
- なんで
Systemクラスにgc()メソッドをはやした？？？？？？？？？？？？？！！！！！！！！！！！！ - デフォルトで
finalじゃない - (C++ほどではないが)標準APIが広すぎる
java.utilのパッケージ分けとけやpackage-privatenew T[]ができないこと- 一応、リフレクションを使うとできるのだがまあまどろっこしい。
null-check-syndrom- どうすれば速度が向上するのか環境によって異なる (もっと言うと、被呼び出し回数や、ライブラリの実装アルゴリズムによっても異なるため、一概にどんな書き方をしたら早いという定量的な考えが存在し得ない)
- だいたいどこでも動く (JVM言語)
new T[]が(funの中でしかできないなど制限はあるものの)できる- クラスに属さない純粋な関数を宣言できる
- 頼むからシンタックスシュガーは
kotlin.syntaxとかに収まっててくれ - あと
to(): Pair<A, B>、おまえ何者だ - たまにJavaとの境界またぐとき
@JvmStaticつけるの忘れていてトラブルを発生させることがある