A plain int field is still different from a volatile int, because in the Java Memory Model different threads could see different values in the same int field because of caching, etc. (of course in reality this might never happen, it depends on the actual architecture of the OS, etc.) Marking a field as volatile implies a memory fence, and also stops the JIT from re-ordering statements, which could also break assumptions about the field. So there is a difference, but it's not always obvious.
Pre-Java 5 this was all a bit of a mess, and many JVMs didn't support volatile longs properly - with Java 5 things are much better, and the semantics are cleaner.
See http://jeremymanson.blogspot.com/2008/11/what-volatile-means-in-java.html for a nice overview and http://gee.cs.oswego.edu/dl/jmm/cookbook.html for the gory details
Getting back to the issue, using volatile doesn't imply a dependency on Java 5 - unless you're relying on specific assumptions (like the double-checked locking idiom). We already use volatile in other places in Felix that have high contention, the question here is whether using volatile will break the bundle state machine - will need to look more closely at this code to be sure. ie. if only one thread is writing to the state and all other threads read it then volatile is fine, the problem is if two or more threads need to both read and write to it concurrently.