1. Kubernetes won the "Container Orchestration Wars" and became a standard for building cloud-like environments. All public clouds offer alternative orchestration solutions which are less complex and more cost-effective. For most applications, it does not matter who manages the containers. Kubernetes becomes a commodity - very comparable to Linux. Kubernetes compatibility becomes less crucial, the importance of container images and runtimes remains.
2. Function as a service FaaS like, e.g., AWS Lambda, Azure functions, Google Cloud Functions, or Oracle Cloud Functions become more popular for their "killer features" like, e.g., event listeners and integration points. Fewer projects try to use functions as a service as a general-purpose programming model. This trend should continue.
3. Public clouds can be expensive. After the initial excitement, slower-growing companies are starting to moving back to their data centers. We will hear the term "repatriation" more often. "Boring" enterprise apps can run more cost-effectively on-premises. "Lifting and shifting" an existing application to the cloud comes with no benefit to the end-user or business department. Refactoring a monolith into "cloud-native" microservices introduces additional complexity with no immediate added value. In 2021+, a monolith becomes another "best practice."
4. Microservices in the clouds can be more expensive to implement and especially to run. I'm expecting a "Monthly Cloud Bill Driven Development" trend to merge sensible microservices into a less reasonable monolith for the sake of cost savings.
5. Companies are starting to notice that clouds can be more secure, flexible and come with authentication, authorization, encryption, and vertical services like, e.g., image recognition, notifications, text to speech, text recognition, fraud detection, key rotation. Such services are hard to replicate on-premise and are the killer use case for the clouds. Running "boring" workloads on-premises and picking interesting cloud services leads to flexible and cost-effective solutions and should replace more dogmatic strategies.
6. Serverless should be the new trend for 2021. A few years ago, "serverless" was the synonym for AWS Lambda. Now we got serverless containers, databases, workflows, and event streams. Serverless only means that you can scale down the service to zero and stop paying for scaled-down resources. I expect a noticeable trend to serverless services.
7. The rise of next-generation runtimes like micronaut or quarkus is undisputable. They share the same principle: deployment happens at build-time, and the runtime becomes simple, fast, and nimble. No reflection, no class loading. I expect Helidon to catch up by reusing some of micronaut's annotation processing features.
8. Quarkus' popularity exploded last year. It is hard to find a Java developer who didn't already experiment with Quarkus. The support of familiar APIs like, e.g., MicroProfile and parts of Jakarta EE combined with a small footprint, fast startup times, and GraalVM integration gives Quarkus an "unfair advantage." However, the competition doesn't sleep. Micronaut is small, if not smaller, than Quarkus but only partially implements MicroProfile and Jakarta EE APIs. Helidon is fully MicroProfile compatible, fast, but not as memory efficient as micronaut. Many micronaut and Helidon committers are working for the same company :-)
9. The speed of Java language innovation got higher in the last years. We got Java Records, Text Blocks and instanceof Pattern Matching. Over time, fewer projects are going to use alternative JVM languages. Plain Java is going to be just "good enough."
10. Java Records stole Lombok's main killer feature: getter / setter / builder generation. Lombok may become less relevant in enterprise projects.
11. Plain Web Components are available on all browsers. ES Modules are available everywhere and already recognized as the future of modularization in JavaScript. The productivity and maintainability of vanilla JavaScript solutions makes JavaScript frameworks less relevant. Frameworks introduce complexity, maintenance costs, and significant time investment. The trend towards plain "standards" in and outside enterprise may increase in 2021+.
12. The great "IntelliSense" and "refactoring" support for plain JavaScript in Visual Studio Code will make typescript less popular over time. Visual Studio Code treats JavaScript as TypeScript already.
13. Productive, plain, modern JavaScript combined with Web Components and ESM compatible libraries like e.g. lit-html makes npm builds on developer's machines optional.
14. Apache Kafka will be considered more as an immutable data store, a single "source of truth," and more minor as a "modern" replacement for Java Message Service / Jakarta Message Service.
15. Apache Kafka is the natural use case for reactive programming and will make reactive programming more popular.
16. Project Loom will eliminate reactive programming constructs for non-reactive resources.
17. ARM-architectures are going to be more popular on servers and also PCs in the short term and could dominate the market in the longer term.
18. GraalVM is still underestimated and often only used for native compilation. In addition to the native compilation, GraalVM is also a fast JVM and multilanguage environment. I expect the growth of GraalVM and also the appearance of a viable competitor.
19. JavaFX combined with GraalVM presents the unique possibility to ship the same native application to run on various devices. You can develop Java applications once and submit them to various app stores - even the Apple AppStore. JavaFX's popularity should grow.
20. Project Panama: "Interconnecting JVM and native code" or the new "JNI" become more critical and popular. Native integration between the JVM and C code plays a vital role in machine learning or GPU access.
21. Visual Studio Code becomes a viable Java, Cloud, and web IDE, however, VSC features are still not widely known across the Java community. Therefore I expect the use of VSC in projects to increase further.
22. "Serverless servers" like, e.g., payara cloud, is an interesting case. Payara Cloud follows opposite design decisions to the "next-generation standards." The application server cluster becomes a Kubernetes Operator and manages the nodes for you. You don't care about the server and only have to push a ThinWAR to the cloud. Payara Cloud hides the Kubernetes complexity and dramatically simplifies the infrastructure. The infrastructure is strictly separated from the business code. Payara Cloud is not GA yet but might become the most productive way to run "boring" applications everywhere.

Subscribe to airhacks.fm podcast via: spotify| iTunes| RSS

The 87th airhacks.tv (and the first from http://youtube.com/c/bienadam/):

"Cloud development, logging frameworks, transactions and micro services, unit-, integration-, system testing, ETags and JPA, Boundary Control Entity pattern, long running processes in the cloud, exception handling, FlywayDB, lombok, CDI events"

See you every first Monday of the month at https://airhacks.tv 8pm CET (UTC+1:00).

Any questions left? Ask now: https://gist.github.com/AdamBien/8b2b52ca341285c15de7d4a9257f3f54 and get the answers at the next airhacks.tv.

Subscribe to airhacks.fm podcast via: spotify| iTunes| RSS

Questions and topics (details: https://gist.github.com/AdamBien/38e1754782c901f5d63e45968f3df610) for the very first airhacks.tv on youtube https://www.youtube.com/c/bienadam/live:

1. How to microprofile metrics in Kubernetes cluster
2. Authentication and microprofile metrics
3. Two microservices, one database ...and transactions
4. Where to put business logic in the BCE pattern?
5. A cloud development environment
6. Interesting ClassCastExceptions
7. Stateless EJB vs. Singleton EJB, and is there a case of pooling?
8. Code reuse with WARs, without EARs
9. Bulkheads, threads, connections ...and browser tabs
10. java.util.Logger vs. java.lang.Logger vs. slf4j and log4j
11. How important are unit tests
12. MicroProfile Rest client and receiving status codes without exceptions
13. JSON Patch and BCE in the frontend: https://github.com/adambien/bce.design
14. ETags with JPA entities
15. Boundaries, BCE and, JAX-RS and @Transactional
16. Long running processes on AWS
17. Singleton in the cloud
18. Exception handling and retries with MicroProfile rest client
19. What is FlywayDB?
20. Lombok: yes or no?
21. What are the differences between integration test, smoke test, system test and unit test?
22. A command pipeline with CDI events?
23. Exception handling in Jakarta EE applications
24. CDI Events with Jakarta EE

See you every first Monday of the month at https://airhacks.tv 8pm CET (UTC+1:00). Show is also announced at: meetup.com/airhacks.

Watch the live stream on https://www.youtube.com/c/bienadam/live.

Any questions left? Ask now: https://gist.github.com/AdamBien/38e1754782c901f5d63e45968f3df610 and get the answers at the next airhacks.tv.

Enforcing "snapping" with the CSS property: scroll-snap-type on the scroll container and scroll-snap-align on the container's children:

Subscribe to airhacks.fm podcast via: spotify| iTunes| RSS

A plain and minimalistic "Plain Web Standards" template (PWS) was released: https://github.com/adambien/pws.

To create a project you have to:

1. Install browsersync
2. git clone https://github.com/AdamBien/pws
3. cd app
4. Perform: browser-sync src -f src --no-notify

This minimalistic "quickstarter" is used in most of my explanatory web screencasts https://www.youtube.com/playlist?list=PLxU9yM-_yPs_B-kaWK0c44KgyWAre4hCH and POCs.

For more serious projects checkout the Web Components, lit-html and redux quickstarter.

Objects ships with useful array index check methods:

checkIndex: Checks if the index is within the bounds of the range from 0 (inclusive) to length (exclusive).

@Test
public void checkIndex() {
    var index = 1;
    var length = 2;
    var actual = Objects.checkIndex(index, length);
    assertEquals(index, actual);

    assertThrows(IndexOutOfBoundsException.class, () -> {
        Objects.checkIndex(2,2);
    });
}

A violation (e.g. Objects.checkIndex(2, 2)) yields a throws an instance of IndexOutOfBoundsException with the following message: java.lang.IndexOutOfBoundsException: Index 2 out of bounds for length 2

checkFromToIndex: Checks if the sub-range from fromIndex (inclusive) to toIndex (exclusive) is within the bounds of range from 0 (inclusive) to length (exclusive).

@Test
public void checkFromToIndex() {
    var fromIndex = 0;
    var toIndex = 0;
    var length = 4;
    var actual = Objects.checkFromToIndex(fromIndex, toIndex, length);
    assertEquals(fromIndex, actual);

    assertThrows(IndexOutOfBoundsException.class, () -> { 
        Objects.checkFromIndexSize(0, 5, 4);
    });
}    

checkFromIndexSize: Checks if the sub-range from fromIndex (inclusive) to fromIndex + size (exclusive) is within the bounds of range from 0 (inclusive) to length (exclusive).

@Test
public void checkFromIndexSize() {
    var index = 0;
    var size = 3;
    var length = 4;
    var actual = Objects.checkFromIndexSize(index, size, length);
    assertEquals(index, actual);

    assertThrows(IndexOutOfBoundsException.class, () -> {
        //1 + 4 >= 4
        Objects.checkFromIndexSize(1, 4, 4);
    });
}

Receiving Server Sent Events (SSE) with plain Java 11+:

The stream of string lines is "reactive", you will receive the events "on the go":

import java.net.URI;
import java.net.URISyntaxException;
import java.net.http.HttpClient;
import java.net.http.HttpRequest;
import java.net.http.HttpResponse.BodyHandlers;

import org.junit.jupiter.api.Test;

public class HttpClientSSETest {

    @Test
    public void receiveEvents() throws URISyntaxException, IOException, InterruptedException {
        var uri = new URI("http://localhost:8080/sse");
        var client = HttpClient.newHttpClient();
        var request = HttpRequest.newBuilder(uri).GET().build();
        var lines = client.send(request, BodyHandlers.ofLines()).body();
        lines.forEach(System.out::println);
    }
}    

The project was created with the "hopefully shortest Java 16 starter". and the SSEs were sent with "mocking backend for frontends" aka mockend.