[digital:meditation]

“All operating systems include stuff you’ll never use. For example, Ubuntu 8.04 LTS includes an easy uninstall feature.
We know - completely redundant. Ubuntu 8.04 LTS for desktops - you’ll never go back.”

8.04 “Hardy Heron”, the latest version of the Ubuntu GNU/Linux distribution, has been released this week, in short sequence as a server version (supported to 2013) and a desktop distribution (supported to 2011), being the Long Term Support version to follow 6.06 “Dapper Drake” which (at least in our professional infrastructure) has proven to be an incredibly stable and maintaineable platform suiting all our needs. And, looking at it closely, it is obvious that 8.04 has seen an amazing load of work compared to its predecessors, seen both in overall stability, performance as well as in “small” details like the customized Firefox starting page or, as quoted above, a pretty cool marketing / product launch campaign which feels in a refreshing way ironic compared to what other companies tend to do getting their new releases out. Along with Ubuntu itself, there also are new releases of Kubuntu (offered as a “stable” version that comes with KDE 3.5 as well as a “bleeding-edge” version including the infamous new KDE 4), the education / classroom distribution Edubuntu and, of course, my personal favorite Xubuntu, including the lightweight XFCE desktop environment, and being great despite the fact that the default backgrounds in GDM and on the desktop itself just painfully suck. ;) Overally, I have been with Xubuntu 8.04 already for quite a few months, and the last few weeks it has turned out to be a stable and pretty usable machine ready for everyday use, addressing a few issues I had to manually deal with in earlier versions (like using the dual-screen setup on my notebook).

Asides this, however, I am whole-heartedly amazed to see Ubuntu turning into something I haven’t seen that often in GNU/Linux community the last twelve years: It seems to be a distribution which gets more and more approved by both community and companies / commercial providers. Maybe the “open” nature of Ubuntu and the fact that there are predictable, long-term supported releases is something that pays off in the end to help this distribution gaining acceptance all around, becoming a “real” all-purpose (including desktop usage) distribution without throwing away most if not all of the GNU ideas.

And, another thing notable to me, being a Java developer: Ubuntu 8.04 seems the first GNU/Linux distribution so far that includes a fully-fledged set of tools in its package repository:


[kr@n428 9:13:11] ~> apt-cache policy openjdk-6-jdk sun-java6-jdk glassfishv2 netbeans
openjdk-6-jdk:
Installiert:(keine)
Mögliche Pakete:6b09-0ubuntu2
Versions-Tabelle:
6b09-0ubuntu2 0
500 http://archive.ubuntu.com hardy/universe Packages
sun-java6-jdk:
Installiert:(keine)
Mögliche Pakete:6-06-0ubuntu1
Versions-Tabelle:
6-06-0ubuntu1 0
500 http://archive.ubuntu.com hardy/multiverse Packages
glassfishv2:
Installiert:(keine)
Mögliche Pakete:2.0.1-0ubuntu5
Versions-Tabelle:
2.0.1-0ubuntu5 0
500 http://archive.ubuntu.com hardy/multiverse Packages
netbeans:
Installiert:(keine)
Mögliche Pakete:6.0.1-0ubuntu2
Versions-Tabelle:
6.0.1-0ubuntu2 0
500 http://archive.ubuntu.com hardy/universe Packages

So, we do have both OpenJDK and Sun’s “regular” Java SDK in its recent versions, along with the current version of the open-source Glassfish application server (V2u1, at least until Monday, April 28, it seems…), and the recent stable version of the NetBeans IDE, so far my favorite Java/all-purpose development environment. Honestly, installing any of these applications using the “vanilla” installer without relying upon apt and the package repository ain’t that much more difficult, but at least this way getting started doing serious work in Ubuntu 8.04 is easier than ever before, and, considering the idea that Glassfish on Ubuntu 8.04 even might become a configuration officially supportable by Sun, this also might grow the acceptance of Hardy Heron as a server distribution compared to, say, RedHat or SuSE Enterprise Linux. Now I (a) wonder whether the packaging folks will be up to keep packages current when, in example, NetBeans 6.1 is about to be released soon, and (b) whether, talking especially about the Java and integration thing, Sun and the OpenSolaris folks are likely to get (Open)Solaris distributions on par with Ubuntu also in terms of desktop usage and package installation / update procedure, or whether Solaris is rather left for the server usage while Sun folks do focus on supporting Ubuntu as main desktop system environment. Let’s see what will happen…

Things are moving on quickly: Release Candidate 1 of what is likely to be the NetBeans 6.1 IDE is available right now. Get it here, and get started immediately. Not much else to say about it, I guess: Performance has somewhat improved, Spring support really has given quite a boost to my productivity using NetBeans lately, and there is a bunch of minor annoyances that has been removed or fixed. In my daily work, I excessively rely upon Spring, maven2 and database tooling as well as XML editing tools, and, as far as these are concerned, NetBeans 6.1 also in pre-RC has been a stable, very convenient tool to be used in everyday work - I actually have already seen final releases of applications to be less stable than that. So, good job so far. However, there is one update I dearly hope it will make its way into 6.1: The 3.1 version of NetBeans Maven Tooling finally offers support for browsing remote repositories. Definitely desirable.

Oh yeah, time passes quickly… Seems it was only yesterday to deal with the prerelease builds of NetBeans 6.0, by now things are already “beta” once again, steadily heading for the 6.1 release supposed to be released in late April 2008. One might wonder whether, just less than five months after releasing a stable 6.0 version, time’s right for a new “stable release” already, but, looking at the current pre-release builds, I’d say it’s definitely worth dealing with, as quite a lot of work obviously has been put into what’s likely to be 6.1 rather soon:

• Issue 44035 is likely to be fixed, making it easier to share NetBeans projects around, including libraries and additional code they possibly use. So far, getting, say, started with a NetBeans project on a different machine and/or a different version of NetBeans on the same machine prove to be difficult once in a while if the project used libraries not known to the IDE library manager. Maybe the changes introduced in 6.1 even make one give up on maven2 for doing dependency management - let’s see…
• Support for Java Bean Patterns is back in 6.1. Though being a feature available in earlier releases, this seemingly got lost somewhere on the way to 6.0 and has caused quite some discussion ever since. Overally, it’s good to see this feature is back to the IDE…
• The tooling for working with the Spring framework has seen some massive improvements. Initially built as a third-party module, it seems the code of spring-netbeans is now part of the official distribution (or at least an official add-on) and comes with a set of useful features, classpath and code-completion for Spring’s XML configuration files being the most notable one in my opinion. Though Eclipse’s SpringIDE still does better in terms of features and performance (code completion in a decently sized applicationContext.xml is ranging somewhere between “somewhat slow” and “unusable”), this is an important first step to ease NetBeans adoption by those used to doing their work based on Spring. And it seems there’s a growing amount of people who do so…
• It seems that tweaking performance has been a major field of work on the way to 6.1… Though I experienced the IDE “hangin’” just in very few situations (like dealing with large JSP files), I couldn’t help noticing that 6.1 prereleases (a) start up faster and (b) seem to get everyday things just done faster than stable 6.0. Surely a good thing. :)
• NetBeans 6.1 is likely to offer somwhat tight integration of MySQL database, which comes as no surprise given that Sun acquired MySQL AB just a while ago. I am torn about that: Given that the NetBeans services / database manager is amazingly good at dealing with generic RDBMS using JDBC and a homogenous interface not introducing any db-specific dependencies, this seems to be definitely a step back. Then again, it’s a good way helping the IDE being adopted by users heavily relying upon the MySQL database, possibly using some sort of LAMP software stack, who by now are provided with a well-integrated, comfortable working environment.

So, after all: I switched to 6.1 prerelease builds for doing productive work in early January, and while watching the IDE grow better and better, I am sure that 6.1, once released, is likely to push forth a movement tendency already seen with earlier stable NetBeans releases. Not much more than that to say: Have a look at the release notes, get it, get work done. Now if I only figured out how to disable that “transparency” effect while moving NetBeans windows around… :)

Still, working with NetBeans on an everyday basis is a breeze, especially talking about the upcoming 6.1 release which indeed has seen quite a bunch of improvements in virtually every field of view (quite a job indeed, given that 6.0 was rather good already). By now, having all these months gone after moving here from Eclipse, there’s only one minor annoyance I stumbled across which however seems to persist and keep on bugging me once in a while when creating new projects using NetBeans: It seems the IDE in some situations has a rather peculiar way of figuring out where to place a newly created projects folder, which makes me then and now fire up an arbitrary file manager (well, usually some sort of Unix shell) to find where on earth my new project actually has been created:

Overally, things seem rather fine: Initially, creating your first new project, NetBeans decides to dump it to a “NetBeansProjects” folder which, on Unix systems, lives in your $HOME. This is rather good, and I tend to go with this default as the place is reasonably named and I don’t have to throw in confusion choosing a different name anyhow. :) So, if you only create “simple” projects in there, you’re perfectly fine. Chances are you will learn to suffer nevertheless, in two different situations:

1. … if you are using Project Groups. This is a pretty good feature, helping you keeping track of projects that somehow belong together without manually opening and closing sets of projects all the time. A very convenient feature, here, is to create a project group to be a “folder of projects”, a group which, as the name implies, contains all the projects in a chosen folder. From that point of view however, switching to that very project group and creating a “new project”, one would expect the IDE to automatically place the newly created project into the group folder rather than the folder the last project used to be created in.
2. … if you are using projects that somehow can have sub-projects. This, in my opinion, is worse than the other point: Right now, you can create, say, a NetBeans module suite, add some modules to it (which are subsequently placed in the module suite’s folder) and, then, create a new webapp, which also will end up in the module suite’s folder even while there’s no obvious reason to add a webapp to a module suite. At this point, it would be great if the IDE could be smarter in figuring out where to place a new project, and be that back to “default” (~/NetBeansProjects) again…

Oh well, but perhaps I should stop complaining and/or filing bugs against the IDE but rather have a look at the source and see whether to fix this on my own. Isn’t that the good thing about open-source software? :)

Es drängt sich der Eindruck auf, daß NetBeans auch im deutschsprachigen Raum an Fahrt und Popularität gewinnt - nicht nur als IDE, sondern auch als Plattform zur Entwicklung von Rich Client - Anwendungen. Anders ist es wohl nicht zu erklären, daß man, während aktuelle Literatur sonst meist nur in englischer Sprache verfügbar ist, für die aktuelle Version 6.0 nur wenige Monate nach der Veröffentlichung schon gleich zwei sehr gute deutsche Veröffentlichungen in den Regalen der Bücherläden der Republik finden kann, die dem interessierten Entwickler bei der Arbeit an und mit NetBeans Hilfestellung bieten sollen: Neben dem umfangreichen ‘NetBeans Platform 6′ von Heiko Böck ist das ‘NetBeans RCP Entwicklerheft’ das zweite, jüngere(?), auf den ersten Blick dünnere der beiden Werke, und doch nach kurzem Vergleich mein knapper Favorit in Sachen NetBeans-Dokumentation.

Dafür gibt es verschiedene Gründe: Zum einen, in der Tat, ist der geringere Umfang der “Entwicklerhefte” ein deutlicher Pluspunkt, wenn man schnell mit einer Technologie zu arbeiten beginnen will. Sicher braucht man tiefer im Alltagsgeschäft irgendwann deutlich mehr Detailwissen, wird man von den vielen kleineren und größeren Tips und Tricks des Böck-Buches profitieren - für den Einstieg indes sind diese tendenziell ebensowenig hilfreich wie für das angenehme Gefühl, sich mit dem Buch, das neben der Tastatur liegt, schnell sowohl Verständnis zu erarbeiten als auch dies in tatsächlichen Ergebnissen umsetzen zu können. Vermutlich ist das Geschmackssache, aber mir erscheint das “NetBeans RCP Entwicklerheft” hier um einiges geradliniger und ‘zielführender’: Die zu entwerfende Beispiel-Anwendung wird zu Beginn des Buches vorgestellt, und danach arbeiten alle folgenden Kapitel geradewegs darauf hin, diese Stück für Stück mit Leben zu erfüllen. Das passiert im Böck’schen Buch im Prinzip auch, aber das Entwicklerheft wirkt hier (nicht zuletzt sicher wieder des gewollt begrenzten Rahmen wegens) einfach konzentrierter und effektiver.

Zum anderen, vermutlich wiederum persönlicher Eindruck: Das Entwicklerheft wirkt didaktisch geschickter, in der Struktur der einzelnen Kapitel, der “Cause-Effect”-Philosophie, kleine Schritte vorzuführen und im Nachgang deren Wirkung zu beschreiben und zu diskutieren. Strukturelle ‘Fehler’ (…) des Böck-Buches (die Position des Kapitels “Aktionen” am Anfang des Buches zwischen “Modul-System” und “Anwendungsaufbau” erschließt sich mir bis heute nicht richtig) verhindert das Entwicklerheft dabei erfolgreich, dafür gelingt es dem Autor, den Gedankenfluß von Aufgabenstellung über Anwendungsentwurf durch die schrittweise Implementation des ‘Task-Managers’ in den einzelnen Kapiteln hindurch zusammenhängend und logisch schlüssig zu erklären und immer genau soviel Wissen zu vermitteln, wie der Kontext zum Ausprobieren erforderlich macht. Sicher kann man auf andere Weise mehr Information transportieren, aber ob dies auch notwendigerweise effektiver ist, kann man wohl diskutieren.

Im Fazit: Wer nach Großtaten auf Basis von NetBeans RCP strebt (und das werden hoffentlich einige sein, um die Verbreitung der Plattform voranzutreiben, ein Gegengewicht zu Eclipse zu schaffen und vor allem noch das ein oder andere Modul zu erzeugen, das für NetBeans als IDE derzeit noch fehlt), wird vermutlich sowohl den “Böck” als auch den “Petri” lesen wollen. Aber für den Einstieg stellt das Entwicklerheft aus meiner Sicht die bessere Wahl dar. Nebenbei: Einen Teil, der mich besonders interessiert (das Generic Languages Framework aka ‘Projekt Schliemann’), fällt leider in beiden Büchern unter den Tisch. Aber man kann wohl nicht alles haben… ;)

After hestitating to do so for quite a while, by now I finally got along installing my working notebook using the 64bit enabled version of xubuntu 7.10 ‘gutsy gibbon’, and I have to report that most of the things moved along rather smoothly. The system works again, does run rather smoothly, not slower than it did before (actually some applications - like the virtualization stuff allowing me to run, well, “other” OSses once in a while if really needed - “feel” a little faster than before).

So far, so good. Well, except for one thing perhaps, which leaves me rather irritated: Though there actually is a native Java version for amd64, also allowing me to immediately move along working with NetBeans on my newly installed machine, the amd64 build of Suns Java distribution obviously doesn’t come with a browser plugin, which is not really a good thing if you’re into creating applets once in a while. Browsing the web I found numerous hints on how to get over this limitation (including installing the IBM Blackdown java package or advices on how to downgrade my browser to be 32bit again and merrily use the old plugins), but no real evidence of being capable of simply plugging one of my installed JDKs to my Firefox 2 browser on this platform like I used to do before.

Even worse, I found this issue report against Sun JDK requesting 64-bit plugin support, an enhancement request that, well, celebrated its 5th birthday yesterday without having a viable solution available now or in near future. Given that JDK 6 Update N is likely to come with an all-refurbished Java plugin, knowing that, five years later, there still is no support for a platform more than common nowadays is rather frustrating. Somehow, Sun people haven’t really outdone theirselves about that. By now, I will evaluate a bunch of other solutions (including the 32bit browser and the icedtea-java7-plugin package that comes with Ubuntu amd64 but so far causes stacktraces on my system), but in the end it’s more than likely I’ll be back to 32bit - caused by an issue someone has failed to address the last five years… Did I mention that official JDK7 pre-release builds for linux-amd64 also suffer from this flaw? Simply disastrous…

It seems, after a bunch of good beta and RC releases, by now they finally did it: NetBeans 6.0 has been released on December 3, 2007. Which is a good thing, as NetBeans contains quite a set of features that should be of quite some interest to developers not only limited to using the Java language, but of course mainly to those, and especially in situations in which you might want to have a tool for rapid application development in a well-integrated environment (in example building JEE applications using the glassfish application server or the OpenESBenterprise service bus implementation). There are quite some good things to be pointed out about NetBeans 6.0, including a rich set of pre-packed features, the ever-growing list of 3rd-party - plugins, a fairly well-organized collection of official tutorials and articles or the ability to get a free DVD media kit containing an up-to-date set of NetBeans and Java software along with documentation and all you need to get started. Having a new on-line release of NetBeans magazine available also is a good thing, and I am surely curious to know what my.netbeans.org, as a developer community, will all be about once it’s finished. But, no matter what reasons, in my opinion one point stands out of all these: So far, NetBeans 6.0 is the first Java IDE ever to be released using a GPL license, thus being “free-as-in-free-speech” software, which is surely a good thing and might push forth adoption of NetBeans being a development environment common to folks into both Java and GNU/Free Software. Anyway, thanks to all the NetBeans people for a fairly good release. :)

Oh well, I should calm down as far as my post headlines are concerned before things are about to get completely stupid. :) Nevertheless, not-so-bad news today is that NetBeans 6.0 RC2 has seen the light of this world by now, which is good in two ways:

At first, Release Candidate 2 points out that things are slowly getting “serious”, that it’s just a matter of time for the first GPL’ed IDE “for” Java written “in” Java is about to be here in a stable release and waiting to make its way into the package repositories of the most common GNU/Linux distributions. This possibly is good news.

But, more than that, the NetBeans Groovy plugin finally is back in action and working with the recent NetBeans version again, rather good for all those who want to use NetBeans as a “multi language” IDE (like me). Now if there only was working Python support - perhaps one should have a look at the Schliemann project allowing for custom language integration in NetBeans and start something similar on one’s own… Nevertheless, RC2 so far does rather well on my box - good work everyone!