Senior Lecturer in Game Development at the University of Brighton. Author of #FXGL game engine. #Java #JavaFX #Kotlin open sourcerer. PhD in Computer Science.
PostgreSQL’s protocol is currently at version 3, and there are concerns about improving the protocol in this regard.
The V4 wire protocol changes and the wanted features for V4 documents share concerns about version 4 with pipelining and multiplexing in mind. PostgreSQL also has a proposed feature called Protocol hooks that decouples PostgreSQL from the current protocol. It aims to provide extensibility of the wire protocol. Such a feature could be an enabler for multiplexing.
It took 25 years to deliver HTTP/2 and introduce multiplexing to increase performance drastically. Most database protocols have not followed the same path yet and remain in the stone age of connection pooling (at least databases with an openly documented protocol).
Multiplexed database protocols could improve performance, and make connection pools a thing of the past. It would also provide the foundation for efficient data streaming from databases.
BlockHound will transparently instrument the JVM classes and intercept blocking calls (e.g., IO) if they are performed from threads marked as “non-blocking operations only” (ie. threads implementing Reactor’s NonBlocking marker interface, like those started by Schedulers.parallel()).
If and when this happens (but remember, this should never happen!), an error will be thrown.
In order for any technology to grow and improve, community support and feedback are paramount.
To get a general idea of what the community would like to see in JavaFX in the future, I have asked developers to share their thoughts. The collated results are given below.
Each entry also includes links to open-source libraries and other resources that may provide (or help develop) some of the necessary functionalities.
Time-traveling cyborgs and robots that are able to love. These interesting and romantic ideas emerged from the imagination of Hollywood film directors.
Nevertheless, many people are afraid of Artificial Intelligence (AI). This also can be seen in the economic world.
Small and medium-sized enterprises (SMEs), in particular, see AI as a threat to their own business. Surprisingly however, all different-sized companies are able to see the potential of AI when it comes to penetrating the national and global market.
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).