About a week ago (on November, 16th, Saturday) this year I attended (although for the first time) JFuture conference.

The set of topics was the ideal match of the areas which I am at the moment highly interested in. And which are very relevant for the current state of the industry. Very great job by the program committee!

But if take apart the topics - the venue, food, price are superb! I can compare it with the many other conferences I attended in Russia (JPoint, Jocker, Highload++) and Europe (Devoxx, GOTO, and various smaller local conferences) I would rate JFuture to be the number one right now in terms of organization, topics and the price. Very well done!

Below I summarize only the talks I attended. Some triggered a few thoughts, some a lot. Below are not the retelling of the talks and all slides, but just my thoughts, what triggered my attention, and what my takeaways/action points are.

Also, the below are only my interpretation and understanding or sometimes extension of the talk by some extra personal research and could be not necessary what the speaker exactly talked about. So all opinions and thoughts are mines.

I don't know exactly how to summarize the conference, this is mainly for myself, the "raw" list notes, action items, tools to explore to come back sometime in the future to coordinate the thought process and choose the roadmap. And scheduled actions, which feel free to skip unless it is also relevant for you.

1. Uncovering Project Amber by Mala Gupta

Java is changing. Like we or not, but it does. For the better.

It is good to understand new language features, but until the next LTS release, which is Java 17, which is planned to be released somewhere fall 2021, realistically everything above Java 11 unlikely will be used by major production systems until Java 17.

Other benefits apart from the new language features are the performance and startup time improvement which has been more covered in details by David Delabassee in his JVMs in Containers: Best Practices talk below.

2. Battle of the Circuit Breakers: Istio vs. Hystrix/Resilience4J by Nicolas Frankel

JFuture - Battle of the circuit breakers

Istio provides global unified fallback implementation without possibility (at least as it has been said) to inject or intercept any business logic behind, so more like "black box" implementation.

While circuit breakers library is the "white box" implementation instead, where you are providing case by case business-specific fallback option.

The fallback options it is the business decision. Circuit Breakers libraries are just handy ways to implement graceful degradation and fallback options.

Fallback should be fast. There is the temptation to implement another service (with lets say outdated data) as the fallback service, although if it also requires the network call, it might not be the ideal form.

It has been suggested as the option to use or consider to use Spring abstraction over circuit breaker, looks like that one Spring Cloud Circuit Breaker. It supports Netflix Hystrix and Resilience4J as the possible implementations, although no Failsafe, for example. But personally, I would use the library directly rather than using Spring abstraction.

Also, another point discussed (asked from the audience) that it might be crucial to know that some particular service is down and the data is serving from the fallback, so the monitoring system should clearly reflect that.

3. Efficient web apps with Spring Boot 2 by Stéphane Nicoll

For the new project, it is recommended to start using WebClient instead of RestTemplate.

Also when you go reactive go it all way down, i.e. reactive end to end.

The obvious or immediate bottleneck so far could be access to the data storage in a reactive manner, although many providers starting to provide the reactive implementation of its data access. And also under R2DBC initiative major DB providers work on the reactive programming API to SQL database.

Demo:

Companion apps fo Efficient Web Applications with Spring Boot 2

Tools:

Which attracted my attention and worth to explore more.

• Micrometer vendor-neutral application metrics facade (think SLF4J, but for metrics)
• OpenTracing vendor-neutral APIs and instrumentation for distributed tracing
• Jaeger open source, end-to-end distributed tracing (in conjunction with OpenTracing)

Actions:

• Utilize more of the Spring Actuator (including metrics support)

4. JVMs in Containers: Best Practices by David Delabassee

JVMs in Containers

Use the latest JVM, apart from the issues resolved and new features, another important aspect is the startup time, and less memory and CPU consumption. Also, latest JVM honors the Docker environment and correctly reports to the underlying Docker container resource constraints the Java application is running in (like available memory and CPUs JDK-8146115 (since Java 10)).

There are various optimization techniques to reduce the resulting Docker image size containing the Java application:

• Use jlink to include only the necessary packages (which allowed to reduce the size of the "Hello World" app from 316mb to 34mb) --add-modules $(jdeps --print module deps ...) --no-header-files --no-man-pages --strip-java-debug-attributes --compress=2
• Use smaller/compact baseline OS image, like Alpine (when the Project Portola is completed)
• If using Debian as the base image always remove native debug symbol, it reduces the size of the resulting image a lot --strip-native-debug-symbols
• Using tools like Jib

In the context of startup time the following optimization techniques could be used:

• Utilize CDS/Class Data Sharing (which has been enabled since Java 1.5, but it improves in terms of the availability, features and ease of use every Java release, and is enabled by default from Java 12+). Good post on that subject: Improve Launch Times On Java 13 With Application Class-Data Sharing
• Use GraalVM and build the native binary for the platform

Also, the overall recommendation is to use the latest possible Java version, as it improves the overall memory footprint and startup time: OpenJDK Startup - Late 2019 Edition. As well it has been said that JVM tries to tune itself depends on the system it is running, and it does that better and better every release, which means less of manual JVM optimizations would be necessary.

(credit of the image OpenJDK Startup - Late 2019 Edition)

For the long-running application it might make more sense to use the HotSpot option, where you run the application once, and it is running for days/weeks/months/years.

Another aspect of choosing the base image is the security, and whether (and how many) vulnerabilities it has.

Tools:

• Helidon is a collection of Java libraries for writing microservices that run on a fast web core powered by Netty (Oracle initiative)
• Quarkus a Kubernetes Native Java stack tailored for OpenJDK HotSpot and GraalVM, crafted from the best of breed Java libraries and standards
• Micronaut a modern, JVM-based, full-stack framework for building modular, easily testable microservice and serverless applications
• OpenFaaS Serverless Functions Made Simple
• Fn Project Open Source. Container-native. Serverless platform
• dive awesome tool for exploring a docker image, layer contents, and discovering ways to shrink the size of your Docker/OCI image
• musl libc a new standard library to power a new generation of Linux-based devices
• Portola Project to provide a port of the JDK to the Alpine Linux distribution, and in particular the musl C library

Actions:

• Explore more of the GraalVM (in particular latest GraalVM 19.3 release with JDK 11 Support, announced a few days after the conference) and in the context of native Dynoman GraalVM based distribution

5. The State of Reactive Streams by Oleh Dokuka

The State Of Reactive Streams En

The talk by itself might require a separate post, so simply follow the slides.

Demo:

Reactive Streams Emulation

Actions:

• RSocket has been a while on my radar, might be good to explore it more
• Reactive Streams and Reactive Streams JVM simply RTFM
• Explore Java 9 Flow API. That course on LinkedIn Learning could be the good starting point: Reactive Java 9
• Explore more of the Kotlin Coroutines and read the guide (I expect it is somehow similar to Go goroutines)
• Explore Project Loom specification/status and available online talks and resources. Good to understand on how it resembles the available these days coroutines in Kotlin.
• Explore Spring web reactive support. Oleh's book could the good option: Hands-On Reactive Programming in Spring 5 (as his understanding of the subject is deep and trusted).
• Understand how RxJava fits now into the world of Java Flow API, Spring Reactive and in general how do they interconnect to each other. Maybe this book could be helpful as it covers RxKotlin implementation and highlights what is the difference or similarity between internal Rx implementation and Kotlin Coroutines: Reactive Programming in Kotlin (although it is old from 2017, maybe it is still relevant).
• Use the latest version of Project Reactor on the project

6. Dealing with Time and Clocks in Code by Kees Jan Koster

(credit of the image xkcd)

Always set up NTP on the server. It is highly critical for correctness for many distributed systems. Although looks like it is not that straight forward as in these 2 articles explained some common pitfalls and the solutions to them: Synchronizing Clocks In a Cassandra Cluster Pt. 1 - The Problem and Synchronizing Clocks In a Cassandra Cluster Pt. 2 - Solutions (although they are 5 years old, so things could be improved/changed over this period of time, but at least how it was in the past, and could be still relevant up today).

On the above articles discussed that with the author of the talk Kees Jan Koster he replied that advices mentioned in the article are excellent one for the database clusters, although for a more general use-case, such as bunch of microservices in application containers, this setup seems overkill. And depending on the system design 30ms could be a plenty precise.

Always use UTC. And convert to UTC as soon as possible, and convert back to the user locale-specific format as late as possible (mainly on the UI layer).

Use ISO 8601 format/Zulu to store date time, i.e. yyyy-MM-ddTHH:mm:ss.SSSZ (or UTC timestamp).

User's locale is most of the time the only source of data on how to convert UTC date time format back to the user's date time. Although it is not always reliable. So maybe this is why so many applications (web and mobile) require or at least allow the user to explicitly set the time zone the user is in.

If you can avoid working with time zone do this. Time zones are difficult.

Always use the library which deals with the date time conversion, do not reinvent the wheel and write your own.

7. Teach your PacMan to play with ML and Reactive Streams by Mary Grygleski/Oleh Dokuka

As I understood the idea of the talk/research/project was to explain that simpler techniques than classical Machine Learning could be used to solve at first look difficult problems (sorry if interpret or call things wrong). One such approach is the Q-Learning/Reinforcement learning.

I found that article that looks like the gentle introduction into the topic An introduction to Q-Learning: Reinforcement Learning and probably more in-depth paper Combining Case-Based Reasoning andReinforcement Learning for Unit Navigation inReal-Time Strategy Game AI.

One of the points of interest of mine whether this approach (if it is indeed simple enough) could be used to program AI in the CodinGame multiplayer contests.

Demo:

Multiplayer Reactive Pac-Man with RSocket

8. Exploring Neural Networking with Kotlin Metaprogramming by Amanda Hinchman

UI testing is hard, and from what I understood there are no good (or any at all) tools available to solve this problem.

UI automation testing or other intelligent testing approaches/frameworks should not be considered as the replacement of the testers, but rather as the tools to simplify and improve the quality of their job.

I've tried TornadoFX-Suite on my own Dynoman project and on the TornadoFX-Suite itself. It failed in both times unless I used it wrong.

Other Talks

Below are available slides of the other talks (for which the slides were published online, but which I didn't attend, so I can't comment on anything).

Hey Google, send 20$ to Mummy!? by Julien Lengrand-Lambert

Hey Google, send 20$ to Mummy!?

IoT powered by Microprofile – Microservices in practice by Mads Opheim

IoT Powered by MicroProfile - JFuture

Distributed Caching Patterns in Kubernetes by Mesut Celik

Distributed Caching in Kubernetes with Hazelcast

Purely Dysfunctional Data Structures in Java by Grzegorz Piwowarek

Purely Dysfunctional Data Structures

Spring Data Moore and beyond by Christoph Strobl

Spring Data Moore and Beyond

Collaborating on Open Source Software by Marit van Dijk

Collaborating on Open Source - JFuture.dev (Minsk) Nov 16th, 2019

Live Coding Music 101 by Piotr Jagielski

Live coding music 101

Again the conference was very good in all the aspects. And I would definitely recommend anyone (although check whether you are interested in the particular talks) attend it the next time!