GarciaPL Notes - Java and Others

Do you still write those special if statements for enums like myEnum.equals(myEnum.TEST) ? If yes, I might be able to share with you a small tip how to avoid it! It will be very beneficial for you because of your code might express itself without a word! Moreover, you might avoid those imports of your enum fields in every class where the comparison is going to be defined by if statement. It will say you a lot of time in case of changing name of enum field.

For instance, for the example defined below, only what you need to do in your code is -> if (operation.isCount()) {...} instead of if (operations.equals(Operation.COUNTA)) {...}

Check this post on Medium.com -> Use enum utility methods in Java ! Avoid equals at all costs!

import org.apache.commons.lang3.EnumUtils;

public enum Operation {

    COUNTA,
    SUM,

    NA;

    public static Operation parse(String input) {
        Operation operation = EnumUtils.getEnum(Operation.class, input);
        if (operation == null) {
            return NA;
        }
        return operation;
    }

    public boolean isCount() {
        return this == COUNTA;
    }

    public boolean isSum() {
        return this == SUM;
    }

    public boolean isCountOrSum() {
        return this == COUNTA || this == SUM;
    }

}

Recently, I was trying to move some files, mostly .java's and.sql's, from one maven module into another one. We were just trying to merge two modules into one module, because of we thought that keeping two modules with pretty the same functionality is odd.

The main point around this movement was to preserve the history of changes made to those files in the past. Everything was fine until we tried to deploy the application on the server. Of course, I forgot to mention that we were using Flyway as a database migration tool. Unexpectedly, one of the file's checksum was not the same as the checksum saved in the database for that SQL file (flyway_schema_history table). We were astonished because of the content of the file did not change at all... but Pull Request on BitBucket was saying that there is a difference. We checked the MD5 for that file before and after the move, it was the same, but for some reason the checksum detected by Flyway was different! To be honest, we spent a lot of time trying to understand why it's happening, and then I found this post made by Richard Tuin [1].

The solution was just to revert moving of those SQL files up to the previous location and try to create a file called .gitattributes. We defined over there just a single line which was disabling CRLF for that single file for which checksum was not the same as this one stored in flyway schema history table. After moving SQL files once again, using git mv [2] command and uploading results on BitBucket, everything was fine!

The content of .gitattributes for that single file should look as below :

fileName.sql -crlf


References :
[1] Richard Tuin - How to make git ignore different line endings
[2] Git mv
[3] Git attributes

Last time I was looking for an explanation what this "Non-Blocking IO" means. It was hard to understand what it's not blocking and what exactly it does or does not. Moreover, I was trying to find information how this correlates with reactive programming in overall... and I found it! Please check article listed in References. Thanks Adam!

In an old approach called threaded blocking IO, we bound every new connection to a new socket and create a new thread to process the data. This means that there is a single open connection which is managed by the single thread. When a client requests a connection from the server socket it sends back a new socket to communicate with. Now multiple connections can be handled until the limit of the maximum number of threads is reached. Each thread requires memory allocation, so while the concurrent connection goes up, the performance of the server goes down.

Instead of binding the thread to a connection, a notification is sent when the data is ready to read from a buffer. NIO uses buffers instead of streams to read/write data because data is processed when it's already there, not when it's actually being received. With this mechanism, multiple connections can be handled by one thread. That's how finally no threads are blocked while waiting on the IO.
The thread is only responsible for reading the buffers when it's notified about the arrival of any new data. This mechanism is called the 'event loop'. Following that logic, lots of concurrent connections can be handled with just a couple of threads. That's why NIO-based servers are so awesome and serve as our first building blocks.

Reactive programming is about using asynchronous, non-blocking building blocks with a functional style of coding.