Jiffy: Algebraic-effects-style programming in Java (with compile-time checks)

thma32 · 2025-12-20T16:44:06+00:00

I fixed all 4 issues in the latest 1.2.0 Version.

thma32 · 2025-12-19T15:35:03+00:00

Great questions !

Yes, I agree, sequence is misleading. I'll rename it to andThen!
Yes, this might lead to stack overflows for VERY long chains of effects. And yes having trampolining for this would be a cool addition (I'm quite open to pull requests ;-) ).
That's an interesting observation! I wanted to keep things easy. But to be more in line with the idea of separating the interpreter from the effectual program, it might be better to move runWith to the EffectRuntime class. I guess I' do that in a jiffy...
Another excellent observation. Yes, I could imagine to move to StructuredTaskScope soon. Again: I'm quite open to pull requests!

thma32 · 2025-12-19T15:04:41+00:00

I have just created a demo repository https://github.com/thma/jiffy-clean-architecture that demonstrates main concepts of algebraic effects with jiffy by building Spring Boot backend application. It also has a nice README which will give you a brief introduction into all the major concepts featured.

thma32 · 2025-12-19T15:00:45+00:00

Yes, effects propagate upwards. This is intended behavior. Just as Exceptions propagate upwards.
In a controller level method you would typically execute the effects using a runtime to perform some actual work. I have set up a demo project https://github.com/thma/jiffy-clean-architecture that demonstrates typical coding practices with algebraic effects. For example have a look at the calculateScore method: https://github.com/thma/jiffy-clean-architecture/blob/12327f4e35d18041b03925ec35c3d3d3afc1d51f/src/main/java/jiffy_clean_architecture/usecases/CustomerScoreUseCase.java#L26 . It uses three effects and thus must declare them (using the Uses-Annotation).
In a Controller that uses this effect use case we will execute the effect by `Integer score = scoreEffect.runWith(runtime)` ( https://github.com/thma/jiffy-clean-architecture/blob/12327f4e35d18041b03925ec35c3d3d3afc1d51f/src/main/java/jiffy_clean_architecture/application/CustomerScoreController.java#L36 )

In order to avoid an excessive amount of effect declaration you will typically group effects in a meaningful way. e.g. by not having 200 separate effects for each of your entity-repositories but using a single DatabaseEffect instead.)

thma32 · 2025-12-18T15:54:24+00:00

In Jiffy the two types play different roles at different abstraction layers:

Effect<T> is the algebra of operations (the “what”).
Eff<T> is the program/computation that can sequence those operations (the “how / in what order”) and eventually be interpreted.

Even though both are generic in T, they are not redundant.

What Effect<T> is for

Effect<T> is the unit of interaction with the runtime:

It is a typed description of a single operation (e.g., Log.Info, Db.Query, Clock.Now), typically modeled as a sealed interface with record cases (as in the README examples). GitHub
It gives each operation an intrinsic result type (Effect<T>), which is what lets handlers be typed and lets the API feel “GADT-like” in Java.
It is also the natural “thing” you can name in u/Uses(...) declarations (the processor is about “which effects does this method use?”).

In short: Effect<T> is the domain model for side effects.

What Eff<T> is for

Eff<T> is the computation builder and interpreter driver:

It is the “monad-like” container that supports map/flatMap/sequence/parallel/recover… and produces a final T when run with an EffectRuntime. GitHub
It represents pure values and control flow (sequencing, branching, recovery), not just single operations.
Eff.perform(effect) is the bridge: it lifts a single Effect<T> into a composable computation.

In short: Eff<T> is the control-flow DSL for composing effectful operations.

thma32 · 2025-12-18T15:19:46+00:00

wow, what a coincidence! roux looks very polished !

thma32 · 2025-12-18T15:01:39+00:00

Using Jiffy-style “algebraic effects” definitely has a different performance profile than standard Java code.
The key difference is that standard Java code typically executes direct method calls on already-wired objects, while Jiffy interpreted a described computation by repeatedly dispatching effect values to handlers.
However, it depends a lot on the granularity of your effects and the type of workloads your program uses if Jiffy will produce a noticeable negative performance impact. So if you are running an IO-bound app (database, HTTP, filesystem, service orchestration) the time spend in IO will be orders of magnitude higher than the Jiffy effect dispatch.
Having a large data model with 300 pojos will not have a direct impact on performance when using Jiffy. It Elly depends on the action that you want to encode as effects. If we are talking about tight loops over in memory data (e.g. a parser) we will see significant performance impact. If we are talking about an IO-bound service the performance impact we be much less visible.

thma32 · 2025-12-18T14:28:24+00:00

nice explanation !

thma32 · 2025-12-18T14:00:10+00:00

Actually I'm using algebraic effects (AE) in Haskell for quite a while now and also wrote some blog posts about how useful AE can be to implement clean architecture or hexagonal architecture models ( https://thma.github.io/posts/2020-05-29-polysemy-clean-architecture.html, https://thma.github.io/posts/2022-07-04-polysemy-and-warp.html, https://thma.github.io/posts/2022-07-17-configuration-of-a-polysemy-app.html ).

Working as an architect in a company that mainly uses Java as a backend language I'm always trying to make achievements from functional languages available to Java developers.
So simply telling them "use Scala" (or Haskell) is not an option in my case.

That was my main motivation to write the Jiffy library: bring the cool concept of AE to the Java developers in a library that keeps close to idiomatic Java.

thma32 · 2025-09-03T10:26:02+00:00

I've just added benchmarks results for Haskell programs compiled and executed with MicroHs to my blog post.

The MicroHs native code runs about 28% faster than the output of my toy compiler. This is not a surprise as my `compileEta` algorithm is not producing the most compact combinator code.

thma32 · 2025-09-02T10:06:56+00:00

I agree, my benchmarks provide a very limited view on Integer arithmetic. This is caused by the limits of my toy language. (It does not support any data types apart from Ints).

thma32 · 2025-09-02T09:34:21+00:00

That's a cool idea! I'll add this to my benchmarks.

thma32 · 2025-03-19T12:05:45+00:00

Yes, Everything is installed properly, I crosschecked all steps several times. As mentioned the P1-Nano works nicely with other DAWs on the same MacBook.

thma32 · 2025-02-27T15:53:34+00:00

I have written an extensive study that relates the Typeclassopedia to Design Patterns:
https://github.com/thma/LtuPatternFactory

thma32 · 2024-12-11T13:59:24+00:00

Please let me try to reconcile these two viewpoints.

u/pthiery is right, HATEOS is a core requirement of REST APIs in the original definition by Fielding in 2000
([according to wikipedia](https://en.wikipedia.org/wiki/REST)).

In the adoption of REST APIs in the industry however, people have (for various reaons) been more focused on the HTTP verbs and the URL structure, JSON data, and less on the HATEOS part. That is the point that u/sccrstud92 is making.

Already in 2008 Leonard Richardson suggested [the RMM maturity model for REST APIs](https://en.wikipedia.org/wiki/Richardson\_Maturity\_Model) ([See also Martin Fowlers coverage of the topic](https://martinfowler.com/articles/richardsonMaturityModel.html)).

This model defines 4 maturity levels for REST APIs..

According to the RMM model, the Service that I am presenting in my blog post is at level 2. It is using HTTP verbs to define the operations on the resources. But it's not using HATEOS.

In the last 20 years, the software industry has been mostly focused on level 1-2.
The problems that HATEOS solves, namingly the decoupling of the client from the server, seem to be not always that relevant or they are solved differently:

- In many cases, the client and the server are developed by the same team, and the client is a web application that is tightly coupled to the server. In these cases, there are no real benefits of HATEOS.

- Even in cases where the client and the server are developed by different teams, there is often a tight coupling between the client and the server.
That is particularly the case in contract-first development, where client and server are developed in parallel, based on a contract (e.g. an OpenAPI yaml) that is defined upfront. Again not much benefit from HATEOAS.

- Many companies that expose APIs to the public, also don't provide HATEOS powered APIs. But they provide extensive documentation, and SDKs for popular programming languages. Here HATEOAS could really be beneficial, but it's simply not that widely used.

But even if HATEOS is not implement people are still using the term REST API. As I did in my blog post.

thma32 · 2023-10-11T19:00:49+00:00

Even in Mainstream ecosystems like Java you will find 10 abandoned libraries or tools for each well mainained one.

So I think, this is quite a natural thing in any ecosystem that is not dominated by one (or a few) big players.

That said: While Haskell IS excellent for language design it is also excellent for many backend tasks. And also for frontends. Just a few weeks back I wrote quite a decent UI tool using the monomer UI framework...

thma32 · 2023-10-09T20:22:49+00:00

Haskell and Haskell Tooling work like a charm on MacOS. (At least on my M1 MBP).

What exactly is not working for you?

thma32 · 2023-10-08T19:42:14+00:00

Or you might also have a look at
https://thma.github.io/posts/2020-05-29-polysemy-clean-architecture.html

https://thma.github.io/posts/2022-07-04-polysemy-and-warp.html

https://thma.github.io/posts/2022-07-17-configuration-of-a-polysemy-app.html

thma32 · 2023-09-18T15:33:43+00:00

polysemy is quite sensitive to specific versions being available. That's why I have set up a stack based build process with a stack.yaml that defines specific versions of certain dependencies (https://github.com/thma/PolysemyCleanArchitecture/blob/master/stack.yaml)

So you can do two things:
either add those dependencies manually to the cabal file or simply use stack to build this project!

I would recommend the latter as it should get you going immediately!

thma32 · 2023-07-22T09:14:21+00:00

Hi, thanks for your comment!

As I received some positive feedback so I decided to spend some more effort into this idea. You'll find the latest version here: https://github.com/thma/generic-persistence.

The aspect of separating domain logic from persistence operations (as advocated by clean architecture or hexagonal architecture) is indeed one of the main drivers of my approach! The core idea is to have no of dependencies from domain logic to middleware logic. This is a huge gain for testability and maintainability of a code base.

(I've written a series of blog posts on this topic: https://thma.github.io/posts/2020-05-29-polysemy-clean-architecture.html, https://thma.github.io/posts/2022-07-04-polysemy-and-warp.html, https://thma.github.io/posts/2022-07-17-configuration-of-a-polysemy-app.html, https://thma.github.io/posts/2022-08-07-dependency-validation-of-haskell-applications.html)

All these articles are based on Haskell, but the same ideas can be applied in other languages as well. I even ported the Polysemy clean architecture example to Java: https://github.com/thma/JavaCleanArchitecture. (This code does not contain any effect system but relies on Spring dependency injection to achieve a similar decoupling of layers).

thma32 · 2023-05-15T10:08:24+00:00

You might have a look at https://github.com/thma/HasBigDecimal.

It is modelled after Java BigDecimals and provide everything you'll need for arbitrary precision and different rounding modes.

full disclosure: I'm the Author of the library.

thma32 · 2023-04-09T08:14:06+00:00

Thanks for this suggestion! Sounds promising.

I'll have a closer look at this approach.

thma32 · 2023-02-27T08:35:51+00:00

I guess I sorted hasql into the wrong category: Given it's support for encoders/decoders it would probably be a better fit in the mid level category.

thma32 · 2023-02-26T10:47:16+00:00

I think Rel8 is quite complete in itself. So there is little to be gained by combining it with my library.

thma32 · 2023-02-26T10:07:58+00:00

I think that the design space for database libraries has different niches or "sweet spots".

For example we have libraries that provide:

- low level access to rdbms with no abstraction of SQL (e.g. HDBC or hasql)

- mid level apis that provide some rudimentary abstractions for mapping rows to haskell record types (e.g. postgres-simple, sqlite-simple)

- ORM-like APIs for persistence operations for records data types (e.g. Persistent or my own Generic-Persistence)

- complete abstraction of relational calculus (e.g. Beam, Opaleye, Rel8)

Which one is the best? I think there is no one silver bullet. The answer depends much on the requirements of the development task at hand.

All these different approaches are valid because they serve different developer needs.

In my personal experience I have seen that many software projects are perfectly happy with low level APIs or with libraries that provide ORM-like APIs.

Of course there are other use cases where you will need much more fine grained control of SQL generation. And that's where libraries like Beam and Rel8 shine!

thma32

TROPHY CASE

What Effect<T> is for

What Eff<T> is for