VB on the JVM

For years, we Javaers have been comparing Swing to VB, particularly with respect to ease of development. The conclusions usually involve Swing being much more difficult and much more powerful. I agree with this, but I also think Swing left out some critical APIs for way too long which made the platform more difficult:
  • no easy to hand code, tight syntax, predictable LayoutManager in the core?
  • no built-in components that are universally necessary: a JDateField, a JIntegerField, a JPhoneField, a JMoneyField etc. JFormattedTextField is not an alternative, it is very difficult to use
  • no easy-to-use all powerful table support out of the box. I don't like having to write fireXXX() methods by hand, and I don't like having to dig around and manually add the curious

    These problems are easily remedied by open source libraries. But finding, evaluating and learning open source libraries adds a huge amount of difficulty to the process. This is particularly painful for me as a contributor to the best JTable API ever, Glazed Lists.

    Anyway, enough ranting. Project Semplice is Sun's new project, the VB language on the JVM. It's an ambitious project and they've got some smart people working on it. My big complaint with it is that there's this VB programmer guy named Jesse Wilson who is not me. Go on, check out the first comment on this blog entry. If their community interops with ours, I've got to share my name. He's probably not a bad guy, but come on, he's a VB programmer! Couldn't Sun have courted a more academic community? Maybe Lisp, OCaml or Haskel? I would much rather be confused for an old Lisp hack than a VB codemonkey. Or perhaps they could have tried to involve another type of community altogether! Maybe they could have written JVM extensions for extreme athletes, mercinaries, rockstars or brain surgeons. Imagine the conversations:
    Confused Person: "Are you a super awesome rockstar?"
    Jesse: "Well, kinda..."

    Another Confused Person: "It's amazing how you have the guts to snowboard out of a helicopter on ungroomed terrain!"
    Jesse: "Well, kinda..."

    Yet Another Confused Person: "You're so compassionate, dedicating yourself to fixing other people at the hospital"
    Jesse: "Well, kinda..."

    Of course to contrast, here's the conversations I'm currently fearing in actual reality:
    Confused Person: "1-based arrays suck, and by association so do you!"
    Jesse: "umm... it... not me...."

    Enough kidding aside, VB is a very productive language and I'm excited to follow the developments on this project. I'm also excited to see Sun coming to the rescue of a programming community that's been abandoned by Microsoft.
  • Glazed Lists 1.6

    The next rev of Glazed Lists is out, 1.6.0. This is an interim release while I try to find time to rework how ListEvents are created, stored and managed. Hopefully things will get a lot more powerful for 2.0, and this paves the way. Plus James has added some killer extensions. Check it out.

    SimpleDateFormat considered harmful

    There's been some discussion on the lists at work about SimpleDateFormat. Apparently it's not safe to be used by multiple threads simultaneously, despite the fact that the format() method doesn't appear to mutate the state of the object. It's a huge design flaw that has bitten many a developer in the ass.

    The discussion turned to possible workarounds and speculation on their comparative performance. Here's the contenders and my speculation:
    • create a new SimpleDateFormat instance on every invocation. I predicted that this approach would be slow because of the computational expense of parsing the format string.
    • synchronize() on a single shared SimpleDateFormat instance. I thought this approach would be fastest.
    • use some sort of simple pooling mechanism to share multiple SimpleDateFormats between the threads. I figured this approach would be slow because there would be a need for two synchronized() blocks: one for fetching objects from the pool and another for returning them
    • Use ThreadLocal, where each Thread has a private SimpleDateFormat instance. I figured this approach would be slow because ThreadLocal probably had some complexity in its implementation.

    Well having placed my bets on the synchronized shared instance, I decided to write a bit of code and benchmark the four options. Here's the results, as obtained unscientifically on my Mac Book Pro:

    ImplementationRuntime (seconds)
    new instance each time9.6
    single synchronized instance3.4
    simple pool2.5

    The results are surprising - ThreadLocal is the clear winner, 50% faster than synchronized(). But don't take my word for it. Critique and tweak and run your own tests.

    Why no API docs?

    I'm preparing the latest release of Glazed Lists, and as with every release I'm going to post the Javadocs online. Posting the Javadocs on the public Internet is pretty easy and it provides some nice benefits:
  • The project becomes Googleable.
  • I can permalink to Javadocs from mailing lists, forums and blogs
  • Potential users can get a feeling for the project's scope and implementation
  • Existing users can easily browse the API without a download

    Unfortunately, not very many projects bother with public Javadocs. I failed to find docs for KTable and JGoodies Forms.

    No Javadocs is a problem for me since when I'm building the Glazed Lists Javadocs I like to use the link feature, which allows you to seamlessly browse documentation across projects. For example, on our BasicEventList doc page, you can navigate directly to Sun's Collection interface by clicking on the appropriate link.

    I hoped that the Javalobby would come to the rescue with their service. The site hosts Javadocs for many open source projects, but unfortunately, they screwed up their version of the package-list file, which breaks compatibility with the -link switch. I notified them of the problem over a month ago but I haven't heard anything back.

    The net result is that Glazed Lists 1.6.0 won't have Javadocs linked for some packages. Too bad!
  • Both Rich and Thin

    There's an ongoing battle between rich and thin applications. Rich client applications like iPhoto are powerful and productive. Thin client apps like Flickr are easy and connected.

    Lately, it seems like the industry is going thin, but I think eventually both application styles will converge. Internet applications with rich-client frontends offer the best of both worlds, and they're already in wide use:
  • iTunes is rich client, but its embedded music store is thin
  • RSS readers
  • Weather and Flights on the OS X Dashboard or as Vista Gadgets

    I love these applications! Thanks to the NewsFire RSS Reader, less than half the time I spend online is in a browser. I think we developers have a golden opportunity to create compelling rich clients as an improved way to access the Internet:
  • A Flickr browser is inevitable, thanks to the service's liberal use of web services.
  • Bugzilla as a rich client embedded in Eclipse, Netbeans and IntelliJ would be sweet for developers
  • The first person with a rock solid MySpace rich client may make some cash!

    I'm sure these ideas may already exist in the wild, but I thought I'd take the opportunity to encourage rich client development!
  • Corel Draw 11 crashing on Mac OS X? I have tips!

    Last night I ran software update on my Mac Book Pro, bringing me up to Mac OS X 10.4.6. And today? Corel Draw 11 crashes on startup!
    Thread 2: Crashed (0xb7fffabc, 0x82fc9d1f)
    0x8387196c: /Applications/CorelDRAW 11/Required/Programs/MacUtilities.DLL.cfm/Contents/MacOS/MacUtilities.DLL [CFM] : + 0x896c
    0x83870ea4: /Applications/CorelDRAW 11/Required/Programs/MacUtilities.DLL.cfm/Contents/MacOS/MacUtilities.DLL [CFM] : + 0x7ea4
    0x8393572c: /Applications/CorelDRAW 11/Required/Programs/MacPort.DLL.cfm/Contents/MacOS/MacPort.DLL [CFM] : + 0xae72c
    0x83938118: /Applications/CorelDRAW 11/Required/Programs/MacPort.DLL.cfm/Contents/MacOS/MacPort.DLL [CFM] : + 0xb1118
    0x7c117a98: /Applications/CorelDRAW 11/Required/Programs/CrlUtl.DLL [CFM] : + 0xe1a98
    0x7c1133a4: /Applications/CorelDRAW 11/Required/Programs/CrlUtl.DLL [CFM] : + 0xdd3a4
    0x7c3246b0: /Applications/CorelDRAW 11/Required/Programs/Draw.DLL [CFM] : + 0x1736b0
    0x7c31c91c: /Applications/CorelDRAW 11/Required/Programs/Draw.DLL [CFM] : + 0x16b91c
    0x7c36db28: /Applications/CorelDRAW 11/Required/Programs/Draw.DLL [CFM] : + 0x1bcb28
    0x83bfba80: /Applications/CorelDRAW 11/CorelDRAW 11 [CFM] : + 0xa80
    0x83bfbba0: /Applications/CorelDRAW 11/CorelDRAW 11 [CFM] : + 0xba0
    0x83bfb944: /Applications/CorelDRAW 11/CorelDRAW 11 [CFM] : + 0x944

    Corel Draw 11 iconFortunately, I've been in this situation before. Today's solution is a natural one: go to /Users/jessewilson/Library/ and delete the folder named CorelDRAW 11 Preferences. Then launch Corel Draw 11.

    If you're having other problems starting Corel Draw, there's a variety of ways to revive the now-unsupported graphics application:
  • Adding a printer, any printer
  • Pressing SHIFT while the app starts
  • Updating to CorelDraw 11.693

    It's really unfortunate that Corel abandoned the Mac market. I've been using Corel Draw since version 3, and I fear the day I have to give in and learn Illustrator.
  • Mac OS X Update 10.4.6 Update kills my Mac

    I'm usually a really big fan of the Mac OS X Software Update app. It's easy to use, automatic and mostly nonintrusive. But after applying today's update, my shiny new Mac Book Pro stopped booting!


    Each time I rebooted, it beachballed on or right before the "Starting Mac OS X" progress bar screen. Fortunately, a kind soul on the Apple forums provided a solution - reboot into "safe mode" and move everthing out of /Library/StartupItems/.

    This sucks. I'm always encouraging my friends & family to switch to Mac, and everytime I run into shit like this I feel like a clown.

    Rounded Corners as a Swing Border

    Rounded BordersIn order to get a desired effect in the Glazed Lists issues browser, I created a border with rounded corners, a la Web 2.0. Implementing the painting logic was tedious, but not particularly difficult -- there's a lot of "magic-numbers" Java2D code to write, such as offsetting by the stroke width and figuring out the stroke angles.

    If you want your Swing app to look Web 2.0, please take and contribute back your enhancements & fixes!