I'm working with BigDecimals and I have the requirement that a division by 0 should not result in an ArithmeticException, but in returning 0 instead (weird business math).
This is a rather new requirement and we already have quite a bit of code, which uses BigDecimals in a lot of places. I don't want to go through all these places and implement zero checks. This also would not help me with 3rd party libraries, which might internally use BigDecimals and will throw an ArithmeticExceptioninstead.
I'd also like to set a default precision/scale and change the compareTo method to able to ignore small rounding errors.
Because of all these global changes which would create a lot of "boilerplate" code, I came up with the idea to change the implementation of BigDecimal. I've already done this before for other 3rd party classes to fix certain bugs myself.
I replaced those classes by creating a class with the same name in the same package like the 3rd party class, and because the external jar files will be loaded after my own classes, I was able to replace them.
But creating a java.math.BigDecimal didn't help me, because it seems that the "native" Java classes are loaded even before my own classes.
Let's assume that I really want every single BigDecimal in my application to work a bit different, how would I be able to replace the "official" BigDecimal? Am I allowed to do that, and could there be some other, technical problems I didn't think of now?
You have to put your classes in the "bootstrap" classpath if you want to override builtin classes. as to the wisdom of actually doing this (i.e. your changes will affect the entire jvm)...