Devoxx Belgium 2022 Takeaways
In October 2022, I visited Devoxx Belgium after two cancelled editions due to COVID-19. I learned a lot and received quite some information which I do not want to withhold from you. In this blog, you can find my takeaways of Devoxx Belgium 2022! 1. Introduction Devoxx Belgium is the largest Java conference in Europe. This year, it was already the 19th edition. As always, Devoxx is being held in the fantastic theatres of Kinepolis Antwerp. The past two editions were cancelled due to COVID-19. As a result, there was a rush on the tickets. The first batch of tickets was sold out in 5 minutes, the second batch in a few seconds. Reactions on Twitter mentioned that it looked like a ticket sale for Beyonce. Although it was my plan to only attend the conference days, I was more or less obliged to also attend the Deep Dive days. For the record, the first two days of Devoxx are Deep Dive days where you can enjoy more in-depth talks (about 2-3 hours) and hands-on workshops. Days three up and including five are the conference days where talks are being held in a time frame of maximum 50 minutes. Nevertheless, I was attending Devoxx for five days. And it was a blast. I really enjoyed the Deep Dive days. The speakers take more time to elaborate on a topic and are also more relaxed. During a conference talk, as a speaker, you need to limit yourself to 50 minutes which can be challenging. I also attended some hands-on workshops, which I enjoyed very much. The workshops are in smaller groups of about 20-30 persons. As the name says, these are hands-on, so you’d better take your laptop with you. Enough for the introduction, the next paragraphs contain my takeaways from Devoxx. This only scratches the surface of a topic, but it should be enough in order to make you curious to dive a bit deeper in the topic yourself. Do check out the Devoxx Youtube channel. All the sessions are recorded and can be viewed there. The organizers did a great job, because the sessions of a particular day were already available on the channel the next day. That is really fast. If you intend to view them all: there are 240 of them… 2. Java Ecosystem Development 2.1 Project Loom – Virtual Threads Virtual threads is about handling numerous blocking requests and responses. When executing a blocking request, the processing itself only takes some nanoseconds. Waiting for the request to be sent over the internet and providing a response takes several milliseconds. This means that in case of a blocking request, the CPU is 99,9% of the time idle. This is really a waste. The current solution to this problem are asynchronous requests. However, the code you need to write for asynchronous processing is complex, difficult to profile and eventually leads to spaghetti code. This is where virtual threads come to the rescue. Virtual threads are not bound to an OS thread. Code is executed on OS thread 1, the OS thread is freed again during the blocking call and when the blocking part is finished, the rest of the code is executed, possibly on another OS thread 2 (but it might also be processed again on OS thread 1). Because the OS threads are freed during a blocking call, many more virtual threads can be executed in parallel. An amount of 1 million virtual threads on a normal laptop is no issue. You can probably run about 4000 threads in parallel without virtual threads. As a consequence, you do not need to write difficult asynchronous code anymore. Another topic which is part of Project Loom, is structured concurrency. Assume you want to interrogate several services in order to obtain the best price for a hotel room. With structured concurrency, you can assign several callbacks and group them together by means of a join and continue when all the wanted results are available. Virtual threads is a preview feature in JDK19, so the implementation can be changed with the next JDK releases. At least, it is an interesting topic to keep an eye on. If you want to know more about virtual threads, you can watch Loom is Looming. 2.2 GraalVM GraalVM Native Image technology compiles Java code ahead-of-time into a native executable file. Only the code that is required at run time by the application is included in the executable file. As a consequence, the startup time of your application is super fast. The build time is longer, however. A perfect use case is when you want to run your Java application as a serverless function, e.g. with AWS Lambda. In this context, it is very important that your application can start very fast. Something to be aware of is that GraalVM does not recognize classes which are loaded by means of reflection. You need to provide this information to GraalVM. There is a tracing tool available which will help you to create the configuration file needed for that. Another initiative in this context is Spring Native. Spring Native is still experimental, but you can give it a try. With the Spring Native project, Spring has tried to remove as much as reflection out of the Spring code. Besides that, it helps you with the reflection parts of used dependencies. It should almost work out-of-the-box. There is also an interesting article about this topic at Medium. If you want to experiment with GraalVM, the workshop is a good starting point. 2.3 What’s Next After Git I am quite interested in version control, so I was curious whether there is already something new cooking in this field. There are two VCS which might be interesting, but bottom line is that Git will remain for a while. The first alternative is Fossil. It is just like Git a distributed system. It does not support rebase and it runs with an SQLite database. The second alternative is Pijul. It is just like Git a distributed system. It follows the patch theory, so basically everything is a cherry-pick. More information can be found in the talk Will Git Be Around Forever. 2.4 JetBrains Fleet JetBrains made the Fleet IDE publicly available during Devoxx. Fleet will have support for multiple languages. That will remove the need to install a seperate IDE for every language. So, no need anymore for IntelliJ, PyCharm, WebStorm, etc. It lacks of course features nowadays, but from now on, you can experiment with it. If you find issues, you can file them with JetBrains. But do note that this is experimental. I have seen quite some Tweets the past weeks from people complaining that some things do not work, but that is why it is still experimental. You need to give JetBrains the time and we should be glad that they want your opinion and feedback. More information can be found at the Fleet website. 2.5 Future of Frontend Development I was quite curious about what can be expected in the near future for frontend development. Conclusion is that the major three frameworks React, Angular and Vue will remain. There are some new frameworks which have more focus on less client side processing. These new frameworks can initially release new features, concepts faster, but the main three frameworks are also working on this. The assumption is that the new frameworks will not be able to compete with the major three, because at that time the major three will have caught up with the new ones. This was a nice talk, so if you want to know more about this topic, just watch the talk. 2.6 Maven I use Maven as primary build tool and learned what is going on with Maven currently and in the near future. Maven wrapper: The Maven wrapper is now an Apache project. When you create a Spring Boot project from the Spring Initializer website, you always get a Maven wrapper. This can be used in order to ensure that everyone is using the same Maven version and you do not need to have installed Maven in order to build the application. Build/Consumer pom decoupling:With Maven 4, the build and consumer pom will be decoupled. What does this mean? Nowadays, the pom file is also deployed as-is to a Maven artefact repository. Many tools are dependent on the structure of this pom file. However, this blocks the Maven project from making enhancements to the pom file in order to easen the life of developers. Therefore, the build and consumer pom need to be decoupled. What can be made easier? E.g. when you work with Maven modules, you are now obliged to add a section for the parent pom. In 99,9% of the time, the parent pom is located in the directory above the pom of a module. Therefore, Maven can sort this out by itself. This means, that in the future, you will not need to add a parent pom section anymore in the pom of a module. Maven will add this section when the pom needs to be deployed to a Maven artefact repository. Improved Reactor: This improvement will make it easier to resume failed builds, especially when you want to build a child pom. More information can be found here. Maven daemon: The Maven daemon keeps the JVM and plugins in memory. This means, when you run consecutive builds, the first build will take some time, but from the second build on, the builds will be faster. I have tried this with a project of mine: mvn clean verify: 38.994 s with Maven daemon, first build: 40.469 s with Maven daemon, consecutive build: 31.571 s Install the Maven daemon and save time! The Maven daemon is also available from SDKMAN. 3. Testing 3.1 Playwright Playwright is an end-to-end testing framework. It is like Selenium but more elaborate. The interesting part was that you can record your test and Playwright will create a template for you. With this template you have a head start for creating the automated test. Other interesting parts were that you can verify whether requests are actually sent to the backend and that Playwright automatically can create screenshots for you during the test. This way, you can have a complete trace of the test. 3.2 Testing an Onion Architecture This was an interesting talk about test slice annotations. You do not have to use SpringBootTest all of the time in order to test your components. Using test slice annotations, you can speed up your tests significantly. Testing the Controller: use WebMvcTest; Testing a Rest Client: use RestClientTest with WireMock and MockRestServiceServer; Testing the repository: use DataJpaTest with testcontainers. Slides and code repository are available. The talk can be viewed here. 3.3 Contract Testing Contract Testing is a test approach in order to verify whether applications will work together based on a specified contract. It situates itself between Integration Tests and End-to-End Tests. The idea is that an independent broker, which is accessible for both parties, verifies whether your implementation is still valid according to the contract. Such a broker is Pact. If you do not know the consumers of your API, then you should use OpenAPI. A similar broker is Spring Cloud Contract. Pact can be used in a polyglot environment whereas Spring Cloud Contract cannot. More information can be found in the talk. 4. Security 4.1 SBOM SBOM’s (Software Bill of Materials) are becoming more and more important. But how do you create your SBOM? One way to do so is by using CycloneDX. CycloneDX can be run from within Maven, so it should be easy to use. Sonatype also provides an experimental website called BOM Doctor. Here you can analyze your SBOM in a graphical way and it will provide a score. Do not know yet how to interpret this graph, but for the spring-boot-starter-web, it looks as follows. Other interesting websites to take a look at are Reproducible Builds and Sigstore. 4.2 Security Knowledge Framework Security Knowledge Framework is the place to be when you want to learn more about application security. The starting point is the Online Demo. Here you will have access to training material, hands-on labs, security checklists for your requirements, etc. It provides you a lot of information and I will need to take the time to dive a bit deeper in this, but it looks very promising and interesting. 5. Artifical Intelligence There were quite some talks about AI. The results that were shown are mindblowing but also scary. Besides that, AI prompt engineering might turn into a future profession. Some interesting websites to take a look at, are: Midjourney Showcase: AI generated pictures, some of them are quite impressive; CodeGeeX: generate code based on a descriptive text; Once Upon a Bot: generate a story based on some input text; Stable Diffusion: experiment yourself with generating images. 6. Other 6.1 Domain Driven Design If you want to get acquainted with DDD, the suggested learning path is the following: Read the blog Domain-Driven Design in 2020 by Alberto Brandolino; Read the book Implementing Domain-driven Design by Vaughn Vernon; Read the book Patterns, Principles, and Practices of Domain-Driven Design by Nick Tune and Scott Millett; Watch the talk The Power of Value by Dan Bergh Johnsson; As last, read the book Domain-Driven Design by Eric Evans. Although DDD is commonly used in a microservices architecture, it might also become important in the Modular Monolith. After Devoxx, I read this Spring blog Introducing Spring Modulith which should help Spring developers with creating domain-aligned Spring Boot applications. 6.2 Women in Tech There were quite some talks about the topic Women in Tech. Food for thought are: Women believe that they should fit to 90% of the requirements of an application compared to 60% for men. In order to attrack women to our profession, we could try to have a bit less of a bro culture. Meaning, less beer and pizza, but a bit more things where women in general feel more comfortable with. A lot of women have been groundbreaking in the software industry. Software programming was initially even a profession for women. Have we forgotten that, do we recognize this enough? 6.3 Learning Through Tinkering In our profession you have to be a life-long learner. You cannot learn everything though, so you need to follow some kind of learning path. The Zone of Proximal Development can help you with that. It consists out of three circles. What you know: these are all the things you already know; You can learn this: these are all the things based upon your current knowledge which you are able to learn; You cannot learn this yet: these are all the things which are out-of-reach at the moment. If you would like to learn these items while skipping the You can learn this phase, you will most likely fail. That is because you would need to learn too many things at once. If you would like to mentor someone or you are looking for a mentor, you should definitely check out the Coding Coach website. 7. Conclusion Devoxx 2022 was great and I am glad I was able to attend the event. As you can read in this blog, I learned a lot and I need to take a closer look at many topics. At least I do not need to search for inspiration for future blogs!
November 9, 2022
by
Gunter Rotsaert
CORE
·
6,491 Views
·
2 Likes
