Euro-Office looks like it could break that stalemate: a fork of OnlyOffice’s modern codebase, but under European governance, with genuinely open development. I run my own Nextcloud instance and I’m looking forward to integrating it once it reaches a stable release.

But excitement is cheap. The interesting question is whether the engineering behind Euro-Office is actually solid, or whether this is just sovereignty theatre — a press release with a GitHub link. To find out, I cloned four of Euro-Office’s repositories¹, read the documentation and README files, and went through the commit logs line by line. What started as a quick look grew into one of my longest articles yet — there turned out to be a lot to say. What follows is based on that primary-source review, supplemented by the project’s public statements and third-party reporting.

Why This Matters

I’ve wanted Europe — and Germany in particular — to become more independent in the IT sector for a long time. Not out of protectionism, but because depending on a handful of US vendors for the most basic tools of daily work — writing a document, editing a spreadsheet, collaborating on a presentation — is a structural vulnerability that can be weaponised at any moment. This isn’t hypothetical: when the Trump administration sanctioned the International Criminal Court, Microsoft shut down the ICC chief prosecutor’s email account². A court based in The Hague, central to Europe’s legal order, lost access to its own communications because a vendor in Redmond flipped a switch. The ICC has since announced it will move to openDesk². That incident alone should have been a wake-up call for every European institution still running on US-hosted productivity software.

The legal picture is equally uncomfortable. Under the US CLOUD Act and FISA Section 702, US-controlled cloud providers can be compelled to hand over European data — even if it’s stored on European soil — without notifying the data subject or any European authority³. Under oath before the French Senate in June 2025, Microsoft’s legal chief for France admitted that he could not guarantee French data would never be transferred to the US government⁴. The same conclusion has been reached at the EU level: the European Data Protection Supervisor found that the European Commission itself violated its own data protection regulations by using Microsoft 365⁵.

I have to ask: how is any of this still GDPR-compliant? Microsoft’s own lawyer cannot guarantee that European data stays in Europe. US law explicitly empowers US agencies to access it without European knowledge or consent. The EDPS has found the Commission itself in violation. And yet Microsoft 365 remains the default across most of European government and industry. Did no one pick this up? Or are we simply too dependent — too scared — to act on what we already know?

It seems, though, that the tide is finally turning. On 18 March 2026, Germany’s IT-Planungsrat — the federal-state coordination body for government IT — adopted the Deutschland-Stack decision (B-2026/03-IT)⁶, which defines binding standards for all federal, state, and municipal digital infrastructure. The accompanying standards annex explicitly lists ODF (Open Document Format) and PDF/UA as mandatory document formats⁷. This isn’t a suggestion; it’s a binding resolution across all levels of German government.

Within Germany, the movement started at the state level. Schleswig-Holstein — the northernmost Bundesland — has migrated 80% of its 30,000 government workplaces to Linux and LibreOffice, and expects to save over €15 million in licence fees that would otherwise go to Microsoft’s upcoming price increases². With the Deutschland-Stack decision, that ambition has now reached the federal level as binding policy for all of Bund, Länder, and Kommunen.

But this is no longer just a German story. Denmark’s Ministry of Digital Affairs has announced that all its employees will work with Linux and LibreOffice instead of Microsoft². France, following the Senate testimony, announced in April 2026 that it would replace Microsoft on all government desktops with Linux⁴. The Netherlands’ municipality of Amsterdam has published a ten-year Digital Autonomy Strategy targeting full sovereignty by 2035². Austria has launched its own sovereignty initiative under the Digital Austria Act 2.0². And at the EU level, the European Commission awarded a €180 million tender for sovereign cloud services to European companies⁸. As Thierry Carrez, general manager of Linux Foundation Europe, put it at KubeCon Europe 2026, the sovereignty conversation is now “happening at all levels of the stack”⁹.

What was once a personal conviction is now a procurement requirement — and that means there’s suddenly real demand for a credible European office suite that can actually deliver.

What Euro-Office Is

Euro-Office was announced on 27 March 2026 at a press event in Berlin¹⁰. It is a fork of OnlyOffice — specifically of OnlyOffice’s AGPL-licensed document editing engine — placed under European governance and open development. The coalition chose to fork OnlyOffice rather than build on LibreOffice/Collabora, explicitly citing OnlyOffice’s more modern architecture and superior browser performance compared to LibreOffice’s aging codebase¹¹.

The backing coalition is substantive: IONOS, Nextcloud, XWiki, OpenProject, Soverin, Abilian, BTactic, and EuroStack¹⁰. Proton is also involved¹². Both IONOS and Nextcloud have committed to hiring double-digit numbers of developers each for Euro-Office¹¹. That represents serious, sustained funding — not a press-release-and-forget play.

Architecturally, Euro-Office is an integration component, not a standalone product. It handles document editing — word processing, spreadsheets, presentations, and PDF — but storage, navigation, permissions, and sharing must be provided by a host platform: Nextcloud Hub, Proton Drive, Seafile, XWiki, OpenProject, or others¹³. The fact that it works independently of Nextcloud¹⁴ is important: it means the project isn’t captive to a single integrator’s roadmap.

As of the 22 April update, the project has a published roadmap, a governance model, and a contribution process¹⁵. The governance follows a “who codes, decides” principle with consensus-based decision-making among project members¹⁵. Regular contributors are added by consensus after sustained contribution (roughly 3–6 merged PRs over a few months). A Code of Conduct based on the Contributor Covenant is in place¹³. This is lightweight, but appropriate for the current stage — formalising too early kills momentum in young open-source projects.

So: real companies, real money, real governance. A published roadmap with a stable 1.0 targeted for summer 2026¹⁶. But roadmaps are cheap too. The question is whether the actual engineering matches the ambition — and whether the project can navigate the political noise that has surrounded it since launch.

The Licence Dispute, Briefly

Unfortunately, the waters around Euro-Office have been muddied by a licensing dispute with OnlyOffice that has attracted more attention than the actual engineering.

OnlyOffice is licensed under the GNU Affero General Public License v3 (AGPLv3), which explicitly grants the right to fork, modify, and redistribute. OnlyOffice has, however, added an additional clause under Section 7 §3(b) requiring preservation of their branding and logos. This is where the dispute lies.

Euro-Office’s position is that they are attributing correctly. The Ascensio credit appears in the theming config, in the codebase, and on the About screens for both desktop and mobile — the engineering details are covered in the theming section below¹⁷. Nextcloud has published a detailed legal analysis arguing that the Section 7 additions are non-obligatory under the AGPL¹⁸. The Euro-Office community has also published a detailed account of the changes they’ve made to ensure licence compliance, including restoring mobile editing that OnlyOffice had artificially disabled and cleaning up the DesktopEditors dual-licence to pure AGPLv3¹⁹.

OnlyOffice disputes this. They have publicly stated that Euro-Office constitutes “an evident and material violation of ONLYOFFICE licensing terms”²⁰ and suspended their eight-year partnership with Nextcloud over the fork²⁰. They argue that the additional branding terms cannot be separated from the main licence.

I am not a lawyer and cannot judge the legal merits of either side. What I can say is that from my limited understanding, Euro-Office appears to be making a good-faith effort to properly attribute: the Ascensio credit is in the code, in the config, and on the About screens. The AGPL grants forking rights. Whether the Section 7 branding clause survives a fork is ultimately a legal question that may or may not be tested in court. But the fork itself is not a violation of open-source norms — it is the norm. That’s how the AGPL works.

Enough about lawyers. Let’s look at the code.

What the Commit Log Shows

The GitHub organisation hosts ~15 repositories covering the full stack¹³: DocumentServer (orchestration, Docker builds, CI), core (C++ conversion engine), sdkjs (JavaScript editing SDK), web-apps (frontend UI), a Nextcloud integration app, DesktopEditors, desktop-apps, and supporting repos for dictionaries, fonts, document formats, and templates. A working Docker image is available²¹:

docker pull ghcr.io/euro-office/documentserver:latest

This is a deployable document server, not a placeholder. The DocumentServer repo alone has over 300 commits on main. All key repos show commit activity through late April / early May 2026.

The commit log reveals several distinct work streams, each visible as clusters of commits.

1. Automated Licence Stripping (DocumentServer, 26 March)

The single largest cluster of early commits — at least ten — built a GitHub Actions workflow that automatically strips the AGPL Section 7(b) trademark clause from all copyright headers after upstream merges (a0f7c65, ca65168, 5674745, 1a14462, among others). The iteration is telling: they refined edge cases around blank-line handling, commit message formatting, a check-mode-first safety step, and making the merge optional. A revert (6c0d308) and subsequent re-approach shows real engineering discipline — they broke something, backed out, and fixed it properly.

This is the foundational infrastructure for staying mergeable with upstream while maintaining their own licence posture. Getting it right early was the correct priority.

2. Build System Overhaul (DocumentServer + core, 28–31 March)

The C++ dependency management was switched from Conan to vcpkg (7873c20). Docker builds were restructured around docker buildx bake for reproducible multi-stage builds (f04a1a4). A .deb/.rpm packaging pipeline was added (8136765, 9bbd9f7), along with Vagrant VMs for Ubuntu 24.04, Debian 12, and Rocky Linux 9 to smoke-test produced packages²². There are numerous fix commits wrestling with registry URLs, caching, and workflow files (b6992c9, 71168a4, dcc0114, among others) — classic “getting CI green” work that anyone who has set up a non-trivial build pipeline will recognise.

OnlyOffice’s build process was one of the core grievances that motivated the fork: their README describes it as “unreliable, outdated or just plain broken”¹³, with binary blobs and compiled/obfuscated code. The commit log shows Euro-Office is doing the work to fix this systematically.

3. ARM64 Support (core, 31 March – 2 April)

V8 and Boost were rebuilt for ARM64 (1725c2b). Emscripten was updated for ARM compatibility (5057738). Architecture-aware vcpkg triplets were introduced (f320bdf). The web-apps build skips imagemin on ARM64 since its native binaries are x86_64-only²³. There is no GHCR ARM64 image yet — ARM users must build locally — but the groundwork is laid.

4. WASM / Emscripten (core, 28 March – 16 April)

Multiple commits address WebAssembly builds: fixes to DrawingFile and general layout (52518f8), the V8 build process (ad832ca), and a notable fix deferring FreeType function bindings until onRuntimeInitialized (146975f). This is browser-side rendering work. If mature, it would reduce the heavy server-side load that has always been Collabora Online’s architectural weakness — and it would be a significant differentiator.

5. Rebranding and Theming (web-apps, 19 March – 22 April)

Icons were shifted from PNG to SVG (5cd4c4e, d863b5b, 3c81545), including dark-theme variants. A theming system was introduced with config.json as single source of truth for brand values¹⁷ — company name, publisher URLs, logo filenames, and an attribution line reading "Euro-Office was based on ONLYOFFICE by Ascensio System SIA". Two build pipelines consume the theme: Grunt for desktop (using `` token replacement) and webpack for mobile (using DefinePlugin constants and LESS globalVars). Hard-coded relative paths in build JSON files were replaced with a $BUILD_ROOT variable so the build works regardless of checkout location¹⁷. About screens were updated with Euro-Office logos and Ascensio attribution on both desktop and mobile (a8dd610, fbd8acc, 4d5e670, cfdf091).

This is proper fork infrastructure — making the codebase brandable and buildable by anyone, not just the original vendor.

6. Nextcloud Integration Modernisation (eurooffice-nextcloud, 28 February – 27 April)

This repo reveals that preparation started a full month before the public announcement. In late February, the frontend build was migrated from webpack to Vite (c83a59b), Vue and @nextcloud/vue were updated to v3+ (323f6ac), and raw-loader was removed (ed84cc0). In early March, a PHP refactoring pass improved type coverage (272c9b1), converted switch statements to match expressions (414b549), and removed redundant use statements (ad68ba6). PHP 8.4.x support was extended (909d027). Bug fixes addressed regex metacharacter escaping in MIME type handling (e182df8), file lookup error handling (6c8114b), and user ID prefix stripping (09e6dc9). Rebranding and repackaging for krankerl (Nextcloud app store tooling) followed on 26 March (8131218, 8de6d6d, cc4ac99).

This was not a spontaneous fork. The Nextcloud integration was being quietly modernised and prepared for weeks before the Berlin launch.

7. Upstream Sync (web-apps, 10–17 March)

Two merge commits pull in OnlyOffice upstream changes from December 2025 (868b36a) and March 2026 (39110cb). An upstream CI file that attempted to use AWS was removed (022e602). This confirms active tracking of upstream — they’re not just forking and walking away.

8. Mobile Dev Workflow (DocumentServer, 17–21 April)

Mobile dev mode was made independent (0e075de). Trusted domains were updated for Android development (d624d5f, e134fcb). A make mobile target was added with automatic LAN IP detection for off-desktop testing²³. Documentation was updated accordingly (2b18260).

9. Governance and Contribution Docs (DocumentServer, 20–22 April)

CONTRIBUTING.md was written and refined across multiple commits (598141c, fdb545b, 4d3145d, 5e4e087). A CODEOWNERS file was added for the server team (9540d86). An attributions file was introduced (e6b9bf8). Coding guidelines were published.

10. Testing (core, 1 April)

An ODT conversion test snapshot was updated for Japanese AIUEO numbering format (03fcc6a) — evidence that automated conversion and rendering tests are being maintained, not just inherited and ignored.

Assessment

Five weeks in, for a fork of a complex codebase, this is about as good as you could reasonably hope for. The commit log tells the story of a team doing the right things in the right order: licence automation first, build reproducibility second, ARM and WASM groundwork third, branding and theming fourth, governance and contribution docs fifth. The Nextcloud integration work predating the public launch by a month shows planning, not improvisation. The stable 1.0 is targeted for summer 2026¹⁶ — and given they’re building on a mature, already-functional codebase rather than starting from scratch, the timeline is plausible, though “summer” is doing some heavy lifting.

That said, several open questions will determine whether Euro-Office becomes a serious contender or just another well-intentioned European initiative that fizzles out.

ODF as native format. The Document Foundation published a pointed response noting that the original Euro-Office press release didn’t mention ODF even once²⁴, and asking whether ODF will be the native format. That’s a legitimate architectural question: if Euro-Office inherits OnlyOffice’s OOXML-first posture, it’s sovereign in governance but still format-dependent on Microsoft’s specification. As discussed above, the Deutschland-Stack standards already mandate ODF for all German government IT⁷ — any office suite that wants to serve the European public sector needs ODF not just as a supported export option, but as a first-class citizen. The latest Nextcloud update lists “full ODF support” as a roadmap priority¹⁵, which suggests they heard the criticism. But whether ODF becomes the native default or just a well-supported secondary format is an open question that will matter for procurement decisions across Europe.

Upstream tracking vs. divergence. The commit log shows two upstream merges from OnlyOffice so far — December 2025 and March 2026 changes pulled into web-apps. That’s a healthy sign early on. But as Euro-Office accumulates its own changes — the theming system, the build overhaul, the licence stripping automation — merging upstream will get progressively harder. At some point, they’ll need to decide whether to track upstream closely or diverge intentionally. Both are viable strategies, but the choice will shape the project’s long-term character.

Governance scaling. The current “who codes, decides” model works for a founding coalition of a dozen organisations. It won’t work at fifty. As the contributor base grows — and it will need to grow if the project is to deliver on its ambitions — the governance will need to formalise without becoming bureaucratic. The early signs are positive (CONTRIBUTING.md, CODEOWNERS, Code of Conduct), but this is a problem that only gets harder with success.

WASM maturity. The browser-side rendering work via WebAssembly is potentially the most significant technical differentiator Euro-Office could offer. If the WASM path matures, it would shift rendering from the server to the client — fundamentally changing the economics of deployment and addressing Collabora’s biggest architectural weakness. The commit log shows active work here, but it’s clearly still early.

The commit log doesn’t resolve these questions. But it does show that real engineers are doing real work, with real money behind them, and that the work so far has been competent and well-prioritised. That’s more than most forks can show at five weeks.

What makes me genuinely hopeful is not just Euro-Office itself, but what it represents. For years, European digital sovereignty has been something people talked about at conferences and wrote into strategy papers, but the actual tools lagged behind the rhetoric. Now, for the first time, there’s a concrete, funded, technically credible effort to build an office suite that Europe can truly call its own — not just in governance, but in code. If Euro-Office delivers on its promise, it won’t just be a replacement for one piece of software. It will be a proof of concept that Europe can build and maintain critical digital infrastructure independently, from the document layer all the way up. That’s the real prize.

I’ll be revisiting this when 1.0 lands — and I’ll be hoping to deploy it on my own Nextcloud shortly after.

Methodology: Repositories were cloned on 3 May 2026 using git clone --depth (30–100 commits per repo). I reviewed the commit messages, dates, and authors — not the actual source code diffs. For each commit, I categorised it by topic (licence stripping, build system, ARM64, WASM, theming, etc.), then summarised the topic clusters into the work streams described above. README files, build documentation (build/), and developer documentation (develop/) were read directly from the cloned repositories. External sources were consulted for coalition, governance, and roadmap context.

We currently see another big shift in how software is written unfolding before our eyes. AI-assisted code co-piloting is the newest variation of automation and code-completion that is aimed at making software development easier. Compared to traditional approaches, which used static analysis and the languages scoping rules together with hand-crafted templates, these tools leverage the power of Large Language Models (LLMs) which have been fine-tuned to provide code completion. A major contender in this space is GitHub Copilot.

In this article, I wish to review a couple of research papers of the last three years to highlight the chances, but also the risks of those technologies and ask: Quo vadis? Where will the field of software development head in the near future, and what do we need to take care of so that this becomes a success story and not a gigantic money pit?

There are three papers in the last few years that truly stand out, and together form a somewhat concerning view on the wide-spread use of AI to write computer-assisted code. The three papers are

• Existence of Stack Overflow Vulnerabilities in Well-known Open Source Projects (2019) by Md. Masudur Rahman and B M Mainul Hossain ¹
• Do Users Write More Insecure Code with AI Assistants? (2022) by Neil Perry, Megha Srivastava, Deepak Kumar and Dan Boneh ²
• The Curse of Recursion: Training on Generated Data Makes Models Forget (2023) by Ilia Shumailov, Zakhar Shumaylov, Yiren Zhao, Yarin Gal, Nicolas Papernot and Ross Anderson ³

Lets begin with the second paper ², which posits the question “Do Users Write More Insecure Code with AI Assistants?”. Unfortunately, the paper can be summarized with a single word: Yes. But it also highlights some more truly concerning facts about AI and LLMs.

Current research on verification of LLMs has led to the notion of “trustworthy AI” and “explainable AI”. The thought was that with explanations, LLMs can become more than just black-boxes that we somehow have to trust to give us the right answers. Being neural networks (NNs), LLMs are just probabilistic models that produce plausible text. They have no notion of knowledge or correctness and can give hilariously wrong results that sound plausible. Especially with ChatGPT, there is a great danger in being overly confident in the output, because ChatGPT is trained to be conversational in tone, but also confident in what it says. Common wisdom under professionals nowadays is to only use LLMs like ChatGPT when one is able to verify the correctness of the output. That this is needed and warranted is highlighted by the very study quoted above. But lets dig into that a bit more, and look at why even getting good explanations cannot increase the confidence in the AI or make AI systems trustworthy.

What the study shows is that humans tend to be more critical of explanations if they perceive themselves as being knowledgeable of a topic, even to the point of being overly critic and not trusting the explanation. However, the study also shows that the less knowledgeable humans are about a topic, the more likely they are to trust any given explanation – even if that explanation is completely and utterly wrong. The study is fascinating in how they generated and presented these fake explanations and how those were received by non-experts (in this case, they used pictures of bids and their classification as well as three groups of people – professional ornithologists, hobby bird watchers and people without any background in birds). In my opinion, this leads to the very interesting possibility of an explanation attack, where LLMs might be trained to maliciously give wrong explanations and guide users towards actions they would otherwise not have undertaken.

Thus, we see that not even explainable AI might be enough to ensure good quality of the code or make the AI trustworthy. But lets assume for a moment that the AI is trustworthy in the sense that is has not been manipulated, but is actually trained to make a best effort to provide high-quality code along with explanations of this code. How does it get the training data?

Lets face it, most code out there in the real world isn’t of the highest quality, most is just average, and as much code below average as above average. Training a model on the real code that is out there will just give us average results. So lets identify high-quality code along with good explanations of the code and train it on that. Stack Overflow has become the de-facto source of information for professional software developers and hobbyists alike, with about 21 millions questions already asked and most of them answered. As of Sept. 2023, during the week it has about 6k - 7.5k questions asked per day and goes down to about 4k on the weekend, highlighting the fact that it is much used by professionals during their work week ⁴. Suffice to say, SO is an influential source for professional software developers.

However, it is not free of errors. In fact, if we look at the first paper ¹, we can see that there are several highly ranked questions that do have security issues. These are widely copied over into open-source libraries, and it stands to reason that this flawed code has also found entry into many closed-source / proprietary computer programs.

This highlights two important issues, especially together with the study quoted above: First, explanations are not enough even when they are provided, since they might come flawed sources. Even when the LLM were to provide n explanation that is sourced from SO, that code and explanation might very well be flawed as well. Automating this process likely increases the velocity with which those security flaws spread even more. It will also cement the code that is written today as the de-facto standard way of writing code in the future and significantly slow down the speed at which old, outdated practices are phased out. Although I do not like the term “cargo-cult programming”, the Wikipedia article for it aptly describes the problem of blindly following patterns and copying them without understanding why and where they might be appropriate, creating code that is deeply flawed in the process. We have already seen the problem prior to the advent of AI-assisted code copiloting, and there is a high likelihood that AI suggestions are all too often applied too eagerly without understanding if they are appropriate in that context.

This leads us to the last paper and the important question of how we get rid of those patterns, how we develop new ways to write code and how we can still drive innovation and novel paradigms to write code in when faced with a high degree of automation and large amounts of code that are written with the assistance of AI code copilots?

And it doesn’t look good that that front, either.

The last study I cited ³ shows that there is what they call a “model collapse” when re-training LLMs on their own outputs, i.e. code generated by themselves as part of an code-copilot. The capabilities of LLMS diminish the more they are trained on their own outputs, making genuine human inputs to retrain them on invaluable for the future. But the problem is that text written by LLMs cannot reliably be distinguished from text written by humans. Unless there is a major theoretical breakthrough, this means that with higher and higher adoption levels of AI-assisted code-copilots, more and more inputs to these systems will likely be AI generated, unless one starts the painstaking process of curating code and text that is verifiably written by humans alone.

The authors write “[…] over time we start losing information about the true distribution, which first starts with tails disappearing, and over the generations learned behaviours start converging to a point estimate with very small variance. Furthermore, we show that this process is inevitable, even for cases with almost ideal conditions for long-term learning i.e. no function estimation error. […] Finally, we discuss the broader implications of model collapse. We note that access to the original data distribution is crucial: in learning where the tails of the underlying distribution matter, one needs access to real human-produced data. In other words, the use of LLMs at scale to publish content on the Internet will pollute the collection of data to train them: data about human interactions with LLMs will be increasingly valuable.”³

The details of the study do not matter much in the context of this blog article, but the above paragraphs should give rising concern as to where we are heading in terms of future LLMs.

Conclusion

So where are we headed in the next 5-20 years? Honestly, I don’t know. At least in Europe, there is an increasing demand for regulation of software development because the economic damages of software failures and security holes skyrocket. Thus far, we as a field haven’t done a good job at pro-actively design those regulations, with much of the industry being very much against it. AI offers great increases in productivity, but also comes with additional demand on verification and quality assurance. Thus far, adoption rates far outpace the speed at which we can learn to responsibly use these technologies and mitigate their short-term and long-term impacts. There is already talk about AI regulation, driven mainly by economists and law-makers, and we computer scientists and also software developers need to make sure out voices are heard in order to ensure that the regulation we will eventually get is reasonable and sound and does increase software quality and security, and doesn’t just cost a lot of money in paperwork and cover-your-ass actions.

We should also be wary were software development as a whole is headed, how we still drive innovation and make sure AI assisted code-copilots are a sustainable, safe and high-quality tool hat is able to stick around for a long time. This will involve better quality assurance of those tools as well as strategies for innovation and re-training of these models to allow programming to still evolve in the future and not approach a fixed point.

What led me to start this experiment was the following quote:

the idea is to add a method Record with(Object... componentValuePairs) in java.lang.Record, and ask the compiler to verify that the even arguments (0, 2, 4, etc) are constant strings

Proposed syntax:

var otherPerson = person.with("name", "John", "age", 17);

I thought this had to be easier and be possible in a typesafe way. So here is my suggestion:

var otherPerson = person.with(Person::name, "John").with(Person::age, 17);

What do we get? Type saftey. Better, easier to read syntax.

Can we pull this off?

Yes

It turns out, its actually possible to pull this off just as written there. Yes, Person::name is an accessor method and doesn’t allow us to set anything directly - but we already know how the component of the record is called when we look at that – and we also know the type.

The question is, can we get this information from the lambda? Turns out we can.

/**
 * c.f. https://stackoverflow.com/a/35223119/1360803
 */
private static SerializedLambda getSerializedLambda(Serializable lambda)
		throws NoSuchMethodException, SecurityException,
		IllegalAccessException, IllegalArgumentException,
		InvocationTargetException {
	final Method method = lambda.getClass()
			.getDeclaredMethod("writeReplace");
	method.setAccessible(true);
	return (SerializedLambda) method.invoke(lambda);
}

We can use this to extract everything we need:

public static <T, F extends Serializable & Function<R, T>> void with(F param) {
	var lambda = getSerializedLambda(param);
	var name = lambda.getImplMethodName();
	var signature = lambda.getImplMethodSignature();
	// get descriptor, strip () of input
	var typeDescriptor = signature.substring(2, signature.length());
	System.out.println(name + ":" + typeDescriptor);
	// if we call this with with(Person::name), we get `name:Ljava/lang/String;`
}

We get the type signature and the name of the accessor method, which is the same as the field. We strip the () from the method signature to get the return type.

Putting it all together, we get this nice method:

@SuppressWarnings("unchecked")
public default <T, F extends Serializable & Function<R, T>> R with(F param, T val) {
	try {
		// get name & type of the changing parameter
		var lambda = getSerializedLambda(param);
		var name = lambda.getImplMethodName();
		var signature = lambda.getImplMethodSignature();
		// get descriptor, strip () of input
		var typeDescriptor = signature.substring(2, signature.length());

		// get record components & replace the value
		var components = getClass().getRecordComponents();
		var params = new Object[components.length];
		for (int i = 0; i < components.length; i++) {
			var component = components[i];
			if (isCompatible(component, name, typeDescriptor))
				params[i] = val;
			else {
				params[i] = component.getAccessor().invoke(this);
				// accessor might modify data, so circumvent accessor
				// but records don't expose their fields :(
				//params[i] = getClass().getField(component.getName()).get(this);
			}
		}
		// create new record
		return (R) getClass().getConstructors()[0].newInstance(params);
	} catch (NoSuchMethodException | SecurityException
			| IllegalAccessException | IllegalArgumentException
			| InvocationTargetException e) {
		throw new RuntimeException(e);
	} catch (InstantiationException e) {
		throw new RuntimeException(e);
	} /*catch (NoSuchFieldException e) {
		throw new RuntimeException(e);
	}*/
}

The full code is available as Gist. I’ve created an interface with this method as only default method, which can be implemented by any record.

And it actually works as advertised:

public static record Person(String name) implements CopyableRecord<Person> {}

var guruJava = new Person("Brian Goetz");
var guruCSharp = guruJava.with(Person::name, "Eric Lippert");

But with a few drawbacks.

The first and most obvious drawback: This only works with method references like Person::firstName. Which is fair, I guess. This doesn’t work:

var original = new Person("Brian", "Goetz");
var copy = original.with(p -> p.firstName(), "Eric"); // nope

In fact, my current implementation silently ignores this (which is ok for a thought experiment, not so much for production code).

Furthermore, the method I have presented above has a few commented-out lines.

params[i] = component.getAccessor().invoke(this);
// accessor might modify data, so circumvent accessor
// but records don't expose their fields :(
//params[i] = getClass().getField(component.getName()).get(this);

These also lead to the commented-out NoSuchFieldException catch-block.

So whats the problem? Accessors can change the data. I’m not sure it would be a good or often used design feature a programmer would want to use to return data that is invalid, instead of just some wrappers around data like Collections#unmodifieableList, but it can happen.

Lets look at an – arguably contrived – example:

public static record Doubling (int n, int m) implements RecordTransform<Doubling> {
	public int n() { return 2 * n; }
	public int m() { return 2 * m; }
}

var original = new Doubling(2, 3); // Doubling[n=2, m=3]
var copy = original.with(Doubling::n, 5); // Doubling[n=5, m=6]

So yeah. By using the accessor we double the data every time we copy the record.

Is this really a problem?

I’m not so sure. Lets say that we use libraries like ASM to access the underlying fields directly. We can still trivially easy break copying:

public static record Doubling (int n, int m) implements RecordTransform<Doubling> {
	public Doubling {
		n = 2 * n;
		m = 2 * m;
	}
}

If we copy the value of the fields, we still double them every time. And circumventing the constructor seems to be a bad idea. If someone wants to alter drastically different data in the accessor or mutate it this way in their constructors, why net let them? Sure, copying then has side-effects that might be surprising on the first glance, but are actually quite logical on second glance.

Whats actually more upsetting in my opinion is that Record#toString doesn’t use the accessor methods and thus displays values you can never extract from the record. It will be interesting to see how that plays out with deconstruction patterns.
If you implement a DoublingRecord like above, what do you expect to happen when you the following?

var original = new Doubling(2,3);
let Doubling(int m, int n) = original;
var copy = Doubling(m, n);

The problems you are facing with a Record#with or Record#copy method are exactly the same that emerge when talking about deconstruction. Whatever solution is chosen for deconstruction will also be applicable for those both methods.

Personally, I’d think this is a non-issue. If someone wants to implement their records that way, let them and let them deal with the fallout themselves.

My point is: If I’m able to pull this off, I’m sure the Java architects will find a way to implement Record#with in a much better way than by using strings to look up values and completely circumventing the type system. It can be done inside the type system, with type safety & compiler support, and probably a lot more elegant than what I’ve cobbled up here.

Disclaimer

This is a thought experiment. Do not use this in production. I’ve not benchmarked it, it doesn’t use MethodHandle/VarHandle and is probably not suitable en masse.

The official Jekyll Documentation a section on this “Jekyll on Windows”, but unfortunately I found the information therein to be outdated.

1. Activate Windows Subsystem In order to install the subsystem, you’ll need to open a PowerShell window and type in the following: > Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux
2. Install a distro Visit the Microsoft Store page for Linux Distros and choose a distro. For the sake of this blog post, I’ll use Ubuntu.
3. Run sudo apt update && sudo apt upgrade
4. Optional Activate Ctrl+Shift+V & Ctrl+Shift+C via RMB (Mouse) > Properties > Options (Tab) > Use Ctrl+Shift+C/V as Copy/Paste
5. Run $ lsb_release -a, which should print:

   No LSB modules are available.
   Distributor ID: Ubuntu
   Description:    Ubuntu 20.04 LTS
   Release:        20.04
   Codename:       focal
   

Jekyll

If you have read the aforementioned documentation page of Jekyll, you’ll have found this part:

Now we can install Ruby. To do this we will use a repository from BrightBox, which hosts optimized versions of Ruby for Ubuntu.

Unfortunately, BrightBox does not support Ubuntu 20.04 LTS (Focal Fossa), which is what Windows installs when you use the MS Store:

E: The repository 'http://ppa.launchpad.net/brightbox/ruby-ng/ubuntu focal Release' does not have a Release file.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details. 

Install ruby-full instead:

$ sudo apt-get install ruby-full

And all build essentials, so that we can build gems with native extensions:

$ sudo apt install build-essential patch ruby-dev zlib1g-dev liblzma-dev libsqlite3-dev nodejs

And finally, for the ease of handling gems, ruby-bundler.

$ sudo apt install ruby-bundler

And…. that’s it. You have now a fully everything needed to get going.

Creating your first site

Lets get the first jekyll site going. The easiest way to set up Jekyll is using the GitHub-Pages gem. It is a great choice even if not deploying on GitHub Pages.

First, we create the following Gemfile:

source 'https://rubygems.org'
gem 'github-pages', group: :jekyll_plugins

And than its just a matter of installing the bundle and running Jekyll:

$ bundle install
$ bundle exec jekyll serve --watch

From time to time, you’ll want to fetch new versions of the github-pages gem:

$ bundle update github-pages

Records will be re-previewed in Java 15 without any changes as part of [JEP 384] and are expected to become a regular feature of the language in Java 16.

Records can have regular constructors, just like classes

Records can have regular constructor. The constructor without formal parameter list, which is a new feature in records and helps combat boilerplate by leveraging auto-initialization, but they can also have regular constructors with a formal parameter list, just like classes.

A simple record might be given as:

record FooBar(String foo, List<String> bars) { }

And then we can add sanity checks – in this case just using the constructor without formal parameter list.

record FooBar(String foo, List<String> bars) {
	public FooBar {
		if (foo == null || foo.isBlank())
			throw new IllegalArgumentException("foo can not be null or blank");
	}
}

Without a formal parameter list, values are assigned after the constructor has run. So one can initialize fields differently and doesn’t need to assign them via this.x = x.

record FooBar(String foo, List<String> bars) {
	public FooBar {
		if (foo == null || foo.isBlank())
			throw new IllegalArgumentException("foo can not be null or blank");
		if(bars == null)
			bars = new ArrayList<>();
	}
}

bars will be assigned correctly and a call to bars() will return the newly created list.

System.out.println(new FooBar("FooBar", null));
// prints FooBar[foo=FooBar, bars=[]]

However, assigning bars inside the constructor to this.bars via this.bars = bars; is heavily discouraged, in fact so much so that it is a point of active discussion on the amber-spec-experts mailing list to remove access to fields via this.x in the canonical constructor altogether (both reads & writes) [amber-spec-experts].

However, you can also use a constructor with a formal parameter list. When doing so, auto-initialization does not work and values must be assigned in the constructor (since the fields are final):

record FooBar(String foo, List<String> bars) {
	public FooBar (String foo, List<String> bars) {
		if (foo == null || foo.isBlank())
			throw new IllegalArgumentException("foo can not be null or blank");
		if(bars == null)
			bars = new ArrayList<>();
		this.foo = foo;
		this.bars = bars;
	}
}

Why would you ever want to do that? Because you can put annotations on them. Currently, libraries like Jackson do not support records, but work to make this happen is underway [3]. Using formal parameter lists for the constructor lets us put annotations on them and get around that limitation:

record FooBar(String foo, List<String> bars) {
	public FooBar(
			@JsonProperty String foo, 
			@JsonProperty List<String> bars) {			
		if (foo == null || foo.isBlank())
			throw new IllegalArgumentException("foo can not be null or blank");
		if(bars == null)
			bars = new ArrayList<>();
		this.foo = foo;
		this.bars = bars;
	}
}

Yes, this actually works right now, in Java 14, with Jackson 2.11.0.

public record FooBar(String foo, List<String> bars) {
	public FooBar(@JsonProperty("foo") String foo,
		 @JsonProperty("bars") List<String> bars) {
		if (foo == null || foo.isBlank())
			throw new IllegalArgumentException("foo can not be null or blank");
		if (bars == null)
			bars = new ArrayList<>();
		this.foo = foo;
		this.bars = bars;
	}

	public static void main(String[] args) throws JsonProcessingException {
		System.out.println(new ObjectMapper()
			.readValue("{\"foo\" : \"foo\", \"bars\": []}", FooBar.class));
		// prints out FooBar[foo=foo, bars=[]]
	}
}

Records will be re-previewed in Java 15 without any changes as part of JEP 384 and are expected to become a regular feature of the language in Java 16.

Lets start with a simple example and how it can be shown to be not immutable:

public static record NaiveRecord(String name, List<Date> values) { }

We can show that this record is mutable by simply adding to or removing from the list as returned by values():

var naive = new NaiveRecord("naive", new ArrayList<>());
System.out.println(naive);
//prints NaiveRecord[name=naive, values=[]]
naive.values().add(new Date(99, 01, 01));
System.out.println(naive);
// prints NaiveRecord[name=naive, values=[Mon Feb 01 00:00:00 CET 1999]]

How can we do it better? We can adress the above problem by making the list immutable, leveraging the canonical constructor without using a formal paremeter list:

public static record BetterRecord(String name, List<Date> values) {
	public BetterRecord {
		values = Collections.unmodifiableList(values);
	}
};

Now, changes to the record via record.values().add/remove() aren’t possible anymore, as they’d throw an UnsupportedOperationException. Unfortunately, changes to the record are still possible by writing to the underlying list directly. If that has escaped or be given away, the record can still experience changes in state (and thus, hashCode()).

var original = new ArrayList<Date>();
original.add(new Date(99, 01, 01));
var better = new BetterRecord("better", original);
System.out.println("%s hash=%s".formatted(better, better.hashCode()));
// BetterRecord[name=better, values=[Mon Feb 01 00:00:00 CET 1999]] hash=-1516124796
original.add(new Date(102, 01, 01));
System.out.println("%s hash=%s".formatted(better, better.hashCode()));
// BetterRecord[name=better, values=[Mon Feb 01 00:00:00 CET 1999, Fri Feb 01 00:00:00 CET 2002]] hash=1357225607
System.out.println("-----");

The solution to that particular problem is to defensively copy the whole list, and then wrapping it into an unmodifiable one.

public static record EvenBetterRecord(String name, List<Date> values) {
	public EvenBetterRecord { 
		values = Collections.unmodifiableList(new ArrayList<>(values));
	}
};

But still, this record remains vulnerable if the data type stored in the list is mutable, as is the case for java.util.Date:

var original = new ArrayList<Date>();
var someDay  = new Date(100, 01, 01);
original.add(someDay);
var evenBetter = new EvenBetterRecord("even better", original);
System.out.println("%s hash=%s".formatted(evenBetter, evenBetter.hashCode()));
// EvenBetterRecord[name=even better, values=[Tue Feb 01 00:00:00 CET 2000]] hash=-1168472954

someDay.setYear(99);
System.out.println("%s hash=%s".formatted(evenBetter, evenBetter.hashCode()));
// EvenBetterRecord[name=even better, values=[Mon Feb 01 00:00:00 CET 1999]] hash=1655265406

We can address this by also creating a deep copy of each element of the list. This is where having a copy constructor comes in very handy. Unfortunately, java.util.Date doesn’t have one. But it does implement Cloneable & has a public clone() method.

public static record ImmutableRecord(String name, List<Date> values) {
	public ImmutableRecord {
		values = values.stream()
				.map(Date::clone)
				.map(Date.class::cast)
				.collect(Collectors.toUnmodifiableList());
	}
}

Here we take the values, clone them, cast them back from Object to Date (as Date#clone returns Object) and then collect them all into an unmodifiable list.

This list is not modifiable by any of the tricks shown so far. We can of course still do shenanigans involving Unsafe or serialization, but this is the kind of record I’d consider reasonably immutable. If you are not using java.util.Date, you might need to make sure that you are actually doing a deep copy of the object, as a shallow copy might have leaked references through which it can be manipulated, too.

Note that only nesting records is no defense again mutation, either. If the nested record is mutable, e.g. by having an improperly treated collection, the holding record becomes mutable, too.

Recap

Records are not immutable, they are only “shallowly-immutable”. We can break immutability in three ways:

• Adding to or removing from the list returned by values()
  (addressed by wrapping it into an unmodifiable list)
• Adding or removing from the original list if we still have a reference to it
  (addressed by copying the list)
• Mutating an element in the list mutates the record
  (addressed by deep copying the elements of the list)

In fact, we can easily devise unit-tests for all three of these properties. The following gist contains a JUnit 5 test case, with unit tests called

• canNotChangeThroughGetter,
• canNotChangeThroughOriginalList and
• canNotChangeThroughOriginalObject.

In order to execute each of these tests with each record, I have added a common interface RecordWithList to all four of these records and execute the tests with each type of record. Not all records pass all tests, which was expected in this case.

Conclusion

Using the canonical constructor without formal parameter list can be quite powerful. Using this.x inside such a constructor is not needed and actively discouraged to the point that the Java architects are considering disallowing such access altogether.

Using a formal parameter list on the constructor allows programmers to place annotations there. With such a constructor, some libraries, most notably Jackson, can be made to work with constructors easily.

Records are only “shallowly-immutable”. If one wants to leverage the beneficial properties of immutable types, great care has to be taken to ensure that the record actually is immutable, and not only appears that way at first glance.

Failure modes

1. Return true, false, NULL or another magic value
2. Use void, throw a (checked) exception
3. Return an intermediate result object

Each of these modes is discussed below, with examples of their usage, strengths and weaknesses.

Return true, false or NULL

This is used in some older, mostly C-style APIs. Today, we can for example find it quite often in the PHP standard library, leading to code like this:

if ($data = xyz_parse($data) === FALSE)
	$error = xyz_last_error();

Obviously this only works in languages like PHP because there is no static typing and in C due to being able to cast values this way. In Java, the only way to signal failure would be to return null or another magic value (via the NULL-Object pattern).

The downsides to this approach are (not exhaustive):

• It is not clear from the method signature what the magic values are
• Without a-priory knowledge about the magic values, checking for them and interpreting them correctly is impossible
• No compiler support, forcing the caller to correctly handle all scenarios by themselves, making errors easy

In multi-threaded contexts, this approach is even worse. In between parsing and retrieving the error, another thread might parse something, overwriting the stored errors. Synchronizing such access is easily forgotten or a performance nightmare.

Therefore, this approach has largely fallen out of favor, especially in programming languages that offer useful alternatives.

We can sometimes see a similar approach being used in Java where no return value is expected and instead a boolean is returned to indicate failure and success, e.g. in Collection#add. The disadvatange is that we do not get any information about the kind of failure and have no way to query what went wrong.

And in case of Collections.unmodifiable[Collection|List|Set|Map], we get a runtime exception (UnsupportedOperationException), which by necessity is unchecked. This defeats all the help the compiler could give us and makes unmodifiable collections prone to let exceptions bubble up the stack without being handled at the proper level.

Throw (checked) exceptions

Checked exceptions are a more elegant way to signal potential failure modes and forcing the caller to handle them. Since failure is to be expected for certain operations, checked exceptions an be leverage to enforce error handling by the caller. Java for example uses checked exceptions when dealing with sockets. The basic assumption is that a call should succeed, but certain operations are known to be unreliable. Socket connections are among them. So the caller gets forced to handle the failure.

try {
	socket.open();
} catch (IOException e) {
	// deal with the failure, e.g. display error message
}

Return result object

Another way to handle expected failure is to return an immediate result object that holds information about the operation. In modern Java, Optional<E> could also be used to signal values that might or might not be present (e.g. a valid parsing result).

ValidationResult result = parser.validate(rawData);
if (result.isValid()) {
	var data = result.getData();
	// process data
}
else {
	var error = result.getValidationError();
	// optional error handling
}

Nice, clean logic for the caller. In Java, ValidationResult#getData could return Optional<BusinessData> to communicate to the caller that the data might or might not be present and to ensure compiler support for missing values.

Leveraging sealed classes and interfaces (algebraic types)

With [JEP 360] considered for Java 15, we might get yet another way to create intermediate result objects that sits somewhere in between checked exceptions and a result object - algebraic types! These are formed with Sealed Types and Records.

Suppose we create a type Result<S, E> = Success<S> | Error<E>, which we could do In Java 15 with

sealed interface Result<S,E> permits Success<S, E>, Error<S, E> {
	record Success<S, E> (S result) implements Result<S, E> {}
	record Error<S, E> (E error) implements Result<S, E> {}
}

Unfortunately, we can not specify a “don’t care” generic wildcard, so a bit repetition is needed there. But now, instead of indicating to a caller the possibility of errorneos execution via throws, we can indicate this via the result type:

class Parser {
	
	public Result<Data, InvalidFormatException> parse(String raw) {
		// [...]
	}
}

A caller is then forced to examine the type, either via instanceof (JEP 305) or leveraging switch expressions (JEP 325), potentially even leveraging pattern-matching with deconstruction patterns inside of any of those (JEP Draft, Pattern Matching).

An example call could look like this:

switch(parser.parse(input)) {
	case Result(Data data) -> process(data);
	case Error(InvalidFormatException e) -> displayError(e);
}

We might even use a more general exception and switch more fine-grained on the exception type (potentially forgoing exhaustiveness checks and necessitating a default clause).

Conclusion

Failure modes can be handled in different ways depending on wether failure is expected or unexpected. Shown here are four ways of handling them, and which one to choose depends on the nature of the problem and the context in which it might occur.

There is a (sometimes) heated debate going on when to use (checked) exceptions and when to use other approaches. A statement that I found very reasonable wrt. exceptions is the following:

Checked exceptions are for environment problems. Unchecked exceptions are programming errors.
— Elliotte Rusty Harold, Exceptions: I’m Telling You For The Last Time

When to use

MapReduce
Important stream operations

As always, A = B is permissible!

When to use

Modifiying the template

In templates, we can use the {lang}...{/lang} template tag to render the contents of a language variable. if the variable is not found, the name of the variable is put out instead. So, a modified version of the template from the last article would look like this:

{include file='documentHeader'}

<head>
    <title>{lang}wcf.page.helloworld.title{/lang} - {PAGE_TITLE|language}</title>

    {include file='headInclude' sandbox=false}
</head>

<body id="tpl{$templateName|ucfirst}">

{include file='header'}

<header class="boxHeadline">    
    <h1>{lang}wcf.page.helloworld.title{/lang}</h1>  
</header>

{include file='userNotice'}

{lang}wcf.page.helloworld.info{/lang}

{include file='footer'}

</body>
</html>

Here we use two language variables – wcf.page.helloworld.title for the page title, which is also used in the heading, and wcf.page.helloworld.info which will hold the text in the blue information box. You might notice that I have removed the whole <p class='info'>...</p> box altogether. This is right – you can use HTML and even template scripting inside language variables.

By now, the page will look like this:

Deploying language variables

In order to define values for our language variables, we will use the Language- PIP, which is XML-based. Therefore, we create a new folder named lang/ in our plugin, and place two files there, namely de.xml and en.xml.

The lang/en.xml file will look like this:

<?xml version="1.0" encoding="UTF-8"?>
<language xmlns="http://www.woltlab.com" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.woltlab.com http://www.woltlab.com/XSD/maelstrom/language.xsd" languagecode="en" languagename="English" countrycode="en">
	<category name="wcf.page">
		<item name="wcf.page.helloworld.title"><![CDATA[Hello, World!]]></item>
		<item name="wcf.page.helloworld.info"><![CDATA[<p class="info">my first page!</p>]]></item>		
	</category>
</language>

Like in the package.xml file, we again declare the used sheme, which in this case is the scheme for language files. Moreover, we declare for which language this file is used - in this case english.

by now you will most probably have notices the <categories> block. Language variables withing WCF are separated into categories. The name of a language variable alsways has to be prefixed with it’s category. It is most important always to use the correct category, as unexpected things can happen if you use the wrong language category (this was cause for much trouble for early WCf 1.x plugins). Unfortunately, as of now there is no documentation about the existing language categories available. Therefore, you will need to take a look into the WCF database youself.

In this case, wcf.page is the correct category.

<instruction type="language">language/*.xml</instruction>