thanks for sharing your view.
The java.lang.Math class has been the subject of much debate since it was introduced as part of the standard library, and lots of people smarter than me have weighed in on whether it's OO or not, so you'd do well to research what they say and decide for yourself. I think the overall consensus is that it is indeed not in line with the core principles of OOD, and the original designers knew that, but did it anyway for performance reasons.
The main issue that had to be dealt with was this: Java could not be a 100% OO language when it was first introduced because there was a legitimate argument that without primitives of any kind, it would be too slow. So int, char, float, double, all these things made it into the language. Now the problem becomes, we have none objects and we need a sensible way to deal with them. The best thing to do is to encapsulate off to the side a library of functions that look more like code from the procedural world than OO. So that's where Math comes from.
So what have we learned? OO is not a simple boolean state...most languages do not cleanly fall into the category of being "OO" or "not OO". C is an example of a language that does fall neatly into "not OO". Smalltalk is an example of a language that falls neatly into "OO". C++ is a hybrid language that has the *capability* to allow OO programming, but it does absolutely nothing to enforce that OO programming is done. Java is much more OO in that it enforces several basic OO programming principles (no globals, you can't add new primitives, etc), but it cannot be assigned to the "OO" category because of things like ints and java.lang.Math.
I hope this does nothing to denigrate the language in your eyes--it's still what it is, a useful programming language that expresses OO designs simply and clearly.
The moral of this story is: don't mimic the Math library in your own code unless you are dealing exclusively with primitives and encapsulate it off to the side as a bit of functional, procedural code in an OO world. :-)
Having static methods or data is decidedly not against OO design principles in and of itself. Like anything else in OOP, though, it can be misused in a non-OO way, just as one can have an Automobile class extend an Engine class or vice versa instead of having Automobile aggregate an Engine instance.
Thanks for your reply .