CODEWITHSUNDEEP
javaunit-testingoopstaticmocking
Paul Stanley
Paul Stanley

Reputation: 4098

Objects made in static calls in java/static mocking

Say I have a static method in java. I wrap the static method in a method like this, so I can 'mock' the static method in testing by mocking the new getInterestingString method: 

Class AClass{

    private static String getStaticString(int parameter){
        Something something = new Something(parameter);
        return something.doSomethingThatReturnsAString();

    }

    public String getInterestingString(int parameter){
        AClass.getStaticString(parameter);
    }

}

After reading how static mocking frameworks work, I am not really thrilled with the idea of the frameworks manipulating the byte code in order to mock their responses, thats a bit hack and slash.

That, and static calls are useful when used correctly (like anything thats useful), but say I am refactoring a legacy app where static calls are there and I have to deal with them whether I like it or not, and I want to make the static calls mockable like above, and I can't change the static method out because of time constraints for example.

My main question: So an object gets created in static method : it isn't needed after the result has been returned, ever. What happens? Is it something I need to worry about efficiency wise?

Other stuff: Help me out with anything I have said here, or if this method has been documented somewhere let me know, as I don't want to poison my codebase and I don't know anything.

Upvotes: 0

Views: 71

Answers (1)

Chris K
Chris K

Reputation: 11917

My main question: So an object gets created in static method : it isn't needed after the result has been returned, ever. What happens? Is it something I need to worry about efficiency wise?

If there are no references held to the object, then it will be released by the GC at some point in the future. The overhead of this on modern platforms is very low, the cost of an allocation is usually just a bump of a pointer local to a thread and the cost of the objects initialisation/constructor. The cost of GC would be free, as the cost of GC is related to how many reachable objects are on the heap. This object would be unreachable, and thus would not have a GC cost. I should note that I am assuming that the object has no destructor method; if it did then there would be a cost; but who uses those these days? If a reference to the object did survive long enough for a GC to occur, then the cost would be the time it takes to detect that the object is reachable and to copy the object between survivor spaces. Which would be measured in microseconds for any normal sized object; BIG objects, eg large arrays can take longer to copy.

In normal applications this minor cost is nothing to worry about. If however it appeared in a loop with millions of iterations, which is not uncommon in a financial or scientific calculation then the cost would be magnified and one would risk a high GC burden. In very low latency applications, GC pauses have to be avoided and thus anything that allocates an object will risk moving the time to next GC pause closer and so is to be avoided. However for all other applications, and unit tests then do not worry about a low microsecond costs. Just printing to stdout costs us more.

Upvotes: 1

Related Questions