Who uses a SecurityManager?

Recently I have started playing with the Jersey project. This project is a reference implementation of the JSR311 that aims to implement REST web services in Java.

One of the features that Jersey has is an injection of values into the private fields of the object. What do you think about this feature? From one perspective it can be nice that you don't have to declare the setter methods, so none can accidentally change the value from outside. However, when I declare private field in my class and I don't declare setter method I want none to access it at all. Even not using reflection. Right?

Previously I knew that Java has a SecurityManager class that is responsible to allow and disallow such an access. I knew that by default applications has no SecurityManager, but I have always thought that in production most of the applications run with the SecurityManager.
I must admit that I used to support production environment only once, and that time I was kinda "business layer developer", so I didn't know much about the core, security and stuff like this.

Personally I have never allowed myself to write code that can contradict with the SecurityManager, unless it was a code that was supposed to be run from a batch (e.g. ant script) or a plugin to an IDE.

And now I suddenly got framework by SUN (!) that contradicts with the SecurityManager. What does it mean? Does SUN expects the users of Jersey not to use the SecurityManager or to configure it in some specific way? Or may be SUN themselves assume that none uses SecurityManager in real life?

As you see this post contains more questions than answers. Thoughts and ideas are appreciated.