Mark Shead

The following is a JUnit test that looks like it should always run without a problem. Mark the current time in a variable called start call Thread.sleep and tell it to sleep for x number of seconds, note the current time again in a variable called end and then assert that end - start is going to be less than or equal to x.

    public void testThreadSleep() throws Exception {
        long start = 0;
        long end = 0;
        long elapsedTime = 0;
        for(int i = 1000; i < 1500 ; i = i + 20){
            start = System.currentTimeMillis();
            Thread.sleep(i);
            end = System.currentTimeMillis();
            assertTrue(i <= end - start);
        }
    }

However in acutally running this code the assertion is not always true. It appears that when you try to call Thread.sleep(x) it may not sleep for the entire x milliseconds. Obviously it might take longer than x because a thread isn’t guaranteed to run. There might be another thread with a higher priority or the system might be doing garbage collection. However I would expect that it wouldn’t run less than the specified amount of time, but that is what appears to be happening.

I believe this has to do with the way that the JVM operates. Evidently it may wake up a thread a few milliseconds before the appointed time. It is possible that it may be anticipating garbage collection and waking threads up slightly early

According to some posts on Java Ranch, Sun is looking to create a Sun Certified Java Associates exam. The idea is to have an exam that companies can use to certify entry level programmers. I’m not sure why this is better than the current Sun Certified Java Programmer certification. It sounds like they want a certification that is easier to pass for someone with less experience. I didn’t find the SCJP exam all that difficult. In fact I didn’t even bother to put it on my resume, but after reading all the comments at Java Ranch about how difficult it is to pass maybe I should.
Continue reading “Entry Level Java Certification (SCJA)”

Agylen: Comparable vs equals has a nice discussion of how compareTo is used in Sets.

If you don’t understand how Java is going to use your compareTo and your equals methods you can run into a problem with Sets. Basically you shouldn’t have a compareTo() method that returns 0 unless equals() returns true.

Since a Set only allows once instance of each object, it will ignore the addition of any objects it already contains. If your object implements the Comparator interface the Set will check the compareTo method not the equals method.

It is common to write compareTo methods that only look at one field. For example, you might want to sort Person objects by their last name and then first name. If you only check the last and first name field, then comparing two John Smiths would return 0 even if they were different objects. This would cause the Set to evaluate them as the same object and prevent you from adding the second John Smith to the Set.