Show HN: Minum – A minimal Java web framework

> What does ‘minimal’ even mean though?

It doesn't include the batteries.

The batteries - extra features - weight you down if you don't need them. So you'd better be able to avoid them. Large projects can be hard to audit to remove things which could be nice and often useful - but just not in your case.

Smaller projects have an advantage that you can easier understand them and decide what you need to add and, crucially, how to add that better, from your personal viewpoint. It's really hard to have nice, tiny, composable building blocks, so we have rather few attempts at that. Actually, a big part of programmer's education is teaching him how to properly write something which is well known, just have many small variations which depend on both requirements and some preferences. With a smaller project you can see those choices easier - and have better chance to correct them the way you need.

> The minimal/zero-dep solution will have have bugs that have already been fixed or avoided by battle-tested libraries

Maybe. Maybe not - you need to have all branches of execution checked, and with all possible input data combinations - and then all problems to get noticed and, crucially, corrected. Some problems, like unnecessary delays, can avoid e.g. representation in the logs.

On the other hand, with smaller projects you have less moving parts and better visibility where, and how, things could go wrong. If you want ultimate reliability with proofs, you'll find it easier going with smaller projects.

So, as they say, there are programs so simple they're obviously correct and so complex it's not obvious which errors they have.

You're correct ... in theory.

At least in this project example code, i see tons of empty class like Result.java with empty content, on separate file.

So is this normal convention for Java dev ? No eslint (or similar tool) to prevent boilerplateness ? That's my point.

Do you Java dev have strict standard on prevent such things spread on all codebase, ecosystem,... ?

Awesome, love to see more Java devs pushing back on the spring madness.

In Db.java, with the write/update/delete locks, that mutate both in memory and on disk, is there not a bunch of race conditions there?

I'm reading it as "minimal in scope". Scope creep tends to be a given for established/battle-tested libraries, and I'd argue that over time scope creep could counteract security benefits of being battle-tested.

Note that I'm not basing this on data, just on my intuition that a lot of major security bugs seem to be related to obscure/infrequently used functionality.

I didn't see looping support for templating, like for rendering collection to HTML table. Did I miss something?