Three of the newest features in Java 1.4 were all things we had to invent back when I was building/architecting the last product I did.
- java.util.logging - A robust logging facility.
We built our own early in the project, but what I can build in a day really isn't as "feature rich" as one that comes as part of a standard API. Although, I'm thinking ours is probably easier to use.
- getStackTrace() - Direct access to the stack.
As part of our logging, we wanted to "automagically" have the logger know the class and method that invoked it, to be able to print it out in the logs. People are forgetful, not to mention lazy, and asking programmers to have to remember to put in the class and method name in every log call seemed painful. So, we rolled our own.
Manually parsing the output of printStackTrace() isn't hard, but the problem comes when you switch JRE's. Sun's stack trace is different from IBM's, for example.
Well, to be truthful, we never did find a good way to implement assertions in our code, which would have been perfect for testing preconditions and postconditions. lindsey and I felt that writing to a "contract" was important. Methods should have defined results, and no undocumented side-effects. The best way I know of to acheive this is through the use of assertions when entering and leaving a method. Of course, that theory encourages the use of single exit points in methods, which I generally think is a good idea anyway.
The way we worked around it was through liberal use of a unit testing framework. Of course, you really need both, but we survived.