この号では
-間に合いません： Java 9の締め切りが再び変わります
-Save Java EE ： ラリーエリソンへの請願
- マイクロソフトがLinkedInを買収
-なぜC2コンパイルをオフにするのですか？
-Holivar： assertを使用するかどうか
...など
1.ニュース
1.1。 Java 9：締め切りは変動しています
リンク： http : //mail.openjdk.java.net/pipermail/jdk9-dev/2016-June/004443.htmlJavaのチーフアーキテクトであるMark Reinholdは、マイルストーンの「機能の完全な」期限が既に過ぎていることを思い出しましたが、Java 9の多くの機能はまだ準備ができていません。 約15のJEPです。 この手紙は、パニックを起こすのではなく、体系的に作業を完了することを提案しています。なぜなら、主なことは、正式な期限ではなく、実際の準備と品質だからです。
合理的なアプローチ。 ただし、これがタイミングの最初のわき柱ではないことを思い出してください。 開発中に期限に合わせるのがどれほど難しいかは、誰もが知っています。 しかし、Javaは公開製品であり、その開発は何百万人もの開発者によって監視されています。 大衆ユーザーはOraklovのメールストーンが何であるかを掘り下げることはありません。 これは、内部Oracleキッチンです。 「こんな日になるだろう」と言われ、ポップコーンを買いだめして待ちます。 約束されたことが起こらない場合、私たちは動揺し、骨を洗い始めます。 進行中の故障を考えると、 オラクルは開発者との関係を強化して評判のコストを最小限に抑えることに意味があります。
1.2。 Java EEの保存：ラリーエリソンへの請願
リンク： https : //www.change.org/p/larry-ellison-tell-oracle-to-move-forward-java-ee-as-a-critical-part-of-the-global-it-industryJava EEの周りの情熱は変わり続けています。 Java EE Guardiansと呼ばれる人々のグループは、Java EEの開発を凍結するためにトップマネジメントの注目を集めることを望んで、Oracle CEOのLarry Alissonに宛てた請願を提出しました。
個人的には、Java EEに関するOracleポリシーについてもよく理解していません。 彼らのコメントを聞くのはとても面白いでしょう。 どこかで会ったら、リンクを共有してください。
1.3。 マイクロソフトがLinkedInを買収
リンク： http : //www.cnbc.com/2016/06/13/microsoft-to-buy-linkedin.htmlトランザクションの量は、ITの世界で通常行われているように、かなり控えめで、約262億ドルです。 ビルガイツの発案により、 LinkedInで作成された膨大な数の内部Javaプロジェクトを長年にわたって管理できるようになります。 これらの開発の一部が新しいMicrosoftプロジェクトに移行する可能性があります。
また、この取引はユーモアのセンスを誇示する多くの機会を与えました。
2.読む
2.1。 HotSpot Insideコレクション
リンク ： https : //wiki.openjdk.java.net/display/HotSpot/PresentationsJVMアーキテクトのジョン・ローズは 、JVMの内部で資料を収集しています。 これまでのところ、文字通りいくつかのリンクがありますが、将来このリストが増えることを期待しています。 リンクをお気に入りに追加してください。
2.2。 OpenJDK静的アナライザー
リンク ： https : //medium.com/@Coder_HarryLee/openjdk-check-by-pvs-studio-f25a2187b8a0#.obyfqnjbs彼らはOpenJDKソースからPVS Studio静的アナライザーに行き、そこにかなりの量の問題を見つけました。 if-else式の湾曲したチェック、忘れられた括弧、コピー＆ペースト、NULLチェックの欠落など。コードアナライザーには懐疑的かもしれませんが、これらのソウルレスマシンはパンを食べても無駄ではありません。
2.3。 assertを使用します（しない）！
リンク ： http : //www.yegor256.com/2016/06/17/dont-use-java-assertions.htmlエゴール・ブガエンコは迅速なジャックでヨーロッパの会議を駆け抜け、PLOに対する過激な見方で多くの騒ぎを起こしました。 すべての人、そしてHibernate、アノテーション、その他多くの人に手に入れました。 悲しい運命は断言をもたらした。 彼の最近の投稿で、イゴールはそれらの使用を放棄し、 例外のみに依存するよう促しています 。
開発者とアサートの関係は決して簡単ではありませんでした。 一部の人にとっては、これは「アクティブな」ドキュメントと追加の無料の「テスト」です。 他の人にとっては、これはバグの意図的な変装です。 個人的に、私はアサートを愛し、 私たちのプロジェクトにはそれらがたくさんあります 。 単純なルールが2つあります。ユーザー入力をチェックしない、およびテストを置換しない。 これらのルールに従い、あなたの信頼できるアシスタントになると断言してください。
これについてどう思いますか？ プロジェクトでassertを使用していますか？
2.4。 メモリfootrpint Javaアプリケーションを削減する
リンク ： https : //blog.buoyant.io/2016/06/17/small-memory-jvm-techniques-for-microservice-sidecars/buoyant.ioには 、Javaプロセスのサポートを開始する製品の1つがあります。 そして、彼らは本当にこれらのプロセスができるだけ少ないメモリを消費することを望んでいました。 その結果、彼らは次の方法で望ましい結果を達成しました。
-32ビットモードの使用
-C2シャットダウン
2番目のアプローチでは問題が発生しますが、 C1で十分なパフォーマンスが得られる場合、それはなぜですか？
3.知恵
3.1。 APIデザイン
3.2。 プロジェクトの外部依存関係
3.3。 オープンソースプロジェクトを支援するには？
3.4。 関数型プログラミングについて
4.ユーモア
4.1おそらくmap-reduceとは何かの最良の説明は
4.2。 モノリスに対するマイクロサービス
JetBrainsの Hadi Haririは、これら2つのアーキテクチャアプローチの主な違いを非常に明確に説明しています。
4.3。 プロジェクトをクリーンアップする場合は...
...それから、誰かがあなたの前にすでにこれを行っていることを覚えておいてください。
ソース： https : //twitter.com/swardley