The language notes next to this one are modern Java and Go or Rust. They are a separate thread.

Where a line says TODO, that part is still to be written from the docs, in my own words.

Why this note exists

I want to be able to explain the architecture, a consumer group, a connector, and the OpenShift custom resources without the docs open.

TODO: turn that into a short list of questions I can answer out loud when this note is finished.

Brokers, topics, and partitions

A Kafka cluster is a set of brokers. Producers append records to topics. A topic is split into partitions, and each partition is an ordered log. A record in a partition has an offset that increases along that partition.

Ordering is per partition. Records on different partitions have no order relative to each other. A key chooses the partition, so records with the same key stay in one partition and keep their order. A record with no key is spread across partitions.

TODO: a sketch of one topic with three partitions, and which keys land together.

TODO: write the ordering rule in one sentence I would actually say.

Replication

Each partition has a leader and zero or more followers. The in-sync replicas are the followers that have caught up with the leader. A record is available to consumers once it has reached the high watermark, the offset through which every in-sync replica has the record.

acks on the producer, min.insync.replicas, and whether an unclean leader election is allowed are the three settings that decide what happens when a broker is lost. They trade durability against availability.

TODO: write those three in my own words, each with the failure it accepts. Take the definitions from the Kafka documentation, and link the page.

KRaft

Kafka can store its own cluster metadata with KRaft, a Raft quorum of controllers, instead of an external ZooKeeper ensemble. Apache Kafka 4.0 is the first major release that only runs in KRaft mode. ZooKeeper mode was removed in that release. The 3.9 line is the last 3.x release, and the bridge used to migrate a ZooKeeper cluster before moving to 4.0.

TODO: from the upgrade notes, write what an operator still runs in KRaft mode, and the order of a migration off ZooKeeper. Link the page. Do not reconstruct the steps from this paragraph.

Producers

A producer batches records, chooses a partition (by key, or across partitions when there is no key), and waits according to acks before treating the send as done.

The idempotent producer and transactions are the two features I want a paragraph on. The idempotent producer avoids duplicates from retries. Transactions let a producer write to several partitions and commit them as one unit, at a cost in latency and complexity.

TODO: those two paragraphs, after reading the producer docs, plus a sentence on when I would leave transactions off.

Consumers and consumer groups

A consumer reads a partition from an offset. A consumer group divides the partitions of its subscribed topics across its members, so each partition is read by one member of the group at a time. When membership changes, the group rebalances and partitions move.

Offsets are how the group remembers its place. Committing an offset before the work is finished means a crash loses that work. Committing after the work means a crash can deliver the same records again. Consumers are expected to tolerate the duplicate.

TODO: enable.auto.commit versus committing after the work, in my own words, with the failure of committing too early.

TODO: one paragraph on cooperative and eager rebalancing, after the consumer docs. Name the protocol version I read about, including the next-generation rebalance protocol if that is the current one, and link it.

Kafka Connect and connectors

Kafka Connect is a separate runtime for moving data in and out of Kafka. A source connector writes into Kafka. A sink connector writes out of it. Connect workers can run as their own cluster, with a config topic, an offset topic, and a status topic.

A connector is the configured job. A task is a unit of that job, and a connector can have several tasks. A converter turns the record's payload into bytes or back, for example JSON or Avro. Those three are different things, and it is easy to talk about them as if they were one.

TODO: write connector, task, and converter in one sentence each, from the Connect docs.

TODO: name one source and one sink I want to be able to configure, after I have picked them. Leave the names out until then.

Kafka on OpenShift

Strimzi is a Kubernetes operator for Apache Kafka. On OpenShift the cluster is declared as custom resources, and the operator reconciles them into pods, services, and configuration. Red Hat's distribution of that operator was AMQ Streams, and has been renamed Streams for Apache Kafka. The rename is recorded in the Streams for Apache Kafka 2.9 release notes. Older pages still say AMQ Streams. The custom resources are the Strimzi ones either way.

The resources this note should be able to tell apart:

• Kafka is the cluster: brokers, and the controller quorum. KRaft or, on older versions, ZooKeeper is a setting of this resource.
• KafkaTopic is a topic, so topic configuration lives in the cluster's API rather than only in a kafka-topics command.
• KafkaUser is a user and its access control, when the user operator is enabled.
• KafkaConnect is a Connect cluster.
• KafkaConnector is a connector deployed onto that Connect cluster.

The topic operator and the user operator are switched on from the Kafka resource. Without them, KafkaTopic and KafkaUser are not reconciled.

A connector can also be created by posting its configuration to the Connect REST API. KafkaConnector is the operator's way of holding that configuration as a resource. They end up as the same connector inside Connect. The difference is what owns the configuration.

TODO: from the current Strimzi docs, summarise a minimal Kafka resource and the listener types I would actually choose on OpenShift. Link the doc. Keep the summary short enough that I can redraw it.

TODO: write how the topic operator and the user operator are enabled, from the docs, in a few lines.

TODO: say which I would use, KafkaConnector or the REST API, and why, after reading both.

TODO: storage, metrics, and what a rolling restart of brokers does to clients. Three short paragraphs, each from a doc page I link.

Open questions

TODO: questions go here as they come up. None yet beyond the placeholders above.

The decision overview for spending more time on Go or on Rust is a separate note. This one is only the code that is already here.

The examples are two programs, not two files. Each program is a package main split across a handler, a parser, and a test.

Where the code is

The statement reader:

• netlify/functions/camt/main.go is the entry point.
• netlify/functions/camt/parse.go turns camt.053 XML into the JSON the page shows.
• netlify/functions/camt/parse_test.go checks the parser against the example file.
• netlify/functions/camt/go.mod names the module hostlund.com/camt and depends on github.com/aws/aws-lambda-go v1.55.1. The go line says 1.26.

The payment reader:

• netlify/functions/pain/main.go
• netlify/functions/pain/parse.go
• netlify/functions/pain/parse_test.go
• netlify/functions/pain/go.mod, module hostlund.com/pain, with the same dependency.

The two programs do not import each other. The namespace wrapper and the small string helpers are copied into each parse.go.

The example documents the tests read are static/samples/camt053-example.xml and static/samples/pain001-example.xml. The software page describes both as written for the site: made-up names and amounts, and a specimen IBAN.

What each program does

parseCamt in netlify/functions/camt/parse.go decodes a bank-to-customer statement. The document element it maps is BkToCstmrStmt/Stmt. For each statement it builds a statementView: an id, a creation time, the account (IBAN, or the other account id when there is no IBAN, plus currency and name), the balances, and the entries. Balance codes such as OPBD and CLBD become labels ("Opening booked", "Closing booked") in balanceLabel. Credit and debit indicators CRDT and DBIT become "Credit" and "Debit" in direction.

An entry can contain transaction details. entryViews flattens NtryDtls/TxDtls. When those details exist, the amount prefers the transaction amount, then the detail amount, then the entry amount. The counterparty depends on the direction: a debit's other party is the creditor, and a credit's other party is the debtor, falling back to the creditor when the debtor name is empty. That logic is counterparty. When an entry has no transaction details, the view still has the entry amount, dates, status, servicer reference, and additional info.

The group header of the sample statement (GrpHdr, message id SAMPLE-2026-02) is not mapped. encoding/xml skips elements that no struct field asks for.

parsePain in netlify/functions/pain/parse.go decodes a customer credit transfer initiation, CstmrCdtTrfInitn. The JSON is one paymentView: the group header (message id, created time, initiator, count, control sum) and a list of payment blocks. Each block has the debtor, the debtor IBAN (or the other account id), the debtor BIC (BICFI, or the older BIC tag when BICFI is empty), the execution date, and the transfers. A transfer's account is the creditor IBAN, or the other account id. Remittance is the unstructured Ustrd lines joined with spaces.

A few parsed fields are not copied onto the JSON. On a transfer, InstrId and the creditor BIC are unmarshaled and then left off transferView. The page does not show them.

Both parsers reject an empty body and a document that does not have the expected shape. camt returns "no statement was found in the file" when no Stmt was mapped. pain returns "no payment was found in the file" when the message id is empty and there are no payment blocks.

How the Experience section shows them

The work page does not paste this source. The sentence there links to the software page. The software page links to /camt/ and /pain/, and describes the two readers in a sentence each.

src/pages/camt.js posts the XML to /api/camt and renders statements: the account line, a balance table (label, date, creditDebit, amount, currency), and an entry table (bookingDate, valueDate, creditDebit, amount, counterparty, endToEndId or reference, remittance).

src/pages/pain.js posts to /api/pain and renders the payment object itself: initiator, message id, count, control sum, and each block's debtor, IBAN, BIC, execution date, and transfers.

Both pages also show the example XML and say the file is not stored. Nothing in the Go writes the body to disk or to a database. The response sets cache-control: no-store.

The third software page, FinTS, is not Go.

How a request is handled

The shape of main.go is the same in both programs.

handler accepts only POST. Anything else is HTTP 405. requestBody base64-decodes the body when IsBase64Encoded is set, which is the API Gateway proxy behaviour, and otherwise uses the body as bytes. evaluate rejects a body over maxBytes (1000000) with HTTP 413, calls the parser, and on success returns 200. camt wraps the slice as {"statements": ...}. pain marshals the paymentView as the whole body. A parser error becomes HTTP 400 with {"error": "..."}.

main has two modes. The statement program reads stdin when CAMT_DEV is stdin. The payment program does the same when PAIN_DEV is stdin. In that mode it prints the status code, a newline, and the JSON. Otherwise it calls lambda.Start(handler).

In gatsby develop, gatsby-node.js mounts POST /api/camt and POST /api/pain. Each mount runs go run . in the function directory with that environment variable set to stdin, passes the request body as the process input, and splits stdout on the first newline into a status and a payload. The timeout is 60 seconds. If the process fails or prints no newline, the dev server responds 500 with {"error":"The file could not be read."}.

On the deployed site, netlify.toml redirects /api/camt to /.netlify/functions/camt and /api/pain to /.netlify/functions/pain. Nothing in this repo sets CAMT_DEV or PAIN_DEV for that deploy, so main takes the lambda.Start path. The Gatsby build command in netlify.toml is npm install && npm run build. It does not compile the Go. Netlify builds a function from each of netlify/functions/camt and netlify/functions/pain, which are package main directories with their own go.mod.

How to build and run them

From netlify/functions/camt or netlify/functions/pain:

go test
go run .

go test runs TestExampleStatement or TestExamplePayment, which read the sample XML three directories up, and TestRejectsEmptyAndOtherXML, which checks that an empty body and an unrelated <Document> are errors.

go run . with neither dev variable set starts the Lambda handler and waits for an invocation. The path that the site uses locally is the dev variable, through the Gatsby process above. Sending a file by hand looks like this, from the function directory:

CAMT_DEV=stdin go run . < ../../../static/samples/camt053-example.xml

The first line of stdout is the status code. The rest is the JSON.

Types and functions

There are no classes. The data types are structs. The XML structs carry xml struct tags, and the view structs carry json struct tags. A tag such as xml:"BkToCstmrStmt>Stmt" maps a nested element. xml:"Ccy,attr" maps an attribute. xml:",chardata" maps the text inside the element. A slice field maps repeated elements: []entry with xml:"Ntry", or []string with xml:"RmtInf>Ustrd".

In the Java libraries this is closest to JAXB or Jackson annotations on fields. The path syntax (Parent>Child) is doing the job a chain of nested types would do. Both styles are in this code. amount is its own struct because currency is an attribute and the value is character data. The account name is a string with a path tag, xml:"Ownr>Nm", because nothing else from that subtree is needed.

localNames is the interesting type. It wraps an xml.Decoder and implements Token() (xml.Token, error). parseCamt and parsePain pass it to xml.NewTokenDecoder. On each start and end element, and on each attribute, the method clears Name.Space. The namespace URI is discarded, so one set of structs accepts a camt.053 whose xmlns is urn:iso:std:iso:20022:tech:xsd:camt.053.001.02 and a later version of the same statement shape. The camt page says this in a sentence. The pain sample is pain.001.001.09, and the same wrapper is why the tag names matter and the URN does not.

The functions, in the order a request uses them:

camt: main, handler, requestBody, evaluate, parseCamt, toView, entryViews, flatten, counterparty, direction, balanceLabel, firstText, cleanList, jsonStatus, jsonResponse.

pain: main, handler, requestBody, evaluate, parsePain, toView, firstText, cleanList, jsonStatus, jsonResponse.

jsonResponse in the camt program marshals on its own. In the pain program it calls jsonStatus and uses that result. The behaviour a caller sees is the same.

Idioms, for a Java developer

One package, several files. Every file says package main. All of the functions and types in the directory are in one package, and main is the entry point, the same role as public static void main. There is no class wrapping them. Java would have made parseCamt a method on a class. Go lets the function sit at package scope.

Visibility is the capital letter. parseCamt, handler, and statement start with a lowercase letter, so another module cannot call them. The tests are package main, not package main_test, so they can call parseCamt directly. A Java test in the same package can call a package-private method for the same reason. The module path in go.mod is the import path, closest to Maven coordinates, and nothing in this repo imports either module. They are programs, not libraries.

Errors are values. parseCamt returns ([]statementView, error). The caller writes if err != nil. There is no throw and no checked exception. fmt.Errorf builds the error. HTTP status is not the Go error return. handler almost always returns a nil error and puts 400, 405, or 413 on the response. The error return is the function runtime's failure channel. A nil error with a 400 response means "the invocation succeeded, the file did not."

Structs instead of beans. A struct is a block of fields. The zero value is usable: pain returns paymentView{} on failure, which is the analogue of an empty object whose fields are "", nil, or 0. There is no constructor unless someone writes one. These files do not. toView fills the struct in a composite literal, which reads like a constructor call with named arguments.

Slices instead of ArrayList. views := make([]statementView, 0, len(doc.Statements)) allocates a slice with length 0 and enough capacity for the statements, then append adds to it. The capacity argument is the same idea as new ArrayList<>(n). append may allocate a larger array if the capacity is exceeded. flatten starts from a nil slice and appends. A nil slice marshals as JSON null if it is ever returned directly. The views in this code are built with make, so an empty list of balances or transfers marshals as [].

The interface is implicit. localNames does not declare that it implements a type. xml.NewTokenDecoder asks for a TokenReader, which is an interface with one method, Token() (Token, error). Having the method is enough. Java would say implements TokenReader. The method has a value receiver, func (l localNames) Token(), and the decoder pointer lives inside the struct, so the copy still reads the same underlying decoder. The loop for i := range element.Attr uses the index because a range value is a copy. Writing through the index updates the attribute that is returned. That is a common Go slip, and this code avoids it.

switch does not fall through. direction and balanceLabel switch on the upper-cased code and return from each case. There is no break. A case ends at the next case.

Variadic helpers. firstText(values ...string) is String... in Java. It returns the first value that is not blank after strings.TrimSpace. Dates use it so a date-only tag wins when it is present and a date-time tag is the fallback: firstText(item.BookingDate, item.BookingTime).

any. map[string]any{"statements": statements} is a map from string to an arbitrary value, closest to Map<String, Object>. any is a predeclared alias for interface{}. This code does not use type parameters beyond that.

Short declarations. stmt := statements[0] declares and assigns. The type comes from the right-hand side, the same information var carries in Java, written at the call.

Tests. parse_test.go imports the testing package. t.Fatal fails the test and stops it, in the role of an assertion failure. There is no test class and no framework in these files. go test finds the files by the _test.go suffix.

What this code does not use

There are no goroutines, no channels, and no mutexes. Concurrency is not a reason this program is in Go. The reasons visible in the code are the small runtime, the XML and JSON libraries, a single binary, and the function entry point.

There is no shared internal package. The duplication of localNames, amount, firstText, and cleanList is the cost of that.

TODO: after changing one of the duplicated helpers, write whether I still want two copies. That is my note to make once I have edited the code, not a refactor hidden in this write-up.

TODO: a line on what felt familiar from Java the first time I reread parse.go, and what did not. I want that in my own words.

The conclusion is blank on purpose. The last section is a checklist, and the lines marked TODO are where my own decision goes once I have done the looking.

Learning curve, coming from Java

Go is a small language with a garbage collector. A Java developer already knows the shape of it: packages, functions, structs, interfaces, loops, and values passed around. The surprises are local. Names that start with a capital letter are public. Errors are returned, not thrown. There is no inheritance of implementation. Interfaces are satisfied by having the methods, with no implements clause. The compiler is fast, and gofmt leaves one layout.

Rust is a different kind of step. Ownership, borrowing, and lifetimes are the language, not a library. The compiler rejects programs a Java compiler would accept, because the Java program would rely on the garbage collector and on the programmer to avoid use-after-free and data races. Reading Rust gets easier before writing it does. Writing it well is the long part.

TODO: after a short exercise in each, write which of those surprises actually slowed me down. Keep it to what I hit, not to a general claim about either language.

Concurrency

Go's unit of concurrency is the goroutine: a function the runtime schedules onto operating-system threads. Goroutines are cheap enough that a server can use one per request and write blocking code. Channels move values between them. select waits on more than one. Sharing memory with a mutex is also ordinary Go. The feel is close to the pitch of Java virtual threads — blocking code, many threads — with channels as an extra primitive. The comparison with virtual threads belongs next to the Java note once that section is filled in.

Rust has threads and mutexes too. The type system tracks Send and Sync, so sharing across threads is a type error when it is unsafe. The usual way to write a network service is async/await on a runtime such as Tokio. That is a different model from goroutines. Suspension points are marked in the code, and the types of the futures can dominate the signature. There is no garbage collector pausing the process, and there is also no runtime that makes a blocking call inside an async function cheap or correct.

TODO: one paragraph in my own words on which model I can hold in my head while reading someone else's code. Goroutines and channels, or async Rust. Write it after reading a real example of each, and link the example.

Memory

Go is garbage collected. The compiler decides whether a value stays on the stack or escapes to the heap. Pointers exist. The programmer does not free memory.

Rust gives each value an owner. A borrow is a reference with a lifetime, and the compiler checks that the reference does not outlive the value. There is no garbage collector. The cost shows up in the types (String versus &str, Vec versus a slice, Box, Rc, Arc) rather than in a collector.

For service code that spends its time on I/O and JSON, the collector is rarely the thing a Java developer is trying to escape. For a parser or a component on a latency budget, the collector is the thing Rust is for.

TODO: say which of those two sentences matches the work I want to be hired for. Leave it empty until the checklist below has an answer.

Tooling and ecosystem

Go ships as the go command: modules, go test, go fmt, and a standard library that covers HTTP, JSON, and concurrency. A program builds to one static binary. The camt and pain readers on this site are that shape: a go.mod, the standard encoding/xml and encoding/json packages, and one third-party module for the Netlify function signature.

Rust ships as rustup and Cargo. Dependencies come from crates.io. rustfmt and Clippy are the usual format and lint tools. Compiler errors are specific. Compile times are longer than Go's, and the ecosystem is large, with more choice of crates for the same job.

TODO: note the first library I had to go looking for in each language, and whether the standard library would have done it.

Where the languages turn up

These are the domains I am weighing, in the terms of the work rather than as a ranking.

Cloud-native and Kubernetes tooling, including OpenShift, is largely Go. Kubernetes itself, the Docker engine, containerd, Terraform, and Prometheus are Go codebases. A controller written with Kubebuilder is Go. OpenShift is a Kubernetes distribution, so the same applies to a lot of the platform tooling around it. The Strimzi operator, which the Kafka note is about, is a Java project (strimzi-kafka-operator). Reading that operator is Java work.

Microservices in the style of a Spring Boot service — HTTP, JSON, a database or a queue — are a short step in Go: one binary, a garbage collector, blocking handlers or goroutines. The same service can be written in Rust. The distance from Spring is larger, because the memory model and the async runtime come along with the HTTP stack.

CLIs are a natural Go program, for the same reason: a static binary and a fast edit-compile cycle. Rust is also a common CLI language. The difference I care about at the start is how long it takes to get the first useful version, not the ceiling.

Systems and performance-critical code is Rust's case. The language is built to express ownership of memory and to exclude data races. Go runs plenty of demanding infrastructure and accepts garbage collection as the trade. I want the later comparison with virtual threads to stay honest about that trade, once the Java note has the Loom section filled in.

WebAssembly is a first-class Rust target, used for code that runs in the browser and in some edge runtimes. Go can compile to WebAssembly. The output includes the Go runtime, so a small module is a less usual reason to pick Go.

TODO: mark which of these domains I actually want the second language for. One of them, not all of them.

Kafka, streaming, and fintech

The Java client that ships with Apache Kafka is the client a Spring service already has a path to. Go has clients in wide use, among them kafka-go and confluent-kafka-go. Rust has rdkafka, which wraps librdkafka. This note does not pick one.

On the banking side, the work described on this site is Java: interfaces, FinTS, file and batch integration, Camunda in an earlier role. Neither Go nor Rust replaces that for the application itself. Go is already how this site reads a camt.053 statement and a pain.001 payment: a small program, XML in, JSON out, deployed as a function. That is a payments-shaped task of the kind Go is comfortable for, and a task a Rust parser would also suit. It is one data point about a fit, and it is written up on its own.

TODO: if a streaming example is the practice project, write down which client I used and what broke. Do not turn this section into a claim that one language is the fintech language.

Job-market signals

Qualitatively, from the shape of the work rather than from a survey table:

Java is still the language the core-banking and payments application roles are written in. A second language adds listings. It does not retire the first one.

Go is the second language that shows up beside Kubernetes, platform, and cloud-native service roles. That follows from where the tooling is written, above, more than from a hiring statistic.

Rust shows up on a narrower set of roles: systems, security-sensitive components, and infrastructure where the memory model is the requirement. Fewer banking application posts ask for it. The posts that do are more specific.

The Stack Overflow Developer Survey publishes language rankings each year. This note deliberately does not copy a percentage, a salary figure, or a "most loved" rank out of it. Those numbers go stale, and a pasted figure with no table under it is worse than none. Read the current edition, and read current listings.

TODO: look at current listings for the kind of role I would actually take in Berlin. Write what the posts asked for, with links to the posts. If a number ends up in this note, it comes from one of those pages and the link stays next to it.

A checklist, and then my conclusion

Answer these in order. The decision is the last line, and it is empty until then.

1. Name the work the second language is for: platform and Kubernetes tooling, service backends beside Java, or systems and performance-critical code. One primary.
2. Do the small version of the program this site already has: read a file, return JSON. Once in Go, once in Rust. Write down which one I was willing to finish, and where I got stuck. The Go version can start from the readers already in this repo.
3. Read one codebase I did not write. A Kubernetes controller in Go, and a small Rust program of similar length. Note which reading was usable on a weekday evening.
4. Read current Berlin listings and the current Stack Overflow survey. Link them. Count nothing in this note that I cannot point at.
5. Decide whether the Kafka-on-OpenShift study needs either language. The Strimzi operator is Java, and the first Kafka client in a Spring service is the Java client. A second language can still be the right use of the time. It is a separate question from finishing that note.
6. Write the conclusion in one paragraph: which language I will commit practice time to, for how long, and what I will ship with it. The other language stays available. This note is about the commitment, not about a ban.

TODO: my conclusion, after the checklist. One paragraph. Leave the paragraph out rather than guess it.

Read as a checklist with the conclusion still empty, Go is the shorter step from Java into Kubernetes-side and service work, and it is the language already running on this site. Rust is the longer step, and the one that matters if the target work is ownership and the absence of a garbage collector. Neither replaces Java for the core banking work on the work page. That leaning is a summary of the sections above. It is not the decision in item 6.

Where a line says TODO, that part is still to be written from my own reading and from code I actually have in front of me.

Why this note exists

The language moved, in public, through a series of JEPs. A lot of service code still looks like Java 8: classes with getters, loops, and a classpath of jars. This note is the list of changes I want to be able to explain without looking them up.

TODO: write down the language level and the frameworks in the code I actually work in, from the build files, rather than from memory.

Records

A record (JEP 395, Java 16) is a class whose state is the list of components in the header. The compiler writes the constructor, the accessors, equals, hashCode, and toString.

TODO: a before and after against a small immutable type I would otherwise have written by hand in a JEE or Spring service.

TODO: where a record is the wrong tool. Mutable state, and a type that needs a superclass, are the cases I want a sentence on.

Sealed types

A sealed class or interface (JEP 409, Java 17) names the types that are allowed to extend or implement it. The set of subtypes is closed.

TODO: a small hierarchy, a result or a message, with the permitted subtypes written out.

TODO: leave a pointer here for the later comparison with a Rust enum and with the usual Go approach of an interface plus unexported implementations. That comparison belongs in a later note. It is not written yet.

Pattern matching

Pattern matching for instanceof (JEP 394, Java 16) binds the tested value, so the cast after the test goes away. Pattern matching for switch (JEP 441, Java 21) lets a switch cover types.

TODO: one example that switches on a sealed type, and what the compiler reports when a permitted subtype is missing from the switch.

Text blocks and var

A text block (JEP 378, Java 15) is a multiline string literal. var (JEP 286, Java 10) infers the type of a local variable from its initializer. Neither one changes the type system. They change how a method reads.

TODO: paste a SQL or JSON literal I would otherwise have built with concatenation, and mark one var I would keep and one I would write out in full.

Virtual threads

Virtual threads (JEP 444, Java 21, Project Loom) are threads scheduled by the JVM onto a smaller set of carrier platform threads. The style they are for is blocking I/O, with a thread per request, at a cost closer to an asynchronous runtime than to the old thread pool.

TODO: after reading the JEP, write what changes for a Spring Boot or servlet service that blocks on I/O, and what stays the same. Pin the notes on synchronized, thread locals, and pooling to the JEP, not to a summary from memory.

TODO: this is the comparison point for goroutines. Leave the comparison until the Go note exists. The decision overview is Go or Rust.

The module system

The Java Platform Module System (JEP 261, Java 9) adds modules with requires and exports. A lot of Spring Boot and older JEE code still ships as a classpath of jars. "Module" in a Maven build is a different thing from a JPMS module.

TODO: state whether any project I touch builds with module-info.java. If the only modules in sight are Maven modules, say that in one sentence.

Streams

The Stream API arrived in Java 8. It is the oldest item on this list, and the one most likely to already be in a codebase that otherwise looks like Java 8. A stream is a pipeline over a source: intermediate operations, then a terminal operation.

TODO: one loop I would rewrite as a pipeline, and one loop I would leave as a loop, taken from code I can point at.

What comes next

The next note in this series is the decision overview, Go or Rust: deciding which to commit to. It is about which language to spend the time on. It is not yet the feature-by-feature comparison.

Kafka on OpenShift is a separate note, Kafka within OpenShift.

TODO: a later note that takes records, sealed types, and virtual threads and sets them next to Go and Rust, once I can write the other side from the language rather than from a glossary.