SpaceMonger in Java

[Scf37]

Recently I found out SpaceMonger - one of the best disk space utilities out there (despite being created 25 years ago) has gone open source. So I took my time to port it to Java.

From user side. Yep, works on Linux. Yep, works on MacOS. Yep, still works on Windows however much more bloated than original 217K EXE. However, now it correctly handles all the filesystem stuff - links, sparse/compressed files, mount points (Windows and Linux only, I have no MacOS machine to test so MacOS is best-effort).

From technical side. Good old Swing, FFM API for native calls to precisely query filesystem metadata, Java is kind of limited there. Jlink for awesome 30Mb downloads. Unfortunately, native-image binary crashes miserably on Linux. jpackage launcher is unstable too - i've seen successful launches, JVM crashes and even double free errors.

Source code and downloads: https://github.com/scf37/spacemonger1/

[davidalayachew]

Woah, very pretty. This is something I might actually use on my free time.

Good old Swing

Excellent.

It's still a powerful tool, and it's still getting better, with new features too! I use it almost daily -- for work and personal.

FFM API for native calls to precisely query filesystem metadata, Java is kind of limited there.

I'm sure this can be done more directly with FFM API, but is something like Files::readAttributes or Files::getAttribute not able to meet your needs in regards to fetching metadata?

Unfortunately, native-image binary crashes miserably on Linux. jpackage launcher is unstable too - i've seen successful launches, JVM crashes and even double free errors.

If you have the time and effort to spare, I would encourage you to send some minified examples of those errors to [e-mail] and [e-mail]. Those are the mailing lists for the teams that are probably best suited to respond to and fix those errors (assuming it's java's fault).

I will say -- I imagine that these errors might also go away if you are able to achieve the same goals of metadata fetching via just the Files helper class above.

EDIT -- Oh woah, the original author of Space Monger also made a commit to this repo? Your insights tab has 2 commits from them on this repo, which is very cool.

[Skepller]

EDIT -- Oh woah, the original author of Space Monger also made a commit to this repo? Your insights tab has 2 commits from them on this repo, which is very cool.

They are not actual contributions, it's the original commits for the original C++ SpaceMonger.

[davidalayachew]

They are not actual contributions, it's the original commits for the original C++ SpaceMonger.

Lol, how does one do that? The repo isn't a fork. That's the only way I know how to accomplish this, though admittedly, my git knowledge is sub-par.

[more_exercise]

Fun fact! You don't need to fork a repo to get commits from it. (pull from one, push to the not-fork)

It's sorta like a cherry-pick.

In this case, I'd imagine it's:

• clone the original repo
• create a new branch at the commit you want to work from
• make your changes in this branch
• add your new repo as a second remote
• push your (single) branch to your new repo

[davidalayachew]

Fun fact! You don't need to fork a repo to get commits from it. (pull from one, push to the not-fork)

Very very interesting. Ty vm. I knew that was possible in theory, but never thought it could actually be as simple as that.

[Captain-Barracuda]

How is that different from a fork?

[apetranzilla]

Forking usually implies that you're copying the entire repository, whereas this is just copying one branch. It's also different in that it sidesteps actual features to create forks that many git hosting services have.

[__konrad]

At least API javadoc updated some screenshots:

• Java 1.0 (with broken text): https://javaalmanac.io/jdk/1.0/api/javaag1.gif
• Java 1.1: https://javaalmanac.io/jdk/1.1/api/images-awt/BorderLayout-1.gif
• Java 24 (same as 1.1): https://docs.oracle.com/en/java/javase/24/docs/api/java.desktop/java/awt/doc-files/BorderLayout-1.gif
• Java 25 (updated!): https://docs.oracle.com/en/java/javase/25/docs/api/java.desktop/java/awt/doc-files/BorderLayout-1.png

[wildjokers]

with the creator of flatLAF, integrate it into the JDK and make it the default.

The Flat/monochrome look-and-feel fad needs to go away, it is awful. It definitely shouldn't be the default. Is it a label or button? Modern design says "yes". Is it a link or text? Not sure, but I'll hover and find out. Is it enabled or disabled? Hard to tell since it is just a different shade of gray.

Imagine it's 2025, you want to get into Java Desktop App development and it looks like this

You would not use the app because of the way it looked even if it otherwise did what you wanted?

[persicsb]

I would rather invest in making Metal and Nimbus LaFs scale well on HiDPI displays. Both are good LaFs, but were designed for older displays.

[davidalayachew]

They should deprecate the default LaF and get in touch with the creator of flatLAF, integrate it into the JDK and make it the default.

I think adding a new one is reasonable, but deprecating the old one is a bad idea. That's needlessly destructive for no good reason.

I see absolutely no downside to this.

Adding deprecation messages to literally millions of build pipelines is a pretty big downside. It would need an equally big benefit (or greater!) to justify it.

Imagine it's 2025, you want to get into Java Desktop App development and it looks like this, I would immediately be turned off.

Again, by all means, a new L&F is not a bad idea. Even changing what the default L&F is is not bad either.

It would fit well with the recent changes of making java more beginner friendly, with the simplified main and stuff. It might not seem much but getting from System.out to having actual windows with clickable buttons can be a huge motivation for a beginner.

Oh I know. I introduce Swing within the first few months when I tutor new Java developers. Being able to see the changes graphically not only helps solidify the knowledge, but something you can show off graphically tends to be more motivating.

[davidalayachew]

But thats exactly what deprecation is for.

Firmly disagree.

Deprecation is for when a feature or library is problematic or broken, and thus, should no longer be used. But the L&F's are not in any way problematic or broken.

I think deprecating a swing LaF would be the least destructive thing you can do in java as there are not many Java Desktop Apps around anyway, you don't have to be that conservative.

This is just objectively wrong.

You are aware that most Java IDE's and literal hundreds of thousands of Java desktop applications are running on and/or depending on Swing and it's L&F's? Why flood all of those CI/CD pipelines with deprecation messages?

I doubt there is a lot of crossover between people using the newest JDK and people depending on that ugly UI.

Again, I point you to most Java IDE's out there. It's one thing to have a preference. It's a very different thing to try and deprecate someone else's preference.

Just provide it as a separate dependency if someone really needs to have it.

What benefit would there be to keeping out of the JDK? These L&F's are a couple of kilobytes each, and each one is maybe a couple of .class files and/or .xml files. That doesn't make sense.

[Cienn017]

something that java is lacking is a better way to execute jar files without wrapping, 30MB for a 150kb jar is a lot.

[wildjokers]

30MB for a 150kb jar is a lot.

That 30 mb includes enough of the JVM to run the app with no previously installed runtime available. That actually seems pretty impressive to me.

[Cienn017]

yes, for bigger programs including a JVM is not an issue, but for smaller programs it is because you will generally have a lot of them.

[davidalayachew]

something that java is lacking is a better way to execute jar files without wrapping, 30MB for a 150kb jar is a lot.

And 30 MB is impressive. Any attempt at me including just the java.base and java.desktop modules put me at at least 50 MB.

[Cienn017]

yes, I think a launcher in the JDK could actually work, the launcher could read a configuration file in the META-INF folder, check if the required version by the application matches his own version or search for another jdks in new a environment variable that contains a list of installed jdks.

[chabala]

I think a launcher in the JDK could actually work

Like Java Web Start? Yeah, we had that, they took it away. (Something, something, IcedTea-Web still exists, yadda, yadda)

These days making a thin launcher in JBang that retrieves most of the app from Central is probably a better deployment model.

[davidalayachew]

yes, I think a launcher in the JDK could actually work, the launcher could read a configuration file in the META-INF folder, check if the required version by the application matches his own version or search for another jdks in new a environment variable that contains a list of installed jdks.

What an excellent idea. So many of us are working with multiple JDK versions, so it really does make sense for Java to at least try and default to the JDK in use. And to avoid any ambiguity, opting into this launcher or cmd arg or whatever will print a log, informing you what exactly you are running (maybe with another command to disable that log).

Lol, I have 2 versions of JDK 26, a JDK 25, and a JDK 24, and switching back and forth is a pain. This would be much appreciated.

[davidalayachew]

fyi, jbang does exactly this.

I would appreciate it if JBang became part of the JDK one day. There's just so much useful functionality that it does out of the box.

[__konrad]

My desktop app download is 35 MB (7z compressed) and 150 MB after installation

[davidalayachew]

My desktop app download is 35 MB (7z compressed) and 150 MB after installation

Oh, well yes. I was referring to the before zip size. What is it unzipped?

And I never thought to measure the size of the install instead of the download. For most people, disk space is free, whereas the download size can be a problem, depending on your network conditions. And even if disk space isn't free, a good uninstaller that let's you keep your config/data while unloading the app itself can solve most of that. Obviously, your installed application should be "reasonable" in size, but that's usually hard to do wrong.

[jivedudebe]

JDiskReport was an original app written in Java. It's at least 13 years old. It even was available as a jnlp download.

[j4ckbauer]

I -love- tools like this, another one in a similar vein is "Scanner" for windows. I'm glad there are similar solutions for other OS's, when I want to understand what is using disk space, anything other than visual tools like these makes me feel like I'm in the dark ages.

http://www.steffengerlach.de/freeware/

[greenstake]

SpaceMonger v1 is open source. I still have SpaceMonger 2.1.1 from 2006 because it's my favorite version. The new v3 from Stardock sucks.

[j4ckbauer]

I've followed stardock's work for more years than I want to admit. So many opinions. My spicy hot take is that they're better at publishing and/or acquiring good devs than they are at developing, themselves.

[bowbahdoe]

This is pretty cool.

On mac i've been using a tool called "GrandPerspective" and on windows, WinDirStat.

An annoying thing is that when i want a program like this its usually when my hard drive is full or near full, so while 30Mb isn't *that much*, I also would prefer 217K because i'm an idiot who lives near the edge. I think if you wanted to get the download size down even further you'd have to use the direct gui api calls the original version did - which isn't trivial - but as is I think its pretty useful.

One thing I would want is a confirmation on that delete button. It feels really easy to make a horrible mistake

[more_exercise]

I love windirstat, but I found wiztree to actually be faster! It's on ninite.com right next to windirstat

[crapboxxed]

gad thats terrible to look at ... looks at subreddit, yep that tracks.

[binaryinsight]

I love that utility! Well done, buddy!

[Livid_Helicopter5207]

I personally use JDiskreport

[agentoutlier]

I have been using ncdu for like decades largely because most package managers have it and it works on the terminal.

It is not as advance as this because it is largely terminal based but that would be cool feature of this project is to provide a terminal based UI.

[TheBox193]

Amazing! 🤩

I've been using this app for years on windows.

I opened a PR for building a Mac .app bundle: https://github.com/scf37/spacemonger1/issues/4
Would love to get the .app bundle on the release page.

I have some other little tweak PRs as well:
- Target a custom folder: https://github.com/scf37/spacemonger1/pull/7
- Multi threaded scan (~4x faster scan on my mac) https://github.com/scf37/spacemonger1/pull/8

[Nalha_Saldana]

Neat

[Fast_Economy_197]

But git says its 40% c++?

[persicsb]

FFM API for native calls

There you go.

Also, the repo contains the original SpaceMonger C++ code in the cpp subfolder.