java
3 posts in this category
Reactive systems using Reactor
Nov 21, 2016
Reactor 3.x is a Java library for writing reactive
applications using the Reactive Streams standard. Reactor Core
provides a reactive streams implementation similar in style to
RxJava 2. Because it is based on standard reactive streams, Reactor
can easily integrate with any other reactive streams library (particularly
RxJava 2). There are adapters available for RxJava 1 and the
CompleteableFuture
API as well as conversions for the new JDK 9
Flow
reactive stream interfaces. Reactor also provides an IPC
API for implementing reactive streams systems for general networking and off-JVM
communication. The main implementation of the IPC API is Reactor Netty
which provides TCP, UDP, and HTTP DSLs. There are other modules in the works,
but Reactor 3.x is still under heavy development.
The Lagom Framework for reactive microservices
Nov 14, 2016
Microservice architecture is amongst the latest in best practices in software architecture. Essentially, microservices are small, independent applications that provide REST APIs for communication. These applications are akin to the Unix philosophy of small programs: each program does one thing and does it well. Each application should work on its own and be independently deployable, thus making each microservice independently maintainable. One simple way to check if a service is a microservice is if it is easily described in a single, simple sentence.
May 29, 2016
It’s been almost six months since we released Log4j 2.5, and we have a bunch of neat things added since then. The biggest change is that now you can operate Log4j in a garbage-free mode during steady state logging. Sounds a bit jargony? The basic idea here is that once your application is initialized and doing its thing (the steady state), logging no longer contributes towards memory pressure, thus you have more control over memory allocation and gargabe collection. Various Java performance gurus point out that logging tends to add a lot of overhead to applications, and one major reason is due to garbage generated by the logging framework. The less garbage objects generated by the framework, the less time your application needs to spend collecting said garbage.