Don’t dread the Thread, it’s just Java async code

Posted on Leave a comment

I grew up with a fear of Java Threads. It was a time when Java and C# were the only “serious” programming languages to be used to write enterprise software. This was especially true in India, which to date remains a laggard in terms of technology adoption. The concept of Threads was hard enough for a budding programmer. And to make matters worse, the Thread API was far from being intuitive. Concurrency, deadlocks, semaphores, and synchronization were topics that were thrown around as stone pelters throw stones on anyone approaching their territory.

The concept of async code in other languages seemed equally mind-bending at first. During the Web 2.0 days, creating dynamic interfaces via Ajax was cool but it forced one to understand async code flow in JavaScript. Somehow, JS (or more precisely, jQuery) managed to make async code not as hard to understand as Threads in Java. Yet, at a grassroots level, both did the same thing—allow developers to write non-blocking code.

Reading the chapter on Concurrency in the book The Pragmatic Programmer triggered this comparison in my head. Having worked on professional software for over 12 years in several different languages, async code now feels intuitive. Back then, it was hard. Threads were hard. Not only would I skip reasoning about potential concurrency issues in my software, I would also leave out without flinching any discussion about concurrency or threads in reference material. Surely threads were designed to be used in “very complex” applications, something that I would not be doing until my late thirties. Hah!

It’s only now that I realize concurrency is unavoidable—it’s implicitly baked into so many daily problems that not thinking about concurrency means knowingly or unknowingly creating software that would not scale to survive the harshness of the real world.

So, here I am writing a note to my younger self:

It’s useful to think of threads simply in terms of tools that provide the ability to execute pieces of code asynchronously. Before asyncawait and Future , the only way to run async code in Java was to use a Thread. In short, a thread is just Java async code.

Node.js made it super-easy to run async code via callbacks, so much so that it became a preferred standard when writing I/O heavy code. So, programmers who would not write async or non-blocking code in Java due to the fear of threads could easily do so in Node.

Best way to split a paragraph into sentences

Posted on Leave a comment

…is to not use your own brain but rather ride on the shoulders of an expert. Surprisingly enough (for most), a popular ‘expert’ is Stanford CoreNLP.

Suppose you have the following paragraph (credit):

Born in Pretoria, South Africa, Musk taught himself computer programming at the age of 12. He moved to Canada when he was 17 to attend Queen’s University. He transferred to the University of Pennsylvania two years later.

Continue reading Best way to split a paragraph into sentences

Creating a Java 10 project in IntelliJ IDEA with JUnit 5 and Gradle support

Posted on Leave a comment

IntelliJ IDEA is a free and open-source (yay!) IDE for Java development. It’s a huge-huge-huge improvement over the slow and ageing Eclipse. Recently, I wanted to do some programming practice, so I thought why not in Java. I started by writing my code in good ol’ Notepad++. Very soon I reminded myself about my TDD resolution — to never write code without unit tests. This meant needing something serious to write my Java code. It was a good opportunity to try out IDEA, something I had been meaning to do since I learnt that Android Studio is based on it (that was long ago, like 3-4 years ago).

Creating a Java project and running/debugging code in IDEA is pretty simple and quick. Configuring IDEA to support JUnit 5 tests, on the other hand, is no child’s play. It took my literally more than a day to get it to work. And hence this blog post, which is a note to self to quickly set up things in future.

If you are interested in checking the Java project that I had created in IDEA (referred to in my screenshots below), check my GitHub repo.

Continue reading Creating a Java 10 project in IntelliJ IDEA with JUnit 5 and Gradle support

Running opentaps in Windows

Posted on Leave a comment

So I’m playing around with opentaps these days. It runs pretty neatly in Linux. Simply executing a shell script it comes with autostarts a built-in Tomcat server and runs the darn thing without a hitch. opentaps under Windows is another animal!

Although opentaps comes with a similar batch script for Windows, the thing doesn’t run without errors. With JDK and all set all right, I was getting this error when visiting opentaps in browser:

HTTP Status 500 –

type Exception report


description The server encountered an internal error () that prevented it from fulfilling this request.


java.util.regex.PatternSyntaxException: Unexpected internal error near index 1

note The full stack trace of the root cause is available in the Apache Tomcat/6.0.26 logs.
Apache Tomcat/6.0.26

It’s amazing that a simple hack posted by someone in 2011 worked for me! After modifying as mentioned in the forum post, be sure to recompile opentaps by running the ant command. Don’t have ant installed? Read this.

Granular Package Archive

Posted on 2 Comments

rpm_logoContinuing my Java learning stint, I started experimenting on RPM packages in the Granular 2008 repository by extracting meta data from them using various Java classes I had written for my on-going college major project. To give a shape (end-user interface) to these leisurely done Java programs, I used my existing project MyBlog to create a website that could display information (extracted by the Java programs) about every RPM package in the repository. In other words, the Java programs store information about each RPM package in a central database which in turn is used by a PHP-based website to display that information, and much more.

In the introduction to Granular Package Archive post I wrote on the Team Granular blog, I explained the various features it has to offer. My personal favorite is the ability to leave comments on individual RPM pages. Other than that, I am quite satisfied with the overall look-and-feel too. In another of my Team Granular blog post, I explained the working of this package archive system, and the way to use it with any other repository of RPM packages.

Some guys at the Unity Project are also contemplating the idea of using this package archive system with their repository too.