Discardable Accidents

This chapter's thesis: the following four things are historical accidents rather than design essence — the language runtime, the one global clock, the dual-edition split, and the semantic freeze on parts of the implementation — and all four can be discarded. But each must first answer the same question: where does the invariant it hosted live after the move? Any "discard" that cannot answer it, however modern its motives, is demolition.

1The problem

The whole method of this volume is to strip the accident from the essence. The previous chapter listed what must not move, and the rewriter's second reaction to that list is usually relief: "So that is all that cannot move? Then there is a tremendous amount that can." This chapter's job is to put that relief through a security check.

Because "discardable" is a more easily misjudged category than "must keep". What must be kept has the community's memory standing guard — touch it and someone shouts at once; what may be discarded tends to be quiet — until three months after the rewrite ships, when people discover that some invariant quietly hosted by an "outdated old design" has become homeless. This chapter picks out the four most tempting "discardables" and demonstrates the correct discarding posture for each: before you throw anything out, re-house the invariant it hosts. The way to grade this chapter is direct: discard any one item by this chapter's recipe — if the matching invariant comes through unharmed, the chapter scores; if the invariant is damaged, this chapter's analysis is wrong.

2The language runtime: discard Java, re-house portability and reversibility

Java is the one of the four accidents most often tabled for rewriting — the implementation volume's double-sided verdict on the runtime (the language was an accident; the ecosystem the accident grew has become essence) is this chapter's footing. Discard it, and three invariants need re-housing.

Portability: back then, Java solved indie distribution with "write once, run anywhere". Today the problem has new answers — engines' cross-platform abstraction layers, the maturing console and mobile storefronts, new general-purpose runtimes such as WebAssembly. The portability invariant can move house, and the new house is roomier.

Reversibility (bytecode that can be turned back into readable form, which is why the community could read the game and change it): this is the one that genuinely needs careful re-housing. Among modern options, "open-source the core" and "an official plugin API" are the two common substitutes, but the implementation volume's lessons must hang on the wall: open source does not equal a promise of stability, and an API does not equal coverage of every need — the "unlimited right of reversal" the community enjoyed in the Java era is one of a kind, and any substitute must honestly admit it is a downgrade and explain why the ecosystem can bear it (Luanti's fully open-source model is an existence proof of "no downgrade", bought at the price of building the content ecosystem from scratch).

Distribution shape and history-visitability: the third invariant, and the easiest to miss. The implementation volume told how the humble jar, plus a launcher that manages directories, made "any number of versions coexisting on one machine" nearly free — the technical premise beneath the history volume's "official back door to old saves". Once the rewrite switches to modern distribution channels (app stores with forced updates), the ability to "reinstall any historical version" does not carry over automatically. Does it count as an invariant? The history volume's position is that it does: history-visitability is the public-works annex to the invariant that the world must outlive the engine. A rewrite proposal that ships "the latest version" without "any old version alongside it" has moved the palace and burned the archive.

Verdict: the language can be discarded; portability must be renewed; reversibility must be either explicitly downgraded or doubly compensated; history-visitability must be written on page one of the new architecture's requirements document — it is too cheap, and cheap things are the ones that get forgotten.

3The one global clock: discard the unified 20-TPS beat, re-house causal discipline

The Game Loop and the Tick established 20 TPS as a contract, and Servers and Scale recorded the community's first groundbreaking (Folia's regional parallelism¹). The rewrite volume's question goes a step further: is the one global clock essence?

The analysis (the servers chapter's interest-management viewpoint has already laid the ground): the global clock's essential function is not "twenty times a second" but causal discipline — within one instant, the order of events is determined, reproducible, dependable. That discipline has no necessary connection to "global": so long as causality is ordered inside each region and the interfaces between regions are clearly defined (message order, delivery guarantees), many local clocks can hold the discipline just as well — at the price of cross-region interaction complexity and the disappearance of "global simultaneity" (events in two regions no longer share a strict "at the same moment"). Folia's exploration mapped the feasibility border of this road: respectable gains for worlds with obvious shards (player gathering points far apart), enormous difficulty for high-interaction-density scenes (ten thousand players in one city).

Verdict: the global clock can be discarded; causal discipline cannot, and must be argued scene by scene — parallelization is not a performance switch; it trades order problems for interface problems. Before signing the deal, look at how much your players love interacting across regions.

What the trade means concretely for redstone players deserves a separate ledger, computed for the rewriter to see. Once the global clock is gone, "one machine straddling two regions" turns from an engineering problem into a diplomatic one: each half of the machine obeys its own region's clock, and signals crossing the seam must travel the inter-region interface — delay, order, even reliability become new variables. The redstone community's decade-plus design language (integer-tick delays, same-tick interlocks — the vocabulary codified in Redstone's Implementation) stands on "the world is one bell"; in a world of local clocks, that language must split into "intra-region grammar" and "cross-region grammar". New ways to play may grow out of the crack (time differences between regions are new physics in themselves), but the rewriter must be clear: you are asking an entire engineering community to relearn its mother tongue. That tuition appears on no performance report; it is charged to the community's emotional account.

4The dual-edition split: discard the second implementation, re-house cross-platform and the business model

The implementation volume wrote out the fork history of Java and Bedrock and the semantic debt between them. From the rewrite perspective, the dual edition is the clearest "discardable" of all: one codebase, many platforms — a standard capability of modern engines. But the warning of this volume's four-product matrix applies here: the Bedrock line carries not just a second implementation but an entire business model (Marketplace, console certification, the cross-platform account system). To discard "two implementations" is really to handle: the cultural merger of two communities (each side's disdain for the other, matured over a dozen years), the contractual reality of two storefronts, and the repricing that "unification" imposes on the players already on both sides (the "interest still accruing" that the implementation volume computed for the split).

One more historical perspective must be faced honestly: is the window for unification open, or already shut? Better Together (2017) was in truth a "half unification" — it merged every non-Java platform onto one codebase, leaving the split of "Java versus everything else". That proves the engineering difficulty of unification is manageable; what is hard is the semantic and commercial alignment that follows: the freedom of Java players and the order of Bedrock players did not swallow each other — the two community contracts each fortified itself. Seven years on, each side's saves, works, and habits have grown seven layers thicker, and the cost of unification keeps climbing that interest curve. So this volume's judgment on this accident splits in two: architecturally, unification is beyond doubt; on timing, every year of delay raises the merger's price. If the rewrite truly happens, its largest dividend is precisely "completing the merger under the cover of a new engine" — a new world has no old residents, hence no demolition disputes; but neither can a new world hold the old residents' memories (the bill for migrating old saves is reckoned in the Compatibility Strategy).

Verdict: two implementations can be discarded, and this volume holds that unification is the one of the four accidents with the most certain payoff — but its cost sits not in engineering; it sits in business and community, and no technical volume can sign that off on anyone's behalf. What the technical volume can say is this: the unified engine must re-house the Java edition's "reversibility dividend" and the Bedrock edition's "manageability dividend" at the same time — lose either, and one side's players will feel that "the ones abandoned were us".

5The semantic freeze on implementation details: discard the "quirks", pay off the dependence first

Redstone's Implementation walked through the four steps by which undefined behavior becomes an API. From the rewrite perspective, these are the subtlest items of all: technically they are pure debt (undocumented, unexplained, refactoring-blocking); as property they are pure assets (depended on, narrated, supplied with tutorials).

There is exactly one correct move for discarding them: pay off the dependence first, then demolish the structure itself. "Paying off" takes the concrete form of an official equivalent — the observer block's answer to the BUD is the most successful precedent: the officials did not directly patch away quasi-connectivity usage; they gave the community a "front door" component, and once the front door had digested the demand, the old door's existence stopped hurting. The counterexample posture is equally clear: forced correction with no substitute is Volume II's 1.9 combat upheaval — the community does not object to progress; it objects to confiscation.

Translate this discipline into rewrite-engineering language and you get a document that should not be postponed: a quirk-replacement requirements list. At kickoff, a rewrite should register three lines for every depended-on implementation detail: how deeply it is depended on (the volume of tutorials, of machines, of jargon); what its "front door" equivalent is, and whether one already exists; the dual-track strategy for the transition (how long old and new coexist, when the old door comes down). In vanilla's world this list was never formally written — the officials sensed dependence indirectly, through the Wiki and the community's temperature. A rewrite project starts with a blank page and has no excuse not to write the implicit contract into explicit terms. The later chapter on who holds the right to rewrite will return to a related question: who gives this list its final sign-off? The answer hints at this chapter's last word on proportion: the technical team may decide "how to fix"; only the community may decide "what may be demolished".

Verdict: quirks can be discarded, but the cost formula of discarding is "the cost of building and popularizing the equivalent", not "the cost of deleting those few lines". A rewrite budget that omits this line item is the wrong budget.

6What this chapter leaves behind

• For players: read in reverse, this list is a minefield guide for the sentimental — when a rewrite project says it wants to "modernize", first ask it where the invariants hosted by the four accidents have moved.
• For developers: what you can take away is the security-check procedure for discards — for every "outdated design", first list the invariant it hosts, then design the new residence, and only then schedule the demolition; plus the "equivalent first" demolition discipline (the observer precedent). What you cannot take away is the thing required to judge "which dependences have grown into a web": a community old enough and large enough — that community is the original source of any dependence list.

注释

1. Minecraft Wiki, "Folia" (the Paper team's experimental regionized multithreaded server fork, which settles the world in parallel by region), minecraft.wiki, retrieved 2026-09-18: see https://minecraft.wiki/w/Folia . ↩