Vanilla Java

When Java 5.0 was released on 30 th September 2004, it introduced StringBuilder as a replacement for StringBuffer in cases where thread safety isn't required. The idea was simple: if you're manipulating strings within a single thread, StringBuilder offers a faster, unsynchronized alternative to StringBuffer . This is an updated article from 2011 From the Javadoc for StringBuilder : This class provides an API compatible with StringBuffer , but with no guarantee of synchronization. This class is designed for use as a drop-in replacement for StringBuffer in places where the string buffer was being used by a single thread (as is generally the case). Where possible, it is recommended that this class be used in preference to StringBuffer as it will be faster under most implementations. Is StringBuffer Really Dead? You might think that StringBuffer has become redundant, given that most single-threaded scenarios can use StringBuilder , and thread safety often require...

In Java development, clear and concise naming conventions are essential for code readability and maintainability. However, sometimes, we stumble upon class names that stretch the limits of practicality. One such example is InternalFrameTitlePaneMaximizeButtonWindowNotFocusedState . But did you know that in Java 6, this class name was even longer? Within the Java 6 JRE, there's a class with an astonishingly lengthy name: com.sun.java.swing.plaf.nimbus.InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonWindowNotFocusedState This mouthful appears to be the product of a code generator that needed to be reviewed, leading to redundant and cumbersome naming. Or is it a geeky poem buried in the code? InternalFrame InternalFrame Title Pane, Internal Frame Title Pane. Maximize Button Window, Not Focused State. The moral of the story is always check the readability/sanity of generated code. In this Hacker News Discussion another class was also consid...

Apache Kafka is a common choice for inter-service communication. Kafka facilitates the parallel processing of messages and is a good choice for log aggregation. Kafka claims to be low latency, high throughput . However, is Kafka fast enough for many microservices applications in the cloud? When I wrote Chronicle Queue Open Source my aim was to develop a messaging framework with microsecond latencies, and banks around the world have adopted it for use in their latency-sensitive trading systems. In this article, I will describe how Kafka does not scale in terms of throughput as easily as Chronicle Queue for microservices applications. As a teaser, I will show you this chart showing that Chronicle Queue is around 750 times faster even for lower throughput. Visualising delay as a distance In order to illustrate the difference, let me start with an analogy. Light travels through optic fibre and copper at about two thirds the speed of light in a vacuum, so to appreciate very short de...

I have three talks I am giving at the moment. The first I have given a few times, the remaining two are still in beta. Latency sensitive Micro-services What can Trading System and Micro-services learn from each other? What strategies do they have in common? http://www.slideshare.net/PeterLawrey/low-latency-microservices-in-java-qcon-new-york-2016 Modelling interactions between microservices. Describing interactions between micro-services in code, as readable messages and graphically. (Beginner to Intermediate) Exceptional Exception Handling There is many different way to handle exception apart from the typical log/ignore and pretend it didn't matter. What are the alternatives and which might you use them. Documentation Driven Development to make contributions easier. How can documentation driven development make it easier to start using and improve adoption rates for your project/product? How does it make it easier to contribute? Why is it so important for Micro...

This blog is moving to  https://vanilla-java.github.io/ Why move to Asciidoc on HubPress on Gighub from Blogger. I am moving my blog to use Asciidoc on Github.com. This is partially to make it easier to embed code and tables, but mostly because I am tired of fighting blogger to not mess with the content when I edit a posting. Please join me on my new source of content, and if you see any mistakes, please fork my blog and issue a Pull Request. EDIT: It has been noted that HubPress.IO doesn't support an RSS feed yet. For this reason I will be posting an abstract and a link on blogger until this feature is added.

Overview One the most common gotchas in Java, is knowing how to print arrays.   If an answer on how to print an array get more than 1000 upvotes, you have to wonder if there is a simpler way.  Just about every other popular language has that simpler way, so it's not clear to me why Java still does this. Unlike other JDK classes, arrays don't have a particularly sane toString() as it is inherited from Object. It prints the type and address right? Actually, it doesn't print the address, it just looks as cryptic as one. It prints the internal representation of the type, and the hashCode() of the object.  As all arrays are an Object, they have a hashCode() and a type and a synchronized lock, and every thing else an Object has, but no methods specific to an array. This is why the toString() isn't useful for arrays. What does it look like unhacked? If I run the following program. public class ObjectTest {     boolean[] booleans = {true...