So, here you see an explorer window, containing the folders of my mailbox:
It may seem like only a little bit of work, and not very impressive at that, but consider this—these are the actual folders in my mailbox and I didn't hardcode them into the module. Therefore, via the JavaMail API, this module accesses my mailbox (which is on an SSL-secured IMAP server, somewhere in the realm of Sun Microsystems), retrieves my folders, and displays them via the Nodes API in my new explorer window. Complete integration is a long way away, and the e-mails are quite far from being integrated in my new JavMail client module, but it's been interesting exploring the Nodes API within the context of my porting exercise.
One further thought about the Nodes API in light of what I wrote in my blog entry yesterday—since the Nodes API is a design pattern, you need to approach it in a different way to standard APIs in the world out there. In the same way as you cannot expect to understand (to the point of being productive) any other design pattern very quickly (e.g., the Model-View-Controller design pattern), it takes a while to really 'get' the Nodes API (and I am quite far from 'getting' all or even most of it). Of this learning aspect in relation to the Nodes API, Tom Wheeler wrote me this today: "I would not call the process 'intuitive'. Rather, it was a long, cold walk down a hall of despair until I finally met enlightenment." Secondly, though, as with any other design pattern—once you do understand it properly, you have a very powerful coding friend. After all, that's what a design pattern is for, to give you guidance and to organize your code in a logical and maintainable way. That's what I've found to be true so far for the Nodes API too, despite the inherent learning curve of the design pattern. Maybe we should not call it "Nodes API", but "Swing Node Design Pattern", because that's closer to what it is and sets the expectation more correctly.