Tech Blog of Stephen Souness

I've just watched a recording of a presentation by Stephen Colbourne from Devoxx Belgium " The New Java Best Practices by Stephen Colebourne ". Some of them I agreed with, some I am yet to warm to. I haven't made much use of "var" in place of specifying a variable type, so I still find code more readable when the type is specified. I am fully onboard with the best practice about the use of modules, "arguably the biggest change since Java 8". unnamed variables came in Java 22, which might explain why I haven't encountered it so far - as companies tend to stick to long term support (LTS) versions of the language so I only got to Java 21. markdown docs. Check out the Inside Java podcast about this ( https://inside.java/2025/01/21/podcast-034/ ) Optional and null - the code style example shows how Optional can flow as more readable This is not an exhaustive breakdown of what Colbourne covered, so I recommend that you take a look for yourself.

I've been checking in some of my experimental code with GitHub repositories over the last while, and noticed that the "Traffic" section under "Insights" shows a dozen or so clones on each repo. I don't have any real followers, so I'm starting going with the assumption that the cloning will be by some automated systems picking up my code for use by artificial intelligence code assistants. Just a pity that GitHub does not offer any way of monitoring the origin of these clones. There's also a possibility that some of the traffic may relate to Dependabot, but in the interests of keeping this post with it's amusing title I'm going to check for that after posting.   (Disclaimer: This post has no connection to Star Wars, or Disney's trademark on "Attack of the Clones", and is not promoting any product or service)

Constructors are still super - eventually  Java 25 has introduced a change to the way that constructors work in the inheritance hierarchy. In previous versions of Java, if we have a class that extends another class then all constructors of the subclass have to either specify a constructor from the base class as the first operation or automatically have the default zero arguments constructor applied by default - or call on alternate constructor and get the subclass's constructor invoked via that. In Java 25 it is now valid to call super() later in the constructor. So, we could have the following as valid code... public class SomeBaseClass { SomeBaseClass () { System . out .println( "Hello from SomeBaseClass constructor" ); } } public class SomeSubClass extends SomeBaseClass { SomeSubClass () { System . out .println( "Hello from SomeSubClass constructor" ); super (); } } public class ConstructorDemo { static void main ()...

Help others to help yourself This post is about how it sometimes pays to take a look beyond the services your team owns, so that you have a deeper understanding of the operating context and can have confidence in the performance and robustness of the implementation. I wouldn't claim to be an expert in anything, but sometimes my extra pair of eyes picks up on an opportunity to make a small change and get a significant benefit. Database queries  Back when I was operating in an environment where teams had access to logs and metrics of the services  of other teams, I could dip into what was going on when my login service was hitting timeouts form a dependency. Based on the details in the logs, the culprit seemed to be delays from a database query. Surprisingly enough, the database was missing an index for most common query pattern, so as we scaled up from a few hundred users to a few thousand  Default configuration options don't always match what has been in place i...

Learning from the mistakes of others A few years ago a team that worked across the office from my team came up with a neat way of introducing a cache to speed up the performance of the most business critical pages on the company's main money earning website. Page load time had been identified as a particularly significant aspect of how search engines would rank the value of websites, so getting a few milliseconds off that metric was a great achievement. Fast forward several months, the unthinkable happened as the infrastructure component that was at the heart of the caching implementation had a temporary outage, taking away the possibility of loading pages at all. It was quite a while ago, and I wasn't directly involved in the recovery process but I expect that it would have taken a stressful hour or three to recover. Avoid introducing points of failure As inevitably happens, the project that I was working on required some performance improvements in order for it to be consider...

Hello world in Java 25 can be very different to any earlier version of Java. void main() { IO.println( "Hello world" ); } That's it, no package, no import, not even having to specify a class. Even that  IO  represents a class that was only introduced in Java 25. If you saw that code in a multi-choice lineup of code that should and should not work in Java 10 years ago you wouldn't dream of regarding it as valid Java. The main method is also so different to traditional Java. There's no "public", no "static", and no parameter list. It's still early days, but I'm not a fan.