Java 11 was officially released by Oracle on 25th Sept 2018. This blog post highlights the subset of features in this next major release of Java that will be of most interest to enterprise Java developers. These include a small number of new language features, for which I have also provided some code examples showcasing how they can be used. This post also outlines the significance of this new Java release from a support & maintenance perspective; upgrade considerations; and includes a reminder about the recent change in the licensing terms for the Oracle JDK.
Oracle have recently made several changes concerning how they maintain, support & license use of Java (more accurately the JDK). This has commercial & technical implications for all enterprises running apps on the JVM (users of the JDK) in production – regardless of the app programming language (Java, Groovy, Kotlin, etc).
Don’t panic! Java is still free. But anyone responsible for developing or provisioning JVM apps for production usage needs to be aware of these changes and consider how it impacts their teams and business.
Java (or more accurately JDK) 10 was officially released on 20th March 2018. It includes a total of 12 new features, a full list of which can be found on the OpenJDK project page for JDK 10 , including links to their relevant JDK Enhancement Proposal (JEP) describing each in more detail. This blog post highlights the subset of features that will be of most interest to enterprise Java developers. These include a small number of new Java language features, for which I have also provided some code examples showing how they can be used.
As a software engineer responsible for building new backend (micro) services, it’s not sufficient to only test that they meet functional requirements. There are additional technical tests, focusing on the quality of the software, that must also be completed to ensure that your new service/application is production-ready. Whilst such tests require additional effort and can push out the date for getting your new service into production, they’re essential if you want to be confident of how your service will operate in production, and avoid any surprises that could negatively impact your business. The main types of tests I’m referring to are load testing (itself a type of performance testing) and soak testing. I’ve covered the subject of load testing (specifically measuring throughput under load) in a previous blog post. In this blog post I cover soak testing, including the aims of this type of test; how to soak test any service (regardless of the language it’s written in) that runs on the Java Virtual Machine (JVM), including those that run in a (e.g. Docker) container.
Java Standard Edition (JSE) 9 (‘Java 9’) was finally completed and publicly released at the end of Sept 2017. This post contains a brief overview of what’s new in Java 9, and outlines the main reasons why you or your business might consider upgrading, if at all. It also provides developers with a link to a set of code examples that I’ve produced, which showcase the major new language features in Java 9 and explains each of them in more detail.
Message brokers are specialised pieces of enterprise middleware designed to support integrating applications in a decoupled (in both time and location) manner, using messaging channels, implemented as either queues (for single consumer) or topics (for multiple consumers). Whilst deploying and operating a broker has an additional, ongoing cost for a business, if the scale of integration in your system and the non-functional requirements warrant it, they can can provide a flexible, better performing and more scalable solution than the alternative of implementing message queues in your database, especially, as is often the case, the latter is already overloaded.There are a considerable number of proven message brokers available today from a variety of vendors. Before committing to building your integrations on a particular broker, you should give careful consideration to how well it satisfies your requirements. I recently went through such an evaluation exercise, and ended-up choosing Amazon Simple Queue Service (SQS). While we haven’t regretted this decision, I did learn a few things along the way. In this post I’ll share a list of the functional and non-functional (technical) requirements that you should consider as part of evaluating a message broker, and also my opinion on how SQS measures up to other brokers in each case, and the trade-offs.
In the process of evaluating and trialling the introduction of messaging to integrate distributed back-end services, and other apps, in our system, the question of whether we were aiming to design a Message Broker or a Message Bus arose. This led to me doing some research to verify and improve my understanding of the difference. This post is a summary of my findings.