Tips for interactively debugging CDI applications

I've grown to really like Contexts and Dependency Injection (JSR299, CDI), a part of the Java EE 6 suite. It's relatively simple and clean, it's extensible, and it allows for a really nice loosely-coupled programming model. It gives you the freedom to use event-driven or direct call operation and can take care of most of your lifetime/lifecycle issues for you.

Of course, this is my blog, so you know there's a "but". Sure enough there is, albeit a pretty minor one: It's a mess for interactive debugging, because stepping through a CDI invocation takes you through layers of weld proxies, scope lookups, and all sorts of other crud you usually don't want to see. LOTS of it. CDI isn't unique in this respect, as anyone who's stepped through EJB calls will know, but it's perhaps worse than some due to extensive use of proxies, interceptors, etc.

There's a solution in Eclipse. It could be simpler and it could be more complete, but it's a heck of a lot better than nothing.

Java EE 7 needs improvements in app configuration mechanisms

Most applications need configuration options or preferences, a way for the user to edit them, and a way for the application to read and edit them. Java EE applications are no exception. Right now Java EE applications have numerous options for such settings - but no single choice that's simple, admin- and app-author friendly, and easy for both admin and app to modify.

This is not a new issue, as can be seen with this 2001 question on The Server Side. Back then they suggested *using JMX* ... which doesn't exactly fit the *simple* requirement.

Java EE is supposed to provide much of the groundwork for apps as part of the container, so the app author can get on with solving their problem. Right now it doesn't help much with application settings, and this needs improvement so that apps:

• Don't need to each provide a custom UI in order to edit even the simplest settings
• Can easily modify their own settings
• Can guarantee the persistence of their settings across redeploys and across cluster nodes
• Don't require a full database and data access layer / JPA / etc just to store simple configuration options.

I'd like to highlight this as an issue for Java EE 7 or 8.

UPDATE: Marcus Eisele pointed out a related post by Antonio Goncalves as part of a jsr342-experts post on configuration. Have a look at Antonio's piece; he's looking at it from a slightly different angle, but with many of the same issues.

See also this stack overflow post from a while back, where I asked for help on this topic and got crickets.

Vaadin is pleasantly productive

I think Vaadin 6 is the first truly productive web UI framework I've worked with. Productive for me, anyway; experiences will vary depending on the task at hand and the developer.

I strongly recommend Vaadin 6 for anyone doing web applications - highly stateful tools where user counts are relatively low and UI complexity is relatively high.

The only real caveats I have to that recommendation are that:

• JPAContainer is very inefficient - largely due to an API design problem in Vaadin's Container API that makes it very hard to use the entity manager efficiently. Alas, this design flaw hasn't been remedied for Vaadin 7, so it's sometimes best to avoid JPAContainer and drive a Vaadin table from the outside instead.
• JPAContainer doesn't play well with Hibernate and lazily loaded entities. A workaround is provided, but it's clearly more used with EclipseLink. This won't be a problem if you drive your tables with your own data model code.
• Vaadin's stateful design means that each client costs you a non-trivial amount of memory on the server. If you want to serve large numbers of users who're doing simpler things you might want to consider a stateless JAX-RS API driven by client-side JavaScript and a lightweight templating engine, or look into one of the stateless server-side frameworks.

Vaadin 6 feels a little bit old at times, and you can certainly see its Java 1.4 history in more frequent use of casts rather than generics. It also requires an extension to integrate it with CDI - even then, only with pseudo-scopes.

Vaadin isn't beautiful, but damn, it works. Works well, and reliably. It's been at least two weeks since I found a bug in the tools I've been using, and that has never happened to me since I started using the Java EE stack!

Despite its flaws, JPAContainer is also impressively powerful. I really hope an enhanced Container API can be introduced to Vaadin 7 so it can reach its potential as a truly awesome RAD tool.

Waits 'till you're asleep ... and [X]

Did the marketing people not even think about this at all?

Caption contest time!

The uncropped original shows I'm not just cropping off important context; that ad is just a little disturbing.

Smart Stay - it waits 'till you're asleep then ...

PostgreSQL rocks, and so does explain.depesz.com

I was modifying one of my aggregate views today and I was struck by just how impressive PostgreSQL is, and how powerful relational databases in general really are. PostgreSQL was executing queries against the view a completely different way when one entry was being queried vs when the whole view was being requested.

You might take this for granted - but when you think about it, it's seriously amazing how a database can take your description of what you want and work out the how for its self. Mostly.

Imagine writing this yourself. Say you're working in Java. You have a complex Criteria query against several different tables related to information about customers. You now want to get information for just one customer, so you add a WHERE clause to the top level. If the database didn't nearly magically push this filter criterion down into all those complex sub-queries and joins you'd be at it for hours; days or weeks if you wanted to make it re-usable and generic across a set of similar criteria queries.

Instead, the DB just does it for you.