Cats-Actors is a Cats Effect native actor library: typed messages, functional state, supervision, and the familiar ! operator, all in F[_].

What is new in this release:

- ControlledTestKit, a new trait in the cats-actors-testkit module. It

provisions an ActorSystem[IO] inside Cats Effect's TestControl and ticks the

simulated clock for you, so scheduled work and timeouts resolve without real

waiting. A one hour receive timeout is now an ordinary unit test that finishes

in milliseconds.

- Receive timeouts, the supervisor restart window and the dead letter mailbox

idle check now read Clock[F].monotonic instead of System.currentTimeMillis, so

they all honour simulated time.

- New TestKit assertions, expectMsgTypeCountN and expectMsgTypeSingle, which

count messages of a type and do not depend on when they arrive relative to

the call.

- Breaking: ActorSystem.uptime is now F[Long] rather than Long.

Scala 2.13 and 3, on JVM, Scala.js and Scala Native.

```

resolvers += "jitpack" at "https://jitpack.io"

libraryDependencies += "com.github.cloudmark.cats-actors" %%% "cats-actors" % "2.2.0"

libraryDependencies += "com.github.cloudmark.cats-actors" %%% "cats-actors-testkit" % "2.2.0" % Test

```

Write up: https://cloudmark.github.io/Cats-Actors-Controlling-Time/

Repo: https://github.com/cloudmark/cats-actors

Feedback and issues welcome.

ldbc v0.8.0 released — SQL injection fix under NO_BACKSLASH_ESCAPES, JDBC 4.3 enquote APIs, and sbt 2 support!

TL;DR: Pure Scala MySQL connector running on JVM, Scala.js, and Scala Native fixes a SQL injection in client-side prepared statements under the NO_BACKSLASH_ESCAPES sql_mode, adds the JDBC 4.3 enquote APIs, and cross-builds its codegen plugin for sbt 1 and sbt 2. Upgrading is recommended if you use the ldbc connector.

ldbc v0.8.0 is out. This is primarily a security release for our Pure Scala MySQL connector that works across JVM, Scala.js, and Scala Native platforms.

The headline of this release is a SQL injection fix for sessions running with NO_BACKSLASH_ESCAPES, alongside JDBC 4.3 enquote APIs and sbt 2 support for ldbc-plugin.

https://github.com/takapi327/ldbc/releases/tag/v0.8.0

Major Changes

🔒 SQL Injection under NO_BACKSLASH_ESCAPES

In 0.7.x and earlier, client-side prepared statements escaped string parameters with backslash escaping only (' → \') and never consulted the server sql_mode.

In a session running with NO_BACKSLASH_ESCAPES, a backslash is an ordinary character. \' therefore does not neutralize the quote, and a string parameter can break out of its literal.

// 0.7.x and earlier, in a session with sql_mode = 'NO_BACKSLASH_ESCAPES'
ps.setString(1, "zzz' OR 1=1 -- ")
// Rendered SQL: WHERE t.name = 'zzz\' OR 1=1 -- '
//            => (name = 'zzz\') OR 1=1  ... always true

Who is affected: the ldbc connector with useServerPrepStmts = false (the default), against a server or session with NO_BACKSLASH_ESCAPES enabled. The jdbc connector is not affected.

The fix has three parts:

• All escaping centralised in QueryRenderer — Parameter no longer exposes a SQL-text representation for strings, so a path that bypasses the sql_mode-aware logic cannot exist by construction
• Escaping follows the sql_mode — quote-doubling (' → '') when NO_BACKSLASH_ESCAPES is active, which is the only way to embed a quote such that it can never be consumed by a preceding backslash
• The sql_mode is tracked for the life of the session — seeded from the handshake status flags and updated from every OK/EOF packet, so a SET SESSION sql_mode = ... issued after connecting is picked up too

No user code changes are required.

🛡️ JDBC 4.3 enquote APIs

Following MySQL Connector/J 9.7.0 (WL #17215), four methods have been added to ldbc.sql.Statement for safely quoting values and identifiers when you assemble SQL as a string.

for
  stmt <- conn.createStatement()
  a    <- stmt.enquoteLiteral("G'Day")              // 'G''Day'
  b    <- stmt.enquoteIdentifier("my table", false) // `my table`
  c    <- stmt.enquoteIdentifier("user", true)      // `user`
  d    <- stmt.enquoteNCharLiteral("Hello")         // N'Hello'
  e    <- stmt.isSimpleIdentifier("user_name")      // true
  f    <- stmt.isSimpleIdentifier("select")         // false (reserved word)
yield ()

isSimpleIdentifier follows the MySQL rules: [0-9a-zA-Z$_] or extended characters (U+0080 and above), not all digits, at most 64 characters, and not a reserved word. When ANSI_QUOTES is enabled, the identifier quote character becomes " instead of \`.

Available on both Statement and PreparedStatement, for the ldbc connector as well as the jdbc connector. The existing ident() helper remains the right tool inside the sql interpolator.

🔧 sbt 2 Support for ldbc-plugin

ldbc-plugin is now cross-built for both sbt 1 and sbt 2 — artifacts for sbt 1 (Scala 2.12) and sbt 2 (Scala 3) are published side by side. The declaration is identical either way; sbt resolves the right artifact.

// project/plugins.sbt — the same for sbt 1.x and sbt 2.x
addSbtPlugin("io.github.takapi327" % "ldbc-plugin" % "0.8.0")

This was the goal set out for the 0.8.x series. Note that the ldbc build itself still runs on sbt 1, because sbt-typelevel has not been published for sbt 2 yet.

🪲 insert Column-Order Fix

The tuple overload of insert now goes through the entity mapping defined by the table's * projection.

userTable.insert((1L, "Alice", Some(20)))

Previously the tuple was cast onto the column encoder directly, so values could be inserted into the wrong columns whenever the field order of the model differed from the column order of the * projection. The change makes the result correct, but if you have such a table it is worth re-running your tests after upgrading.

📦 Dependency Updates

⚠️ Breaking Changes

Parameter is now sealed and no longer exposes sql

ldbc.connector.data.Parameter is now a sealed trait with one case class per type, and def sql: String has been removed. This is part of the SQL injection fix — rendering a string into a SQL literal depends on the sql_mode, so that representation was removed to leave QueryRenderer as the only route.

Custom Parameter implementations are no longer possible; use the factory methods such as Parameter.string(...). Code that read param.sql should use param.toString, which is a sql_mode-independent literal for display and diagnostics only — it must not be used to assemble SQL for execution.

params removed from SQLException

SQLException and its subclasses lost the params: SortedMap[Int, Parameter] argument, as did ERRPacket.toException. As a result, the OpenTelemetry attributes error.parameter.$i.type / error.parameter.$i.value and the "and the arguments were" section of exception messages are no longer emitted.

This closes the paths by which bound values could leak through exception messages and telemetry. If you build dashboards or alerts on those attributes, you are affected.

Four abstract methods added to Statement

The four enquote methods are abstract members of ldbc.sql.Statement. No impact if you use the connectors ldbc provides, but implementing Statement or PreparedStatement yourself will now fail to compile.

What has not changed

Deprecated APIs

The APIs deprecated in 0.7.0 remain available in 0.8.0 and will be removed in a future release.

Why ldbc?

• ✅ 100% Pure Scala — No JDBC dependency required
• ✅ True cross-platform — Single codebase for JVM, JS, and Native
• ✅ Fiber-native design — Built from the ground up for Cats Effect
• ✅ ZIO Integration — Complete ZIO ecosystem support
• ✅ First-class testability — Dedicated rollback and MUnit testing modules
• ✅ Production-ready observability — OpenTelemetry Semantic Conventions compliant
• ✅ Enterprise-ready — AWS Aurora IAM authentication support
• ✅ AI/ML ready — MySQL VECTOR type support
• ✅ Security-focused — sql_mode-aware parameter escaping and JDBC 4.3 enquote APIs
• ✅ sbt 1 & sbt 2 — Codegen plugin cross-built for both
• ✅ Migration-friendly — Easy upgrade path from 0.7.x

Links

• GitHub: https://github.com/takapi327/ldbc
• Documentation: https://takapi327.github.io/ldbc/
• Scaladex: https://index.scala-lang.org/takapi327/ldbc
• Migration Guide: https://takapi327.github.io/ldbc/latest/en/migration-notes.html

Quick question, how the heck you guys generate Scala code from OpenAPI specs?

I have been trying to generate client code for Meta business API using the Scala generators from openapi-generator but there is always a problem:

All of them, ignore the oneOf spec on openapi (that in theory should generate a sealed trait as the sum type implementation) and instead they generate a single case class with all fields required, nothing is optional.

What is the tool/strategy you guys use to generate API model from OpenAPI? At this point, i'm considering to generate the Scala code using an LLM instead of the classic deterministic approach.

Thanks 🙏

I wanted to share a project I built earlier this year. It is a distributed task scheduler for hybrid classical-quantum workflows in the quantum cloud. Throughout development I had various conversations with quantum hardware providers like IBM, who have shown interest in adopting bits and pieces of this into their production system, and thanks to generous support from Amazon, I am extending the scheduler to support direct FPGA-level coordination tailored to on-prem hybrid HPC clusters, as well as dynamic AWS resource allocation/release for long running quantum workflows. Developed fully in Scala using the Typelevel stack.

There is a 30 page accompanying paper coming (to be published, in review, a shorter version is up on quant-ph) for anyone interested in the details of the math behind this but an ultra simplified summary for those who aren't familiar with quantum: Essentially scheduling quantum tasks differ from scheduling classical tasks on a few fundamental points:

1) There are very few accessible quantum devices right now. This results in queue times that can often last up to 2-3 days. Due to various restrictions, today's quantum programs don't take more than 3-4 seconds. This means that sometimes you have to wait days to execute something that will take seconds.

2) Quantum programs are probabilistic by their nature. The probability of success not only depends on the device they are executed on but also when it is executed. A user program is mapped onto a quantum device's topology (not really same but think of it as like different memory registers) but each device component have vastly different error metrics for different functions that change throughout the day due to decay (negative) and recalibration (positive). Mapping a user program to the quantum device is NP-hard. Not only this, but there are a variety of different physical architectures for these devices, super conducting, neutral atoms, ion traps, photonic devices etc. While on the logical level, they look the same thanks to abstractions, the execution semantics are vastly different. One example is parallelism. While superconducting devices can execute multiple operations in parallel, ion traps are often sequential due to limited LIZ. Since qubits have limited life times, sequential execution and longer programs are exposed to larger error. Tl;dr is that a scheduler has to jointly optimize the makespan AND the fidelity (probability of success). Last but not least, because the underlying physics is different, all of these devices report different error metrics and expose different capabilities, which have to be unified by the scheduler.

3) Certain physical rules limit our scheduling capabilities. For example, entanglement and the no-cloning theorem prevents us from blindly cutting a program into smaller pieces and executing them individually. Same goes for task duplication. It is possible to cut the quantum programs however putting the results back together requires exponential classical post-processing work. So the scheduler needs to dynamically adjust when and how to deploy techniques like this based on the resource availability at the time. Balance the classical and quantum workloads.

Same goes for executing multiple tasks on a single Quantum Processing Unit. This is possible to do, but 1) because each component have different error characteristics, this increases the competition for high quality components 2) These programs can adversely interfere through effects such as measurement crosstalk and ruin each others' readings.

4) Quantum programs need to be generated by classical programs and results need to be read back into a classical program.

All of this becomes a thousand times more messy when you try to do distributed quantum computing. We do DQC through EPR pairs, a set of entangled qubits. Generating these is no easy process, and they have short lifetimes. This means that your pair needs to navigate the network, go into your QPU and execute within a time frame. This exposes a special type of synchronization barrier across nodes.

All this complexity is beyond what a programmer should be expected to endure, so I built qurator to heuristically make these complex decisions based on resources available. Currently has support for IBM, IonQ, IQM, AQT, QuEra, Rigetti and Pasqal quantum devices.

Hello!

I have been working on new minimalistic LSP for scala/java.

Works with multiple BSP servers, lazily started, reports diagnostics.

Go to def works based on semanticdb, falls back to source parsing.
JAR/JDK indexes are too loaded lazily.

Still a bit barebones but works good enough for day to day work.

Why?

Metals/Intellij can be very memory heavy, slow-ish, instable, at least in my experience. This is an attempt to improve on that. And we dont need that many features, especially in these agentic days.

Disclaimer: this is my first time implementing an LSP. :)

Contributions and feedback welcome!

I've been working on bringing shadcn-style components to Scala.js, and the first alpha of shadcn-scalajs is now available.

It's still early and there are many components and APIs I want to improve, but I'd love to get some feedback from people actually using Scala.js.

Demo: https://shadcn-scalajs.vercel.app

If you're building frontend apps with Scala.js, give it a try and let me know what you'd like to see next.

Unsure if this was already discussed here, but when working with Scala code, I'm wondering what tips & tricks people have for working with Scala or other JVM languages in general

For example, I can name the use of:

• cellar for quickly querying the APIs of JVM libraries.
• Metals MCP standalone (since v1.6.6); although, to be honest, I'm having a better time using IntelliJ IDEA's MCP server as it's been more reliable for me. LLM may need explicit instructions to perform IDE-like operations (e.g., renaming symbols).
• Using sbt in client mode, via sbt --client; this being the default in sbt 2.x, although here an issue is that sbt can leak memory, and LLM may need instructions to kill it if it becomes unresponsive.
• Activating available linting via sbt-tpolecat and WartRemover.

Can you share other Scala or JVM-specific tricks for minimizing costs or increasing performance?

Thanks,

sbt 1.13.0 and 2.0.7 are released with a fix for remote code execution vulnerability via BSP over TCP. Builds with the default serverConnectionType are not affected.

Are you working with MCP from a developer standpoint? Do you have some pain points, experiences?

Asking since some time ago I picked up chimp https://github.com/softwaremill/chimp a PoC of an MCP toolkit for Scala 3. It is gradually turning into a complete MCP SDK, supporting both server & client, both http & stdio, with integrations for Pekko, ZIO and ox in place. Main focus now is on conformance to the latest MCP protocol version.

I've created an sbt2-only port of it to unblock my personal projects and hopefully yours, since the original author has been inactive for a long time

You may find it on my github: https://github.com/grouzen/sbt2-explicit-dependencies

I was watching a really nice video related to effects from him, but then I saw a few comments on Reddit with mentions that he left the language. His GitHub is mostly Typescript now 🤔

I asked moderators about whether I can post this. They said yes, but if you feel different let us know.

---

We just added Scala support to Enola (open-source). A tool to maintain codebase quality for any Scala project

Most architectural problems start with a PR. The mistakes may not be obvious at the time, but without knowing, it carries architectural debt.

By the time the codebase feels wrong, it usually already is. That's what my co-founder and I saw. So we tackled it.. As best as we could 😄 The problem has only exacerbated with agentic development.

Enola is an open-source architectural quality gate that checks developers or agents changes as they happen. What do we measure?

Example of an output:

Architecture
  Pattern:             go-standard (95% confidence)
  cyclic dependencies         0
  layer violations            0

Impact analysis (hotspots)
  coupled modules            36
    high criticality         20
    medium criticality       16
  Top hotspots (by coupling):
    module                            fan-in  fan-out crit     blast radius
    internal/facts                       152        0 high     68
    pkg/bootstrap                          8       49 high     4
    pkg/command                            1       42 high     1
    internal/engine                        7       27 high     7

Code health
  deep dependency chains      8
    cmd/enola                                    depth 10
    pkg/command                                  depth 9
  complexity outliers        15
    internal/server.Server.registerTools         complexity 177

Now we are looking for feedback and contributors to improve Scala performance. If you work with Scala, run it against something real. I’d like to know what it misses and is it useful. The more messy the better.

https://github.com/enola-labs/enola (Fully local, Apache 2.0, installation takes 2 minutes).

Quafadas/vecxt is, I think now interesting enough to talk about (if you are interested in such things)...

Here are it's headlines;

Useability

• Pythonic sytnax - readable by default
• No given / implicit resolution, easy / fast compilation story.
• "simple" design choices. The vector concept is extension methods on Array- no type heirachy etc. Jump to definition takes you to the code you want to read, not an abstraction.
• Cross platform, most of the API is tested against a single cross platform test suite for JVM, JS, Native

Performance

Is where most the effort is invested, trying to get this right inside the constraints above...

• delegate to platform BLAS implementations where they exist. On macOS on the JVM, matmul JNI's into Accelerate... on Native, CBLAS.
• SIMD fast paths, wherever we can hit them (JVM only)
• layout abstraction inlines an indexing strategy that traverses the storage array monotonically in shortest possible hops (i.e. straight down the cache lines, and you don't have to think about it)
• It benchmarked well vs breeze on what I believe to be reasonably representative workloads (it is not a crushing victory maybe 20% faster, but at least comparable)

Memory

The core Matrix representation is a strided view over a single contiguous Array. That choice permeates the design:

• transpose is zero-copy
• submatrices/views are zero-copy
• striding/layout is explicit which is what enables the cache friendly algorithms

Many operations have in-place variants which mean you can opt out of nice syntax, and into allocation/control complexity where profiling says it matters.

Bytecode

This was the "silent killer" that made me nearly give up the project. I didn't appreciate it's significance for a long time, I only knew "something wasn't working". Eventually I realised that Intrinsification and JIT optimisation happen under surprisingly narrow conditions, and "just inline everything" can actually make things worse by producing methods that exceed a series of JIT limits / gates.

So vecxt now has CI checks around the bytecode it generates.

Among other things:

• method size is checked
• array operations are checked for bytecode patterns that can interfere with JVM specialisation / intrinsification

And yes, AI wrote the code

In recent months, 100% of the code has been written by AI.

My curiosity was in understanding the design concepts and constraints, I read the tests and investigated the generated bytecode/benchmark results.

The surface area of a numerical library like this is frankly too large for one person to maintain, and obviously so. Can it done with one person and an AI? Maybe... better would be more people and an AI :-). The process of using AI to explore and implement the ideas is a part of the journey - writing the code wasn't the goal for me.

I'm interested in criticism / discussion particularly from people interested in numerical computing and this domain. If someone does take the time to try it, don't be shy... whether the experience was good or bad...

Curious to hear VirtusLab & Databricks folks talking about this. It should be a huge improvement, and can solve a great chunk of the "Scala tooling" story we've been debating over the last few years.

A Scala Days talk, maybe?

zio-temporal — a fork of vitaliihonta/zio-temporal (a ZIO wrapper around Temporal's Java SDK) that's been diverging for a while now — just cut v1.0.0-RC2, and it's a big one.

Jackson is gone. The serialization layer is now built on zio-json instead of Jackson + reflection. That's the headline change, but the real point isn't "we swapped libraries" — it's what it buys you:

Compile-time codec safety. Under the old Jackson integration, a workflow/activity type without a registered Jackson module compiled fine and only failed at runtime — often as a workflow silently hanging on its first execute(). Every type crossing a workflow/activity/signal/query boundary now needs a ZTemporalCodec[T] (usually just derives JsonCodec on the case class), or your build doesn't compile. No more "forgot to register a Scala module" surprises.

Automatic codec registration. The first cut of the migration required manually chaining .addInterface[Workflow] calls into a CodecRegistry. That's gone too — as of RC2, calling ZWorker.addWorkflow[I], ZWorker.addActivityImplementation(...), or client.newWorkflowStub[I](...) (the calls you're already making) auto-registers that interface's codecs. For most workers/clients, derives JsonCodec on your domain types is now the entire migration — no CodecRegistry wiring at all.

A few other things worth knowing:

• Streaming encode: payloads are written directly into Protobuf's ByteString buffer via zio-json's Write bridge, skipping the intermediate String allocation the old reflection-based path required.
• Workflow history replay: histories already recorded under Jackson replay transparently for primitives and case classes. Sum types are the one exception — the JSON shape changed ({"type":"X",...} → {"X":{...}}), so any sealed trait reachable by an in-flight workflow needs @jsonDiscriminator("type") before you upgrade, or replay fails on the old payload. This is covered with a worked example (and the actual failure you'd see) in the migration guide, not just asserted.
• Scala 3 only.

Full migration guide, with every breaking change and worked examples: https://guizmaii-opensource.github.io/zio-temporal/docs/migration-1.0

It's still an RC — feedback, bug reports, and rough edges are exactly what we're looking for before the 1.0.0 final. Repo: https://github.com/guizmaii-opensource/zio-temporal

Apache Fory JSON is a high-performance JSON serialization framework for Java. It maps Java objects to and from standard JSON text and UTF-8 bytes.

In the published benchmarks, it reaches up to 10.91× Jackson’s throughput and 10.89× Gson’s in java-json-benchmark, and up to 5.55× and 10.00× respectively in the jvm-serializers MediaContent benchmark.

It supports JDK 8+, Android, and GraalVM Native Image. JDK17+ Record is also supported.

We’re looking for a Senior Data Engineer with strong Scala and Apache Spark experience to join an international project working with large-scale distributed data systems.

🌎 Location: Argentina
🏠 Modality: 100% Remote
🗣️ English: Upper-Intermediate / B2+
💻 Seniority: Senior

What we’re looking for:

• Strong professional experience with Scala
• Hands-on experience with Apache Spark
• Experience building and maintaining large-scale data pipelines
• Strong SQL skills
• Experience with distributed data processing
• Knowledge of ETL / ELT workflows
• Experience with Apache Kafka is a strong plus
• Comfortable communicating and collaborating in English

We’re especially interested in engineers who enjoy working hands-on with data-intensive systems, distributed architectures, performance optimization, and large datasets.

💬 Interested? Send me a DM with your CV/LinkedIn profile.

And if you know someone with a strong Scala + Spark background, referrals are very welcome! 🙌

I’ve always hoped Scala would find its place in the AI era.
I thought Scala had a lot of qualities that would make it particularly good for AI-generated code: strong type safety, functional programming, expressive types, and the ability to catch many mistakes at compile time.
But somehow, I hadn’t really thought about Kotlin.
A lot of companies already use Kotlin in production, and it has many of the same practical advantages: type safety, null safety, concise syntax, some functional programming features, and of course the huge Java ecosystem behind it.
That made me wonder if Kotlin might actually be better positioned than Scala for the AI era.
If AI writes more and more of our code, maybe languages with stronger type systems will have an advantage because the compiler can act as another layer of verification for AI-generated code. But if that’s true, ecosystem and adoption matter too — and Kotlin obviously has a big advantage there.
I still think Scala has some unique strengths, especially its type system and FP capabilities. But now I’m wondering whether I’ve been overlooking Kotlin.
What do you think? Does Scala have any particular advantage over Kotlin when it comes to AI-generated code?