10年後にアプリケーションを17からJava 25に移行する仕事ができるのが待ちきれない！

構造化並行処理がasync/awaitよりも良い感じになることを願ってる。例を見てると自信が持てないけど、どうなるか見てみよう。

プレビューがある方が、今のC++が実装なしで機能を標準化しようとしてる混乱よりずっと良いね。

ちょっと脱線するけど、2009年に僕のタッチSymbianフォンで動いてたJavaで作られたGmailアプリをまだ覚えてるよ。めっちゃ可愛くて、ちゃんと仕事もしてくれた。

いいね、昔に書いたスイングアプリを復活させようかなって考えてたんだけど、ほとんどおもちゃみたいなもんだからあんまり修正したくなかったんだ。でも、やってみるつもり！

JetBrainsの素晴らしいツールや賢い学生プログラムがなかったら、今のJavaはどうなってたんだろうね。

JVMとそのエコシステムは、Scalaみたいな他の言語からも使えるよ。Scalaにはセクシーな機能がいっぱいあるし、Clojureとかもね。

それには同意できないな。私の経験とは全然違うよ。手伝った会社は何十社もあったけど、JVMの新しいバージョンに移行するのに苦労してた。毎回、大きな問題があって、再作業や再テストがたくさん必要だった。Java 17か18のあたりで離脱したけど、関わってた誰もそのバージョンを使ってなかったから関係なかった！ 2022年の特にひどいプロジェクトでは、クライアントが内部システムのJVMを1.5から更新する必要があって、私の役割はその効果を判断することだった。すぐにいくつかの重要なライブラリがJava 1.7のあたりでサポートを終了していて、進む道がないことがわかった。単に廃止された製品だったんだ。私のチームはその3rdパーティのjarのソースコードを取得して再コンパイルしようとしたけど、範囲が広がっていくばかりだった。1.7にするのも問題になるって私が言っても聞いてくれなかった。さらに、あるマネージャーが私の評価を信じず、別の人を連れてきて私が間違ってることを証明しようとした。大きな対立になってしまって、正直うんざりしたよ。その人は私ほど経験がなかったのに、ただ自信過剰で傲慢だった。結局、そのクライアントを切ることにしたけど、彼らはフォーチュン10のトップだったから残念だった。最後に聞いたとき、彼らはそのアップグレードに進展がなく、まだ1.5を使っている状態だったよ。

特に、static関数を宣言して、それをsuperのパラメータの一部として呼び出すことでいつでもバイパスできたからね。public Foo(int x) { super(validate(x)); } validateはsuperの前に実行されるのに、superは技術的にはコンストラクタの最初の文だったし、コンパイラもそれで満足してた。

JDK 1.0の前からJavaをプログラミングしてるけど、その頃気になってたミスフィーチャーは、もうずいぶん前に対処法を学んだよ。

それってJava 22からできなかったっけ？

8から17歳の頃は、使っちゃいけないもの（Sunパッケージ）が消えて大変だった。でも、たくさんのライブラリはそれでも動いてたしね。javaxからjakartaへの移行も大変だったけど、それを乗り越えれば大丈夫。21や25に行くのは簡単そうに見えるよ。新機能が追加されるだけで、長い間必要だった整理が終わったからね。これからは最新の状態を保つのがずっと楽になると思う。

そうだね、Java 9はエコシステムのPython 3の瞬間だったけど、もうずっと前から解決されてるよ。

参考までに、最近17から21に移行するのに全く問題はなかったよ。すべてうまくいったし、唯一の小さな問題はGradleを同時にアップグレードすることだったけど、それはあまり関係なかった。

頑張ってね！

モジュールインポートは普通のインポートとは違って、実際に開発者が書かなきゃいけないインポートの数を減らすのに役立つみたいだね。ちなみに、Javaで動くScalaはインポートのリネーミングや型エイリアスもあって、君が言ったことができるよ。

大規模なコードベースでは、インポートの主な問題は「そのものがどこから来たか」だよね。明示的なインポートが本当に必要なんだ。特にビルドで何かが壊れた時、依存関係の正しいバージョンがあるかどうか不安になるし（その名前がどの依存関係から来たのか分からない）。小規模なコードベースでは何でも動くけど。追記：なんでインポートを見る必要があるの？普通のエディタなら隠してくれるし、必要ないよ。コードから名前をクリックしたりホットキーで直接ナビゲートすればいいんだから。

知ってる限りでは、主に単一ソースファイルのプログラムを書くのを楽にするためのものだよ。

C#とNimはそのスタイルが好きだけど、良いIDEがないとほとんど読めなくなるよね。C#の開発体験が嫌になる理由の多くは、フル機能のVisual Studioを使わないからだと思う。VSCodeは素晴らしいけど、csprojやslnファイルを開くことはまずないかな。実際のXML内容を手動で編集する必要があるときだけだよ。500ドルで永続的かつ完全ライセンスのコピーが買えるってことはあまり知られてないけど、サブスクリプションや他の怪しいクラウド詐欺みたいなものは必要ないんだ。ただ、マイクロソフトの製品ページを見てると、そう思わせるような作りになってるけどね。[0] https://www.microsoft.com/en-us/d/visual-studio-professional...

IDEなしでは意味がわからない言語構造についての不満は理解できないな。IDEがあるんだから、そこでコードを見てるわけでしょ。IDEを持ってない人は自分で問題を作ってるだけだから、やめた方がいいよ。GitHubでコードを見てる人は、通常は参照を細かく追うレベルで分析してるわけじゃないし、簡潔さが時々のイライラを大きく上回ると思う。

僕が見る限り、Javaは冗長で使うのが退屈だから人気がないんだよね。正直言って、今はそれが大きな問題だとは思わない。Clojureのプログラムの方が好きだけど、今のところはJavaの方がTypeScriptよりマシだな。

多分、マルチスレッドのサービスをシングルスレッドのワーカーに置き換える人が増えてるのが関係してるんじゃないかな。

ひそかにKotlinとComposeがJVM上でデスクトップアプリを復活させてくれることを期待してるんだよね :-)

Javaはめっちゃ人気があって、大規模なバックエンドシステムで広く使われてるよね。ここにいる人たちは、そんなシステムで働いてないのかな？親のコメントみたいなのを見るといつも驚くんだよね。キャリアの中でJavaに触れる機会はほぼ無限にあったから。

Javaは中規模から大規模プロジェクト、特にスレッド処理や複雑なIOが必要なものには最適な言語だと思う。最近、ハードウェアアーキテクチャがまた分散してきてるから、もっと重要になってほしいな。SpringフレームワークはJavaの評判を下げてる気がする。Spring Bootはマシだけど、やっぱり厄介だよね。残念ながら、Pythonが勝った気がする。大体のことには十分だけど、実際は結構クソだよね。最近はRustを使ってプロダクションのAIシステムを作ろうとしてる人もいるみたい。

Javaの継続的な採用に対する最大のリスクは、周囲の文化だと思う。古いJavaプログラマーや古いJavaプログラムは、今の言語が他の人気のある現代的な言語と同じくらい簡潔にできるツールを持っているのに、無駄に冗長なままだよね。厳しい戦いだけど、まだ巨大な存在だから、もしかしたらその山を登れるかもしれない。

Oracleはなんか不安だな。Oracleの怒りを買わずにJavaを使えるかな？多分、openjdkを使ったり、いろいろ工夫すれば大丈夫かも。でも、他の言語を使ってその心配をしなくてもいいならそっちの方がいいな。C#は、Oracleに膝を壊される不安なしにJavaっぽい体験ができるから、すぐそこにあるし。Javaの使い方が分からないし、OracleのEULAに違反しない方法も知らない。調べて安全に使う方法を見つけることもできるけど、Javaを使わない選択肢もあるよね。Javaは必須じゃない（グリーンフィールドプロジェクトには）。良い代替がたくさんあるから、そっちを選びたいな。

Javaの一番の問題は、スムーズじゃないことだね。使えるjdkの実装がいくつもあって、ビルドシステムも色々あるし。C#のエコシステムは確かに小さいけど、ずっとスムーズだよ。

10年前に書いたClojureプログラムに戻ると、ちゃんと動くんだ。これはJVMのおかげなのか、それともClojureの動き方のおかげなのか？ Clojurescriptプロジェクトでも同じような話があるよ。古いnbbスクリプトを取ってきても、そのまま動くし。たまにnpmの依存関係を更新しないといけないこともあるけど、大体はひどく壊れてることはないよ。一方で、5つの相互依存するスクリプトを動かすために、変なPythonの依存関係やvenvの魔法のダンスに半日もかけたばかりなんだ。

Javaはほとんどの命令型言語と同じ問題を抱えてるんだ。可変状態と不変状態の明確な分離がなくて、ツールによって厳密に強制されてないからね。多くの大規模なJavaプログラムは不変コレクションを使ってこの問題を回避しようとするけど、確かに効果はあるけど限界がある。Javaはオブジェクト指向でもあるから、ストレスがかかるとスパゲッティの親子関係になっちゃうんだよね。

つい2週間前に提出されたから、今後のリリースでも何か見られるかもしれないね。

プロジェクトValhallaは、一回のリリースで実現するには大きすぎるよ。表面的な言語やJVMへのすべての変更が実現しても、新しい最適化を追加するのはまだ始まりに過ぎないからね。

バルハラのことを初めて聞いたのは2014年だったと思うから、もう10年以上前だね！でも、Javaの設計には本当に満足してる。こんなに丁寧に開発された技術って、ほんとに珍しいよ。長期的な安定性を求めるなら、Javaが最適だね。