この号では
-間に合いません：
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デザイン
例外をスローするか、エラーコードを返しますか？ ユーザーにコレクションまたはイテレーターを提供しますか？ ストリーム処理またはメモリ内モデル？ 多くの質問があり、さらに多くの解決策があります。 優れたAPIを作成することは、非常に難しい仕事です。
3.2。 プロジェクトの外部依存関係
一部のプロジェクトでは節約でき、他のプロジェクトでは致命的となる考え。
3.3。 オープンソースプロジェクトを支援するには？
この声明は、オープンソースだけでなく、あらゆるプロジェクトに当てはまります。 誰もが優れたドキュメントがどれほど重要かを理解しています。 しかし、私たちは通常、非常に困難にそれを書くための時間を見つけます。
3.4。 関数型プログラミングについて
4.ユーモア
4.1おそらくmap-reduceとは何かの最良の説明は
4.2。 モノリスに対するマイクロサービス
JetBrainsの Hadi Haririは、これら2つのアーキテクチャアプローチの主な違いを非常に明確に説明しています。
4.3。 プロジェクトをクリーンアップする場合は...
...それから、誰かがあなたの前にすでにこれを行っていることを覚えておいてください。
ソース：
https :
//twitter.com/swardley問題： 前 - 次