Announce : BlueZ-based implemantation of JSR82

Hi,

We have developped a JSR-82 implementation for Linux, which is based on BlueZ and which is compatible with most USB-Dongle's.

We've used parts of JavaBluetooth.org's works and parts of JBluez's stuff.
The native C-Code of the project is entirely based on the BlueZ project and I would like to thanks Marcel Holtmann for his answers to my questions, which were all helpfull.

We've decided to make the Linux version OpenSource.

The JSR-82 specification is not yet fully implemented but the major part of the work (let say 95%) is done.

The package can be downloaded at the following address:
http://www.avetana-gmbh.de/avetana-gmbh/jsr82.xml

The web site is in german but will be soon translated in english.

JSR-82 is a Sun Microsystems specification for easily developping bluetooth based application in Java.
Good tutorials can be found on the Java developper Center web site as well as on manay other web sites.
For more information about JSR-82, please consult the site:
http://www.jcp.org/en/jsr/detail?id=82

We have developped a JSR-82 implementation for Linux, which is based on BlueZ and which is compatible with most USB-Dongle's.

We've used parts of JavaBluetooth.org's works and parts of JBluez's stuff.
The native C-Code of the project is entirely based on the BlueZ project and I would like to thanks Marcel Holtmann for his answers to my questions, which were all helpfull.

We've decided to make the Linux version OpenSource.

The JSR-82 specification is not yet fully implemented but the major part of the work (let say 95%) is done.

Hi Julien,

Quoted 8 lines

We have developped a JSR-82 implementation for Linux, which is based on BlueZ and which is compatible with most USB-Dongle's.

We've used parts of JavaBluetooth.org's works and parts of JBluez's stuff.
The native C-Code of the project is entirely based on the BlueZ project and I would like to thanks Marcel Holtmann for his answers to my questions, which were all helpfull.

you are welcome.

Quoted 2 lines

We've decided to make the Linux version OpenSource.

Quoted 2 lines

The JSR-82 specification is not yet fully implemented but the major part of the work (let say 95%) is done.

I would never use Java for Bluetooth programming, but it seems that some companies wants this, especially mobile phone manufacturers. So I think we should build up a clean implementation of the JSR-82 standard that uses BlueZ as underlying Bluetooth stack.

Clean means for me that we
should concentrate on BlueZ and try to interface BlueZ<->JSR-82 as best as possible.

Give me some comments if there is really interest in doing this.

Regards

Marcel

It seems that the current implementaion of "hciconfig" does not support the "flush timeout" configuration for ACL data.

Is there any plan on it as it is important for the real-time traffic?.

According to the specification, the default value is infinite.

Quoted 4 lines

I would never use Java for Bluetooth programming, but it seems that some companies wants this, especially mobile phone manufacturers. So I think we should build up a clean implementation of the JSR-82 standard that uses BlueZ as underlying Bluetooth stack.

This is exactly what I did, or at least I have implemented a big part of the JSR-82 Standard with BlueZ as underlying Bluetooth stack. (I suppose but do not really know if the implementation is clean:)). If you want this implementation to be part of the BlueZ project, I (and especially my boss:) agree.

To better understand the way I have interfaced BlueZ <->JSR-82 and if you have enough time for this, I invite you to have a quick look at the file sources/c/BlueZ.cpp contained in the tgz archive downloadable at
http://www.avetana-gmbh.de/avetana-gmbh/jsr82.xml

This c file mostly re-write some BlueZ method and has surely to be cleaned and documented.
This will be the next step of my work. This version is still a beta-version but is stable and robust enough to be used in a project. especially if the project uses RFCOMM connections. (there is still some work to do with L2CAP).

Quoted 2 lines

Give me some comments if there is really interest in doing this.

I will continue to work on this project until I reach a clean and really stable implementation. If you have any comment about the implementation do not hesitate to mail me.

There are main reason why I rewrote some BlueZ functions is that:
- Functions like "sdp_service_search_attr_req" return a list of sdp_record_t. If I had to parse these sdp_record_t in order to construct the requested Java Objects, this would have been an amazing amount of switch or if statement. The best solution was therefore to directly send the bytes to the java implementation.

Quoted 3 lines

What I also don't wanna use is somekind of "de.avetana.bluetooth" vendor extensions. If something is not possible in pure Java JSR-82, sorry not my bad ;)

JSR-82 provides just the minimal amount of classes. It lets the programmer use "background classes" but this is transparent for the end-user (I will give some example of this transparency in the future how-to). These de.avetana.bluetooth.* classes are really needed to fully implement all javax.bluetooth.* classes.

Quoted 3 lines

The native interface should only be a wrapper. Let's talk about the stuff and put some of it back to the Bluetooth library where it should belong.

I would say that 90% of the native interface is today a wrapper. Only the service search uses home-made-functions derived from the BlueZ code.

Hi Julien,

Quoted 7 lines

There are main reason why I rewrote some BlueZ functions is that:
- Functions like "sdp_service_search_attr_req" return a list of sdp_record_t. If I had to parse these sdp_record_t in order to construct the requested Java Objects, this would have been an amazing amount of switch or if statement. The best solution was therefore to directly send the bytes to the java implementation.

put this problem up in a seperate thread on the mailing list and tell how the Java Objects have to look like. We should find a better solution for that.

Quoted 4 lines

Quoted 3 lines

What I also don't wanna use is somekind of "de.avetana.bluetooth" vendor extensions. If something is not possible in pure Java JSR-82, sorry not my bad ;)

Quoted 5 lines

JSR-82 provides just the minimal amount of classes. It lets the programmer use "background classes" but this is transparent for the end-user (I will give some example of this transparency in the future how-to). These de.avetana.bluetooth.* classes are really needed to fully implement all javax.bluetooth.* classes.

You must explain this to me in detail, because I don't understand why. Actually I think we should avoid this.

Quoted 7 lines

Quoted 4 lines

The native interface should only be a wrapper. Let's talk about the stuff and put some of it back to the Bluetooth library where it should belong.

I would say that 90% of the native interface is today a wrapper. Only the service search uses home-made-functions derived from the BlueZ code.

As said already, lets fix this in the Bluetooth library itself. I know that SDP itself is a horrible mess of object oriented stuff, but I think we will find a solution for it.

Regards

Marcel

-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Am Di, den 25.05.2004 schrieb Marcel Holtmann um 17:07:

Quoted 1 line

Hi Julien,

Hi Marcel,

Quoted 11 lines

Quoted 7 lines

There are main reason why I rewrote some BlueZ functions is that:
- Functions like "sdp_service_search_attr_req" return a list of sdp_record_t. If I had to parse these sdp_record_t in order to construct the requested Java Objects, this would have been an amazing amount of switch or if statement. The best solution was therefore to directly send the bytes to the java implementation.

put this problem up in a seperate thread on the mailing list and tell how the Java Objects have to look like. We should find a better solution for that.

I will post this today or tomorrow. Furthermore, I will provide the HOW-TO help file next week (sorry for the delay, but I currently have a lot of work to do!).

Quoted 4 lines

Quoted 4 lines

Quoted 3 lines

What I also don't wanna use is somekind of "de.avetana.bluetooth" vendor extensions. If something is not possible in pure Java JSR-82, sorry not my bad ;)

Quoted 8 lines

Quoted 5 lines

JSR-82 provides just the minimal amount of classes. It lets the programmer use "background classes" but this is transparent for the end-user (I will give some example of this transparency in the future how-to). These de.avetana.bluetooth.* classes are really needed to fully implement all javax.bluetooth.* classes.

You must explain this to me in detail, because I don't understand why. Actually I think we should avoid this.

In order to explain this, I will take an example:
JSR-82 provides an interface called ServiceRecord. The role of the class could be compared with the role of the sdp_record_t of BlueZ: storing attributes and related DataElements.
But no implementation of ServiceRecord is provided, it is just an interface.
Moreover, a look at the description of some JSR82 methods like LocalDevice.getRecord() shows that two kinds of ServiceRecord are
needed: a "local" ServiceRecord and a "remote" ServiceRecord. This two ServiceRecord must differ (for example, the "local" Service Record does not implement some methods like getConnectionURL()).
That's why I had to provide two different implementation of ServiceRecord (LocalServiceRecord and RemoteServiceRecord). But if you use the javax.bluetooth.* api, you will mostly manipulate ServiceRecord objects without even knowing if they are instance of Local- or RemoteServiceRecord.

Quoted 11 lines

Quoted 7 lines

Quoted 4 lines

The native interface should only be a wrapper. Let's talk about the stuff and put some of it back to the Bluetooth library where it should belong.

I would say that 90% of the native interface is today a wrapper. Only the service search uses home-made-functions derived from the BlueZ code.

As said already, lets fix this in the Bluetooth library itself. I know that SDP itself is a horrible mess of object oriented stuff, but I think we will find a solution for it.

Thanks!

Regards,

Julien

Quoted 8 lines

Regards

Marcel

Quoted 9 lines

-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Yeah, having built a JSR82 solution with callbacks to Java from the native layer for SDP, I can whole-heartedly recommend passing the bytearray returned from the search back to Java and parsing it there.

I'd been thinking of splitting the SDP code along these lines: one base layer which encapsulates the protocol and some user-space helper functions which (de-)construct the byte-arrays passed to this base layer. What do you think Marcel?

Quoted 4 lines

Quoted 4 lines

Quoted 3 lines

What I also don't wanna use is somekind of "de.avetana.bluetooth" vendor extensions. If something is not possible in pure Java JSR-82, sorry not my bad ;)

Quoted 8 lines

Quoted 5 lines

JSR-82 provides just the minimal amount of classes. It lets the programmer use "background classes" but this is transparent for the end-user (I will give some example of this transparency in the future how-to). These de.avetana.bluetooth.* classes are really needed to fully implement all javax.bluetooth.* classes.

You must explain this to me in detail, because I don't understand why. Actually I think we should avoid this.

In order to explain this, I will take an example:
JSR-82 provides an interface called ServiceRecord. The role of the class could be compared with the role of the sdp_record_t of BlueZ: storing attributes and related DataElements.
But no implementation of ServiceRecord is provided, it is just an interface.
Moreover, a look at the description of some JSR82 methods like LocalDevice.getRecord() shows that two kinds of ServiceRecord are
needed: a "local" ServiceRecord and a "remote" ServiceRecord. This two ServiceRecord must differ (for example, the "local" Service Record does not implement some methods like getConnectionURL()).
That's why I had to provide two different implementation of ServiceRecord (LocalServiceRecord and RemoteServiceRecord). But if you use the javax.bluetooth.* api, you will mostly manipulate ServiceRecord objects without even knowing if they are instance of Local- or RemoteServiceRecord.