10 Things You Didn’t Know About jOOQ

jOOQ has been around for a while - since around 2009 as a publicly available library, and since 2013 as a commercially licensed product. A lot of things have happened in 12 years. Here are 10 things that you maybe didn't know about jOOQ. 1. eq, ne, gt, ge, lt, le are inspired by XSLT … Continue reading 10 Things You Didn’t Know About jOOQ

How to Write a Simple, yet Extensible API

How to write a simple API is already an art on its own. I didn't have time to write a short letter, so I wrote a long one instead. ― Mark Twain But keeping an API simple for beginners and most users, and making it extensible for power users seems even more of a challenge. … Continue reading How to Write a Simple, yet Extensible API

Dear API Designer. Are You Sure, You Want to Return a Primitive?

Some APIs are set in stone. For instance, the JDK's. Or public APIs, like the one between a database and a database client (e.g. JDBC). This makes designing such APIs rather difficult as a lot of thinking needs to be done prior to publishing an API. Which means that being defensive when designing the API … Continue reading Dear API Designer. Are You Sure, You Want to Return a Primitive?

A Curious Incidence of a jOOQ API Design Flaw

jOOQ is an internal domain-specific language (DSL), modelling the SQL language (external DSL) in Java (the host language). The main mechanism of the jOOQ API is described in this popular article: The Java Fluent API Designer Crash Course. Anyone can implement an internal DSL in Java (or in most other host languages) according to the … Continue reading A Curious Incidence of a jOOQ API Design Flaw

Yak Shaving is a Good Way to Improve an API

Yak Shaving (uncountable): (idiomatic) Any apparently useless activity which, by allowing you to overcome intermediate difficulties, allows you to solve a larger problem. (idiomatic) A less useful activity done to consciously or unconsciously procrastinate about a larger but more useful task. Both interpretations of the term Yak Shaving as explained by Wiktionary are absolutely accurate … Continue reading Yak Shaving is a Good Way to Improve an API

You Will Regret Applying Overloading with Lambdas!

Writing good APIs is hard. Extremely hard. You have to think of an incredible amount of things if you want your users to love your API. You have to find the right balance between: Usefulness Usability Backward compatibility Forward compatibility We've blogged about this topic before, in our article: How to Design a Good, Regular … Continue reading You Will Regret Applying Overloading with Lambdas!

This is the Final Discussion!

Pun intended... Let's discuss Java final. Recently, our popular blog post "10 Subtle Best Practices when Coding Java" had a significant revival and a new set of comments as it was summarised and linked from JavaWorld. In particular, the JavaWorld editors challenged our opinion about the Java keyword "final": More controversially, Eder takes on the … Continue reading This is the Final Discussion!

How to Design a Good, Regular API

People have strong opinions on how to design a good API. Consequently, there are lots of pages and books in the web, explaining how to do it. This article will focus on a particular aspect of good APIs: Regularity. Regularity is what happens when you follow the "Principle of Least Astonishment". This principle holds true … Continue reading How to Design a Good, Regular API

The Golden Rules of Code Documentation

Here's another topic that is highly subjective, that leads to heated discussions, to religious wars and yet, there's no objective right or wrong. A previous post on my blog was reblogged to my blogging partner JavaCodeGeeks. The amount of polarised ranting this blog provoked on JCG is hilarious. Specifically, I like the fact that people … Continue reading The Golden Rules of Code Documentation

Bloated JavaBeans™, Part II – or Don’t Add “Getters” to Your API

I have recently blogged about an idea how JavaBeans™ could be extended to reduce the bloat created by this widely-accepted convention in the Java world. That article was reblogged on DZone and got quite controversial feedback here (like most ideas that try to get some fresh ideas into the Java world): http://java.dzone.com/articles/javabeans™-should-be-extended. I want to … Continue reading Bloated JavaBeans™, Part II – or Don’t Add “Getters” to Your API