Classes being Java's only translation units are one of the downsides that I'm mentioning. Really my objection is more that it doesn't allow use of the right tool for the job (which is not always an object).
I'm not sure I see where objects enter into this. I mean, you seem to be asking for something like this,
public unit Util {
public void foo() {
// do things
}
}
which would compile down into a bytecode-containing artifact which we could call a unit file, which the JVM would load at runtime using some sort of unit loader. Callers could import the Util unit and then invoke foo with the statement
Util.foo();
But then, I don't see the diffence between the above and the following,
public class Util {
public static void foo() {
// do things
}
// If we're really pedantic, we can ban construction of Util instances
private Util() {}
}
which compiles down into a bytecode-containing artifact called a class file, which the JVM loads at runtime using a class loader. Callers can import the Util class and then invoke foo with the statement
Util.foo();
What's this downside you speak of? Is there something a different kind of translation unit would do that a class currently doesn't?
There's no 'object' involved here. First you said this requires subclassing, which it doesn't. Now you're handwaving about a feature that's specifically there to allow for things like plain global functions - a static method has no instance, there's no dynamic dispatch and it can't be overridden. People often point out the facility's utter un-OO-ness. The OO equivalent would be a class method which Java doesn't support at all.