The FAWE patch

If you run FastAsyncWorldEdit, you may see this in /oasis status:

FAWE: can log edits under the wrong player, run /oasis fawe patch

That line can look alarming, so here’s the whole story. The short version is that you don’t have to do anything. Oasis and FAWE work fine without the patch. The patch fixes one rare mix-up, and whether you turn it on is up to you.

Why it exists

FAWE has a small bug. When two WorldEdit jobs run at the same time, FAWE can mix them up and hand a piece of one job to the other. For Oasis, that means part of one player’s edit can end up logged under the other player’s name.

For a logging plugin, the name is the whole point. If it’s wrong, a lookup can blame the wrong person, and a rollback of one player can miss part of their edit or touch part of someone else’s. The same mix-up can also trip up FAWE itself, in its own undo history and in pastes.

We found the bug while testing Oasis and reported it to the FAWE team as issue #3668. The fix is a one-line change, and it’s waiting to be merged as pull request #3669. Until FAWE ships it, the patch lets you have that fix today.

What the patch does

The patch makes the same one-line change, in memory, while your server runs. Oasis never touches the FAWE jar. Your FAWE install stays exactly as you downloaded it, and if you take Oasis out, FAWE is back to normal on the next start.

Run this to see what it would do. This command doesn’t change anything:

/oasis fawe patch

If you’re happy with it, turn it on:

/oasis fawe patch confirm

Oasis remembers your choice and applies the patch again every time the server starts, even after you update FAWE. To turn it off, run:

/oasis fawe unpatch

That takes effect right away.

Do you need it?

Probably not urgently. The mix-up only happens when edits overlap, so a server where builders rarely run WorldEdit jobs side by side may never see it. If lots of people use WorldEdit at once, or you want every name in your history to be right, turn it on.

You don’t need to keep track of FAWE’s progress either. When a FAWE release includes the fix, Oasis notices, stops patching, and the line disappears from /oasis status. Oasis also leaves alone any FAWE version it doesn’t recognise.

One small note: if your server runs on Java 26 or newer, Java prints a warning when the patch turns on. That’s Java pointing out that a plugin changed another plugin’s setting, which is exactly what you asked for.

How it works, for the curious

You don’t need any of this to use the patch. It’s here for anyone who wants to know exactly what Oasis changes before saying yes.

The bug

When FAWE runs an edit, it collects the chunks the edit changes in a queue. Each queue carries its edit’s processors: the steps that check limits and masks, and the one Oasis adds to log the edit and name the player behind it.

FAWE gets that queue from QueueHandler.getQueue. To save a little work, getQueue keeps one queue per thread and hands that same queue to every edit that asks for one on that thread. So when two edits run on the same thread, they share a queue, and a chunk from one edit can run with the other edit’s processors. For Oasis, that chunk gets logged under the other player’s name. FAWE’s own undo history can get its wires crossed the same way.

The fix

The fix in pull request #3669 is one line in getQueue: create a new queue every time instead of reusing the shared one.

final IQueueExtent<IQueueChunk> queue = pool();
final IQueueExtent<IQueueChunk> queue = create();

What Oasis does

Oasis can’t edit FAWE’s code while it runs, and it doesn’t want to touch your jar. Instead, it swaps out the one piece that pool() reads from: the queue pool inside FAWE’s running QueueHandler. Oasis puts in a pool that never keeps a queue. Every time pool() looks in it, it finds nothing and creates a fresh queue, which is exactly what the fix does. /oasis fawe unpatch puts FAWE’s own pool back, and that takes effect immediately.

Before it changes anything, Oasis reads FAWE’s getQueue to make sure it’s the code it expects:

• If getQueue still uses the shared pool, the patch is available.
• If getQueue already creates a new queue, your FAWE has the fix, and Oasis does nothing.
• If the code looks different from either, Oasis leaves it alone and says so in /oasis status.

The patch only lives in memory, so it’s gone when the server stops. That’s why Oasis writes your choice to a small file, plugins/Oasis/fawe-patch, and patches again at each start while that file is there. /oasis fawe unpatch deletes the file.

Why Java 26 warns

The pool sits in a field FAWE marks as final, which means it’s never supposed to change after FAWE sets it. Java 25 lets a plugin change such a field anyway. Java 26 still allows it but prints a warning, as part of Java’s plan to make final truly final (JEP 500). A later version of Java may refuse unless the server is started with permission to allow it. By then we hope FAWE has shipped the fix and nobody needs the patch at all.