title: Why do standard classes sometimes have seemingly unrelated methods?
body: <p>While studying the standard Java library and its classes, i couldn't help noticing that some of those classes have methods that, in my opinion, have next to no relevance to those classes' cause.</p>
  
  <p>The methods i'm talking about are, for example, <a href="http://docs.oracle.com/javase/7/docs/api/java/lang/Integer.html#getInteger(java.lang.String)" rel="nofollow">Integer#getInteger</a>, which retrieves a value of some "system property", or <a href="http://docs.oracle.com/javase/7/docs/api/java/lang/System.html#arraycopy(java.lang.Object,%20int,%20java.lang.Object,%20int,%20int)" rel="nofollow">System#arraycopy</a>, whose purpose is well-defined by its name.
  Still, both of these methods seem kinda out of place, especially the first one, which for some reason binds working with system resources to a primitive type wrapper class.</p>
  
  <p>From my current point of view, such method placement policy looks like a violation of a fundamental OOP design principle: that each class must be dedicated to solving its particular set of problems and not turn itself into a Swiss army knife.
  But since i don't think that Java designers are idiots, i assume that there's some logic behind a decision to place those methods right where they are. So i'd be grateful if someone could explain <strong>what that logic really is</strong>.</p>
  
  <p>Thanks! </p>
  
  <p><strong>Update</strong></p>
  
  <p>A few people have hinted at the fact that Java does have its illogical things that are simply remnants of a turbulent past. I reformulate my question then: why is Java so unwilling to mark its architectural flaws as deprecated, since it's not like that the existing deprecated features are likely to be discontinued in any observable future, and making things deprecated really helps refraining from using them in newly created code? </p>