However, there are two steps that are not done:

1. Set up the M2_REPO environment variable in Eclipse
2. Download and install JTA

For the first, I found the following command:

mvn -Declipse.workspace=
 eclipse:add-maven-repo

And for the second problem, I found the answer on JUGPadova website. In short, the problem has to do with Sun’s licensing of some of their J2EE jar files. Once I downloaded the JTA.1.0.1B.jar file, the following command put it in place and took care of all remaining errors in my Eclipse project.

mvn install:install-file \
  -Dfile=./jta-1_0_1B-classes.zip \
  -DgroupId=javax.transaction \
  -DartifactId=jta -Dversion=1.0.1B \
  -Dpackaging=jar

The trick comes when you need to scale this up to more complex domain objects which have more then one or two attributes. So for example, how does this translate when you have a Class that represents a person. If that person’s name changes, does that make them a new person? Probably not. However, if their address changes, and the address is represented by an object composited within Person, then you can make a very strong argument that it represents a new address. Therefore, a new Address object needs to be instantiated.

The same argument could be made for a person’s email address or phone number.

This idea becomes important when you think about creating multi-threaded systems. Having all of your domain objects immutable means that they are all read-only. This means that you really do not have any shared resources between threads and it reduces the complexity of the entire application.

I am still thinking all of this through and have yet to try any of it on a real life application. In theory though it makes a lot of sense, but I am not sure how well it will work in practice. I think there will always be some information in domain model objects, or any class for that matter, that it makes sense to have change and thus violates this idea of having all objects be immutable.

I have scoured the web to find a solution to this and have come up empty handed. I basically need a solution that configures Log4j to, when the current log file is deleted, create a new file. Anyone have any ideas?

So far my best advice has been: don’t delete the log file .

I was working on an Ant build script today in Eclipse and wanted to change the default editor behaviour to use spaces instead of tabs. So I wandered into the Preferences section. I know the setting is not going to be under Java, so I try the General tab, no luck. Finally, I try the “Web and XML” tab. Sure enough, there is a tab for XML files under which I can set the “Indent using spaces” option and press apply.

I then go back to editing my build file and it is still using tabs. Apparently, to Eclipse, a build file is not an XML file. So back into the preferences I go. This time I see the Ant tab and am able to set it to use spaces there.

Something as fundamental to programming as the option of using Tabs or Spaces should be obvious and easy to set for every editor. This is one area that NetBeans has Eclipse beat hands down. It is very easy to set editor styles in NetBeans. Granted, Eclipse’s editor styles and setting are more powerful, but they are also incredibly complex and confusing.

Every time I go looking to set spaces instead of tabs for the Java editor, it takes me at least a half hour of searching and hunting. This is because it is not even an option. Instead, it needs to be configured via the Code Style Formatter by either creating a new style or modifying one of the default styles.

What is the saying, “Make the simple things simple and the complex things possible”? This is one area that Eclipse makes what should be an easy thing incredibly complex. i think this is Eclipse’s biggest downfall, it simply is not simple to use. Nothing is intuitive about the application. True, it is very powerful and configurable. I guess that it is why it is the number one IDE, but simple it is not.

I use Eclipse all the time, but for new programmers I always recommend NetBeans because it is simple to use and easy to start working with.

Here is a small trick for working with NetBeans and Ant build files. One problem with NetBeans is that if your source code already has a build file, NetBeans will use that build file. Unfortunately, when you do this, you loose a fair bit of NetBeans functionality like the ability to run individual JUnit test classes. You can test the entire application, assuming that you have setup a JUnit test target in your build file, but you cannot run a single test. This little trick gets around that.

I have to start by saying that this trick is fairly obvious. The trick is to rename the build file. Instead of calling it @build.xml@, call it something else. This will allow you to setup your project, in NetBeans, as a “project With Existing Sources” instead of a “With Existing Build Script”. This means that NetBeans will create its own build script and give you the full functionality and power of NetBeans.

h3. Refactoring Build Scripts

If you have an application that is divided into several different projects that you would like to manage with separate build scripts, but not necessarily different build scripts, then this trick will work. The idea is to use the “DRY(Don’t Repeat Yourself)”:http://en.wikipedia.org/wiki/Don’t_repeat_yourself principle. Take all the parts that are the same in the build scripts and put them into a separate file. Then import that file into the build scripts for each project.

The advantage is now when you have to make changes, you only need to go to one file. You no longer need to edit one file and then copy-paste those changes into several more files. This saves you from copy-paste errors or forgetting to change a file.

bq. The initial release today will include the HotSpot runtime, javac compiler, JavaHelp, and Sun’s Java ME implementation. The rest of Java will be released under GPLv2 early next year. (“Javalobby.org”:http://www.javalobby.org/java/forums/t84244.html)

The interesting part of this release is the inclusion of a Classpath Exception which

bq. permits you to link your code to open source Java without forcing your code to fall under the GPL as well. (“Javalobby.org”:http://www.javalobby.org/java/forums/t84256.html)

In addition to the open source GPLv2 license, Sun is going to dual license Java so that commercial entities can use it without having to worry about the viral nature of the GPL, even though the Classpath Exception is, as I understand it, suppose to handle this.

In order to help us with this transition, “Sun has set up an FAQ page”:http://www.sun.com/software/opensource/java/. In addition, there is also the “OpenJDK website”:https://openjdk.dev.java.net/.

The following links have more information:

* “Open Source Java Editorial on Java.net”:http://today.java.net/pub/a/today/2006/11/13/open-source-java-editorial.html
* “Java GPLed on the O’reilly onJava.com website”:http://www.oreillynet.com/onjava/blog/2006/11/java_gpled_1.html?CMP=OTC-FP2116136014&ATT=Java+GPLed

As I find more links of interest I will post them here.

bq. This article is an in-depth examination of one of the simplest but most pleasing features in Java 5.0–the @for-each@ loop. I present eleven short items discussing various nuances of usage, pitfalls to be aware of, and possible optimizations surrounding the use of the @for-each@ loop. In the first section, I discuss what kind of iterations are possible with the @for-each@. The next section illustrates common programming errors in using the @for-each@ loop. The final section shows how to write new classes that can be used as targets of a @for-each@ loop. I also talk about advanced implementations that allow multiple iterable views; lazily construct objects just in time for iteration; and enable possible generic algorithm and compiler optimizations of the @for-each@ loop.