I believe you can achieve the same in Java by static import.
EDIT: Also, I think the parent comment was not complaining about the missing possibility of creating standalone functions, but rather saying that not every functionality can be forced into objects, i.e. there is still need of standalone functions in OOP.
You still have to put each method in some class in java, in C++ you can just put it in namespace. It makes more sense, even if in practice the difference is minimal.
> there is still need of standalone functions in OOP
I think it's more than just syntax - it's culture. In C++, free standing functions has been a part of the culture of the language since the beginning. The design of the language encourages them - there are even cases, such as operator overloading, where it's preferable to implement it as a free standing function rather than a class method. In Java, when I write a class that is a collection of static methods, I feel like I'm fighting against the language and it's culture, even though they are sometimes used.
Such functional namespaces were part of Java from the very beginning (Math is a good example and with release of Java 8 now there are many more in standard library). I have not seen an enterprise project yet, in which there's no something ending with Utils or Helper, that is just a collection of functions. Such naming is an anti-pattern, of course, but still, almost every developer in Java world uses this and has it part of it's development culture.
Yes, that was the point I was getting at. It's obviously part of how real Java code is written, but I feel like I'm going against how the language was designed when I do it. (Clearly, everything is not an object, and a class is not always the most appropriate way to group code.)
I add the example of Ruby's modules, that can be included in other modules and eventually classes. Combined with dynamic typing they provide a way to import very generic functions, even if they end up being methods (everything is an object in Ruby.)
Erlang and Elixir are a kind of trade off between functional and OO languages. Formally they are fully functional but their processes (a first class construct) are objects by all means. Processes receive messages (equivalent to method calls) and respond by sending other messages (the caller must pass its process id inside the original message.) We could say that OOP objects are castrated processes because they don't multitask.
What I noticed is that an Erlang/Elixir application has many function calls but far fewer processes/objects than objects in OOP programs. Processes usually encapsulate the main data structures. The equivalent of a Java ArrayList would be a process but its elements don't necessarily need to be processes. Pattern matching and some syntactical sugar help (example: http://culttt.com/2016/04/11/working-keyword-lists-maps-elix...).
Maybe those languages are a more equilibrate middle ground between the extremes of pure OO and pure functional, with the advantages of concurrency and all the external but mandatory infrastructure inside the language (deployment, supervisor trees, etc. - a part of devops.)
Languages that were actually designed to be functional-first, but multi-paradigm, like F# also support this.
Though to be honest, not allowing free functions in Java or C# is kind of silly. It seems like the compiler could pretty easily autogenerate a static class per namespace to actually stick them into, so that it would really just be a bit of syntax sugar.
