Posts Tagged ‘Java’

Encoding is essential for handling text, binary data, and secure transmission across applications. Understanding advanced encoding techniques can help prevent data corruption and ensure smooth interoperability across systems. This post explores key encoding challenges and how Java/Kotlin, Node.js, and Python tackle them.

1️⃣ Handling Special Unicode Characters (Emoji, Accents, RTL Text)

Java/Kotlin

Java uses UTF-16 internally, but for external data (JSON, databases, APIs), explicit encoding is required:

String text = "🔧 Café مرحبا";
byte[] utf8Bytes = text.getBytes(StandardCharsets.UTF_8);
String decoded = new String(utf8Bytes, StandardCharsets.UTF_8);
System.out.println(decoded); // 🔧 Café مرحبا

✅ Tip: Always specify StandardCharsets.UTF_8 to avoid platform-dependent defaults.

Node.js

const text = "🔧 Café مرحبا";
const utf8Buffer = Buffer.from(text, 'utf8');
const decoded = utf8Buffer.toString('utf8');
console.log(decoded); // 🔧 Café مرحبا

✅ Tip: Using an incorrect encoding (e.g., latin1) may corrupt characters.

Python

text = "🔧 Café مرحبا"
utf8_bytes = text.encode("utf-8")
decoded = utf8_bytes.decode("utf-8")
print(decoded)  # 🔧 Café مرحبا

✅ Tip: Python 3 handles Unicode by default, but explicit encoding is always recommended.

2️⃣ Encoding Binary Data for Transmission (Base64, Hex, Binary Files)

Java/Kotlin

byte[] data = "Hello World".getBytes(StandardCharsets.UTF_8);
String base64Encoded = Base64.getEncoder().encodeToString(data);
byte[] decoded = Base64.getDecoder().decode(base64Encoded);
System.out.println(new String(decoded, StandardCharsets.UTF_8)); // Hello World

Node.js

const data = Buffer.from("Hello World", 'utf8');
const base64Encoded = data.toString('base64');
const decoded = Buffer.from(base64Encoded, 'base64').toString('utf8');
console.log(decoded); // Hello World

Python

import base64
data = "Hello World".encode("utf-8")
base64_encoded = base64.b64encode(data).decode("utf-8")
decoded = base64.b64decode(base64_encoded).decode("utf-8")
print(decoded)  # Hello World

✅ Tip: Base64 encoding increases data size (~33% overhead), which can be a concern for large files.

3️⃣ Charset Mismatches and Cross-Language Encoding Issues

A file encoded in ISO-8859-1 (Latin-1) may cause garbled text when read using UTF-8.

Java/Kotlin Solution:

byte[] bytes = Files.readAllBytes(Paths.get("file.txt"));
String text = new String(bytes, StandardCharsets.ISO_8859_1);

Node.js Solution:

const fs = require('fs');
const text = fs.readFileSync("file.txt", { encoding: "latin1" });

Python Solution:

with open("file.txt", "r", encoding="ISO-8859-1") as f:
    text = f.read()

✅ Tip: Always specify encoding explicitly when working with external files.

4️⃣ URL Encoding and Decoding

Java/Kotlin

String encoded = URLEncoder.encode("Hello World!", StandardCharsets.UTF_8);
String decoded = URLDecoder.decode(encoded, StandardCharsets.UTF_8);

Node.js

const encoded = encodeURIComponent("Hello World!");
const decoded = decodeURIComponent(encoded);

Python

from urllib.parse import quote, unquote
encoded = quote("Hello World!")
decoded = unquote(encoded)

✅ Tip: Use UTF-8 for URL encoding to prevent inconsistencies across different platforms.

Conclusion: Choosing the Right Approach

• Java/Kotlin: Strong type safety, but requires careful Charset management.
• Node.js: Web-friendly but depends heavily on Buffer conversions.
• Python: Simple and concise, though strict type conversions must be managed.

📌 Pro Tip: Always be explicit about encoding when handling external data (APIs, files, databases) to avoid corruption.

In a world where systems are becoming increasingly distributed and cloud-native, microservices have emerged as the de facto architecture. But as we scale
microservices horizontally—running multiple instances for each service—one of the biggest challenges becomes inter-service communication.

How do we ensure that our services talk to each other reliably, efficiently, and in a way that’s resilient to failures?

Welcome to the world of Feign and Spring Cloud.

The Challenge: Multi-Instance Microservices

Imagine you have a user-service that needs to talk to an order-service, and your order-service runs 5 instances behind a
service registry like Eureka. Hardcoding URLs? That’s brittle. Manual load balancing? Not scalable.

You need:

• Service discovery to dynamically resolve where to send the request
• Load balancing across instances
• Resilience for timeouts, retries, and fallbacks
• Clean, maintainable code that developers love

The Solution: Feign + Spring Cloud

OpenFeign is a declarative web client. Think of it as a smart HTTP client where you only define interfaces — no more boilerplate REST calls.

When combined with Spring Cloud, Feign becomes a first-class citizen in a dynamic, scalable microservices ecosystem.

✅ Features at a Glance:

• Declarative REST client
• Automatic service discovery (Eureka, Consul)
• Client-side load balancing (Spring Cloud LoadBalancer)
• Integration with Resilience4j for circuit breaking
• Easy integration with Spring Boot config and observability tools

Step-by-Step Setup

1. Add Dependencies

If using Eureka:

       config:

           default:

                connectTimeout:3000

                readTimeout:500

[/yml]

Enable retry:

What Happens Behind the Scenes?

When user-service calls order-service:

1. Spring Cloud uses Eureka to resolve all instances of order-service.
2. Spring Cloud LoadBalancer picks an instance using round-robin (or your chosen strategy).
3. Feign sends the HTTP request to that instance.
4. If it fails, Resilience4j (or your fallback) handles it gracefully.

Observability & Debugging

Use Spring Boot Actuator to expose Feign metrics:

And tools like Spring Cloud Sleuth + Zipkin for distributed tracing across Feign calls.

Beyond the Basics

To go even further:

• Integrate with Spring Cloud Gateway for API routing and external access.
• Use Spring Cloud Config Server to centralize configuration across environments.
• Secure Feign calls with OAuth2 via Spring Security and OpenID Connect.

✨ Final Thoughts

Using Feign with Spring Cloud transforms service-to-service communication from a tedious, error-prone task into a clean, scalable, and cloud-native solution.
Whether you’re scaling services across zones or deploying in Kubernetes, Feign ensures your services communicate intelligently and resiliently.

While Python dominates in model training, Java is becoming increasingly vital for deploying and serving AI/ML models in production. Its performance, stability, and enterprise integration capabilities make it a strong contender.

Java Example: Real-time Object Detection with DL4J and OpenCV

[java]
import …

public class ObjectDetection {

public static void main(String[] args) {
String modelPath = "yolov3.weights";
String configPath = "yolov3.cfg";
String imagePath = "image.jpg";
Net net = Dnn.readNet(modelPath, configPath);
Mat image = imread(imagePath);
Mat blob = Dnn.blobFromImage(image, 1 / 255.0, new Size(416, 416), new Scalar(0, 0, 0), true, false);

net.setInput(blob);

MatVector detections = net.forward(); // Inference

// Process detections (bounding boxes, classes, confidence)
// … (complex logic for object detection results)
// Draw bounding boxes on the image
// … (OpenCV drawing functions)
imwrite("detected_objects.jpg", image);
}
}

[/java]

Python Example: Similar Object Detection with OpenCV and YOLO

[python]

import numpy as np

net = cv2.dnn.readNet("yolov3.weights", "yolov3.cfg")
image = cv2.imread("image.jpg")
blob = cv2.dnn.blobFromImage(image, 1/255.0, (416, 416), swapRB=True, crop=False)
net.setInput(blob)
detections = net.forward()

# Process detections (bounding boxes, classes, confidence)
# … (simpler logic, NumPy arrays)
# Draw bounding boxes on the image
# … (OpenCV drawing functions)
cv2.imwrite("detected_objects.jpg", image)
[/python]

Comparison and Insights:

• Syntax and Readability: Python’s syntax is generally more concise and readable for data science and AI tasks. Java, while more verbose, offers strong typing and better performance for production deployments.
• Library Ecosystem: Python’s ecosystem (NumPy, OpenCV, TensorFlow, PyTorch) is more mature and developer-friendly for AI/ML development. Java, with libraries like DL4J, is catching up, but its strength lies in enterprise integration and performance.
• Performance: Java’s performance is often superior to Python’s, especially for real-time inference and high-throughput applications.
• Enterprise Integration: Java’s ability to seamlessly integrate with existing enterprise systems (databases, message queues, APIs) is a significant advantage.
• Deployment: Java’s deployment capabilities are more robust, making it suitable for mission-critical AI applications.

Key Takeaways:

• Python is excellent for rapid prototyping and model training.
• Java excels in deploying and serving AI/ML models in production environments, where performance and reliability are paramount.
• The choice between Java and Python depends on the specific use case and requirements.

Original post

From LinkedIn: https://www.linkedin.com/posts/matthias-patzak_cto-technology-activity-7312449287647375360-ogNg?utm_source=share&utm_medium=member_desktop&rcm=ACoAAAAWqBcBNS5uEX9jPi1JPdGxlnWwMBjXwaw

Summary of the question

As CTO for a mainframe rebuild (core banking/insurance/retail app, 100 teams/1000 people with Cobol expertise), considering Java/Kotlin, TypeScript/Node.js, Go, and Python. Key decision criteria are technical maturity/stability, robust community, and innovation/adoption. The CTO finds these criteria sound and seeks a language recommendation.

TL;DR: my response

• Team, mainframe rebuild: Java/Kotlin are frontrunners due to maturity, ecosystem, and team’s Java-adjacent skills. Go has niche potential. TypeScript/Node.js and Python less ideal for core.
• Focus now: deep PoC comparing Java (Spring Boot) vs. Kotlin on our use cases. Evaluate developer productivity, readability, interoperability, performance.
• Develop comprehensive Java/Kotlin training for our 100 Cobol-experienced teams.
• Strategic adoption plan (Java, Kotlin, or hybrid) based on PoC and team input is next.
• This balances proven stability with modern practices on the JVM for our core.

My detailed opinion

As a CTO with experience in these large-scale transformations, my priority remains a solution that balances technical strength with the pragmatic realities of our team’s current expertise and long-term maintainability.

While Go offers compelling performance characteristics, the specific demands of our core business application – be it in banking, insurance, or retail – often prioritize a mature ecosystem, robust enterprise patterns, and a more gradual transition path for our significant team. Given our 100 teams deeply skilled in Cobol, the learning curve and the availability of readily transferable concepts become key considerations.

Therefore, while acknowledging Go’s strengths in certain cloud-native scenarios, I want to emphasize the strategic advantages of the Java/Kotlin ecosystem for our primary language choice, with a deliberate hesitation and deeper exploration between these two JVM-based options.

Re-emphasizing Java and Exploring Kotlin More Deeply:

• Java’s Enduring Strength: Java’s decades of proven stability in building mission-critical enterprise systems cannot be overstated. The JVM’s resilience, the vast array of mature libraries and frameworks (especially Spring Boot), and the well-established architectural patterns provide a solid and predictable foundation. Moreover, the sheer size of the Java developer community ensures a deep pool of talent and readily available support for our teams as they transition. For a core system in a regulated industry, this level of established maturity significantly mitigates risk.

• Kotlin’s Modern Edge and Interoperability: Kotlin presents a compelling evolution on the JVM. Its modern syntax, null safety features, and concise code can lead to increased developer productivity and reduced boilerplate – benefits I’ve witnessed firsthand in JVM-based projects. Crucially, Kotlin’s seamless interoperability with Java is a major strategic advantage. It allows us to:

  • Gradually adopt Kotlin: Teams can start by integrating Kotlin into existing Java codebases, allowing for a phased learning process without a complete overhaul.
  • Leverage the entire Java ecosystem: Kotlin developers can effortlessly use any Java library or framework, giving us access to the vast resources of the Java world.
  • Attract modern talent: Kotlin’s growing popularity can help us attract developers who are excited about working with a modern, yet stable, language on a proven platform.

Why Hesitate Between Java and Kotlin?

The decision of whether to primarily adopt Java or Kotlin (or a strategic mix) requires careful consideration of our team’s specific needs and the long-term vision:

• Learning Curve: While Kotlin is designed to be approachable for Java developers, there is still a learning curve associated with its new syntax and features. We need to assess how quickly our large Cobol-experienced team can become proficient in Kotlin.
• Team Preference and Buy-in: Understanding our developers’ preferences and ensuring buy-in for the chosen language is crucial for successful adoption.
• Long-Term Ecosystem Evolution: While both Java and Kotlin have strong futures on the JVM, we need to consider the long-term trends and the level of investment in each language within the enterprise space.
• Specific Use Cases: Certain parts of our system might benefit more from Kotlin’s conciseness or specific features, while other more established components might initially remain in Java.

Proposed Next Steps (Revised Focus):

1. Targeted Proof of Concept (PoC) – Deep Dive into Java and Kotlin: Instead of a broad PoC including Go, let’s focus our initial efforts on a detailed comparison of Java (using Spring Boot) and Kotlin on representative use cases from our core business application. This PoC should specifically evaluate:
   • Developer Productivity: How quickly can teams with a Java-adjacent mindset (after initial training) develop and maintain code in both languages?
   • Code Readability and Maintainability: How do the resulting codebases compare in terms of clarity and ease of understanding for a large team?
   • Interoperability Scenarios: How seamlessly can Java and Kotlin code coexist and interact within the same project?
   • Performance Benchmarking: While the JVM provides a solid base, are there noticeable performance differences for our specific workloads?
2. Comprehensive Training and Upskilling Program: We need to develop a detailed training program that caters to our team’s Cobol background and provides clear pathways for learning both Java and Kotlin. This program should include hands-on exercises and mentorship opportunities.
3. Strategic Adoption Plan: Based on the PoC results and team feedback, we’ll develop a strategic adoption plan that outlines whether we’ll primarily focus on Java, Kotlin, or a hybrid approach. This plan should consider the long-term maintainability and talent acquisition goals.

While Go remains a valuable technology for specific niches, for the core of our mainframe rebuild, our focus should now be on leveraging the mature and evolving Java/Kotlin ecosystem and strategically determining the optimal path for our large and experienced team. This approach minimizes risk while embracing modern development practices on a proven platform.

Here’s a super tricky Java interview question that messes with developer intuition:

❓ Weird Question:

“What will be printed when executing the following code?”

import java.util.*;

public class TrickyJava {
 public static void main(String[] args) {
 List list = Arrays.asList("T-Rex", "Velociraptor", "Dilophosaurus");
 list.replaceAll(s -> s.toUpperCase());
 System.out.println(list);
 }
 }

The Trap:

At first glance, everything looks normal:

Arrays.asList(...) creates a List.
replaceAll(...) is a method in List that modifies elements using a function.
Strings are converted to uppercase.
Most developers will expect this output:

[T-REX, VELOCIRAPTOR, DILOPHOSAURUS]

But surprise! This code sometimes throws an UnsupportedOperationException.

✅ Correct Answer:

The output depends on the JVM implementation!

It might work and print:

[T-REX, VELOCIRAPTOR, DILOPHOSAURUS]

Or it might crash with:

Exception in thread "main" java.lang.UnsupportedOperationException
at java.util.AbstractList$Itr.remove(AbstractList.java:572)
at java.util.AbstractList.remove(AbstractList.java:212)
at java.util.AbstractList$ListItr.remove(AbstractList.java:582)
at java.util.List.replaceAll(List.java:500)


Why?

Arrays.asList(...) does not return a regular ArrayList, but rather a fixed-size list backed by an array.
The replaceAll(...) method attempts to modify the list in-place, which is not allowed for a fixed-size list.
Some JVM implementations optimize this internally, making it work, but it is not guaranteed to succeed.

Key Takeaways

Arrays.asList(...) returns a fixed-size list, not a modifiable ArrayList.
Modifying it directly (e.g., add(), remove(), replaceAll()) can fail with UnsupportedOperationException.
Behavior depends on the JVM implementation and internal optimizations.

How to Fix It?

To ensure safe modification, wrap the list in a mutable ArrayList:

List list = new ArrayList<>(Arrays.asList("T-Rex", "Velociraptor", "Dilophosaurus"));
list.replaceAll(s -> s.toUpperCase());
System.out.println(list); // ✅ Always works!


Gavin Bierman, from Oracle’s Java Platform Group, captivated attendees at Devoxx Belgium 2024 with a forward-looking talk on Java’s evolution under Project Amber. Focusing on productivity-oriented language features, Gavin outlined recent additions like records, sealed classes, and pattern matching, while previewing upcoming enhancements like simplified main methods and flexible constructor bodies. His session illuminated Java’s design philosophy—prioritizing readability, explicit programmer intent, and compatibility—while showcasing how these features enable modern, data-oriented programming paradigms suited for today’s microservices architectures.

Project Amber’s Mission: Productivity and Intent

Gavin introduced Project Amber as a vehicle for delivering smaller, productivity-focused Java features, leveraging the six-month JDK release cadence to preview and finalize enhancements. Unlike superficial syntax changes, Amber emphasizes exposing programmer intent to improve code readability and reduce bugs. Compatibility is paramount, with breaking changes minimized, as Java evolves to address modern challenges distinct from its 1995 origins. Gavin highlighted how features like records and sealed classes make intent explicit, enabling the compiler to enforce constraints and provide better error checking, aligning with the needs of contemporary applications.

Records: Simplifying Data Carriers

Records, introduced to streamline data carrier classes, were a key focus. Gavin demonstrated how a Point class with two integers requires verbose boilerplate (constructors, getters, equals, hashCode) that obscures intent. Records (record Point(int x, int y)) eliminate this by auto-generating a canonical constructor, accessor methods, and value-based equality, ensuring immutability and transparency. This explicitness allows the compiler to enforce a contract: constructing a record from its components yields an equal instance. Records also support deserialization via the canonical constructor, ensuring domain-specific constraints, making them safer than traditional classes.

Sealed Classes and Pattern Matching

Sealed classes, shipped in JDK 17, allow developers to restrict class hierarchies explicitly. Gavin showed a Shape interface sealed to permit only Circle and Rectangle implementations, preventing unintended subclasses at compile or runtime. This clarity enhances library design by defining precise interfaces. Pattern matching, enhanced in JDK 21, further refines this by enabling type patterns and record patterns in instanceof and switch statements. For example, a switch over a sealed Shape interface requires exhaustive cases, eliminating default clauses and reducing errors. Nested record patterns allow sophisticated data queries, handling nulls safely without exceptions.

Data-Oriented Programming with Amber Features

Gavin illustrated how records, sealed classes, and pattern matching combine to support data-oriented programming, ideal for microservices exchanging pure data. He reimagined the Future class’s get method, traditionally complex due to multiple control paths (success, failure, timeout, interruption). By modeling the return type as a sealed AsyncReturn interface with four record implementations (Success, Failure, Timeout, Interrupted), and using pattern matching in a switch, developers handle all cases uniformly. This approach simplifies control flow, ensures exhaustiveness, and leverages Java’s type safety, contrasting with error-prone exception handling in traditional designs.

Future Features: Simplifying Java for All

Looking ahead, Gavin previewed features in JDK 23 and beyond. Simplified main methods allow beginners to write void main() without boilerplate, reducing cognitive load while maintaining full Java compatibility. The with expression for records enables concise updates (e.g., doubling a component) without redundant constructor calls, preserving domain constraints. Flexible constructor bodies (JEP 482) relax top-down initialization, allowing pre-super call logic to validate inputs, addressing issues like premature field access in subclass constructors. Upcoming enhancements include patterns for arbitrary classes, safe template programming, and array pattern matching, promising further productivity gains.

Links:

• Project Amber
• JDK 23 Release Notes
• JEP 482: Flexible Constructor Bodies
• Java Mailing Lists

At Devoxx Belgium 2024, David Vlijmincx delivered an engaging session on Project Panama, demonstrating its power by building a custom file system in Java. This practical, hands-on talk showcased how Project Panama simplifies integrating C libraries into Java applications, replacing the cumbersome JNI with a more developer-friendly approach. By leveraging Fuse, virtual threads, and Panama’s memory management capabilities, David walked attendees through creating a functional file system, highlighting real-world applications and performance benefits. His talk emphasized the ease of integrating C libraries and the potential to build high-performance, innovative solutions.

Why Project Panama Matters

David began by addressing the challenges of JNI, which many developers find frustrating due to its complexity. Project Panama, part of OpenJDK, offers a modern alternative for interoperating with native C libraries. With a vast ecosystem of specialized C libraries—such as io_uring for asynchronous file operations or libraries for AI and keyboard communication—Panama enables Java developers to access functionality unavailable in pure Java. David demonstrated this by comparing file reading performance: using io_uring with Panama, he read files faster than Java’s standard APIs (e.g., BufferedReader or Channels) in just two nights of work, showcasing Panama’s potential for performance-critical applications.

Building a File System with Fuse

The core of David’s demo was integrating the Fuse (Filesystem in Userspace) library to create a custom file system. Fuse acts as a middle layer, intercepting commands like ls from the terminal and passing them to a Java application via Panama. David explained how Fuse provides a C struct that Java developers can populate with pointers to Java methods, enabling seamless communication between C and Java. This struct, filled with method pointers, is mounted to a directory (e.g., ~/test), allowing the Java application to handle file system operations transparently to the user, who sees only the terminal output.

Memory Management with Arenas

A key component of Panama is its memory management via arenas, which David used to allocate memory for passing strings to Fuse. He demonstrated using Arena.ofShared(), which allows memory sharing across threads and explicit lifetime control via try-with-resources. Other arena types, like Arena.ofConfined() (single-threaded) or Arena.global() (unbounded lifetime), were mentioned for context. David allocated a memory segment to store pointers to a string array (e.g., ["-f", "-d", "~/test"]) and used Arena.allocateFrom() to create C-compatible strings. This ensured safe memory handling when interacting with Fuse, preventing leaks and simplifying resource management.

Downcalls and Upcalls: Bridging Java and C

David detailed the process of making downcalls (Java to C) and upcalls (C to Java). For downcalls, he created a function descriptor mirroring the C method’s signature (e.g., fuse_main_real, returning an int and taking parameters like string arrays and structs). Using Linker.nativeLinker(), he generated a platform-specific linker to invoke the C method. For upcalls, he recreated Fuse’s struct in Java using MemoryLayout.structLayout, populating it with pointers to Java methods like getattr. Tools like JExtract simplified this by generating bindings automatically, reducing boilerplate code. David showed how JExtract creates Java classes from C headers, though it requires an additional abstraction layer for user-friendly APIs.

Implementing File System Operations

David implemented two file system operations: reading files and creating directories. For reading, he extracted the file path from a memory segment using MemorySegment.getString(), checked if it was a valid file, and copied file contents into a buffer with MemorySegment.reinterpret() to handle size constraints. For directory creation, he added paths to a map, demonstrating simplicity. Running the application mounted the file system to ~/test, where commands like mkdir and echo worked seamlessly, with Fuse calling Java methods via upcalls. David unmounted the file system, showing its clean integration. Performance tips included reusing method handles and memory segments to avoid overhead, emphasizing careful memory management.

Links:

• Project Panama Documentation
• Fuse Documentation
• JExtract
• David Vlijmincx’s GitHub

Serverless computing has transformed application development by abstracting infrastructure management, offering fine-grained scaling, and billing only for execution time. At Spring I/O 2024 in Barcelona, Maximilian Schellhorn and Dennis Kieselhorst, AWS Solutions Architects, shared their expertise on building serverless Java applications with Spring. Their session explored running existing Spring Boot applications in serverless environments and developing event-driven applications using Spring Cloud Function, with a focus on performance optimizations and practical tooling.

The Serverless Paradigm

Maximilian began by contrasting traditional containerized applications with serverless architectures. Containers, while resource-efficient, require developers to manage orchestration, networking, and scaling. Serverless computing, exemplified by AWS Lambda, eliminates these responsibilities, allowing developers to focus on code. Maximilian highlighted four key promises: reduced operational overhead, automatic granular scaling, pay-per-use billing, and high availability. Unlike containers, which remain active and incur costs even when idle, serverless functions scale to zero, executing only in response to events like API requests or queue messages, optimizing cost and resource utilization.

Spring Cloud Function for Event-Driven Development

Spring Cloud Function simplifies serverless development by enabling developers to write event-driven applications as Java functions. Maximilian demonstrated how it leverages Spring Boot’s familiar features—autoconfiguration, dependency injection, and testing—while abstracting cloud-specific details. Functions receive event payloads (e.g., JSON from API Gateway or Kafka) and can convert them into POJOs, streamlining business logic implementation. The framework’s generic invoker supports function routing, allowing multiple functions within a single codebase, and enables local testing via HTTP endpoints. This portability ensures applications can target various serverless platforms without vendor lock-in, enhancing flexibility.

Adapting Existing Spring Applications

For teams with existing Spring Boot applications, Dennis introduced the AWS Serverless Java Container, an open-source library acting as an adapter to translate serverless events into Java Servlet requests. This allows REST controllers to function unchanged in a serverless environment. Version 2.0.2, released during the conference, supports Spring Boot 3 and integrates with Spring Cloud Function. Dennis emphasized its ease of use: add the library, configure a handler, and deploy. While this approach incurs some overhead compared to native functions, it enables rapid migration of legacy applications, preserving existing investments without requiring extensive rewrites.

Optimizing Performance with SnapStart and GraalVM

Performance, particularly cold start times, is a critical concern in serverless Java applications. Dennis addressed this by detailing AWS Lambda SnapStart, which snapshots the initialized JVM and micro-VM, reducing startup times by up to 80% without additional costs. SnapStart, integrated with Spring Boot 3.2’s CRaC (Coordinated Restore at Checkpoint) support, manages initialization hooks to handle resources like database connections. For further optimization, Maximilian discussed GraalVM native images, which compile Java code into binaries for faster startups and lower memory usage. However, GraalVM’s complexity and framework limitations make SnapStart the preferred starting point, with GraalVM reserved for extreme performance needs.

Practical Considerations and Tooling

Maximilian and Dennis stressed practical considerations, such as database connection management and observability. Serverless scaling can overwhelm traditional databases, necessitating connection pooling adjustments or proxies like AWS RDS Proxy. Observability in Lambda relies on a push model, integrating with tools like CloudWatch, X-Ray, or OpenTelemetry, though additional layers may impact performance. To aid adoption, they offered a Lambda Workshop and a Serverless Java Replatforming Guide, providing hands-on learning and written guidance. These resources, accessible via AWS accounts, empower developers to experiment and apply serverless principles effectively.

Links:

• Slides on SpeakerDeck
• AWS Serverless Java Container
• Lambda Workshop
• Serverless Java Replatforming Guide

Simon Ritter, Deputy CTO at Azul Systems, delivered a captivating session at DevoxxUK2024, exploring the transformative potential of Java’s Vector API. This innovative API, introduced as an incubator module in JDK 16 and now in its eighth iteration in JDK 23, empowers developers to harness Single Instruction Multiple Data (SIMD) instructions for parallel processing. By leveraging Advanced Vector Extensions (AVX) in modern processors, the Vector API enables efficient execution of numerically intensive operations, significantly boosting application performance. Simon’s talk navigates the intricacies of vector computations, contrasts them with traditional concurrency models, and demonstrates practical applications, offering developers a powerful tool to optimize Java applications.

Understanding Concurrency and Parallelism

Simon begins by clarifying the distinction between concurrency and parallelism, a common source of confusion. Concurrency involves tasks that overlap in execution time but may not run simultaneously, as the operating system may time-share a single CPU. Parallelism, however, ensures tasks execute simultaneously, leveraging multiple CPUs or cores. For instance, two users editing documents on separate machines achieve parallelism, while a single-core CPU running multiple tasks creates the illusion of parallelism through time-sharing. Java’s threading model, introduced in JDK 1.0, facilitates concurrency via the Thread class, but coordinating data sharing across threads remains challenging. Simon highlights how Java evolved with the concurrency utilities in JDK 5, the Fork/Join framework in JDK 7, and parallel streams in JDK 8, each simplifying concurrent programming while introducing trade-offs, such as non-deterministic results in parallel streams.

The Essence of Vector Processing

The Vector API, distinct from the legacy java.util.Vector class, enables true parallel processing within a single execution unit using SIMD instructions. Simon explains that vectors in mathematics represent sets of values, unlike scalars, and the Vector API applies this concept by storing multiple values in wide registers (e.g., 256-bit AVX2 registers). These registers, divided into lanes (e.g., eight 32-bit integers), allow a single operation, such as adding a constant, to process all lanes in one clock cycle. This contrasts with iterative loops, which process elements sequentially. Historical context reveals SIMD’s roots in 1960s supercomputers like the ILLIAC IV and Cray-1, with modern implementations in Intel’s MMX, SSE, and AVX instructions, culminating in AVX-512 with 512-bit registers. The Vector API abstracts these complexities, enabling developers to write cross-platform code without targeting specific microarchitectures.

Leveraging the Vector API

Simon illustrates the Vector API’s practical application through its core components: Vector, VectorSpecies, and VectorShape. The Vector class, parameterized by type (e.g., Integer), supports operations like addition and multiplication across all lanes. Subclasses like IntVector handle primitive types, offering methods like fromArray to populate vectors from arrays. VectorShape defines register sizes (64 to 512 bits or S_MAX for the largest available), ensuring portability across architectures like Intel and ARM. VectorSpecies combines type and shape, specifying, for example, an IntVector with eight lanes in a 256-bit register. Simon demonstrates a loop processing a million-element array, using VectorSpecies to calculate iterations based on lane count, and employs VectorMask to handle partial arrays, ensuring no side effects from unused lanes. This approach optimizes performance for numerically intensive tasks, such as matrix computations or data transformations.

Performance Insights and Trade-offs

The Vector API’s performance benefits shine in specific scenarios, particularly when autovectorization by the JIT compiler is insufficient. Simon references benchmarks from Tomas Zezula, showing that explicit Vector API usage outperforms autovectorization for small arrays (e.g., 64 elements) due to better register utilization. However, for larger arrays (e.g., 2 million elements), memory access latency—100+ cycles for RAM versus 3-5 for L1 cache—diminishes gains. Conditional operations, like adding only even-valued elements, further highlight the API’s value, as the C2 JIT compiler often fails to autovectorize such cases. Azul’s Falcon JIT compiler, based on LLVM, improves autovectorization, but explicit Vector API usage remains superior for complex operations. Simon emphasizes that while the API offers significant flexibility through masks and shuffles, its benefits wane with large datasets due to memory bottlenecks.

Links:

• Azul Systems website

At Spring I/O 2024 in Barcelona, Balkrishna Rawool, a software engineer at ING Bank, captivated attendees with an in-depth exploration of continuations, the underlying mechanism powering Java’s virtual threads. Introduced as a final feature in Java 21 under Project Loom, virtual threads promise unprecedented scalability for Java applications. Balkrishna’s session demystified how continuations enable this scalability by allowing programs to pause and resume execution, offering a deep dive into their mechanics and practical applications.

Understanding Virtual Threads

Virtual threads, a cornerstone of Project Loom, are lightweight user threads designed to enhance scalability in Java applications. Unlike platform threads, which map directly to operating system threads and are resource-intensive, virtual threads require minimal memory, enabling developers to create millions without significant overhead. Balkrishna illustrated this by comparing platform threads, often pooled due to their cost, to virtual threads, which are created and discarded as needed, avoiding pooling anti-patterns. He emphasized that virtual threads rely on platform threads—termed carrier threads—for execution, with a scheduler mounting and unmounting them dynamically. This mechanism ensures efficient CPU utilization, particularly in I/O-bound applications where threads spend considerable time waiting, thus boosting scalability.

The Power of Continuations

Continuations, the core focus of Balkrishna’s talk, are objects that represent a program’s current state or the “rest” of its computation. They allow developers to pause a program’s execution and resume it later, a capability critical to virtual threads’ efficiency. Using Java’s Continuation API, Balkrishna demonstrated how continuations pause execution via the yield method, transferring control back to the caller, and resume via the run method. He showcased this with a simple example where a continuation printed values, paused at specific points, and resumed, highlighting the manipulation of the call stack to achieve this control transfer. Although the Continuation API is not intended for direct application use, understanding it provides insight into virtual threads’ behavior and scalability.

Building a Generator with Continuations

To illustrate continuations’ versatility, Balkrishna implemented a generator—a data structure yielding values lazily—using only the Continuation API, eschewing Java’s streams or iterators. Generators are ideal for resource-intensive computations, producing values only when needed. In his demo, Balkrishna created a generator yielding strings (“a,” “b,” “c”) by defining a Source object to handle value yields and pauses via continuations. The generator paused after each yield, allowing consumers to iterate over values in a loop, demonstrating how continuations enable flexible control flow beyond virtual threads, applicable to constructs like coroutines or exception handling.

Crafting a Simple Virtual Thread

In the session’s climax, Balkrishna guided attendees through implementing a simplified virtual thread class using continuations. The custom virtual thread paused execution during blocking operations, freeing platform threads, and supported a many-to-many relationship with carrier threads. He introduced a scheduler to manage virtual threads on a fixed pool of platform threads, using a queue for first-in-first-out scheduling. A demo with thousands of virtual threads, each simulating blocking calls, outperformed an equivalent platform-thread implementation, underscoring virtual threads’ scalability. By leveraging scoped values and timers, Balkrishna ensured accurate thread identification and resumption, providing a clear, hands-on understanding of virtual threads’ mechanics.

Links:

• Balkrishna Rawool’s GitHub Repository
• Slides on SpeakerDeck