八年前的 2014 年 8 月 29 日，當(dāng)時(shí)的林業(yè)（Forestry for Minecraft）維護(hù)團(tuán)隊(duì)成員之一的 CovertJaguar（同時(shí)也是 Railcraft 的原作者，參見「茶后談#9」、「茶后談#109」）創(chuàng)建了一個(gè)標(biāo)題為「Kill MJ Support and remove all dependence on Buildcraft API」（「移除對(duì) MJ 的支持和對(duì) BuildCraft API 的依賴」，即 ForestryMC/ForestryMC#161，如下圖）的 issue ticket。彼時(shí)，BuildCraft 的原作者 SpaceToad 于 2014 年年初突然宣布回歸 BuildCraft 的開發(fā)，并在當(dāng)年四月底前后開始著手編寫一套全新的 MJ API，力圖為開發(fā)者提供更「靈活」的選擇。然而，在迭代了幾個(gè)版本之后，有開發(fā)者發(fā)現(xiàn)：這套全新的 API 沒有正確處理舊版?MJ API（即「茶后談#24」中提及的由 CovertJaguar 修改后的那一版）的向后兼容，開發(fā)者被迫必須在這兩套 API 中二選一，而無法同時(shí)兼容。更為致命的是，這些開發(fā)者還在新版 MJ API 中發(fā)現(xiàn)了一些致命錯(cuò)誤，使得其完全無法正常使用。CovertJaguar 認(rèn)為在這樣的情況下，繼續(xù)維持一個(gè)「和 RF 在同一級(jí)別上」，但「明顯更復(fù)雜」且「有各種 bug」的 API 的兼容不再可取，建議「立即移除全部對(duì) MJ API 的兼容」并「提供對(duì) RF API 的原生支持」，還建議編寫一套內(nèi)部使用的能量傳輸機(jī)制供引擎和機(jī)器使用，以避免對(duì) RF API 的硬依賴。CovertJaguar 還提到了 RailCraft 稍后也會(huì)如此跟進(jìn)。由此，林業(yè)成為了「MJ 三巨頭」中第一個(gè)正式開始考慮「放棄 MJ」的模組，并在大約一個(gè)月的時(shí)間內(nèi)完成了放棄 MJ API 兼容并提供原生 RF API 兼容的轉(zhuǎn)變。本文部分內(nèi)容轉(zhuǎn)述自 asie 的博文?https://blog.asie.pl/2015/01/buildcraft-history-and-design/，在此向其表示由衷的感謝?！颈酒诰庉嫞?TUSK】