If I release it, you won’t get the same experience I get

# If I release it, you won’t get the same experience I get Source: [https://notes.highlysuspect.agency/cant-release-that.html](https://notes.highlysuspect.agency/cant-release-that.html) In my[minecraft modding repo](https://codeberg.org/quat/mods/)I was doing some build\-tooling refactoring, and to give myself confidence I didn’t break anything I wrote a program called[jardiff](https://codeberg.org/quat/mods/src/branch/trunk/jardiff)\. It takes two files or directories as arguments and does the following: - if it’s a directory, it checks they have the same file listing, and then recurses into each file - it also does that for the files inside`\.zip`s and`\.jar`s - if it’s a`\.json`, it parses the json and standardizes the formatting before diffing - if it’s a`\.class`, it runs it through a Java disassembler \(objectweb asm textifier\) before diffing- because you deserve better than “Binary files differ” - otherwise it does a normal diff and displays the results if it’s text- I implemented the meyers diff algorithm by hand\. Totally unnecessary but a fun yak shave So it’s like a more lenient[diffoscope](https://diffoscope.org/); I wanted to make sure that the new build tooling creates artifacts which*function*the same as the old artifacts, but I don’t care if they’re byte\-for\-byte \(hence the json reformatting\)\. For example, in the old tooling I had a Java 8\-compatible sourceset and three of the mods I built contained classes harvested from it\. In the new tooling I decided to remove this sourceset and just paste the classes into each mod, so they are now compiled alongside the rest of the mod, using Java 25\.`jardiff`uncovered this difference because a class file’s version number is visible in its disassembly\. However I decided that this change was acceptable\. I don’t support minecraft versions which require java 8 anymore and removing the sourceset made things simpler enough to justify a little cut\-pasting\. So what I did was: I went into the sourcecode of`jardiff`and modified the disassembler to always output the same class file version number\. When I ran jardiff again those particular differences were gone and I could easily look for more\. > something abt having the code of the tool right there in front of you at the time you use the tool\. something about how you don’t have to bake in choices or make things configurable when you can just splice in the code you need and skip the parts you don’t I can get a lot done quickly with`jardiff`because its sourcecode exists in my editor when I use it\. I can ignore or exacerbate changes I’m looking for; I can decide whether the order of entries in the zip file matters, I can splice in a custom`ClassVisitor`which always reports the same version number, etc\. I’ve done this countless times when working on the new build tooling to focus in on exactly the differences I’m looking for\. If I package this up into a single binary, then the sourcecode to the tool is not in front of you when you use it, and this flexibility is lost\. I could readd them as configuration options, but will I enjoy plumbing them through the entire codebase? will I even remember what they all are when I need one? I could add a regex filter but my brain is in class\-parsing mode; I know exactly what to change in order to make the disassembler report the same version number, but I would have to shift into regex mode to phrase that in terms of textual regex find\-and\-replace; of course there’s more of a risk of false\-negatives too where I accidentally find\-and\-replace out text which*should*be different but just*happens*to look like a class file version number \(…contrived, I guess, but I wrote`jardiff`for peace of mind\) What’s the chance that the next difference I find would be something covered by an existing flag, rather than a new type of difference I wasn’t expecting \(and therefore I need to write code anyway?\) If I add a domain\-specific language to let you program your own filters, would you even bother to learn it? would it be as easy to use as the one already built into my editor that already understands the sourcecode of the tool extremely well? compiling it as a binary freezes it in amber, there is always a power imbalance between the Developer and the User signified by who’s code gets to be part of the binary and who’s doesn’t, who gets the real language and who gets the DSL, … ## \!\!\!\!\!\!\!download today\!\!\!\! [Just copy and paste these two classes somewhere](https://codeberg.org/quat/mods/src/branch/trunk/jardiff/src/main/java/jardiff)and figure it out yourself lol