Jolie is a programming language where a service is a first class thing

A language whose unit of design is the service

Jolie is a service-oriented programming language, designed to offer native abstractions for the development of microservices. That is the whole pitch, and it is more specific than it sounds.

Most languages treat a network service as a deployment concern. You write a class, you expose it over HTTP with a framework, you put a description of the endpoint in an IDL, and you write the deployment separately. Jolie starts from the other end. A service is the thing you are writing, and the abstractions the language offers are about services, so the interface is part of the program rather than a description of it.

The implementation is Java, and the repository is a full Java project with a pom.xml at the root. The tree shows the parts you would expect from a language implementation: jolie/ for the core, jolie-cli/ for the command line tool, libjolie/ and lib/ for the runtime libraries, extensions/ for the extension mechanism, javaServices/ for the JVM-hosted components, and include/ for the native headers.

The homepage is jolie-lang.org, and the documentation for programming with Jolie is at docs.jolie-lang.org, with the interpreter documentation held separately in the wiki. That split is itself informative. The language and how to write programs in it are documented in one place, and the runtime and its options in another, which is how a language with a real runtime behaves.

The interpreter, the CLI and the rest of the runtime

The repository layout describes a language with a runtime, not just a compiler.

There is jolie/ for the interpreter itself and jolie-cli/ for the command line front end. There is build-tools/ and release-tools/ and a scripts/ directory, which is the shape of a project that packages releases rather than just publishing source. There is a tools/ directory, a test/ directory, and a support/ directory.

Then there are the parts that tell you what kind of project this is. There is a packages/ directory, which is how Jolie distributes its standard library and add-on modules. There is a docker/ directory, and a .devcontainer/ directory, so there is a container path for development as well as for deployment. There is extensions/, which is a first class extension mechanism rather than a plugin bolted on. And there is a .licenserc.yaml alongside LICENSE and LICENSE.uri-libs.txt, which is a licence checker configuration, and the second licence file for the URI libraries suggests third party code with its own terms is vendored and tracked.

There is also a MAINTAINERS.md, which is a small signal about governance, and a .idea/ and .vscode/ directory, so contributors are expected to work in the two common Java IDEs. The lgtm.yml file is a configuration for the LGTM static analysis service, which dates the continuous integration setup, since .github/ workflows and the Java CI badge in the README are what run today.

Getting it and running it

The project does not put an install command in the README, and that is a deliberate choice rather than an omission. Installation instructions live on the project website, at jolie-lang.org/downloads.html, and the README points there.

So the first step for anyone evaluating Jolie is to read the website's installation page and the language documentation at docs.jolie-lang.org, then the interpreter documentation in the wiki, which covers the runtime itself rather than the language.

The README asks you to submit anything you have made in or for Jolie to the awesome Jolie list, a curated collection in a separate repository. That is a small but telling request, because it is the mechanism by which a small language finds its examples, and the examples are what a language needs most when its user base is not large.

The development environment is set up for containers, with a .devcontainer/ directory, and the project is packaged for Docker with a docker/ directory. For a language whose programs are services, a reproducible runtime environment matters more than it does for a library, since the runtime and the service deployment are the same thing.

One thing to plan for is that a Jolie program needs a Jolie runtime to run, so the deployment story is not a jar next to your application but an interpreter with your service loaded into it. The interpreter documentation is where that is described.

A roadmap, and two release lines moving independently

The project publishes a roadmap on GitHub, as a project board, and says you can check it to see what is staged for the next release. For a language with a small team, a public board is the main way to see whether the thing you need is coming.

The release history shows two lines moving at once. The listed releases are v1.12.8 dated 2026-03-01, then v1.13.4 and v1.13.3 both dated 2025-09-15. A 1.12 patch released after a 1.13 patch tells you that 1.12 is a maintenance line and 1.13 is the main line, and both receive fixes.

That pattern is common in a language with a stable core and an evolving one, and it has a practical consequence for adopters. You pin a minor version, you get security and bug fixes on that line, and the newer line is where new language features land. Whether that is a good deal depends on whether the features you want are language features or library features, because library features usually arrive as packages and can often be backported.

The last push was on 2026-08-26 and the repository is not archived. The project also has a Travis configuration in the root next to the GitHub workflows, and a Code of Conduct and a contribution guide, so the CI setup spans two generations of tooling.

How the community is organised

The project describes itself as an open source project based on community effort, and it is unusually explicit about the ways you can help.

Contributions and constructive discussions are always welcome, and the README says there are many ways to contribute, including coding, improving the documentation, helping out with newcomers, and even event organisation. Anyone interested should look at the contribution and organisation guide in CONTRIBUTING.md, and all interactions are expected to follow the code of conduct.

The contact channels are the GitHub repository itself, with discussion threads, issues and pull requests, and a Discord server for chat and audio or video calls.

This is worth reading as a signal about the project rather than as a list of links. A language whose documentation says helping newcomers and running events are contribution activities is trying to grow a community around itself, and for a language that competes with the dominant options in the JVM space, the community is the asset that cannot be imported from elsewhere.

It also shapes the risk assessment. A small community around a small language means the bus factor is low and the long term maintenance of your services written in it depends on a few people. The maintainers file in the repository is the concrete answer to that question, and reading it is the first step for anyone considering Jolie for production work.

Where Jolie is the wrong choice

There are clear cases against, and none of them are about the language design.

The first is the talent pool. Jolie is a niche language with a small community, and a service you write in it is a service you can only staff from that small community. For a hobby project, a research prototype, or a service that one or two people maintain, that is a reasonable price for a better way to express the architecture. For a product team that expects to hire and to survive a change of staff, it is a serious constraint, and no amount of language elegance removes it.

The second is the ecosystem. The standard library and the add-on modules live in the packages/ directory of this repository rather than in a public registry with thousands of packages, and the awesome Jolie list is the discovery mechanism for the community's own work. So the practical reality is that you will be writing more of the integration yourself than you would in a mainstream stack.

The third is the deployment model. A Jolie program is interpreted by the Jolie runtime, so the operational story is different from deploying a jar or a binary. That is not a defect, it is the design, but it means your monitoring, your packaging and your upgrade path are all Jolie specific, and the operational documentation is thinner than what a mainstream framework ships.

The alternative is to stay with a mainstream language and model the service boundary with a framework and an IDL, accepting that the interface lives in a separate artefact. If you have a large team and a long life ahead of the code, that trade is often the right one, and Jolie is most persuasive in exactly the opposite situation, where a handful of people need to express a service boundary precisely.

Editorial conclusion

Jolie fits a team designing a service boundary in code, where the interface, the deployment and the behaviour of a service are written in one place rather than split between a framework, an IDL and a deployment tool. It does not fit a team that needs broad hiring reach or a large package ecosystem, since the language is small, the community is small, and the licence is LGPL-2.1 with its own obligations for a distributed application. Before adopting it, read the documentation site and the interpreter documentation, check the roadmap for what is staged, and be honest about the trade, which is a more expressive way to write services in exchange for a much smaller talent pool.

Frequently asked questions

Official sources

1. jolie/jolie on GitHub
2. License: LGPL-2.1
3. Project website
4. README
5. Releases