It's certainly not idiomatic in Java, C# or most any OO language to have a lot of static methods that make assumptions about the state of the universe (typically indicated by use of static variables). I've experienced the pain of untangling at least two large-scale applications and one integration test project that introduced static variables everywhere, including one that only allowed one user to be instantiated at any given moment, because the static User.getUser() method was the only way to get an active instance of the user class. That was very painful.
However, it was bad code. I've seen bad code just like this in C#, in Perl, and in C++. It's a crutch that a certain category of procedural programmers reach for because it feels kind of familiar. Global state is easy to understand, until enough code has been produced that it isn't.
There are a few things for which global state makes sense, but in an idiomatic Java application, these should be confined to not much more than a logging framework (so that you can call something like LogManager.getLogger("somename"), the global dependency bindings map that might be required by a dependency injection framework, and perhaps something that is fairly expensive to build, like an object-relational mapper's session factory.
If you're using Spring sensibly, dependency lookup is typically confined to a narrow part of the application. I've seen Spring used essentially to implement the Service Locator pattern, which essentially has each class constructor ask for its dependencies by calling out to Spring, but this is just asking for pain later and usually frustrates testability, since unit testing shouldn't need to rely on the dependency injection framework. Instead, the locus of Spring usages should be small: I usually have the controller factory in an MVC project build the dependencies needed. For services, there's also usually a reasonable place that you can hook in that's relatively narrow.
Considering that J2EE was sort of an architecture-astronaut version of object purity, I'd almost be more surprised to see lots of static (global) state in a J2EE app. However, knowing that a lot of junior engineers who don't quite know how to do loose coupling sensibly and senior engineers entrenched in procedural ways of solving problems are often thrown at a large-scale project, it's not actually that surprising to see a spaghetti and meatballs approach to a poorly understood problem domain when just the right combination of the wrong people was put on a project.
