Rust for Java Developers

1. The big picture

Before any tooling: understand the one fundamental difference between Java and Rust. Everything else follows from it.

In Java, you compile your code to bytecode (.class files). Bytecode is not something your CPU understands. It's instructions for an imaginary computer, the Java Virtual Machine. When you run your program, the JVM starts up, loads your bytecode, interprets it, watches which parts are "hot", and compiles those to real machine code while the program runs (the JIT compiler). A garbage collector runs alongside, cleaning up objects you no longer use.

In Rust, there is no virtual machine. The compiler turns your source code straight into native machine code for a specific CPU and operating system. The output is a regular executable file, just like ls or git. You run it, the operating system loads it, and the CPU executes your instructions directly. There's no interpreter, no JIT and no garbage collector.

Hold onto this picture. It explains almost every "why" in this guide:

2. Setting up your environment

One installer, a handful of tools. Here's what each tool is for and why you need it.

The cast of characters

In Java you assemble a toolchain from separate projects: a JDK from some vendor, SDKMAN to switch JDKs, Maven or Gradle to build, Checkstyle/Spotless for formatting, SpotBugs or Sonar for linting, IntelliJ for code intelligence. Rust ships an official, integrated toolchain where every piece comes from the same project and works together out of the box.

Why each one exists

Install it (macOS)

1. Install the linker (skip if you already have Xcode or its CLI tools, e.g. because you use git or Homebrew):

   xcode-select --install

2. Install rustup, which installs everything else. This is the official installer from rustup.rs; accept the default option:

   curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

   It puts tools in ~/.cargo/bin and toolchains in ~/.rustup, and adds ~/.cargo/bin to your PATH. Nothing is installed system-wide and no sudo is needed. Open a new terminal afterwards.

3. Verify:

   rustc --version     # rustc 1.9x.0 (...)
   cargo --version
   rustup show         # which toolchain is active, and which targets

4. Set up the editor. Two good choices:
   • RustRover (JetBrains): feels like home if you live in IntelliJ. Check the license terms for commercial/work use with your team.
   • VS Code + the "rust-analyzer" extension: free and the most widely used. Add "CodeLLDB" if you want a debugger.

Pinning a version per project

Like a .sdkmanrc or Gradle toolchains, put a rust-toolchain.toml in the project root and rustup automatically switches to (and downloads) that version when you're in that folder:

[toolchain]
channel = "1.90.0"
components = ["clippy", "rustfmt"]

3. Anatomy of a project

Create one and look inside. A Rust project is much smaller than a Maven one.

cargo new hello_rust        # an application (binary)
cargo new --lib my_utils     # a library
cd hello_rust

cargo new also runs git init and writes a .gitignore containing just /target. Here's everything it creates, plus what appears after the first build:

hello_rust/
├── Cargo.toml        # project manifest
├── Cargo.lock        # exact resolved versions (after 1st build)
├── .gitignore        # "/target"
├── src/
│   └── main.rs       # entry point
└── target/           # all build output (git-ignored)
    ├── debug/
    │   └── hello_rust   # ← your executable
    └── release/

hello-java/
├── pom.xml
│
├── .gitignore
├── src/
│   ├── main/java/com/acme/App.java
│   ├── main/resources/
│   └── test/java/com/acme/AppTest.java
└── target/
    ├── classes/
    └── hello-java-1.0.jar

Cargo.toml: your pom.xml

The manifest is written in TOML, a simple config format (think .properties with sections). Compare:

[package]
name = "hello_rust"
version = "0.1.0"
edition = "2024"

[dependencies]
serde = { version = "1", features = ["derive"] }
tokio = { version = "1", features = ["full"] }

[dev-dependencies]   # test scope
mockall = "0.15"

<groupId>com.acme</groupId>
<artifactId>hello-java</artifactId>
<version>0.1.0</version>
<properties><maven.compiler.release>21...
<dependencies>
  <dependency>
    <groupId>com.fasterxml.jackson.core...
    <artifactId>jackson-databind</...
    <version>2.17.0</version>
  </dependency>
  ... <scope>test</scope> ...

There's no groupId. Crate names on crates.io are a single global namespace (first come, first served), so serde is just serde.

Cargo.lock: the exact versions

Cargo.toml says "serde version 1-something". Cargo.lock records exactly which version was picked (e.g. 1.0.219) for every dependency, including transitive ones, with checksums. It's generated automatically and you never edit it by hand. Commit it to git, so every developer and every CI build uses identical versions. Java has no built-in equivalent; it's like Gradle dependency locking or a fully pinned BOM.

src/main.rs: the entry point

fn main() {
    println!("Hello, world!");
}

That's the whole program. There's no class, no public static void, no String[] args (you get arguments through std::env::args()). By convention, cargo knows that src/main.rs means "build an executable" and src/lib.rs means "build a library". There's no XML telling it where sources are. Convention over configuration, like Maven's src/main/java, but stricter.

target/: build output

Same idea as Maven's target/: throwaway, git-ignored, can grow to gigabytes because it caches compiled dependencies. cargo clean wipes it.

4. The daily dev loop

The cargo commands you'll actually use, and the order you'll use them in.

Reading the compiler is part of the job

Java devs often skim compiler errors. In Rust, the compiler is a teacher. Its errors show the exact spot, explain what's wrong, and often include the fix:

error[E0382]: borrow of moved value: `name`
 --> src/main.rs:4:20
  |
2 |     let name = String::from("Gabriel");
  |         ---- move occurs because `name` has type `String`, which does not implement the `Copy` trait
3 |     let other = name;
  |                 ---- value moved here
4 |     println!("{}", name);
  |                    ^^^^ value borrowed here after move
  |
help: consider cloning the value if the performance cost is acceptable
  |
3 |     let other = name.clone();
  |                     ++++++++

Every error has a code; rustc --explain E0382 prints a full article with examples. Expect to spend your first weeks "fighting the borrow checker". That's normal, and it's the compiler catching bugs that would have been runtime problems in Java.

Tests live next to the code

Unlike Java's separate src/test/java tree, Rust unit tests usually sit in the same file as the code, in a module that only compiles during cargo test. That's why cargo new --lib generates this:

pub fn add(left: u64, right: u64) -> u64 {
    left + right
}

#[cfg(test)]          // ← compiled ONLY for `cargo test` (never in your binary)
mod tests {
    use super::*;      // ← tests can see private functions too

    #[test]             // ← like JUnit's @Test
    fn it_works() {
        assert_eq!(add(2, 2), 4);
    }
}

5. Compiling & building executables

What happens when you hit build, the difference between debug and release, and how to ship.

Inside cargo build

A key difference from Java: dependencies are compiled from source. Maven downloads ready-made .jar files. Cargo downloads source code from crates.io and compiles it on your machine with your settings, so the optimizer can inline across library boundaries. This is why the first build of a project with 200 dependencies takes minutes, while later builds are fast because the compiled deps are cached.

Debug vs release

Cargo has build profiles. Real numbers for the hello-world above, built on Linux x86-64:

Tune profiles in Cargo.toml, similar to Maven profiles but for compiler settings:

[profile.release]
lto = true           # link-time optimization across all crates
codegen-units = 1     # slower build, better optimization
strip = true         # remove symbols → smaller binary
panic = "abort"      # don't unwind on panic → smaller, slightly faster

Shipping your executable

The release binary is your deployable. Copy it to a machine with the same OS/CPU and run it. There's no JRE to install, no -Xmx to tune, no classpath. A few things to know:

Targets: one binary per platform

Every platform has a target triple: arch-vendor-os(-abi). Your Apple-silicon Mac is aarch64-apple-darwin. A typical Linux server is x86_64-unknown-linux-gnu.

rustup target list --installed
rustup target add x86_64-unknown-linux-musl              # add a target (downloads its std)
cargo build --release --target x86_64-unknown-linux-musl  # → target/x86_64-unknown-linux-musl/release/

Cross-compiling Mac → Linux also needs a Linux-capable linker. The easy paths are cargo-zigbuild or cross (which runs the build in Docker), or simply building inside a Docker container, which is what most CI pipelines do.

Docker: the payoff

FROM rust:1 AS build
WORKDIR /app
COPY . .
RUN cargo build --release

FROM gcr.io/distroless/cc-debian12
COPY --from=build /app/target/release/myapp /
USER nonroot
ENTRYPOINT ["/myapp"]
# image: ~25–40 MB total. With musl + FROM scratch:
# just the binary (a few MB)

FROM maven:3-eclipse-temurin-21 AS build
...
RUN mvn -q package

FROM eclipse-temurin:21-jre
COPY --from=build /app/target/app.jar /
ENTRYPOINT ["java","-jar","/app.jar"]
# image: ~200+ MB (JRE + OS + jar)
# memory at idle: often 100s of MB

If your binary links extra C libraries (for example, the Kafka client in chapter 14 needs zlib), use a slim Debian image such as debian:bookworm-slim as the runtime stage instead, built from the matching rust:1-bookworm image so the glibc versions match.

6. How code is organized

Workspace → package → crate → module → item. Four words that confuse every newcomer, explained with Java equivalents.

Crate: the most important word

A crate is what the compiler compiles in one go. It always has a root file: src/main.rs for an executable (binary crate) or src/lib.rs for a library (library crate). When people say "crate" in conversation, they usually mean a library you can depend on, like "the serde crate".

A package can contain one library crate and any number of binary crates. A very common pattern is to put all logic in lib.rs (testable, reusable) and keep main.rs thin: parse args, call into the lib. Extra executables go in src/bin/:

my_service/
├── Cargo.toml
└── src/
    ├── lib.rs             # library crate "my_service": all the real logic
    ├── main.rs            # binary "my_service": thin, calls the lib
    └── bin/
        └── migrate.rs     # second binary "migrate" → cargo run --bin migrate

Modules: explicit, not folder-magic

Here's the part that surprises Java developers most. In Java, a file at com/acme/payments/Payment.java automatically belongs to package com.acme.payments. In Rust, a file is ignored until a parent module declares it with mod. The module tree starts at the crate root and is built explicitly:

src/
├── lib.rs
├── payments.rs
└── storage/
    ├── mod.rs        # or: src/storage.rs
    └── postgres.rs

// src/lib.rs (crate root)
pub mod payments;   // loads payments.rs
pub mod storage;    // loads storage/mod.rs

// src/storage/mod.rs
pub mod postgres;   // loads storage/postgres.rs

Then you refer to things by path, the way you'd use a fully-qualified Java name, and use works like import:

use crate::storage::postgres::Repo;   // crate:: = "from the root of THIS crate"
use serde::Deserialize;              // from an external crate (a dependency)
use std::collections::HashMap;       // from the standard library (like java.util)

Visibility: private by default

Struct fields are private by default too. A pub struct with private fields is Rust's version of encapsulation: outsiders must use your constructor and methods.

Try it: who can see this function?

Pick a visibility for calc_fee, defined in module payments::fees, and watch which parts of the code can call it.

// src/payments/fees.rs
fn calc_fee(amount: Decimal) -> Decimal { ... }

Workspaces: multi-module projects

For a larger system with several crates, like a Maven multi-module build, make a workspace. All members share one Cargo.lock (consistent versions) and one target/ (shared compile cache):

platform/
├── Cargo.toml          # [workspace]
├── Cargo.lock
├── crates/
│   ├── domain/         # lib
│   ├── persistence/    # lib, depends on domain
│   └── api-server/     # bin, depends on both
└── target/

[workspace]
members = ["crates/*"]
resolver = "3"

[workspace.dependencies]  # like <dependencyManagement>
serde = "1"
tokio = { version = "1", features = ["full"] }

7. Crates & the ecosystem

How dependencies work, where they come from, and which crates replace the Java libraries you know.

From Cargo.toml to compiled dependency

Version requirements (semver)

Features: optional parts of a crate

Crates can have features: optional functionality you switch on, which is compiled only if you ask for it. It's like choosing between spring-boot-starter-* modules, but inside a single dependency. For example, serde = { version = "1", features = ["derive"] } turns on the ability to auto-generate (de)serialization code. If you get "cannot find derive macro", you probably forgot a feature.

Macros: Rust's Lombok and annotation processors

You'll see #[derive(Debug, Clone, Serialize)] above structs. Derive macros generate code at compile time, much like Lombok's @Data or an annotation processor. Function-like macros end in ! (println!, vec!) and also expand at compile time, with no runtime reflection. Rust's standard library offers limited runtime type information through Any and TypeId, rather than Java-style inspection of fields and annotations. Libraries such as serde use derive macros to generate implementations at compile time; traits and explicit composition cover many other framework tasks.

The Java → Rust library map

This is the short version. Chapter 12 covers frameworks, messaging, cloud and secrets in depth, and chapter 13 covers databases (JDBC, JdbcTemplate, JPA, drivers including Oracle).

Discover crates on crates.io and read docs for any published version on docs.rs. Docs are auto-generated for every crate, which is one of the ecosystem's best features.

8. How Rust runs: memory without a garbage collector

This is the heart of Rust. If you understand this chapter, the compiler's strictness stops feeling arbitrary.

First: what's actually running?

Stack and heap in 60 seconds

Both languages use the same two memory areas:

• Stack: fast, automatic, fixed-size slots for each function call's local variables. When a function returns, its stack frame is gone instantly.
• Heap: a big pool for data whose size or lifetime isn't known up front (a growing list, a string read from a file). Someone must decide when to free each heap allocation.

Who frees heap memory is the core design question of a language:

The ownership rules

Compare what happens in each language when you "copy" a variable holding a string:

Borrowing: using without owning

Moving everything around would be painful, so you can borrow a value with a reference (&). It's like handing someone a pointer while you keep ownership. The compiler enforces one rule, the same idea as a ReadWriteLock but checked at compile time with zero runtime cost:

And one more guarantee: a reference can never outlive the thing it points to. The compiler tracks this with lifetimes. Most of the time it infers them silently. Occasionally you'll annotate one ('a) to explain a relationship the compiler can't guess. That's an advanced topic; for now, just know what the word means.

fn total(items: &Vec<u64>) -> u64 { items.iter().sum() }   // borrows: reads only
fn add_fee(items: &mut Vec<u64>) { items.push(150); }       // borrows mutably
fn archive(items: Vec<u64>) { /* takes ownership */ }      // freed when this fn ends

fn main() {
    let mut amounts = vec![1000, 2500];   // main owns the Vec
    add_fee(&mut amounts);                // lend it for writing
    println!("{}", total(&amounts));    // lend it for reading
    archive(amounts);                      // give it away (move)
    // total(&amounts);   ← compile error: amounts was moved
}

Watch it happen: step through a real program

Click Next to see what happens in memory, line by line. This exact program compiles and prints "Gabriel" twice; un-commenting line 4 produces the error shown in step 3.

 1fn main() { 2    let a = String::from("Gabriel"); 3    let b = a;              // move 4    // println!("{a}");     // ✗ E0382 if uncommented 5    let r = &b;             // borrow 6    println!("{r}"); 7    consume(b);             // move into function 8} 9 10fn consume(s: String) {11    println!("{s}");12}                           // s dropped here

9. Why Rust is efficient

It's not magic, and Java's JIT is excellent. Rust wins on memory, startup, and predictability, for concrete reasons.

Reason 1: data is laid out compactly

In Java, almost everything is an object on the heap, every object carries a header, and collections hold pointers to objects scattered around memory. Rust stores values inline by default:

Reason 2: no GC, so less memory and no pauses

A garbage collector needs headroom: Java heaps commonly run with 2–3× more memory than the live data so the GC can work efficiently, plus background CPU to trace and compact. Rust frees each value the moment its owner goes away, so memory use tracks live data closely and there are no stop-the-world pauses. Latency is predictable: p99 looks like p50. That matters for payment APIs with strict SLAs.

Reason 3: zero-cost abstractions

Rust's motto: what you don't use, you don't pay for; and what you do use, you couldn't hand-code any better. An iterator chain like items.iter().filter(...).map(...).sum() compiles to the same tight loop you'd write by hand. There's no lambda objects, no boxing, no virtual call per element.

Reason 4: generics are compiled per type (monomorphization)

Reason 5: no warm-up

The JVM starts slow and gets fast as the JIT learns your hot paths. Rust is fully optimized from the first instruction. That matters for CLIs, serverless and lambdas, autoscaling containers, and anything with cold starts.

The honest scorecard

10. Java habits to unlearn

Not syntax, but design reflexes. Each of these will trip you up until it clicks.

No null references. Use Option

Rust has no null for references: a reference must always point at a valid value. Raw pointers can be null, and dereferencing one requires unsafe. A value that might be absent has the type Option<T>, which is either Some(value) or None. It's like Java's Optional, but mandatory and free: the compiler won't let you use the inside without handling None, so a null dereference can't happen in safe Rust (.unwrap() on None panics instead).

No exceptions. Use Result

A function that can fail returns Result<T, E>: either Ok(value) or Err(error). Errors are ordinary return values, visible in the signature like checked exceptions, but without the ceremony. The ? operator means "if this is an error, return it to my caller":

Config load(Path p) throws IOException {
    String txt = Files.readString(p);
    return parse(txt);  // may throw too
}

fn load(p: &Path) -> Result<Config, AppError> {
    let txt = fs::read_to_string(p)?;
    parse(&txt)                // returns Result
}

Panics (panic!, .unwrap()) exist for bugs, the "this should never happen" cases. They're like an unchecked Error, not for normal control flow. In production code, prefer ? over .unwrap().

No inheritance. Use traits + composition

There are no classes and no extends. Data lives in structs, behavior goes in impl blocks, and shared behavior is defined by traits, which are like Java interfaces with default methods. Key difference: you can implement a trait for a type after the fact, even for types you didn't write, such as adding your own trait to String.

Enums that carry data, plus match

Rust enums are much more powerful than Java's. Each variant can hold different data, similar to Java 21's sealed interfaces with records. match is checked for exhaustiveness, so if you add a variant, every match that forgot it becomes a compile error:

enum PaymentStatus {
    Pending,
    Settled { at: DateTime<Utc> },
    Failed { code: u16, reason: String },
}

match status {
    PaymentStatus::Pending => retry_later(),
    PaymentStatus::Settled { at } => log_settled(at),
    PaymentStatus::Failed { code, .. } => alert(code),
}   // forgot a case? → doesn't compile

Immutable by default

let x = 5; can't be changed. You must write let mut x = 5; to allow it. That's the opposite of Java, where you add final to forbid changes.

Don't fight the borrow checker with Java-style object graphs

Java designs often have objects pointing at each other (parent ↔ child, observers, bidirectional links). That pattern is hard in Rust because ownership must be a tree. Idiomatic Rust prefers data flowing down and results flowing up, IDs instead of back-pointers, and plain functions over deep object hierarchies. When you feel you're fighting the compiler, the fix is usually to restructure the data, not to add more clone().

11. Concurrency in one page

"Fearless concurrency": the ownership rules from chapter 8 also prevent data races in safe code.

Two marker traits, checked automatically by the compiler, decide what's allowed across threads:

• Send: this value can be moved to another thread.
• Sync: this value can be shared by reference between threads.

Try to share a non-thread-safe value (like Rc or a plain mutable Vec) between threads and you get a compile error in safe Rust, not a data race in production at 3 a.m. To share mutable state you wrap it, for example Arc<Mutex<T>>. In Rust the data lives inside the mutex, so you physically can't touch it without locking. Compare Java, where the lock and the data are separate and nothing stops you forgetting synchronized.

12. The Spring world in Rust

Spring Boot, Spring MVC, Spring Kafka, Spring Cloud Vault, AWS starters… where are they in Rust? There's no Spring equivalent, and understanding why is the key to the whole Rust backend ecosystem.

Why there is no "Rust Spring"

Spring's magic is built on three JVM features: runtime reflection (inspecting classes and annotations while the program runs), classpath scanning (finding every @Component at startup), and dynamic proxies (wrapping your bean in a generated class, which is how @Transactional, @Cacheable and @Async work).

Rust does not provide Java-style classpath scanning or general runtime reflection over fields and annotations. Any and TypeId offer limited runtime type information, and Rust also supports runtime dispatch, for example through dyn Trait and function pointers. Frameworks commonly use explicit wiring, traits and macros instead of Spring's reflective container. So the ecosystem grew in a different shape:

• Small, focused libraries that compose, instead of one framework that controls your program.
• Compile-time macros (#[derive(...)], #[tokio::main]) where Java would use annotations read at runtime.
• Explicit wiring in main(): the ~30 lines Spring Boot does invisibly, you write yourself, once.

Spring Boot feature by feature

Dependency injection without a container

In Spring, the container creates beans and injects them. In Rust you do constructor injection by hand, exactly like a plain Java main() without Spring. Everything handlers need goes into one "application state" struct, wrapped in Arc (a thread-safe shared pointer) so all requests can share it:

@Repository
class PaymentRepo { PaymentRepo(DataSource ds) {...} }

@RestController
class PaymentController {
  private final PaymentRepo repo;
  PaymentController(PaymentRepo repo) { // injected
    this.repo = repo;
  }
}
// the container finds & wires these at startup

pub struct AppState {          // your "context"
    pub repo: PaymentRepo,
}

// in main(): wire it yourself, once
let pool  = PgPoolOptions::new().connect(&url).await?;
let state = Arc::new(AppState {
    repo: PaymentRepo::new(pool),
});
let app = http::router(state);  // handlers receive it

A handler asks for the state with the State extractor: State(state): State<Arc<AppState>>. For testability, define a trait (an interface) for the repository and generate a mock of it with mockall, the Mockito equivalent. This is the same "program to an interface" idea you already use in Java.

REST APIs: Spring MVC → axum

@RestController
@RequestMapping("/payments")
class PaymentController {

  @GetMapping("/{id}")
  Payment get(@PathVariable UUID id) {
    return repo.findById(id)
      .orElseThrow(NotFoundException::new);
  }

  @PostMapping
  Payment create(@RequestBody NewPayment body) {
    return repo.create(body);
  }
}

pub fn router(state: Arc<AppState>) -> Router {
    Router::new()
        .route("/payments", post(create_payment))
        .route("/payments/{id}", get(get_payment))
        .with_state(state)
}

async fn get_payment(
    State(state): State<Arc<AppState>>,
    Path(id): Path<Uuid>,
) -> Result<Json<Payment>, ApiError> {
    let p = state.repo.find(id).await?
                  .ok_or(ApiError::NotFound)?;
    Ok(Json(p))
}

Handler parameters are called extractors. They play the role of Spring's argument annotations, but they're plain types checked at compile time:

Global error handling (the @ControllerAdvice equivalent)

#[derive(Debug, thiserror::Error)]
pub enum ApiError {
    #[error("payment not found")]         NotFound,
    #[error("invalid request: {0}")]       BadRequest(String),
    #[error(transparent)]                   Database(#[from] sqlx::Error),
}

impl IntoResponse for ApiError {
    fn into_response(self) -> Response {
        let (status, message) = match &self {
            ApiError::NotFound      => (StatusCode::NOT_FOUND, self.to_string()),
            ApiError::BadRequest(_) => (StatusCode::BAD_REQUEST, self.to_string()),
            ApiError::Database(e)   => {
                tracing::error!(error = %e, "database error");  // log details…
                (StatusCode::INTERNAL_SERVER_ERROR, "internal error".to_string()) // …never leak them
            }
        };
        (status, Json(json!({ "error": message }))).into_response()
    }
}

The #[from] attribute lets ? automatically convert a sqlx::Error into ApiError::Database, the way a Spring DataAccessException bubbles up to the advice.

Configuration: application.yml & profiles

The config crate gives you Spring-style layering: a default file, a per-environment file, then environment variables override everything. The settings are deserialized into a typed struct, the equivalent of @ConfigurationProperties:

#[derive(Debug, Deserialize, Clone)]
pub struct Settings {
    pub server: Server,
    pub database: Database,
    pub kafka: Kafka,
}

impl Settings {
  /// default.toml → {APP_ENV}.toml → APP__* env
  pub fn load() -> Result<Self, ConfigError> {
    let env = std::env::var("APP_ENV")
        .unwrap_or_else(|_| "local".into());
    Config::builder()
      .add_source(File::with_name("config/default"))
      .add_source(File::with_name(&format!("config/{env}"))
                    .required(false))
      .add_source(Environment::with_prefix("APP")
                    .separator("__"))
      .build()?
      .try_deserialize()
  }
}

[server]
port = 8080

[database]
url = "postgres://app@localhost/payments"
max_connections = 10

[kafka]
brokers  = "localhost:9092"
group_id = "payments-svc"
topic    = "payment-events"

A missing or wrongly typed setting fails at startup with a clear error, the same as a bad @ConfigurationProperties binding.

Messaging: Spring Kafka → rdkafka

The standard Kafka client is rdkafka, a Rust wrapper around librdkafka, the battle-tested C library that also powers Confluent's Python, Go and .NET clients. Configuration keys are the same ones you know (bootstrap.servers, group.id, enable.auto.commit…). There's a pure-Rust alternative, rskafka, but it's minimal.

The big difference: there's no @KafkaListener container that manages threads, retries and acknowledgments for you. You write the consumer loop and run it as a background task:

@KafkaListener(topics = "payment-events",
               groupId = "payments-svc")
void onEvent(String payload, Acknowledgment ack) {
    handle(payload);
    ack.acknowledge();
}
// container: threads, polling, retries, DLT

pub async fn run_consumer(cfg: Kafka) -> anyhow::Result<()> {
    let consumer: StreamConsumer = ClientConfig::new()
        .set("bootstrap.servers", &cfg.brokers)
        .set("group.id", &cfg.group_id)
        .set("enable.auto.commit", "false")
        .create()?;
    consumer.subscribe(&[&cfg.topic])?;
    loop {
        let msg = consumer.recv().await?;
        let payload = msg.payload_view::<str>()
                         .transpose()?.unwrap_or_default();
        // handle(payload) ...
        consumer.commit_message(&msg, CommitMode::Async)?;
    }
}
// in main: tokio::spawn(run_consumer(cfg));

What you build yourself (or with small helper crates): retry/back-off (backon), dead-letter publishing (a FutureProducer to a DLT topic), Avro with Schema Registry (schema_registry_converter), and parallelism per partition (spawn tasks). There's no mature Rust equivalent of Kafka Streams.

Cloud & secrets: AWS, Azure, GCP, Vault

let aws = aws_config::load_from_env().await;
let s3  = aws_sdk_s3::Client::new(&aws);
s3.put_object()
    .bucket(bucket)
    .key(key)
    .body(ByteStream::from(bytes))
    .send()
    .await?;

let client = VaultClient::new(
    VaultClientSettingsBuilder::default()
        .address(env::var("VAULT_ADDR")?)
        .token(env::var("VAULT_TOKEN")?)  // never hard-code
        .build()?,
)?;
let creds: DbCredentials =
    vaultrs::kv2::read(&client, "secret", "payments/db").await?;

Cross-cutting concerns: the big map

Testing a service

Where Java's ecosystem still clearly wins

Be realistic when choosing Rust for a service:

• Oracle database: no driver as mature as ojdbc and no ORM support (details in chapter 13).
• Enterprise integration: SOAP/WS-Security, JMS/IBM MQ, Spring Integration / Camel, Spring Batch, XA/JTA distributed transactions. These are thin or absent.
• Kafka Streams and stateful stream processing libraries.
• Security framework: nothing as complete as Spring Security; you assemble it from pieces, and auth code needs careful review.
• Convention & hiring: every Spring app looks alike, while Rust services vary more between teams.

A common, pragmatic architecture is polyglot: keep integration-heavy services in Java/Spring, and use Rust for focused, performance- or cost-critical services (gateways, high-throughput consumers, low-latency APIs, CLIs), talking over REST, gRPC or Kafka.

13. Data access: JDBC, JdbcTemplate, JPA → Rust

The part of the stack you touch every day. Some things map one-to-one; some work quite differently. Both are covered here.

The layers you know, and their Rust counterparts

Seven things that work differently

1. There is no JDBC. Java's java.sql is a standard every vendor implements, so you can swap drivers. Rust has no such standard. Each database has its own driver crate with its own API. sqlx gives you one API for PostgreSQL, MySQL/MariaDB and SQLite; for anything else (Oracle, SQL Server) you use that database's crate directly.
2. Async by default. Every query is .await-ed. While a query waits for the database, the thread serves other requests instead of blocking, like WebFlux + R2DBC rather than classic JDBC. (Blocking drivers exist too; wrap them in tokio::task::spawn_blocking.)
3. The pool comes with the library. PgPool is your HikariDataSource. You create it once in main, it's cheap to clone, and you pass it around.
4. Row mapping is generated at compile time. #[derive(sqlx::FromRow)] writes the RowMapper for you, like BeanPropertyRowMapper but generated during compilation, so there's no reflection.
5. SQL can be verified at compile time. With the query! macros, a typo in a column name is a build error, not a BadSqlGrammarException in production (see below).
6. No persistence context. No Hibernate session, no lazy loading, no automatic dirty checking, no LazyInitializationException, and no hidden N+1 queries. What you query is what you get.
7. Transactions are explicit values. There's no @Transactional proxy. You hold a transaction object, run queries on it, and commit. If you don't commit (because of an error, an early return or a panic), it rolls back automatically when dropped.

JdbcTemplate ↔ sqlx, operation by operation

Every Rust snippet below is from the sample service built for this guide and compiles against sqlx 0.9.

@Repository
class PaymentRepo {
  private final JdbcTemplate jdbc;
  private static final RowMapper<Payment> MAPPER =
    (rs, i) -> new Payment(
      rs.getObject("id", UUID.class),
      rs.getBigDecimal("amount"),
      rs.getString("currency"),
      rs.getObject("created_at", OffsetDateTime.class));

  Optional<Payment> find(UUID id) {
    var list = jdbc.query(
      "SELECT id, amount, currency, created_at " +
      "FROM payments WHERE id = ?", MAPPER, id);
    return list.stream().findFirst();
  }

  long countByStatus(String status) {
    return jdbc.queryForObject(
      "SELECT count(*) FROM payments WHERE status = ?",
      Long.class, status);
  }

  int markSettled(UUID id) {
    return jdbc.update(
      "UPDATE payments SET status='SETTLED' WHERE id=?", id);
  }
}

#[derive(Debug, Serialize, sqlx::FromRow)]  // ← the RowMapper
pub struct Payment {
    pub id: Uuid,
    pub amount: Decimal,
    pub currency: String,
    pub created_at: DateTime<Utc>,
}

#[derive(Clone)]
pub struct PaymentRepo { pool: PgPool }

impl PaymentRepo {
  pub async fn find(&self, id: Uuid)
      -> sqlx::Result<Option<Payment>> {
    sqlx::query_as::<_, Payment>(
      "SELECT id, amount, currency, created_at
       FROM payments WHERE id = $1")
      .bind(id)
      .fetch_optional(&self.pool)
      .await
  }

  pub async fn count_by_status(&self, s: &str)
      -> sqlx::Result<i64> {
    sqlx::query_scalar(
      "SELECT count(*) FROM payments WHERE status = $1")
      .bind(s).fetch_one(&self.pool).await
  }

  pub async fn mark_settled(&self, id: Uuid)
      -> sqlx::Result<u64> {
    let r = sqlx::query(
      "UPDATE payments SET status='SETTLED' WHERE id=$1")
      .bind(id).execute(&self.pool).await?;
    Ok(r.rows_affected())
  }
}

Batch insert and streaming

// jdbcTemplate.batchUpdate("INSERT INTO tags ...", rows)  →  one multi-row INSERT
let mut qb: QueryBuilder<Postgres> = QueryBuilder::new("INSERT INTO tags (payment_id, tag) ");
qb.push_values(rows, |mut b, (id, tag)| { b.push_bind(id).push_bind(tag); });
qb.build().execute(pool).await?;

// jdbcTemplate.queryForStream(...)  →  rows arrive one at a time, constant memory
let mut rows = sqlx::query_as::<_, Payment>("SELECT id, amount, currency, created_at FROM payments")
    .fetch(pool);
while let Some(p) = rows.try_next().await? {
    // export p ...
}

Compile-time checked SQL: something Java doesn't have

sqlx's macros (query!, query_as!, query_scalar!) check your SQL against a real database schema while compiling. They verify table and column names, parameter types, result column types, and nullability (a nullable column must map to Option<T>).

This is the real compiler output from the sample service, with a typo in a column name:

error: error returned from database: column "currncy" does not exist
  --> src/jdbc_style.rs:60:5
   |
60 | /     sqlx::query_as!(
61 | |         Payment,
62 | |         "SELECT id, amount, currncy, created_at FROM payments WHERE id = $1",
63 | |         id
64 | |     )
   | |_____^

For CI, where there's no database, run cargo sqlx prepare (from cargo install sqlx-cli). It saves the query metadata into a .sqlx/ folder that you commit, and builds with SQLX_OFFLINE=true use it. The function forms (sqlx::query_as::<_, T>(..), used above) skip compile-time checking; use them for dynamic SQL.

Transactions: @Transactional vs explicit

@Transactional
public Payment create(NewPayment p) {
  Payment saved = repo.insert(p);
  audit.log(saved.id(), "CREATED");
  return saved;
}
// a proxy opens the tx before the call,
// commits after, rolls back on
// RuntimeException (not checked ones!)
// gotcha: self-invocation skips the proxy

pub async fn create(&self, p: &NewPayment)
    -> Result<Payment, sqlx::Error> {
  let mut tx = self.pool.begin().await?;
  let payment = sqlx::query_as::<_, Payment>(
      "INSERT INTO payments (id, amount, currency)
       VALUES ($1,$2,$3) RETURNING id, amount, currency, created_at")
    .bind(Uuid::new_v4()).bind(p.amount).bind(&p.currency)
    .fetch_one(&mut *tx).await?;      // ← on tx, not pool
  sqlx::query("INSERT INTO audit_log (payment_id, action)
               VALUES ($1, 'CREATED')")
    .bind(payment.id).execute(&mut *tx).await?;
  tx.commit().await?;                     // explicit commit
  Ok(payment)
}  // any `?` above returns early → tx dropped → ROLLBACK

ORMs: JPA, Hibernate and Spring Data → SeaORM and Diesel

@Entity @Table(name = "payments")
class Payment {
  @Id UUID id;
  BigDecimal amount;
  String currency;
  String status;
  OffsetDateTime createdAt;
}

interface PaymentRepo
    extends JpaRepository<Payment, UUID> {
  List<Payment> findByStatusOrderByCreatedAt(String s);
}

// usage
for (var p : repo.findByStatusOrderByCreatedAt("PENDING")) {
  p.setStatus("SETTLED");   // dirty checking
}                           // flushed at commit

#[derive(Clone, Debug, PartialEq, DeriveEntityModel)]
#[sea_orm(table_name = "payments")]
pub struct Model {
    #[sea_orm(primary_key, auto_increment = false)]
    pub id: Uuid,
    pub amount: Decimal,
    pub currency: String,
    pub status: String,
    pub created_at: DateTimeUtc,
}

// usage: no derived methods, build the query
let pending = payment::Entity::find()
    .filter(payment::Column::Status.eq("PENDING"))
    .order_by_asc(payment::Column::CreatedAt)
    .all(&db).await?;

for p in pending {
    let mut am: payment::ActiveModel = p.into();
    am.status = Set("SETTLED".to_owned()); // mark changed
    am.update(&db).await?;     // explicit UPDATE
}

SeaORM's ActiveModel tracks which fields you Set, so update writes only those columns. It's the closest thing to dirty checking, but it's explicit: nothing is flushed behind your back. SeaORM 2.0 (stable since July 2026) also adds an "entity-first" workflow where it can create tables from your entities, a bit like hibernate.ddl-auto.

Which one feels like what you use today?

Database drivers

Migrations: Flyway & Liquibase

let pool = PgPoolOptions::new().max_connections(10).connect(&url).await?;
sqlx::migrate!("./migrations").run(&pool).await?;   // applies migrations/2026…_create_payments.sql

14. Putting it together: a real service

A small "payments" microservice that combines the last two chapters: REST, PostgreSQL, migrations, Kafka, S3, Vault, config and JSON logging. It was built and run for this guide, and the outputs below are real.

Project layout

payments-svc/
├── Cargo.toml
├── config/
│   └── default.toml        # application.yml
├── migrations/
│   └── 2026…_create_payments.sql  # Flyway V1__
└── src/
    ├── main.rs        # @SpringBootApplication + wiring
    ├── config.rs      # @ConfigurationProperties
    ├── http.rs        # @RestController
    ├── error.rs       # @ControllerAdvice
    ├── repo.rs        # @Repository (sqlx)
    ├── jdbc_style.rs  # JdbcTemplate-style examples
    ├── kafka.rs       # @KafkaListener
    └── cloud.rs       # S3 + Vault clients

[dependencies]
tokio      = { version = "1", features = ["full"] }  # runtime
axum       = "0.8"                    # starter-web
tower-http = { version = "0.7", features = ["trace", "timeout"] }
serde      = { version = "1", features = ["derive"] } # Jackson
serde_json = "1"
sqlx = { version = "0.9", features = ["runtime-tokio",
  "postgres", "migrate", "macros", "uuid",
  "rust_decimal", "chrono"] }      # jdbc + Hikari + Flyway
uuid          = { version = "1", features = ["serde", "v4"] }
rust_decimal  = { version = "1", features = ["serde"] } # BigDecimal
chrono        = { version = "0.4", features = ["serde"] }
config        = "0.15"                 # application.yml
tracing       = "0.1"                  # SLF4J
tracing-subscriber = { version = "0.3", features = ["env-filter", "json"] }
thiserror     = "2"
anyhow        = "1"
futures-util  = "0.3"
rdkafka       = { version = "0.39", features = ["cmake-build"] } # spring-kafka
aws-config    = { version = "1", features = ["behavior-version-latest"] }
aws-sdk-s3    = "1"                    # spring-cloud-aws
vaultrs       = "0.8"                  # spring-cloud-vault

main.rs: the whole "application context"

pub struct AppState {
    pub repo: repo::PaymentRepo,
}

#[tokio::main]                                          // starts the async runtime
async fn main() -> anyhow::Result<()> {
    // 1. logging (like logback.xml): RUST_LOG=info,payments_svc=debug
    tracing_subscriber::fmt().with_env_filter(EnvFilter::from_default_env()).json().init();

    // 2. configuration (like application.yml + profiles)
    let settings = config::Settings::load()?;

    // 3. connection pool (like HikariCP) + migrations (like Flyway)
    let pool = PgPoolOptions::new()
        .max_connections(settings.database.max_connections)
        .connect(&settings.database.url)
        .await?;
    sqlx::migrate!("./migrations").run(&pool).await?;

    // 4. wire the "beans" by hand
    let state = Arc::new(AppState { repo: repo::PaymentRepo::new(pool) });

    // 5. background Kafka consumer, runs concurrently with the web server
    tokio::spawn(kafka::run_consumer(settings.kafka.clone()));

    // 6. HTTP server (like embedded Tomcat) with graceful shutdown
    let listener = tokio::net::TcpListener::bind(("0.0.0.0", settings.server.port)).await?;
    axum::serve(listener, http::router(state))
        .with_graceful_shutdown(async { tokio::signal::ctrl_c().await.ok(); })
        .await?;
    Ok(())
}

What happened when it ran

$ APP__DATABASE__URL=postgres://app:***@localhost/payments RUST_LOG=info ./payments-svc

$ curl localhost:8080/health
UP
$ curl -X POST localhost:8080/payments -d '{"amount":"125.50","currency":"EUR"}' -H 'content-type: application/json'
{"id":"1b4fa61e-…","amount":"125.5000","currency":"EUR","created_at":"2026-10-21T11:33:20.006238Z"}
$ curl localhost:8080/payments/1b4fa61e-…
{"id":"1b4fa61e-…","amount":"125.5000","currency":"EUR","created_at":"2026-10-21T11:33:20.006238Z"}
$ curl -X POST … -d '{"amount":"-5","currency":"EUR"}'
{"error":"invalid request: amount must be positive"}     # 400
$ curl localhost:8080/payments/00000000-0000-0000-0000-000000000000
{"error":"payment not found"}                            # 404
$ curl -X POST … -d '{"amount":"oops"}'
Failed to deserialize the JSON body into the target type: amount: invalid value: string "oops",
expected a Decimal type …                                # 422, rejected by the Json extractor

The migration was recorded in _sqlx_migrations, and the payment plus its audit row were committed in one transaction. With no Kafka broker running, the consumer logged structured JSON connection errors (from librdkafka) and the HTTP API was unaffected.

Shipping it in Docker

# ---- build stage: needs C toolchain for librdkafka ----
FROM rust:1-bookworm AS build
RUN apt-get update && apt-get install -y --no-install-recommends \
      cmake pkg-config libcurl4-openssl-dev libsasl2-dev libssl-dev zlib1g-dev
WORKDIR /app
COPY . .
ENV SQLX_OFFLINE=true                 # use committed .sqlx/ query cache, no DB at build time
RUN cargo build --release --locked   # --locked: fail if Cargo.lock would change

# ---- runtime stage: same Debian release as the build (glibc must match) ----
FROM debian:bookworm-slim
RUN useradd --system --uid 10001 app
COPY --from=build /app/target/release/payments-svc /usr/local/bin/
COPY config /config
WORKDIR /
USER app
ENTRYPOINT ["payments-svc"]
# secrets: inject APP__DATABASE__URL / VAULT_TOKEN at runtime, never bake them in

15. Zero → hero roadmap

A realistic path for an experienced Java developer, with time estimates assuming a few hours a week.

The best free resources

16. Java ↔ Rust cheat sheet

Print this table.

Numbers in this guide were measured on real projects built with rustc 1.97 on Linux x86-64: a cargo new hello world (binary sizes, startup time) and the chapter 14 payments service (axum 0.8, sqlx 0.9, SeaORM 2.0, rdkafka 0.39, aws-sdk-s3 1.x, vaultrs 0.8, run against PostgreSQL 16; crate count, build time, binary size, memory). Crate versions and maturity statuses were checked in October 2026. Re-check them on crates.io before choosing. Your exact numbers will differ by platform and version. Memory and performance comparisons are typical ranges, not guarantees; always measure your own workload.