Senior Lecturer in Game Development at the University of Brighton. Author of #FXGL game engine. #Java #JavaFX #Kotlin open sourcerer. PhD in Computer Science.
Kotlin offers many exciting features.
In general, developers tend to cite null safety as their favorite. For me, it’s function extensions. But delegation comes a close second.
The delegate pattern is ubiquitous in the Object-Oriented Programming world. Some languages, such as Kotlin, provides a native implementation.
But delegation doesn’t stop at the class level. Kotlin does provide delegation at the property level. It provides some out-of-the-box delegates, but you can easily create your own.
Java developers are particularly spoiled when using Hazelcast. Because Hazelcast is developed in Java, it’s available as a JAR, and we can integrate it as a library in our application.
Just add it to the application’s classpath, start a node, and we’re good to go. However, I believe that once you start relying on Hazelcast as a critical infrastructure component, embedding limits your options. In this post, I’d like to dive a bit deeper into the subject.
Functional Programming is becoming more and more popular. Spring provides a couple of DSLs for the Kotlin language. For example, the Beans DSL and the Routes DSL allow for a more functional approach toward Spring configuration. On the type side, Vavr (previously Javaslang) is pretty popular in Java, while Kotlin has Arrow.
In this post, I’d like to describe how one can use Arrow’s type system with Spring Data. Ultimately, you can benefit from the explanations to craft your custom Spring Data repository.
I’ve been playing with GraalVM Ahead-Of-Time compilation capability since I became aware of it.
As a long-time Spring aficionado, I carefully monitored the efforts that the engineers at Tanzu have put into making Spring AOT-compatible. Recently, they announced the beta version of the integration.
In this post, I want to check how easy it is to produce a (working!) Docker image from an existing Spring Boot application.
In this article, we comparatively evaluate four different approaches to render particles in JavaFX in terms of runtime performance.
The approaches are Canvas, PixelBuffer AWT, PixelBuffer CPU and PixelBuffer GPU.
The evaluation suggests the following order of approaches from fastest to slowest:
– PixelBuffer GPU (fastest).
– PixelBuffer CPU.
– PixelBuffer AWT.
– Canvas (slowest).