You wouldn't inherit from java.lang.Math if you just wanted to use it, you'd
just import and use that package. You'd only inherit if you wanted to create
your own custom version that changed the functionality in some way (eg. change
tan() so it returns NaN instead of throwing an exception where the function's
undefined). And if your XML parser does in fact use functions and data types
defined in java.lang.Math, you want to introduce that dependency. You
don't want multiple definitions for the same thing running around unless there's
a really good reason for it (like they're not really the same thing, they just
look like they are). The problem isn't from true dependencies where package 2
really does use package 1, it's bogus dependencies where package 1 isn't used by
package 2, isn't used by anything package 2 uses, but gets pulled in anyway only
because it happens to be in the same container as something that is needed. [ Reply to This | Parent | # ]
|