java.ural.Meetup
の2回目の会議に参加するよう招待します。この会議は、ulのKonturの新しいオフィスの会議室で開催されます。 Maloprudnaya、5。14：00から。
ボーナスとして、 3月15日にエカテリンブルクで開催された
java.ural.Meetup @1
ミーティングからのレポートの記録を公開します。
java.ural.Meetup
とはjava.ural.Meetup
ですか？
年の初めに、「新しいJavaエンジンが必要ですか？」という投票がエカテリンブルクの開発者に配布されました。 肯定的なフィードバックが収集されたため、mitapが必要であると判断しました。 ほぼ2か月後、 mitapが発表されました 。 2週間後、最初の
java.ural.Meetup
ミーティングで
java.ural.Meetup
、エカテリンブルクから60人以上の開発者
java.ural.Meetup
集まりました。 会議では、Contourの開発者が現在のタスクについて話しました。
カットの下で、2回目の会議の発表と最初のmitapからのビデオレポート。
お知らせjava.ural.Meetup @ 2
場所 ： ulの Konturのオフィス マロプルドナヤ、5 。
日時 ： 12月1日土曜日14:00から 。
参加は無料ですが、 登録が必要です（車で到着する場合は、駐車場にアクセスするために彼の番号を示すことを忘れないでください）。
Mitapプログラム：
- レポート「Java 11」を使用したGrigory Koshelev。
- Andrey Nevedomskyとレポート「Springで依存関係を解決するカスタマイズ」。
- デニス・シロフはレポート「Clojure。 JVM用のLISPですが、なぜですか？」
- バーでのアフターパーティー。
1. Java 11
グリゴリー・コシェレフ・グンコシェレフ前回の会議から、
java.ural.Meetup
はJava 10をリリースし、すぐにレガシー（およびJava 9）になり、Java 11のLTSバージョンに道を譲りました。8のリリース後にJavaで発生した変更を見てみましょう。
2. Springで依存関係を解決するカスタマイズ
アンドレイ・ネベドムスキーSpringは、最もよく使用される依存性注入フレームワークです。 すぐに使用できる豊富なツールを提供しますが、これらのツールを使用するときに妥協する必要がある場合があります。 レポートでは、依存関係を解決するためにspringの機能を拡張する方法を示し、それらをすぐに使用できるツールと比較します。
3. Clojure。 JVM用のLISPですが、なぜですか？
デニス・シロフJVMの現代の世界には、Java、Scala、Kotlin、Groovyなどの非常に多様な言語があります。 どちらを選択するのですか？ レポートでは、Clojureプログラミング言語、次の（そしておそらく現在の）システムを開発するためにこの特定の言語を選択できる理由、およびこの言語の最も重要なコンポーネントの1つであるREPLでのインタラクティブな開発に焦点を当てます。
java.ural.Meetup @ 1のビデオ+マテリアル
1. .NETとJava仮想マシンの統合
グリゴリー・コシェレフ・グンコシェレフJavaの世界には、ツール、フレームワーク、ライブラリの多様性と成熟度の面で.NETよりも大きな利点があります。 Contourでは、本質的に同じ問題を解決するJavaライブラリ（たとえば、データベースのドライバーまたは一般的なツールのクライアントライブラリ）がより優れている（より速く、より機能的で、より優れている）という事実に繰り返し遭遇し、直面し続けています.NETでの対応物よりも。
このレポートは、このような例と、.NETプロジェクトのニーズに合わせてJavaエコシステムで最高のものを借りる方法に専念しています。
主な焦点は、ネイティブ層（ JNI ）を使用してC＃コードからJavaコードを呼び出すことによる低レベルの統合です。
これは、 Java Native Interface標準の一部であるJava Invocation APIを使用して実装されます 。
呼び出しAPIを使用して、.NETプロセス内でJava仮想マシンを実行します。 実際、このメカニズムは、ある意味で
java.exe
の実装（jvm.dllのラッパー（Windows用のJVM実装））と重複しています。
Java Native Interfaceの特別なラッパーを介したC＃コードとJavaオブジェクトの相互作用。 JNIはネイティブプラスコードから/で動作するように設計されているため、あらゆる種類の生のポインタがそこから突き出ています。 C＃（およびJava）では、オブジェクト/構造体へのポインタについて何も知らず、仮想マシンがメモリ管理に完全に従事している管理環境での作業に慣れています。 ラッパーの主なタスクは、ネイティブコードの機能をC＃インターフェイスにカプセル化することでした。
免責事項。 このレポートのバリエーションは、 DotNext Piter 2017およびJoker 2018カンファレンスで発表されました。
→プレゼンテーションリンク： pptx 。
→コードへのリンク： .NETパーツ 、 Javaパーツ 。
2.非同期マイクロサービスインタラクション
セルゲイ・アヌフリーエフとエフゲニー・シュティコフSpring Boot 2.0およびSpring Framework 5.0のリリースのずっと前に、.NETプロジェクトで長い間実践されてきたJavaサービスでの非同期マイクロサービス対話の必要性に直面していました。
Vert.xはサービスの基盤として選ばれました。これは広義のフレームワークではありませんが、ツールキットのカテゴリに属します（ 用語の違いは何 ですか ）。 これにより、マイクロサービスのアーキテクチャを独立して決定することが可能になり、標準の
CompletableFuture
が非同期のメインユニットになりました。
このレポートは、このようなサービスの構築に使用される2つのツール、クラスタークライアントと分散クエリトレースに当てられています。
クラスタークライアント。 呼び出されたマイクロサービスの目的のレプリカを選択する問題を解決するクライアントライブラリ。 同時に、トポロジーはオンザフライで変更されます（Service Discoveryの組み込みメカニズム）。 .NETでのこのライブラリの実装は、Eastプロジェクト clusterclusterの一部としてオープンソースでレイアウトされています。
分散トレース。 トレースツリー全体（子リクエスト）を構築する機能を備えた、すべてのサービス間リクエストに関する情報の収集。 このツールは、クライアントリクエストが多数のマイクロサービスに渡される可能性がある場合にボトルネックを見つけるのに役立ちます。
→プレゼンテーションリンク： pdf
3.ストリーミングアーキテクチャの中心にある高性能Javaアプリケーション
アレクセイ・キルピチニコフBeeVeeContourインフラストラクチャの将来に関するレポートは、 東部 、より正確にはテレメトリサービスの収集に関する部分に関するものです。 テレメトリ-ログ、メトリック、および分散トレース。
これは、1秒間に少なくとも100万のイベントを処理できるプロトタイプを組み立てる必要があるという話です（この順序は、マイクロサービスから収集されたテレメトリデータによる）。 プロトタイプは、 Apache Kafkaメッセージブローカーに基づいていました。これは、HTTPサーバーとしてRapidoidを使用して、サーバーがJavaで書き込まれるデータです。 なぜKafka、HTTP、およびRapidoidなのか？ レポートをご覧ください！ ネタバレ：ラピドイドスモッグ。 :)
このレポートのバリエーション（ただし.NET開発者向け）は、4月20日金曜日に開催されたSpbDotNet＃30ミーティングで発表されました 。
免責事項。 春以来、プロトタイプは徐々に食料品ソリューションに変わりつつあります。 テレメトリ収集および処理システムが次の会議の1つでどのように見えるかについて説明します。
→プレゼンテーションリンク： pptx 。
→コードへのリンク： spaceport 、 launchpad 。