[Ekaterinburg, announcement] java.ural.Meetup @ 2 - the announcement of the second Java-mitap + video reports from java.ural.Meetup @ 1
On the first day of winter, December 1 , we invite you to take part in the second
Bonus publish recordings of reports from the meeting
What is
At the beginning of the year, a survey was dispersed among the developers of Ekaterinburg: “Do we need new Java engines?” Positive feedback was collected - so we decided to have mitaps. Almost two months later, the mitap was announced . Two weeks later, the first meeting of
')
Under the cut, the announcement of the second meeting and video reports from the first meeting.
Program mitap:
From the last meeting of
Spring is the most used framework for dependency injection. It provides a rich out-of-the-box toolkit, but sometimes you have to make compromises when using these tools. In the report, I will demonstrate ways of expanding the possibilities of dependency rewinding, as well as compare them with out-of-the-box tools.
In the modern world for the JVM there is a huge variety of languages, among which are Java, Scala, Kotlin, Groovy, as well as many others. Which one should I choose? In the report we will talk about Clojure programming language, why you can choose this language to develop your next (and maybe current) system, and also focus on one of the most important components of this language - interactive development in the REPL.
The Java world has a huge advantage over .NET in terms of the variety and maturity of tools, frameworks, and libraries. In the Contour, we have repeatedly encountered and continue to face the fact that Java libraries that solve essentially the same problem (for example, a driver for a database or a client library of some popular tool ) turn out to be better (faster, more functional, better) than their counterparts under .NET.
The report is devoted to such examples and ways to borrow the best that is in the Java ecosystem for the needs of .NET projects.
The focus is on low-level integration by using the native layer ( JNI ) to invoke Java code from the C # code.
This is implemented by the Java Invocation API , which is part of the Java Native Interface standard.
Run a Java virtual machine inside a .NET process using the Invocation API. In fact, this mechanism in some sense duplicates the implementation of
Interaction of C # code with Java objects through a special wrapper around the Java Native Interface. JNI was designed to work from / to the native plus code, so all sorts of raw pointers stick out of it. In C # (as well as in Java) we are used to working in a managed environment, when we don’t know anything about pointers to objects / structures, and the virtual machine completely manages memory. The main task of the wrapper was to encapsulate the features of native code in C # interfaces.
Disclaimer. Variations of this report were presented at the conferences DotNext Piter 2017 and Joker 2018 .
→ Link to the presentation: pptx .
→ Link to code: .NET part , Java part .
Long before the release of Spring Boot 2.0 and the Spring Framework 5.0, we were faced with the need for asynchronous microservice interaction in our Java services, as has been practiced in our .NET projects for a long time.
Vert.x was chosen as the basis for our services, which is not a framework in a broad sense, but belongs to the category of toolkits ( what is the difference in terminology ). This allowed to independently determine the architecture of microservices, and the standard unit of asynchrony became the standard
The report is devoted to two tools used in the construction of such services: cluster client and distributed query tracing.
Cluster client. Client library, which solves the problem of selecting the desired replica of the called microservice. At the same time, the topology changes on the fly (built-in mechanism for Service Discovery). The implementation of this library on .NET is laid out in Open Source as part of the Vostok project - clusterclient .
Distributed tracing. Collection of information on all interservice requests with the ability to build the entire trace tree (child requests). This tool helps in finding bottlenecks when a client request can scatter across dozens of microservices.
→ Link to the presentation: pdf .
The report on the future of the Contour infrastructure is about the East , more precisely about the part concerning the collection of telemetry services. Telemetry - logs, metrics and distributed traces.
This is a story about how it was necessary to assemble a prototype that allows pumping at least 1 million events per second through itself (such an order according to telemetry data collected from microservices). The prototype is based on the Apache Kafka message broker, which is stored in a server written in Java using Rapidoid as the HTTP server. Why Kafka, HTTP and Rapidoid? See the report! Spoiler: Rapidoid smog. :)
A variation of this report (but for the .NET developer audience) was presented at the SpbDotNet # 30 meeting on Friday, April 20.
Disclaimer. Since spring, the prototype is gradually transformed into a grocery solution. We will tell you about how the telemetry collection and processing system now looks like at one of the following meetings.
→ Link to the presentation: pptx .
→ Link to code: spaceport , launchpad .
java.ural.Meetup meeting, which will be held in the conference room in the new office of the Contour at ul. Maloprudnaya, 5. Beginning at 14:00.
Bonus publish recordings of reports from the meeting
java.ural.Meetup @1 , held March 15 in Yekaterinburg.
What is java.ural.Meetup ?
At the beginning of the year, a survey was dispersed among the developers of Ekaterinburg: “Do we need new Java engines?” Positive feedback was collected - so we decided to have mitaps. Almost two months later, the mitap was announced . Two weeks later, the first meeting of
java.ural.Meetup gathered more than 60 developers from Ekaterinburg. At the meeting, the developers from Kontur spoke about their current tasks.
')
Under the cut, the announcement of the second meeting and video reports from the first meeting.
Announcement java.ural.Meetup @ 2
Location : Kontura office at ul. Maloprudnaya, 5 .
Date and time : Saturday, December 1 from 2 pm .
Participation is free, but registration is required (if you plan to arrive by car, please do not forget to indicate its number to access the parking).
Program mitap:
- Grigory Koshelev with the report "Java 11".
- Andrey Nevedomsky with the report “Customization of dependency resolving in Spring”.
- Denis Shilov with the report “Clojure. LISP for JVM, but why? ”
- Afterparty at the bar.
1. Java 11
Grigory Koshelev gnkoshelevFrom the last meeting of
java.ural.Meetup Java 10 managed to exit and immediately become legacy (as well as Java 9) to give way to the LTS version of Java 11. But let's look at the changes that occurred in Java after the release of 8-ki.
2. Customizing dependency resolver in Spring
Andrey NevedomskySpring is the most used framework for dependency injection. It provides a rich out-of-the-box toolkit, but sometimes you have to make compromises when using these tools. In the report, I will demonstrate ways of expanding the possibilities of dependency rewinding, as well as compare them with out-of-the-box tools.
3. Clojure. LISP for JVM, but why?
Denis ShilovIn the modern world for the JVM there is a huge variety of languages, among which are Java, Scala, Kotlin, Groovy, as well as many others. Which one should I choose? In the report we will talk about Clojure programming language, why you can choose this language to develop your next (and maybe current) system, and also focus on one of the most important components of this language - interactive development in the REPL.
Video + content from java.ural.Meetup @ 1
1. Integrating .NET and Java Virtual Machines
Grigory Koshelev gnkoshelevThe Java world has a huge advantage over .NET in terms of the variety and maturity of tools, frameworks, and libraries. In the Contour, we have repeatedly encountered and continue to face the fact that Java libraries that solve essentially the same problem (for example, a driver for a database or a client library of some popular tool ) turn out to be better (faster, more functional, better) than their counterparts under .NET.
The report is devoted to such examples and ways to borrow the best that is in the Java ecosystem for the needs of .NET projects.
The focus is on low-level integration by using the native layer ( JNI ) to invoke Java code from the C # code.
This is implemented by the Java Invocation API , which is part of the Java Native Interface standard.
Run a Java virtual machine inside a .NET process using the Invocation API. In fact, this mechanism in some sense duplicates the implementation of
java.exe - essentially wrappers around jvm.dll (JVM implementations under Windows).
Interaction of C # code with Java objects through a special wrapper around the Java Native Interface. JNI was designed to work from / to the native plus code, so all sorts of raw pointers stick out of it. In C # (as well as in Java) we are used to working in a managed environment, when we don’t know anything about pointers to objects / structures, and the virtual machine completely manages memory. The main task of the wrapper was to encapsulate the features of native code in C # interfaces.
Disclaimer. Variations of this report were presented at the conferences DotNext Piter 2017 and Joker 2018 .
→ Link to the presentation: pptx .
→ Link to code: .NET part , Java part .
2. Asynchronous microservice communication
Sergey Anufriev and Evgeny ShtykovLong before the release of Spring Boot 2.0 and the Spring Framework 5.0, we were faced with the need for asynchronous microservice interaction in our Java services, as has been practiced in our .NET projects for a long time.
Vert.x was chosen as the basis for our services, which is not a framework in a broad sense, but belongs to the category of toolkits ( what is the difference in terminology ). This allowed to independently determine the architecture of microservices, and the standard unit of asynchrony became the standard
CompletableFuture .
The report is devoted to two tools used in the construction of such services: cluster client and distributed query tracing.
Cluster client. Client library, which solves the problem of selecting the desired replica of the called microservice. At the same time, the topology changes on the fly (built-in mechanism for Service Discovery). The implementation of this library on .NET is laid out in Open Source as part of the Vostok project - clusterclient .
Distributed tracing. Collection of information on all interservice requests with the ability to build the entire trace tree (child requests). This tool helps in finding bottlenecks when a client request can scatter across dozens of microservices.
→ Link to the presentation: pdf .
3. High-performance Java application in the heart of the streaming architecture
Alexey Kirpichnikov BeeVeeThe report on the future of the Contour infrastructure is about the East , more precisely about the part concerning the collection of telemetry services. Telemetry - logs, metrics and distributed traces.
This is a story about how it was necessary to assemble a prototype that allows pumping at least 1 million events per second through itself (such an order according to telemetry data collected from microservices). The prototype is based on the Apache Kafka message broker, which is stored in a server written in Java using Rapidoid as the HTTP server. Why Kafka, HTTP and Rapidoid? See the report! Spoiler: Rapidoid smog. :)
A variation of this report (but for the .NET developer audience) was presented at the SpbDotNet # 30 meeting on Friday, April 20.
Disclaimer. Since spring, the prototype is gradually transformed into a grocery solution. We will tell you about how the telemetry collection and processing system now looks like at one of the following meetings.
→ Link to the presentation: pptx .
→ Link to code: spaceport , launchpad .
Source: https://habr.com/ru/post/352934/
All Articles