Category Archives: Java/Java EE

Refactoring JUnit 3.8 to 4.0 when hierarchy extends TestCase

Posted on by
Reply

Problem:

I want to start writing tests in JUnit 4.0, but I have a lot of tests in JUnit 3.8.  I can’t just start writing tests in 4.0, because I rely on common setup/assertions in my custom superclass which extends TestCase. (Which means JUnit will only look for 3.8 style tests)

Solution:

Create one or more new classes to contain static method equivalents that you need.  The new code can use static imports to get these methods.  The original abstract class can delegate to them.

Limitations:

Some frameworks require you extend a certain class.  Until the framework provides a non-JUnit 3.8 dependency, there’s not much you can do here.  You can still use this approach for tests that don’t require that special framework.

UML for refactoring:

Sample code:

package com.javaranch.asserts;

import static com.javaranch.asserts.JavaRanchTestUtil.*;
import junit.framework.*;

public abstract class AbstractJavaRanchTestCase extends TestCase {
   @Override
   public void setUp() throws Exception {
      super.setUp();
      setUp_propertyConfiguration();
   }
}

Conclusion:

I’ve done this refactoring enough times that is second nature by now.  This blog post documents the refactoring since I’m not finding it on the web.

What other problems/sticky situations have you encountered when mixing JUnit 3.8 and 4.0 code?

Plugging Video & Image Memory Leaks in Adobe Air

Posted on by
1

Adobe AIR is known for memory leak issues, especially in regards to loading and unloading video. I have seen applications with alternating video and images crash unexpectedly after running for only 20 minutes with no user input. After doing some investigating on my own, I can confirm what others have said in the past: You have to take extra steps when unloading a video or image, or risk a serious memory leak.

Removing Images: Clear the “source” attribute
Let’s say you want to unload a set of images from display object myContainer. The obvious solution would be to myContainer.removeAllChildren(), but unfortunately, this is not enough to recover the memory for the images. To truly recover the memory, you need to call:

for each (var child:DisplayObject in myContainer.getChildren()) {
   if(child is Image) {
      (child as Image).source = "";
   }
}
myContainer.removeAllChildren();

My thanks to Russell Brown for this non-trivial solution. I can confirm his results; implementing this solution significantly reduces memory leakage.

Removing Movies: Close the movie
Next, let’s say you want to unload a movie. Most people would just stop the video and remove it from the screen but like the issue with images, this is not enough. Developers should use the following code to properly unload a movie and recover the memory:

for each (var child:DisplayObject in myContainer.getChildren()) {
   if(child is VideoDisplay) {
      (child as VideoDisplay).stop();
      (child as VideoDisplay).close();
      (child as VideoDisplay).source = "";
   }
}
myContainer.removeAllChildren();

Granted, this code assumes you may have multiple movies in your container, although it can be combined with the previous solution to remove images and movies at the same time. Thanks to Ryan Phelan for their groundwork discovering this issue.

Adobe’s Broken Garbage Collector
For whatever reason, simply removing an image or video from the scene and setting references of it to be null is not enough for the garbage collector to recover the memory. If you have an application that cycles through two movies, for example, you may see the memory continue to grow drastically over time as all the previous copies of the video are kept in memory. Hopefully, Adobe will resolve this in future versions of the AIR runtime, but in the meantime developers must take extra steps to sure items have been unloaded and memory reclaimed.

The “Reinventing the Wheel” Anti-Pattern

Posted on by
1
Reinventing the Wheel As a moderator on the JavaRanch, I often come across posts asking how to reinvent features that are available in most application servers. In JDBC for example, I’ve had people ask how to implement their own database connection pooling and how to create their own JDBC driver. Often times the developer is trying to create something that already exists, but they are unsure how to use it. The general rule of thumb I tell programmers is, “If you feel like you are reinventing the wheel, you probably are”.

Review the API
If you ever get the feeling you are inventing the wheel, it’s a pretty good indication you are. In such situations, ask yourself “Is it likely a developer using the same component would need functionality X?”. If the answer is “yes”, then there’s a good chance there’s already such a feature in the API. Most often, reinventing the wheel comes from developers who are too lazy to review the API but not lazy enough not to rewrite the feature they think they are missing. Also, search the web. In some cases, you may need to download a new or updated library to get the feature you want, but this may give you access to even more features.

Your wheel isn’t better
Often called “Reinventing the square wheel”, it is likely the code you are recreating is worse, more buggy, and far less stable than the code you should be using. If you consider it for a moment, it makes sense a method built within the API should be better than a method built on top of the API. The API developer has access to private methods and objects that you do not have access to, and therefore your solution is limited by the public/external methods of the API. Furthermore, the fact the code is part of the API means scores of developers have hopefully reviewed the code for errors and performance enhancements.

That doesn’t necessarily mean the API implementation is better, but whenever I hear a developer say “I have a faster and cooler way of doing this than the way they do it in library” I cringe at the thought of what they may have written. If you do happen to create a better wheel, join the open source project and publish it for others to judge.

There’s always public humiliation
Many of the worst best articles that appear on the The Daily WTF come from programmers reimplementing the most basic functions of a language. One of the things that separates an experienced programmer from a beginner is the ability to recognize what tools in the API are needed for a task and how quickly they can be put together. And with that, I present a list of examples written by real developers and posted online for the world to see:

Any my personal favorite: I’ve heard from some good sources that the next version of SQL will use the word “GIMMIE” instead of “SELECT”