Which in English means “NetBeans 4.0 Release Candidate 1”. I’d been distracted from work on the Zeppelin project for a couple of months but have upped tools again and the tool is NB4RC1. The news is mostly good.
Getting to 4.0 · As for NB4, it feels pretty good; I had a bit of pain getting my 3.6 Zeppelin set-up transferred, mostly since NB doesn’t mind you having your source files in your own directory, but if you want the built-in JUnit support (and you do), it really wants the test files in its own directory space.
Those of us who watch the NetBeans mailing lists know that the #1 transition pain point is exactly this, people who have elaborate custom project setups who are having trouble working them into NB4’s all-Ant-all-the-time world-view.
I haven’t yet had occasion to get in there and hack the Ant files, but I’m sure that’ll happen and it’s nice to know there’s no mysteries anywhere lurking in there.
As for the way it works, it’s slick and quick and the OS X integration is really getting pretty good; but look here, and if you’re on a laptop you will definitely need uControl so that you can use the function keys NB4 wants.
Houston, We Have a Problem · Nothing to do with NetBeans, mind you. Zeppelin includes, among other things,a large persistent in-memory data store each instance of which needs two processes running, and my current testbed is using two of them on a 200M dataset. So when I pull the trigger and the five JVMs start grinding away, it becomes apparent that this is perhaps not exactly the kind of workload an OS X laptop is optimized for.
As in, I’ve got lots of time to write this and listen to background music while the data-load process runs. That’s OK, I put in a hail to John Fowler back at the Mother-Ship for the use of some of those neato new boxes, and if my calculations are correct, a couple of them should make this Zeppelin go supersonic.
