//XPath NetBeans plugin

I built some time ago a NetBeans plugin which simplifies browsing through large xml documents a bit. Just start typing a XPath expression in the text field of the TopComponent and the result of the (last) xml editor in focus are computed and printed in the textarea below. (You can open the XPath window either by using the context menu on xml files or directly via the window menu)

It uses the JDK's javax.xml.xpath package which means XPath 1.0 support.

xpath query results

it also supports basic auto completion and localized error messages (in other words: XPathExpressionException.getCause().getLocalizedMessage()).

I uploaded the module to the plugin portal. Feel free to use it ;)

//NetBeans OpenGL Pack #2 in most popular plugins ranking

NetBeans OpenGL Pack logoSince I haven't bloged for a long time about the OpenGL Pack, here are some notes for the last two update releases.

Beside updates and fixes the only new feature I added is the OpenGL Quicksearch. It uses the NetBeans 6.5 Quicksearch functionality (similar to ctrl + 3 in eclipse) and searches through several OpenGL resources.

currently are five resources available for search:

power users can restrict the search to a category with the following prefixes ([prefix  space] searchstring  (space searchstring)*):
gl for GL SDK, ext for GL extensions, nv for Nvidia extensions, ati for ATI/AMD Extensions.

JOGL component in NetBeans Formdesigner OpenGL quicksearch GLSL editor

Pictures featuring: Form Designer sample project, GL Quicksearch, updated GLSL 1.3 editor

Changes in 0.5.3:

  • Java Applet and Webstart support
  • OpenGL Quicksearch
  • GLSL editor updated to support GLSL 1.3 (OpenGL 3.0 spec)
  • two new NetBeans Form Designer sample JOGL projects
  • NetBeans 6.5 and JDK6 are the new minimum requirements

Changes in 0.5.2 since last release:

  • JOGL distribution has been updated to version 1.1.1
  • GLSL linker now does not stop linking shaders on compiler warnings
  • the pack should now correctly deploy JOGL and GlueGen's native libraries on all supported platforms (64bit bug)

To download the pack, please visit the plugin portal.

As always, please use the user mailing list for feedback and the issue tracker for bug reports on the project page.

- - - - -

BTW the pack recenty reached the 36k downloads milestone which makes it to the #2 in the most popular plugins category of the plugin portal ;)

//Enabling the new java browser plugin on ubuntu

When you are using Ubuntu and upgraded from older releases to intrepid or jaunty you might have run into a setup bug which causes the browser to keep using the old java plugin despite having latest Java SE and plugin packages installed (e.g 1.6 update 13 from multiverse repository).

To fix this you will have to update some symlinks and let them point to the correct location.

one easy way of doing this is by using the update-alternatives command:

 sudo update-alternatives --all

this will iterate through all symlinks in /etc/alternatives which have more than one alternative and ask you which one to use. Simple update all links which point to:


to the location of the new plugin (e.g for i386):


For all other links just hit Return.

This is a little bit of a brute force approach but there shouldn't be many of them and it is the only way to make sure you don't overlook one of them since they are all called differently ;)

Next time you restart your browser the new plugin should be loaded and applets which use e.g jnlp for deployment (or out of process functionality) should work.

//Java - JavaScript Communication example

Communication between java applets and javascript code is already available since J2SE 1.3 (aka LiveConnect, which was btw. rewritten from scratch in Java 6 update 10 as part of the new plugin) and is really easy to implement. It is a simple way to break out of the sandbox and do things which would usually require full system access (a signed applet + user approval via security dialog). For example applets living in a sandbox are only allowed to read mouse events via the AWT/Swing event mechanism which works as long the mouse is over the applet.

To read e.g the mouse position globaly you would need to call MouseInfo.getPointerInfo().getLocation() which would cause a java.security.AccessControlException: access denied. However, in javascript it is trivial to track mouse events for the whole html document (e.g google adds track onclick x,y events).

All you have to do is to use the object tag instead of applet tag (which is deprecated anyway) and give the object (applet) a name via the id attribute.

<form name="FishForm">   
<object width="256" height="256" type="application/x-java-applet" id="CrazyFish">
<param value="http://people.fh-landshut.de/~mbien/weblog/java_js_interop/launch.jnlp" name="jnlp_href" />
<param value="false" name="draggable" />

 now you can simply call methods as usual.

<script language="JavaScript1.2">
document.onmousemove = onMouseMoved;

var tempX = 0;
var tempY = 0;

var applet = document.FishForm.CrazyFish;

function onMouseMoved(e) {
// javascript -> java calls
applet.jsObjectOrigin(findPosX(applet), findPosY(applet));
applet.jsMouseMoved(tempX, tempY)
return true

 the other side is a plain old public method implemented in the java applet.

* called from javascript.
public void jsMouseMoved(int x, int y) {
//do something usefull

 RIA/Web2.0 Observer Pattern in action ;)

(The applet won't work with JRE version < 1.6 update 10 (or the equivalent on Mac OS) since I used the jnlp deployment mechanism, but it wouldn't have been necessary for this particular applet)

... and never forget Web 2.0 is watching you

//There is no place like

I have decided to host my blog myself and thought I report about some highlights ;). The reason why I haven't bloged for a long time was actually a configuration issue of the old setup which confused <myDomain>/myBlog with <myBrother'sDomain>/myBlog. Selfhosting is also a good opportunity to play with enterprise software at home in a daily basis (not only the usual try and remove evaluation with constructed dummy projects or brainstormed scenarios).

I initially evaluated OpenSolaris since I was really eager to try out ZFS. But I decided to stay with Ubuntu 9.04 server edition (aka jaunty jackalope) since I already use the desktop version for my workstation. The other reason was the lower memory footprint of Ubuntu (256MB) compared to OpenSolaris (512MB) which is relevant if you run your site on over 10 years old hardware like I do.

Ubuntu has great software repositories which just provide everything to get started (e.g Sun JDK6.13 and in theory also glassfish, netbeans, eclipse, your favourite database etc but i prefer in those cases zip files ;-) ).

Installation with gimmicks like Software RAID (RAID 1), firewall configuration went flawlessly. The combination GlassFish2.1 + Roller 4.0.1 + hsql 1.8 worked also on first attempt.

a few thing I noticed:

  • 5 years ago the whole process would take far longer than two evenings
  • -XX:OnOutOfMemoryError=<send me a mail command> (since java 1.6) is really cool
  • Cloudcomputing is overrated (web services should always be weather independent)
  • There is no place like

don't worry the upcomming entries should be more technical - this is mainly a test ;-)

//FishFarm wins second prize in GlassFish Community Innovation Awards Program

I recently won with FishFarm the second prize in the GlassFish Community Innovation Awards Program -  which is pretty cool. I would never have thought that I have a chance to win something in the GAP.

Since you probably don't know what FishFarm actually is, I will try to introduce it with this entry.


FishFarm = Shoal + Fork/Join Framework
Shoal = simple to use clustering framework currently based on JXTA and used within GlassFish

Fork/Join Framework = pretty cool concurrency framework for local parallelization of tasks (jsr166y targeted for Java 7)

=> FishFarm = simple but pretty cool solution for distributing concurrent tasks over a p2p network [q.e.d.]


Project FishFarm is a simple solution for distributing computational intensive tasks over the network based on Java SE APIs.

The goal of this project is to take any task written in the Fork/Join Framework (JSR166y targeted for Java 7) and distribute the computation over multiple nodes in a grid. FishFarm introduces no new frameworks and is also no full featured distribution system.

The initial focus was to make the ForkJoinPool (which is a core part of jsr166y) distributable with as few code changes as possible. Thanks to Doug Lee these modifications are now in trunk of his Fork/Join Framework and he even provided a handful of utility methods to make further extensions simpler.

How it works:

All you need to make your Application distributable is to replace ForkJoinPool with FishFarm's DistributedForkJoin pool.

  ForkJoinPool pool = new DistributedForkJoinPool();

// submit as many tasks you want (nothing changed)
Future futureResult1 = pool.submit(new MyTask());
Future futureResult2 = pool.submit(new LongRunningTask());

// block until done
  System.out.println("result of task 1: " + futureResutl1.get());
// or ask if done
System.out.println("task 2 isDone=" + futureResutl2.isDone());

Every DistributedForkJoinPool is member of a peer2peer network and automatically steals work from overstrained pools if idle. DistributedForkJoinPool extends ForkJoinPool and will complete submitted tasks even when working offline or on node failures. No additional configuration required.

I wouldn't call it ready for production yet but it should be stable enough to have fun ;-)

webstartable demos


In case you are wondering why you are reading this entry via the RSS feed of my brother's (Adam) blog. This is a bug which confuses both urls, I hope this should be fixed with the next roller deployment.

This is Michael - over and out ;-)

//Web 3.0 alias Java 6 update N + JavaFX Desktop profile anounced

"The Workaround" - better known as Web 2.0 is now no longer necessary ;).

With Java 6 update 10 and later + JavaFX Desktop profile it is possible to run REAL applications (lets call them applets) out of process in the browser. The browser sandbox is now optional, if you like the applet to persist, just drag it out of the browser and you can use it stand alone (same process -> same state).

If you close it, it simple moves back to the browser, but what happens if you close the browser when the stand alone applet is still up and running you may ask? Now you technically transformed your applet to a webstart application and installed it on your system. Isn't that cool?!! Installation has never been so easy.

Additional to that a great demonstration of the Adobe - Photoshop/Illustrator exporter plugin has been shown on the JavaOne tech session where a professional designer and a java geek developed side by side a cool looking animated application without knowing concrete implementation/design details from each other*. Now you are able not just to develop techical superior applications you can also make them look awesome with minimal effort. (technically the exporter plugin exports each layer so coolest things will be possible)

But this is not everything: missing audio and video codecs are now ready to use, BDLive which brings network to your Blu-ray player has been shown and BDLive developer discs are now availabe at BDLive.com.

The early access JavaFX SDK will be available in June. More information on javafx.com (well the webside does not look and feel very good but thats probably because its not written in JavaFX script... ;) )


*Sun Tech Session 3

Applets Reloaded with Ken Russell

Livedemo including sourcecode and documentation of the draggable applet feature is now available.

//NetBeans OpenGL Pack 0.5.1 released

The NetBeans OpenGL Pack 0.5.1 has been released. This is a small bugfix release with no major features added.

Changes since last release:

  • updated JOGL distribution to v1.1.1rc8
  • updated JOGL demos (added gears Applet demo)
  • added JOGL API support module for doc and source integration
  • webstart support for JOGL project templates (just enable it in the project properties)
  • improved JOGL deployment code (fixed some issues on 64bit systems)
  • bug fixes

To download the pack please visit the plugin portal page.

The OpenGL pack will be soon available via plugin portal update center (Tools | Plugins). This will make our old  "NetBeans OpenGL Pack update center" obsolete (and improve the download speed!). However, we will use the old update center for experimental not final releases in future.

As always, please use the user mailing list for feedback and the issue tracker for bug reports on the project page.


Write once run everywhere [1][2][3][4][5][6] - seems like the platform agnostic JOGL deployment is working ;)

//How to reuse modules across different NetBeans applications

If you develop NetBeans modules you probably also wondered how to add a pre-packaged .nbm file as dependency to your module or how to use modules in multiple suites.

After some search I found that there is currently no official supported way for doing this. The reason is the bidirectional dependency between the suite and each module in the suite. This makes it hard to reuse modules across suites but it is still possible. In this entry I will describe different techniques/hacks to workaround this issue. (Note: technique, hack and workaround in the same sentence ;) )

In general, you can add a dependency to a module when the module you like to depend on is in:

a) your suite

b) the target NetBeans platform (default target platform is the installed IDE)

As mentioned above a) works only for one suite -> only b) is left

option 1. Assemble your own target platform:

point and click

  • Either make a copy of NetBeans, or if there's a lot of stuff you don't want, create an empty suite. Then build it and create a zip distribution and unpack that
  • Launch the result
  • In Tools | Plugins, install the module(s) you want globally (check the "Force install into shared directories" checkbox)
  • Shut it down
  • In your real IDE, use Tools | NetBeans Platforms to point at the copy of the platform that now has the module you want in it
  • Set your suite to build against that. It should pick up the module you installed and all classes in it's public packages

or put it in a build script

option 2. Install the module into your IDE:

point and click

  • enable "Force install into shared directories" in Tools | Plugins | Settings
  • install your module(s)
  • restart NetBeans
  • your module is now in the extra cluster and part of your IDE

or declarative

edit Info/index.xml inside your .nbm file

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE module PUBLIC "-//NetBeans//DTD Autoupdate Module Info 2.5//EN" "http://www.netbeans.org/dtds/autoupdate-info-2_5.dtd">
<module codenamebase="org.yourorghere.module4" distribution="" downloadsize="0" global="true"
homepage="" license="AD9FBBC9" moduleauthor="Michael Bien" needsrestart="false" releasedate="2008/04/07" targetcluster="milkyway">
    <manifest AutoUpdate-Show-In-Client="true" OpenIDE-Module="org.yourorghere.module4" OpenIDE-Module-Implementation-Version="080407"
OpenIDE-Module-Java-Dependencies="Java &gt; 1.5" OpenIDE-Module-Name="module4" OpenIDE-Module-Requires="org.openide.modules.ModuleFormat1" OpenIDE-Module-Specification-Version="1.1"/>
    <license name="AD9FBBC9">[NO LICENSE SPECIFIED]

alternatively you can add the flags to module/nbproject/project.properties and rebuild/create NBM (if source available)


Now when you install the module with Tools | Plugins, NetBeans will place the module directly into the installation folder in the new created "milkyway" cluster. With this trick you should be able to use the same library wrapper module in as many suites you want.

Thanks to all on the mailing lists for the help on that topic.


I am already looking forward to JSR 277 which will hopefully replace the current implementation of the NetBeans module system. (no there was nothing anounced but this would make defenetive sense)

//NetBeans 7.0 with better desktop integration planed

Note: This entry has been posted on 1. April 2008 and nothing of that below is true :-)

- - - - -

You probably already know a lot of changes are planed for the NetBeans 7.0 release.

One of the bigger changes is tighter integration to the Windows Presentation Foundation for the SWT/JFace rewrite of NetBeans 7.0 similar tho the Eclipse roadmap. The minimum system requirement will rise to windows vista ultimate with a DirectX 10 capable graphics card and a USB stick plugged into your system (swap file for java quickstarter) to render NetBeans 7 in full HD. The primary reason for that was the out of the box Java 6 incompatibility to apple systems (who knows maybe it is compatible with MacOS X but no one will tell you because if he tried installing SE 6 on macs he/she also signed an NDA...) and the issue that many architects simple do not understand the internals of linux distributions (e.g Ubuntu) to install NetBeans.

On older cards or other operating systems JEdit will be started in compatibility mode (motif look&feel and full shell support).

The reason for that are the new consumer guidelines and download size limitations of the java 6 Update 10 release. (there is a because of backwards compatibility problems [to build 11] not fixable ArrayIndexOutOfBounds bug in the pack200 implementation - primary reason why the swing renderer does not fit into the NB 7 distribution anymore if started with Java 6 update 10).

This brings several advantages. E.g instead of playing Jake in the browser (update 10 required) NetBeans 7.0 will be capable to render Halo 3 in the editor pane (with full profiler integration and 16x FSAA text overlay). Regular patches will be available via update center.
Additionally to that better joystick support is planed. This should improve the navigation through larger projects and replace the "go to declaration" action. You may also activate the force feedback option in the new "user experience" tab in the options dialog to detect the files which causes unit tests to fail. (Note: not available in JEdit compatibility mode but there will be a blinking icon instead)

The higher costs to develop NetBeans 7.0 make a complete free distribution not feasible but it will be still free for opensource developers (but not without limitations e.g UML diagrams will be limited to only two kind of widgets "hack" and "ship" while maintaining 100% SSP compatibility).

//Garbage First - It has never been so exciting to collect garbage :)

If you are reading this entry, you probably already know about G1 the new Garbage First concurrent collector currently in development for Java 7.

Jon Masamitsu made recently a great overview of all GCs currently integrated into JVM of Java SE 6 and announces the new G1 collector on his weblog.

I asked him in the comments some questions about G1 and a very interesting discussion starts. Tony Printezis an expert from the HotSpot GC Group joined the discussion and answered all the questions very detailed.

(I have aggregated the discussion here because I think it is much easier to read if the answer follows next to the question without the noise between them)

me: I just recently thought about stack allocation for special kind of objects. Couldn't the hotspot compiler provide enough information to determine points in code when its safe to delete certain objects? For example many methods use temporary objects. Is it really worth to put them into the young generation?

Tony: Regarding stack allocation. I believe (and I've seen data on papers that support this) that stack allocation can pay off for GCs that (a) do not compact or (b) are not generational (or both, of course).

In the case of (a), a non-compacting GC has an inherently slower allocation mechanism (e.g., free-list look-ups) than a compacting GC (e.g., "bump-the-pointer"). So, stack allocation can allow some objects to be allocated and reclaimed more cheaply (and, maybe, reduce fragmentation given that you cut down on the number of objects allocated / de-allocated from the free lists).

In the case of (b), typically objects that are stack allocated would also be short-lived (not always, but I'd guess this holds for the majority). So, effectively, you add the equivalent of a young generation to a non-generational GC.

For generational GCs, results show that stack allocation might not pay off that much, given that compaction (I assume that most generational GCs would compact the young generation through copying) allows generational GCs to allocate and reclaim short-lived objects very cheaply. And, given that escape analysis (which is the mechanism that statically discovers which objects do not "escape" a thread and hence can be safely stack allocated as no other thread will access them) might only prove that a small proportion of objects allocated by the application can be safely stack allocated (so, the benefit would be quite small overall).

(BTW, your 3D engine in Java shots on your blog look really cool!)

thank you! :)

Read More

//Java 3D is dead (again). Long live Java 3D! ;-)

It was like a deja-vu for me as I read this announcement about the future plans of the Java 3D scenegraph API. It is already the second time the development of Java 3D has been set to 'maintenance mode' and stopped for any further improvements.

But this time it is not bad at all. Why?

"Specifically, we are working on a new 3D scene graph, as part of the
JavaFX player, that will complement the 2D Scenario scene graph. Its
initial focus will be 3D effects, casual games, and simple 3D viewing

OK. But what about projects like Wonderland which use Java 3D and are no "simple 3D viewing applications"?

It is getting even better: Project Wonderland announces the complete move to the JMonkeyEngine!

"As part of our recent review of Wonderland, which resulted in the API
cleanup tasks that are now underway, we also took a long look at our
graphics subsystem. Our main goal here was to ensure we could create a
very rich 3D experience. We also reviewed the tool chain for creating and importing
content into Wonderland. After careful consideration by the Wonderland
team, and discussion with the Java 3D team we have decided that
Wonderland will be best served by moving to the JMonkeyEngine scene
graph API... "

Now it is getting very interesting. Wonderland was always in my opinion a far to advanced project to be limited to the visual and design constrains of Java 3D (watch the videos!). The JMonkeyEngine is a full featured 3D (game) engine already used by professional game companies (NCsoft...).

Still not happy?

then be patient and wait for Java 3D 1.5.2 (maintenance release) which will be relicensed to a dual GPLv2 + CP ex license.

//Java SE 6 Update N Early Access build 10 available + new FAQ and release dates

a new ea build of Java 6 Update N is available with a lot of bugfixes, ready for testing.

my favorite fixes:

6641571RFE Enable new plug-in as default in 6u10 b10
6524352 Defect support for high-resolution mouse wheel
this was actually a really annoying one :) 

release schedule (on top) + download link (bottom).

New Java Kernel FAQ (interesting!)

//Pictures of my old 3D Engine in Java

Here are some screenshots of my 3D Engine (codename Metaverse) I made a few years ago (click to enlarge). It is written in Java and uses JOGL (JSR 231) as OpenGL binding and JInput to access the controllers.

These shots show the real time lighting and water rendering capabilities. They also show that you are the whole time on a real 3D planet (codename potato ;) ).

The next shows a 'test vehicle' to test model loading, animation, physics and collision detection of the Engine. You can use this vehicle to discover the planet - it makes even a lot of fun to drive through rough terrain and try to survive jumps from steep hills ;). The other screenshot shows the planet as wireframe.

The last two show the continuous triangulation of the terrain mesh and the space subdivision into a quad-tree (important for fast frustum culling and physics). The viewer is configured to be located inside the river bed.

You think that Java for 3D Graphics is like a penguin in hell? If you follow some rules to prevent stop the world garbage collections (full GCs) and prevent calls through the JNI where possible you can reach with the server (hotspot compiler) JVM performance comparable to C++ code.

The rendering performance is quite good. Even fast fly overs are rendered with 60+ fps (frames per second). If the camera stays still the renderer reaches 200+ fps on my notebook (ATI X1600) .

I have currently no time to continue with this project but if I think back how fun it was to work on that engine I would love to start hacking again immediately ;).

//NetBeans OpenGL Pack is evolving

The NetBeans OpenGL Pack is slowly evolving to a set of useful integrated tools, demo applications and editors for Java OpenGL development.

The features currently included are:

  • Editor for the OpenGL Shading Language (GLSL) with compiler error annotation, code folding, syntax highlighting, auto completion and documentation.
  • Easy access to the GLSL compiler and linker of your graphics driver integrated in the editor
  • OpenGL Capabilities Viewer
  • Integration of JOGL GUI components into the Matisse GUI builder
  • JOGL project templates
  • Ready to run JOGL demos and examples of the OpenGL Programming Guide (also known as Red Book) 

We are currently fixing the last bugs and hope to build the first release soon. The early access version is available via Update Center in the download section of the project page.

The project has also been recently mentioned in the NetBeans Magazine [issue four] covering NetBeans 6 features. Geertjan Wielenga interviewed me about the GLSL editor in the Schliemann section of the magazine.