Use the patterns, Luke

Patterns are good. Everyone agrees with that...which doesn't mean that everyone uses patterns. But even worse than not using patterns is using them wrong. Let's imagine you want to create a Singleton, but you implement it wrong. Because it's stated that it is a pattern we assume it is right...we know what it does. This makes it hard to find the problem...the same way we don't test if Sun's API is right, we assume the pattern is correct. And probably it will take some time till someone finally finds it.

An innovative approach to help in this problem is PEC (Pattern Enforcing Compiler). What it does is check if your implementation of the Design Pattern (Singleton, for example) is correct, at compile time. It's very easy to use. You only need to add the following to your code (copied from website):

1. Add "import pec...*;", e.g. "import pec.compile.Singleton.*;"
2. Add "implements ", e.g. "implements Singleton"
3. Compile with PEC

If your code doesn't implement a correct Singleton (for example) a compile error is shown (the error messages are normally very good explaining what is missing in the pattern). I think this is a good idea and may prevent a few headaches. But there is a catch...there is no magic here...not only you need to implement the Singleton right, you have to implement Singleton the way PEC thinks it should be implemented. I'm not saying that PEC doesn't "enforce" a good Singleton pattern, but there are always different ways of implementing a pattern. For example, in PEC a Singleton must have a static method called "instance" to retrieve the Object instance (no other name). However, if you adhere to PEC guidelines, you gain a powerful tool against those nasty-hard-to-find-bugs. The good news is that PEC is extensible. You can add your patterns, either new ones, or different implementations of those supplied by PEC.
So, in conclusion this can be a handy tool if you adhere to PEC's implementation of patterns or you have the time to extend PEC and create your patterns.

Direct Web Remoting

Have you seen Google suggest already ? It's a new service from google (still in beta) that suggests words as you type (similar to auto-completion in popular programming editors). I don't know the details of how it is done, but I presume it uses something similar to DWR.
DWR allows client-side JavaScript to call server-side java, without a page refresh. Although I don't like JavaScript that much, I have to admit that with DWR we could create extremely flexible user interfaces. It's still in alpha stage, but at least for me it worked pretty well (Firefox, of course). The way DWR works is quite ingenious. It creates an IFRAME which calls a servlet that does our work. On reply, the IFRAME has an "onload" script that returns the result to the JavaScript. Thus, the IFRAME is used just for the request and response process and is immediately deleted.
Don't know if it will catch on, but with all the different rich client frameworks emerging, it will be a difficult fight for all.

XML-based GUI

I recently had to develop a Swing application. I touched Swing only a few times before. And because of that lack of experience I didn't want to do it manually. It would take much too long (and is quite boring too). XML based GUIs seemed a valid alternative. A little research and I ended up choosing SwixML.
With SwixML you can define all the user interface in a single XML file. This has several advantages: you clearly decouple presentation from business logic, it's easier to code and the resulting XML file has a lot less lines than the corresponding Swing code. Also, for those who know the Swing API well, transition to SwixML should be smooth. All Swing components have a corresponding XML element with the exact same name. Properties also have the same name. You can think of the XML structure as a complete representation of the Swing GUI components. This is also a clear advantage for SwixML developers: there's no need to explain what the elements and attributes are. A link to the Swing API suffices (after code-reuse, we now have documentation-reuse).
Be sure to check the samples page to see the simplicity of the XML structure.