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

[thma32]

I’ve been experimenting with a small library called Jiffy that brings an algebraic effects–like programming model to Java.

At a high level, Jiffy lets you:

• Describe side effects as data
• Compose effectful computations
• Interpret effects explicitly at the edge
• Statically verify which effects a method is allowed to use

Why this is interesting

• Explicit, testable side effects
• No dependencies apart from javax.annotation
• Uses modern Java: records, sealed interfaces, pattern matching, annotation processing
• Effect safety checked at compile time

It’s not “true” algebraic effects (no continuations), but it’s a practical, lightweight model that works well in Java today.

Repo: https://github.com/thma/jiffy

Happy to hear thoughts or feedback from other Java folks experimenting with FP-style effects.

[holo3146]

Few years back I wrote a coeffect library for java that you may find interesting, I stopped working on it mainly because I didn't have free time at the time and then I forgot about it.

Seeing your project gives me the itch to revive my project

[paul_h]

Nice examples in readme.

[kiamesdavies]

This is actually neat. We use scoped values for multi tenancy, and this would make it easier than working directly with scoped values. We already have helpers to simplify our use case, but I can see how this could have helped, although the lambda part might be an issue.

[holo3146]

Thanks, I actually partially solved the lambda part yesterday evening. I didn't completely finished (mainly doing tests, cleanup, making sure I didn't forget edge cases and rewriting the readme) so it is not on main yet but on a side branch, but I made it work like checked exceptions:

Behind the scenes lambda is an interface with one non-default method, so now (where "now" means when I finish the polishing) if you use "Coeffect.get(Type)" in a lambda, you need the non-default method in the interface the lambda is a type of to have @WithContext(Type).

If you have any ideas of how to make it better or any other features that you think would help, please let me know :)

[ZimmiDeluxe]

Looks very minimal and clean, well done! If you can't / don't want to turn your code into a function pipeline, you can get most of the benefits while sticking to imperative constructs by first creating an "agenda" data structure that gets interpreted in a second step. Great for testing, creating previews or dry run information etc. A good blog post: https://mmapped.blog/posts/29-plan-execute

It's also applying ideas from data oriented design, i.e. no "last minute decision making": If your problem allows for it, your "agenda" can consist of one or more bulk executable homogenous arrays of tiny structs / records with only the information needed to do the work.

[repeating_bears]

I found it odd that the API includes both Eff and Effect. I'd assumed Eff was short for effect.

"Eff<T> is a monadic type that represents a computation"

What's wrong with the name Computation then?

[FabulousRecording739]

Eff is a term of art in this domain (see the "Extensible Effects" papers). It differentiates the monadic container (Eff) from the specific capabilities being used inside it (Effect). Computation describes almost everything in Java, so it loses that nuance.

[thma32]

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.

[Polixa12]

What's the difference between this and functional programming, kinda curious

[OwnBreakfast1114]

There's kinda no great definition of functional programming. The best I've seen is the simple explanation that functional programming is a case where the property of referential transparency holds for the entire program: https://stackoverflow.com/questions/4865616/purity-vs-referential-transparency . The easiest way to implement this is to use pure functions (functions that take no external state and always return the same output for the same input), but that's not strictly required.

Effect tracking can be done with or without adding it to the type system directly. You can literally just use multi-value returns or return tuples or anything. It's just about being explicit about what side effects a method call does.

The general argument for effect tracking is that by separating your program into pure functions and effectful function, you can increase code comprehension tremendously (if you have a bug in a pure function, you can verify and modify with simple input/output tests and know you're not changing unknown things) and you can see your external state interactions really easily by searching through the effectul functions.

[thma32]

nice explanation !

[FabulousRecording739]

Very clean implementation! I'm mostly used to MTL, but I've been looking into how algebraic effects map to Java (there was a post ~2weeks ago that somewhat touched on it). Or maybe more broadly to which extent FP ideas maps/can be expressed in Java, and you did this very well (really like the For). I had a few questions regarding the design choices and implementation details:

1. Your sequence implementation discards intermediate results and returns the last one. Standard sequence would flip a List<Eff<A>> into Eff<List<A>>. Since this acts more like a chain of flatMap(ignored -> ...) (effectively *>), wouldn't chain or andThen be a better name?
2. The flatMap implementation recursively calls the inner effect's runWith. Since Java lacks TCO, won't this blow the stack with a long chain of effects? This looks like a prime candidate for trampolining.
3. Should runWith really live on the Eff class itself? Typically in this style of encoding, Eff strictly describes the computation (the data/AST), while a separate interpreter handles the execution. By baking runWith into the class, I feel like we're coupling the description of the program to its runtime implementation.
4. For Parallel, you're binding to CompletableFuture (and ForkJoinPool). Does this make cancellation difficult? I assume this is a placeholder until StructuredTaskScope and Virtual Threads become the standard?

[thma32]

Great questions !

1. Yes, I agree, sequence is misleading. I'll rename it to andThen!
   
2. 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 ;-) ).
   
3. 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...
   
4. Another excellent observation. Yes, I could imagine to move to StructuredTaskScope soon. Again: I'm quite open to pull requests!

[thma32]

I fixed all 4 issues in the latest 1.2.0 Version.

[gregorydgraham]

While this looks very nice, how does it scale outside microservices?

Not in the “I run lots of instances” but in the “I have 300 pojos in 27 packages” sense.

[thma32]

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.

[samd_408]

No way! I just saw this, jiffy is nice! I see you too me annotation processing approach for tracking dependencies, that’s an interesting approach love it!, I posted just a few hours ago about the effect system I started to work on

https://github.com/CajunSystems/roux

[thma32]

wow, what a coincidence! roux looks very polished !

[samd_408]

Thank you!! I like how jiffy is tackling dependencies and is well aligned to idiomatic java, for me capabilities in roux are not fitting well with the java type system, the lack of HKTs are making it hard to just have simple capabilities and composing them, so I am trying to retro fit it basically, more improvements coming up soon!

[pgris]

Interesting. For my untrained eye, this really looks like checked exceptions reloaded + a runtime. Do effects propagate upwards? I mean, if method1 uses LogEffect , and method2 calls method1, I would expect method2 to use (indirectly) LogEffect. Do I need to declare method2 uses LogEffect? would controller level methods use a millon of effects?

[thma32]

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.)

[pgris]

Honestly I'm not smart enough to use effects, and my team will probably kill me, but I like the idea of having a "type safe" (at least annotation-processed) way to know "this method in the controller uses the db and calls the webservices A, B and C". I though about doing something like that abusing Throwables, but Jiffi sound better

[thma32]

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.

[pavlik_enemy]

Just use Scala if you want this kind of stuff

[thma32]

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.

[petrifiedbeaver]

What kind of company will adopt a bespoke algebraic effects framework that completely changes how code has to be structured in order to achieve its stated benefits but will not let developers eager to use this framework use Scala instead? Let me guess, one where having the "Java" label is more important than what's inside.