I am using Ubuntu 8.04 which contains a pre-compiled HAL  0.5.11rc2. I didn't report this bug at Ubuntu's bug tracker first as I think it may be in the source code. I am running it inside a VM on an x86 .

I have been communicating with a HAL daemon across the D-BUS daemon and was trying to call the FindDeviceByCapability method on the org.freedesktop.Hal.Manager interface (using /org/freedesktop/Hal/Manager as the object path). According to the specification, this method takes a string as an argument and returns an object array i.e.:
---
org.freedesktop.Hal.Manager interface

Only the /org/freedesktop/Hal/Manager object implements this interface. It's primarily used to discover devices. The following methods are available:
Method	Returns	Parameters	Throws	Description
...
FindDeviceByCapability	Objref[]	String capability	 	 Finds devices of the given capability.
---
However, when I call this method I am getting back an array of string objects, which doesn't play nice with my dbus-java bindings. I have attached the verbose output of these for verification. 

I thought there might be something wrong with the binding initially, but I also examined the source code for HAL in the git repository (which should have the latest version theoretically).  Under the project tree in the hald/hald_dbus.c file [1], I looked at the code that implements this method in manager_find_device_by_capability(). Its comments (just above the function) suggests it returns an object array. I noticed it uses a callback iterator function in the same file calledforeach_device_by_capability(). Looking at this function (which seems to build the object array) I noticed that it sets the type for each UDI to string, instead of object_path i.e. 
---
 604 static gboolean
 605 foreach_device_by_capability (HalDeviceStore *store, HalDevice *device, gpointer user_data)
 606 {
 607         DeviceCapabilityInfo *info = (DeviceCapabilityInfo *) user_data;
 608 
 609         if (hal_device_has_capability (device, info->capability)) {
 610                 const char *udi;
 611                 udi = hal_device_get_udi (device);
 612                 dbus_message_iter_append_basic (info->iter,
 613                                                 DBUS_TYPE_STRING,
 614                                                 &udi);
 615         }
 616 
 617         return TRUE;
 618 }
---

it even creates a DBUS_TYPE_STRING_AS_STRING type for the array in:
---
 661         dbus_message_iter_open_container (&iter, 
 662                                           DBUS_TYPE_ARRAY,
 663                                           DBUS_TYPE_STRING_AS_STRING,
 664                                           &iter_array);
---
Now I realise that changing this to the right type to match the specification would break alot of code that expects a string array (despite the specification saying that it returns an object array) e.g. see the tutorial at [2]. Hopefully a solution can be found that doesn't break too much code? I can work around the bug for now

[1] http://gitweb.freedesktop.org/?p=hal.git;a=blob;h=68892755c9f41b329801c0b1af6f251d71a7fcbf;hb=95bd4f1bf9a62f1551461841d64f6f1cdea6a92e;f=hald/hald_dbus.c
[2] http://softwarecommunity.intel.com/articles/eng/3818.htm