[mises]

Maybe because no body had commented as such until now? I am rather practical about this: I don't really like Java because it forces things that make more sense as functions to be under an object. What if I just want a simple global utility function, and don't want to make every single class inherit from a class containing only that? It's a lot of unnecessary hassle for something like that. I'm not saying OO is bad, I said it was too pedantic. I like languages which allow you to do what makes sense.

[pvg]

and don't want to make every single class inherit from a class containing only that

That's not how having a global utility function works in any OO language I can think of.

[mises]

You could also make a class of global functions and use that, but I think the point still stands: it forces square pegs into round holes, so to speak.

[fnrslvr]

> You could also make a class of global functions and use that

I'm not sure I understand your issue with doing this. You need to put your global (i.e. public static) functions in classes not because Java is forcing OO practices into everything, but because classes effectively serve as Java's translation units. I think they serve this purpose pretty well in practice.

[mises]

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).

[fnrslvr]

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?

[pvg]

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.

[pvg]

Any point can still stand if you completely change what you supposedly meant. It's an unassailable, impenetrable point.

A class with some static methods is just a namespace. In Java it pretty much turns OO off.