Meng Lin's Byte-Wise Words

Today, I saw something incredible which basically looks like this. public class Thing { final ThingService thingService ; public Thing ( final ThingService thingService) { this . thingService = thingService ; } public Single<List<String>> getOtherThings ( final List<String> keys ) { return keys.stream() .map(key -> getOtherThing(key)) .reduce( Single. just (Collections. emptyList ()) , (singleThing1 , singleThing2) -> singleThing1 .flatMap(thing1 -> singleThing2 .map(thing2 -> { final List<String> newList = new LinkedList<>( thing1 ) ; newList.addAll(thing2) ; return newList ; })) ) ; } } public class ThingService { public Single<List<Strin...

Inheritance is one of the foundations of object-oriented programming, it sounds straight forward on paper, but when it comes down the specifics, the rules are subtly different from language to language, and I will compare and demonstrate the subtlety with field overriding in Java and Scala . Java way Consider this example for field overriding in Java. public class Parent { protected static String name = "parent" ;      public String getName () {      return this .myName() ;      } } public class Child extends Parent { final static String name = "child" ; } public static void Main ( final String[] args) { final Parent parent = new Parent() ; final Child child = new Child() ; parent.getName() ; // "parent" child.getName() ; // "parent" } If you know Java, it's probably not hard to tell both "getName" results are "parent", and there is a legitimate reason for that, in Java, fields cannot be overr...

Often you will see this usage of an Rx Single : Single. just (doThing())) So what problems does it have? To start with, unless the statement is the beginning of an async flow, then this would be fine. Otherwise, you are just asking for trouble, because it spins off an orphaned async flow which is not subscribed to . Secondly, this statement is often accompanied by the following usage: single.flatMap(thing -> Single. just (doThing(thing))) And that is just unnecessary , the correct way should be: single.map(thing -> doThing(thing)) Finally, the biggest issue with this approach is: it does not guarantee  re-evaluation of the async method, the logic will be evaluated once at the first run, even before it was subscribed. And even worse, if there is a retry policy configured, the retry will just pick up the same result every time, producing false results for the retries. But this problem is not unsolvable, there are two principles to consider: - If the code is the beginning of a...

Anyone who has used a switch statement should be familiar with this in Java. private String getName (String input) { switch (input) { case "a" : return "A" ; case "b" : return "B" ; case "c" : return "C" ; default : return "D" ; } } Looks pretty straight forward at a glance, but is it really? What if I use enums instead? public enum InputTypes { A , B , C ; } Now the code would look like the following: private String getName (InputTypes input) { switch (input) { case A : return "A" ; case B : return "B" ; case C : return "C" ; default : return "D" ; } } But for any eager eye, it should be obvious that there is something fishy here: in the enum, I have exhausted all the options in that enum, why shou...

It probably rarely occurs to people there could be a small bump on performance when manipulating strings in Java, since the computing power nowadays also considered to be infinite, and nobody will really try to add a dozen dead sea scrolls into one string or tweak it. Why should I bother!? Yes, when it comes to critical systems, or simply for optimisation's sake, devs should be more conscious about what object to use when altering a string. As a starter, String  is the most straight forward object to use in Java. The good thing about string object is that it is an immutable object , which means it will NOT change after it is instantiated, and any modification will cause a copy of the object be created. There is a lot of benefits to this implementation like  those . But when it comes down to mass modifications, it is more of a pain in the jacksie. What happens now, panic? Of course not, the clever people before us have not only come across the problem b...

I've been planning to write this for a long time, since I got so fascinated by the simplicity and elegance of message queue, and the performance boost it could bring to various systems. So here we are. TL;DR If you just want to see an example, or make sure you get the right dependencies: boom, here you go! What is Message Queue? Message Queue is the storage area of a mechanism, which allows distributed applications to communicate asynchronously by sending messages between the  applications .  Why Message Queue? I think you can probably google a dozen reasons why you should do it. Speaking from my experience working in various integration projects, message queue, is the pursue for high performance, high scalability, high resilience and low coupling, while accomplishing asynchronous communication, buffering and filtering at the same time. What Choices Do I Have? Rather than trying to implement you own message queueing, here is so...