Java memes which refuse to die (javacodegeeks.com)

I haven't actually seen a Factory Factory in a while. I think Dependency Injection has pretty much killed that anti-pattern.

Factory factories USED to be a problem in my Java programming, but they aren't anymore because I created a configurable builder class for generating my factory factories. I call it FactoryFactoryBuilder, and it completely eliminated the factory factory problem.

StringBuilders are verbose, but they do make a measurable difference in your code.

The problem with no using them is that then you need to be sure your code is never called by something else that runs it in a loop.

A fair while ago (JDK 1.5 had just been released, so I was still looking at StringBuffer) I did some analysis on the bytecode generated by concatenation.

There is a pretty significant difference:

http://nicklothian.com/blog/2005/06/09/on-java-string-concat...

Using a public field removes one of the major benefits of object-oriented design. Don't misunderstand me: in many cases, really all you need is a collection of related fields and making them public is indeed OK - like a struct in C.

But I tend to err on the side of safety with my fields - private member, public accessors - while I work out my modeling and refactoring. When the design settles, then I can relax access if it's OK. And when something changes in the design (atomicity requirements, immutability, etc) I already have most of the boilerplate in place. Mostly though, I keep my accessors.

On a related note, do Java IDEs not provide boilerplate code? I'm more an Objective-C guy and the language now supports "here's a property" and "create the accessors" alongside my needs for custom ivar names, custom setters, etc. Even if Java the language doesn't have similar features, I'd expect IDEs to give you this kind of boilerplate stuff.

Except that a lot of reflection-based Java code relies on the Javabean property pattern (getters & setters) by default.

You can often customize this (it is Java after all!) but sometimes it's better to just go with the expected standard in the language.

Good luck adding Validation at a later date... And the fact many libraries rely on the pattern.

Java rely needs properties...

I don't know if that's the answer you're looking for, but a call to append is synchronized:

    public synchronized StringBuffer append(/* Something */);

... but chaining them doesn't mean that the chain is synchronized.

   sb.append(key).append("=").append(value).append(", ");

is executed the same way as

   sb.append(key);
   sb.append("=");
   sb.append(value);
   sb.append(", ");

Two concurrent threads running this part of code might do this:

   sb.append(key);   // # 1
   sb.append("=");   // # 2
   sb.append(value); // # 3
   sb.append(", ");  // # 4

   // Thread 1 executes #1
   // Thread 2 executes #1
   // Thread 1 executes #2
   // Thread 1 executes #3
   // Thread 2 executes #2
   // Thread 2 executes #3
   // Thread 2 executes #4
   // Thread 1 executes #4

This can be executed in many more different ways.

To ensure that only one thread executes those `append` at once, you would have to synchronize on the `StringBuffer` instance:

    synchronize(sb){
        sb.append(key).append("=").append(value).append(", ");
    }

Then only one thread will do the appending at a time. But this introduce yet another lock in your code, and render the `synchronized` methods useless and redondant.

It seems bizarre, but it's just because they were part of different versions. StringBuffer was in Java 1.0, and StringBuilder was added in Java 1.5. If they were both part of the original Java libraries they would hopefully have been given better names. I suppose they could have called StringBuilder "UnSynchronizedStringBuffer" or "NotThreadSafeStringBuffer", but those are problematic on their own.

You have the same problems with Vector and ArrayList I guess, although since ArrayList was added as part of the collections libraries it makes a bit more sense.