Java 15 became GA earlier this month (Sept 2020) (as announced by Oracle). As per Oracle’s now regular time-based schedule for major new releases of Java, this release was expected and comes 6 months after the previous one (Java 14 in March 2020). In this post I outline what I personally consider to be the most significant new features in Java 15 from a developer’s perspective, focusing primarily on the new Java language. I’ve also included some of the changes to the JDK core libraries / APIs and the JVM which will be of interest to developers.Continue reading
Deploying and running services on Function-as-a-Service (FaaS) compute platforms like AWS Lambda has some compelling benefits for appropriate use-cases (short running workloads), including true (low-latency) elastic scalability, at finer granularity, with significant cost-savings based on scaling to zero.
At the same time, the Spring application framework (and more recently Spring Boot) has long encouraged and helped accelerate building modern, flexible enterprise apps that run on the JVM, that are easy to test, by abstracting away generic code (‘plumbing’) for integrating an app with its libraries and APIs; using familiar design/programming patterns (IoC/DI, proxies, Template methods etc); and providing valuable features (declarative transaction management, environment specific config, etc).
In an ideal world we’d use all these technologies – building Java/JVM functions with the help of Spring that are deployed and run on AWS Lambda – to realise their combined benefits.
But can these technologies be made to work together effectively? Or do we need to accept that when it comes to designing and building services to run on FaaS platforms like AWS Lambda, tech stacks (programming languages and application framework) offer than Java and Spring may offer a better solution?
Java 12, or more accurately the Java Development Kit (JDK) 12) was officially released by Oracle on the 19th March 2019. This blog post highlights the subset of new features in this next major release of Java that will be of most interest to enterprise Java developers, in terms of the Java language, the core library APIs and other JDK features. It also outlines the support & maintenance available for this new release, and how this might influence your decision on whether to adopt it in production.
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.