How to uninstall jclasslib bytecode viewer on Mac
Save any edited class files before quitting jclasslib. This guide covers the downloaded Mac app, with Homebrew handled separately below.
Quit and remove the app
Keep Java installations, class files and JARs. The desktop viewer and the separately used library are independent installations.
Quit jclasslib bytecode viewer using its own quit action. In System Settings › General › Login Items & Extensions, turn off any jclasslib bytecode viewer login entry if present. After backing up, move /Applications/jclasslib bytecode viewer.app to Trash in Finder and leave Trash intact until the wanted data is confirmed saved.
Review local data
Use Shift + Command + G in Finder to inspect each complete path. Copy wanted contents elsewhere before deciding to move that item to Trash. These locations come from the recorded test and the live Homebrew cask. Do not create a missing path. A * marks a matching range, not a literal filename; inspect the actual matches individually.
| Location | Contents and decision |
|---|---|
~/Library/Preferences/org.jclasslib.browser.plist |
Preferences; keep if you want to restore settings |
~/Library/Saved Application State/com.install4j.8931-3388-4457-4383 |
Window restoration state; remove if no longer wanted |
If you installed it with Homebrew
To uninstall without running zap:
brew uninstall --cask jclasslib-bytecode-viewer
This removes the cask-managed app, without running its zap data list.
The following direct command applies the cask’s entire zap list independently of Mole’s checkboxes. Use it only after backing up and approving every target.
brew uninstall --cask --zap jclasslib-bytecode-viewer
The live zap targets are ~/Library/Preferences/org.jclasslib.browser.plist, ~/Library/Saved Application State/com.install4j.8931-3388-4457-4383.
Zap removes the listed targets, including any settings or user data inside them. Use the command without zap when retaining any target. Live cask.
Check the result
ls -ld '/Applications/jclasslib bytecode viewer.app'
pgrep -ifl '/Applications/jclasslib bytecode viewer[.]app/'
A listed app path means that bundle remains. “No such file or directory” means that exact path is absent; “Permission denied” leaves the check unconfirmed. This checks one location, not other copies, background services or user data.
A pgrep result means a running command line matches this app path. No output means no such match, not that independent helpers or other app copies are absent; an error leaves this step unconfirmed.
What Mole lists
~/Library/Preferences/org.jclasslib.browser.plistis selected by default.
These defaults assume “Remove data and settings with apps” is off, which is the default. Enabling it also selects eligible reviewed app data; shared and protected items retain their individual boundaries. Mole invokes Homebrew zap only when the whole zap scope passes its check. Unchecked, shared or out-of-boundary paths and unsupported directives suppress zap; selected remnants still use Mole’s own deletion flow.
What this test covered
Removal used a source-built Mole app. The recorded first-launch scan was partial and does not establish every file the app can create.
The official app opened an empty class-file view and was removed. No JVM was attached and no class file was edited.
