これは、Java 19 のリリース直後に投稿する絶好の機会です。はい、別の「私の言語の方が優れています」という投稿です。いや、書きたくなかった。しかし、人々の が私を良くすることがあります。この場合、投稿はコメントとして開始され、最終的に投稿に変更することにしました。これは、主に Quarkus について不平を言う で強化されました (追加する場合は、やや不公平です)。 悪い投影 この投稿 最初の記事はほとんどナンセンスで時代遅れのクリックベイトです。次の主張でそれを要約します。 ゲッター/セッター コレクションの と何かの に特化した演算子のオーバーロードがありません [] + チェックされた例外 依存関係の管理 2 番目の記事には、Jakarta EE および JVM における一般的なプログラマーの美学に関連する不満があります。具体的には、検証および同様の主張のための注釈の使用。これははるかに情報に基づいた記事ですが、いくつかの欠陥があり、最後の方で対処します。 ゲッターとセッター 最新の Java では、ゲッターとセッターは必要ありません。 Java 14以降の記録があり、反対の主張もありますが、Lombokは依然として良好です。ゲッター/セッターが必要になる唯一のポイントは、非常に特殊な設定 (JPA など) です。ここでも、Lombok は問題を完全に解決します。 この記事は、Java にシンタックス シュガー機能がないことを長々と説明しています。これは意図的なものです。最新の構文のニュアンスに興味がある場合は、Kotlin を参照してください。 Java は「遅くて安定している」ものです。これは良いことであり、Java の長寿の主な理由です。 構文シュガーと演算子のオーバーロード 最新の Java には、switch、var、複数行の文字列などのパターンが含まれています。いくつかの今後の機能には、文字列テンプレートが含まれます。文字列テンプレートのサポートには、Java が「正しく行う」ことを望んでいるため、しばらく時間がかかります。 APIレベルでそれに対するサポートがいくつかあります（そしてしばらくの間）。これは高性能ではありません。文字列テンプレートの目標は、次のようなもの する根本的なオーバーライド可能な構文を作成することです。 を許可 ResultSet rs = DB."SELECT * FROM Person p WHERE p.last_name = \{name}"; この投稿の公開以来、開発者は上記のコードが SQL インジェクションの脆弱性であると誤って想定しました。そうではありません。これは文字列置換のように見えますが、その構文を使用してパラメーター化された SQL 呼び出しを生成するコードです。 更新: は、コンパイラがスコープから動的にチェックして取得する変数であることに注意してください! name は開発者がカスタム実装することができ、「組み込み」である必要がないため、複雑なテンプレートをその場で構築できます。 DB しかし、6 か月後に登場する Java ではなく、現在の Java について話しましょう。アペンドの使用は、10 年以上にわたって の推奨事項ではありませんでした。最もパフォーマンスが高く読みやすい を使用します。コレクションに関しては、 と の違いは文字通り 4 文字です。それらのキャラクターは非常に重要です。これは簡単にオーバーライドできます。意味の違いも理解できます。 Java 配列は非常に高速です。多くの場合、ネイティブの速度は高速です。コレクションはそれほど高速ではありません。これをここですぐに確認できるという事実は非常に価値があります。 String + get() [] 演算子をオーバーロード という事実は、大きな利点です。 が表示された場合、これは文字列または数値であり、隠しメソッドではないことがわかります。これは、Java の最大の強みの 1 つであり、他の言語が取り残される中、ほぼ 30 年間 Java が人気を博してきた理由の 1 つです。 Java の構文は、大規模な読み取り用に設計されています。 1M 行または 100k 行のコードを含むプロジェクトがある場合、問題は変化します。この時点で、問題をデバッグしているときに、モジュール Y のプログラマ X が誤って演算子をオーバーライドしたことを発見するのは困難です。その時点で構文は単純である必要があり、最初に節約した小さな費用は 10 倍の利息で支払われます。コードがより複雑になり、年齢が上がるにつれて、単純なフリップの定義が変わります。それに加えて、厳密でシンプルなコードを大規模に解析するツールの機能を追加すると、さらに大きなメリットが得られます。 できない a + b チェック済み例外 チェック例外はオプションです。しかし、これらは Java の最高の機能の 1 つです。非常に多くのコードが予期せず失敗します。趣味で物を作るならそれでいいのかもしれません。プロフェッショナルなアプリケーションを構築したい場合、すべてのエラーを処理する必要があります。チェック例外は、そのナンセンスを回避するのに役立ちます。怠惰のために、人々はチェック例外を嫌います。 Java はあなたを自分自身から守ります。 ネットワーク接続、DB 接続、ファイルのオープンなどを行い、潜在的なエラーを処理する必要がない場合はありません。パントすることはできますが、チェックされた例外により、どこかでパントし続ける必要があります。これは驚くべき機能です。 依存関係 Maven と Gradle には多くの問題があります。しかし、それをいくつかのミレージを備えた他のほとんどの依存システムと比較すると、それらはうまく機能しています。それらには問題がありますが、貨物のようにパッケージがほとんどない若いものと比較することはできません。 Maven central は、27 テラバイトの jar と 億のリクエストを備えた大容量です。それは完全にカチカチ音をたて、ダウンタイムはほとんどありません。 4960 NPM のような他のツールは、maven の強みを完全に示しています。 Maven の依存関係が問題である場合、NPM には 100 倍の問題があり、監視もありません。これらのものが成長するにつれて、複雑さが生じます。特に、市場に出回っているmavenの複数のバージョンでは。ただし、maven と gradle がそれらのために行っていることの 1 つはツールです。多くの場合、IDE は問題を解決し、すぐに修正を見つけるのに役立ちます。 ジャワの文化的問題 2 番目の記事はより興味深いもので、ある程度同意します。 Java 開発者は、あらゆる問題をより複雑な問題にする傾向があります。場合によっては、これが必要になります。Java は 800 ポンドのプログラミング プラットフォームのゴリラであり、そのソリューションはしばしば過度に設計されています。これは、電力不足よりも優れている傾向がありますが、代償が伴います. 検証に注釈を付ける理由 この記事は、何気ない観察者には「正しいこと」のように見えますが、問題のある興味深い例を 1 つ取り上げました。 @NotNull @Email String noReplyEmailAddress 著者は、これは悪いことであり、カスタム タイピングを実装する必要があると主張しています。 public record EmailAddress(String value) { public EmailAddress { // We could've used an Either data type, ofc; Objects.requireNonNull(value); // regexp could be better if (!value.matches("^[^@\\s]+@\\S+$")) throw new IllegalArgumentException( String.format("'%s' is not a valid email address", value)); } } 上記のコードは有効な Java コードであるため、これは Java で完全に可能です。しかし、それにはいくつかの問題があるため、Bean の検証が行われています。 これは最適化できません - Bean 検証は、フレームワークによって検証チェーンを上に移動できます。宣言型 API であるため、クライアント側のコードでシームレスに検証することもできます。ここでは、バリデーションを実行するために実際にコンストラクターを実行する必要があります。 宣言的な注釈をチェーンの下に移動して、データベースの制約をシームレスに適用することができます。 一度に複数のアノテーションを適用できます 構文はより簡潔です その結果、注釈が奇妙に感じられ、入力が強制されない場合があります。それは本当だ。しかし、それらはパフォーマンスとパワーを向上させます。それらの使用の背後には、多くの考えと常識があります。私は著者の主張を理解しています.私もIoCの大ファンではありませんが、この特定のケースでは彼は間違っています. ついに この記事は防御に多くの時間を費やしました。ギアを切り替える時が来ました。 Java は約 30 年前から存在しており、現在でも Java 1.0 とほとんど互換性があります。それは素晴らしく、他に類を見ません！ その保守的なアプローチの強みの 1 つは、何が起こっているのか誰も気付かずに、驚くべき「ボンネットの下」の最適化を実行できることです。 Java 9 RAM の使用量を大幅に削減しました。同様に、Loom は Java 同期アプリケーションのスループットを向上させます。 Valhalla は、コレクションのパフォーマンスをさらに向上させ、オブジェクト/プリミティブ分割を統合します。パナマは最終的に JNI を排除し、ネイティブ コードとの統合プロセスをより快適なものにします。 は、文字列がメモリ内でシームレスに表現される方法を完全に置き換え、 良い点は、JVM が大きなテントであることです。 Java のファンでない場合は、Kotlin または Scala が好みに合うかもしれません。 JVM の利点は普遍的に適用され、ここで述べた機能のほとんどは共同エコシステム全体に利益をもたらします。 この話は ここで最初に公開されました。

Chain

Instantly

Shai is a Developer Advocate at Lightrun, where he's busy explaining why hotfixing just to add a log line needs to be a thing of the past. He is also a JavaOne rockstar that has been developing software professionally for ~30 years, a published author, an open-source hacker (founder and long-time maintainer of Codename One) , an experienced Java trainer and a public speaker. When he's not in front of his machine you can find him making food for his two kids or doing Yoga with his wife (well, at least attempting to).

2021 - HackerNoon Contributor of the Year - DEBUGGING

2022 - HackerNoon Contributor of the Year - Coding Skills

2022 - HackerNoon Contributor of the Year - Debugging

2022 - HackerNoon Contributor of the Year - Java

2022 - HackerNoon Contributor of the Year - Monitoring

2022 - HackerNoon Contributor of the Year - Software Testing

Talk to the Duck Blog

Read My Stories

Newsletter

Follow me on Twitter

2021 - HackerNoon Contributor of the Year - KOTLIN

2021 - HackerNoon Contributor of the Year - JAVA

Nominated for 2022 - HackerNoon Contributor of the Year - Monitoring

Nominated for 2022 - HackerNoon Contributor of the Year - Debugging

Nominated for 2022 - HackerNoon Contributor of the Year - Java

Nominated for 2022 - HackerNoon Contributor of the Year - Coding Skills

Nominated for 2022 - HackerNoon Contributor of the Year - Software Testing

Author/DevRel/Entrepreneur/Hacker

このオーディオは、ストーリーの元の言語で制作されています。

長すぎる; 読むには

Let Your Engineers & PMs focus on Product. Apply for $50K Credits!

なぜ Java は依然として人気があるのか

なぜ Java は依然として人気があるのか

長すぎる; 読むには

Company Mentioned

Coin Mentioned

@shai.almog

関連ストーリー