Maven Runs out of Memory

Maven 1.0 has some problems with memory leaks. Most of the time these aren’t issues, but if you are trying to compile a multiproject you might run into problems. By default Maven tells java to let it have up to 256MB of ram. If you need to increase this you’ll need to open the maven.bat (windows) or (unix) file and change the way that java is called. Somewhere around line 118 (on the .bat file)you should see the following:

if "%MAVEN_OPTS%"=="" SET MAVEN_OPTS="-Xmx256m"

Change the line so it reads:

if "%MAVEN_OPTS%"=="" SET MAVEN_OPTS="-Xmx1000m"

This will give Maven 1GB of memory to work with. While this doesn’t really solve the problem of the memory leak, it may give you enough space to keep the problem from crashing Maven.

You can also set MAVEN_OPTS by setting it up as a variable in your environment. If you do this the environment will override anything you set in the .bat or .sh file.

Why Java Won’t Get It Right

Why Java Won’t Get It Right is an interesting entry about some of the problems with Java technology. The best part is that it is written by someone who actually knows Java. A part that I particularly liked was:

They over-architect everything. I’ve actually used a Java framework (I’m not gonna say which) that had XML config files that configured more XML config files! That’s just silly.

The author makes comparisons to Ruby on Rails and talks about how he doesn’t think Java will ever have anything like Rails.

I’ve seen a few demos of Rails and it is impressive, but much of the functionality it gives you has been available in WebObjects for some time. In fact I’ve met several Ruby developers that started with Rails and switched to WebObjects as their application got bigger. (Update: It turns out I was mistaken. They switched from Ruby to Webobjects, but they were using a different web framework instead of Rails.)

There is an interesting comparison between a Ruby project and a Java project posted on the Ruby on Rails site. The code comparison is interesting because it shows how much Ruby does for you automatically if you know how to use it. A lot of what Ruby is doing is giving you automatic setters and getters.

It would be interesting to see a comparison between the amount of code necessary to write a Ruby application and the same app in WebObjects, but when it comes down to actual productivity the language being used is rarely the bottleneck. The skills of the programmer are by far the most important factor. The tools available in the language are second and the language ranks third or lower.

Good tools have a huge impact on productivity. Simple things like auto-complete and real time syntax checking cumulatively make a large difference in productivity. One of the areas where WebObjects really shines is in giving you the ability to graphically connect your data with the view. You can still do everything manually in code, but the graphical tools give you the ability to really think about the problem on a level that is much closer to the user experience.

Thread.sleep() problem

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();
            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

Entry Level Java Certification (SCJA)

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)”

Comparable vs. Equals

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.