UI tooling and beyond in NetBeans and Eclipse(4)

Whoever is reading this weblog more or less regularly will have noticed that I am an enthusiastic user of NetBeans for most of my development needs, and this holds true even now that, given a current project of ours, I have to switch IDE at least once daily, as we do a project based on Eclipse Rich Ajax Platform and NetBeans, as comes as no surprise, is not too good a tool for building applications which are more or less built atop the Eclipse RCP core (well, getting deeper into things and especially talking about RAP application deployment, you’ll figure out that Eclipse itself also leaves a lot to be desired here, but that eventually is another story).

Anyway: One of many fields in which NetBeans these days still does excel compared to Eclipse is building graphical user interfaces using the GUI builder that comes pre-installed with every NetBeans package and even from this point of view is way ahead of the Visual Editor available to Eclipse users, in case of which even installing and getting the bits to work seems an adventure of its own. And here, we’re not even talking about RAP (based upon RWT) which is the “web alternative” and, though pretty complete (and getting better with each release), always lagging a bit behind the “desktop RCP” (based upon SWT) in terms of technology, widgets, … . However, Eclipse then again is a bit ahead from our current projects point of view: The “single sourcing” approach the RAP people are trying to push forth – the idea of having one codebase and run this both “on desktop” and “in a web browser” without too much ado – is really a good approach, well, if you need to cater for both web users who still want a good feature set and to internal users to which using a browser based interface eventually is not an option. Yes, there are quite some drawbacks about the way the Eclipse runtime environment does work and scale when deployed to an application server (in example talking about one dedicated “UIThread” per user session which definitely is not the way people think of doing server-sided Java applications… 🙂 ), but overally, it’s more than so far you can do with Netbeans unfortunately, where you’re left with either doing a desktop (Swing based) application or a web application using some framework for this purpose (JSF, Wicket, …). Works, but one of the ideas you want to address when considering single-sourcing (having programming models as well as user interfaces as close to each other as somewhat possible for web and desktop) falls short here. There have been numerous projects trying to make Swing a web application platform too, but most of them seem discontinued, and none of them integrate well with the tooling one is used to (and enthusiastic about 🙂 ) in NetBeans.

And, talking about e4, the next major version of Eclipse IDE/platform, the current status quo might become even more apparent: e4 comes with XWT, a technology to allow for declarative UI description using XML file definitions rather than writing code, allowing for, well, “declaration” rather than coding of user interfaces, which has a bunch of more or less obvious advantages. Not that this idea is generally all new (just consider XUL used by the Mozilla applications), but along with the “usual tooling” to be found in an IDE like Eclipse, this might turn out to be a rather impressive feature. First demonstrations, like this screencast showing the visual editor for XWT, leave one end up with expectations rather high. So let’s wait and see…

… both what Eclipse people will keep on doing related to XWT until e4 is to be released, and what Oracle is likely to do to Java technologies like Swing or maybe JavaFX. Maybe the latter one might be an interesting alternative if integrated with web and desktop environments and the appropriate tooling. I am curious to see things proceed, talking about both technologies…

Leave a Reply

Your email address will not be published. Required fields are marked *