Is it wrong to have static and non-static methods in the same class?
Not really in regular java programming.
But if you're working extensively with dependency injection you probably have few or no static methods at all. In such a context it's fairly common to have only a few utility classes with static methods, and no other static methods.
No, it's not wrong. For example, a common use is to have static factory methods in a class definition.
I think it's fine to create static utils classes, especially when you're not really sure (yet) what the design should be, because you're still learning about the problem domain.
Staticness is a "yet to designed properly" marker. Often the static solution is perfectly adequate; but sometimes, as the project progresses, you find you do have to rewrite that "whole part", but you have (at that later stage) a far more complete understanding of the problem domain, and are therefore in a position to actually design a "proper solution" to those problems.
I think us programmers hammer ourselves unfairly about "rework". You need to do the work in order to understand the work well enough to do the work properly. I see no way past this catch 22;
I can cite many examples of static from the core API. java.lang.Math, java.util.Arrays, java.util.Collections. BUT please note that these classes are "utils classes" which exist only to provide a bunch of static methods. IMHO, The presence of static methods in a "stateful object" is just begging to be refactored.
I'll betcha that todays API designers would love to be able to split-down Integer (and the other wrapper classes)... BUT they're well and truly stuck with what they've got. Which is a warning in itself... that static implies final, and there's a darn good reason that (unlike C++) java methods can be overridden by default. Static is inherently more "binding" than non-static... down the trick you CAN NOT adapt implementations to different situations, contexts, etc, etc, etc.
Cheers. Keith.
I believe its a bad idea to have static and non-static methods in the same class with the same name. This can be very confusing. I would suggest trying to make the names different in this case.
Similarly, don't make methods with the same name but different case, or methods with the same name as the class in the same class. Both are legal, and even occur in the JDK, but are confusing IHMO.