Traditional Java Bean contract (default constructor, setters and getters), however, creates the issue of mutable state. Not saying that this is what you're advo

Traditional Java Bean contract (default constructor, setters and getters), however, creates the issue of mutable state. Not saying that this is what you're advocating, but the builder pattern avoids this (by allowing immutable objects to be created). That being said, much like other design patterns, the Builder pattern substitutes for something Java lacks: pass by name parameters. Sure, a third generation IDE (IDEA, Eclipse, Netbeans) can generate/refactor the code for me (which allows me to be almost as quick with Java as I am with Perl, Python and Scala) but it can't read the code. Additionally, on the JVM if the builder is also an inner class, the are issues introduced with using it in some non-Java languages. I've ran into this issue when using Avro and Protocol Buffers with Scala (can easily be circumvented, by either modifying the code or using a Java "facade"). That in general shows a problem that design patterns pose when dealing with byte code-compatible but feature disparate OO languages (they pose problems in allowing the more powerful language's idioms reduce boilerplate).