JSR-80 - USB and Java

[Jurrie Overgoor]

Hello everyone,

The Usb4Java project also has an implementation of JSR-80. But the JSR-80 doesn't seem to be getting a lot of traction these days. I was wondering why, and if there are people who would like to have that project be revived?

All things stem from pet projects, and so is this. I am working on porting a third party Windows-only program. It configures a USB piano. I would like to have a Linux and an Android version. JSR-80 with implementations for each of these platforms would be ideal for me. It seems like the way to go.

USB is available on a wide range of devices. And since Java promises to be cross-platform, it seems the two would be an excellent match. Why didn't JSR-80 take off I am wondering.

With kind regards,

Jurrie Overgoor

[Dennis Sheirer]

The existing implementation seems to be fairly complete.  Is there additional features or capabilities that you thinking about?

I'm using it here: https://github.com/DSheirer/sdrtrunk  and I have a couple additional native library implementations (mac/aarch64 and windows/aarch64) here: https://github.com/DSheirer/usb4java-native-libraries . I've thought about using JDK23 FFM and JExtract to wrap libusb, simply to avoid compiling additional native JNI libraries for future hardware, but that's just a thought at this point :-)

Denny 

[GM SEED]

For what it's worth, my observations on usb4java after having used it for several years:

1) Firstly, thanks to DSheirer for providing natives that usb4java 1.3.0 doesn't provide.

2) Following on from point 1), if my memory serves me well then I think v1.3.0 dates back to 2018, and 6 years ago. It's as though a v1.4.0 isn't going to happen and is of slight concern when a project is dependent on a third-party library. I've posted questions on the usb4java GitHub Issues page and it is clear that it is dead. So, I think it is natural to wonder where it is heading.

3) I recently converted our project from J8 to J21 and since usb4java doesn't have a module-info.java file there is the usual and annoying way of having to reference a non-module project, but it does work. However, since usb4java is really nothing more than a wrapper around the natives I did encounter an issue in Eclipse being unable to find the correct native dll. I spent some considerable time on this and never did find an answer. The solution I came up with in the end was to modified the Loader.java file so when run in Eclipse it knew where to find the natives. Personally, I've never liked the copying of the natives to a temporary location.

4) Let's say a new USB project was developed and compliant to JSR-80 as the original post suggests. It would need to be faster than the current usb4java. If it was slower then what would be the point? If it was as efficient, what would be the point? And then how is a pure Java USB library going to be faster than the underlying C libusb natives? I'd be very surprised if it would be. This also leads to the question apart from performance, what new would such a project bring to the table?

Graham

[Jurrie Overgoor]

Hi Danny and Graham,

Thanks for replying.

I think I might not have explained myself clearly enough 😀

I would like to have a standard like JSR-80 that only contains specification, no implementation. It would contain classes or interfaces like `UsbDevice`, `Pipe`, etc.

Then, other projects could implement support for that spec for a specific platform. Usb4java (or similar) could be that project for Linux, using native libraries. Or perhaps it could be supported directly in the JVM. Google could support it on their Android platform. And so on. (It's a bit like for example the Jakarta JPA spec, which according to Wikipedia has multiple vendors / implementations.)

What you would end up with is 1 specification to which you can program, and a wide range of implementations that would "just work". In my case (configuring the USB piano) I could create 1 Java library for communicating with the device. Then I could have a desktop application and an Android application. On Windows the desktop application would use the Windows implementation for the JSR-80 (or similar) spec; on Linux it might use Usb4java. If Google would support the spec, then on Android I can re-use my Java library again.

To me it seems that JSR-80 was very much (or exactly) the spec I'm talking about. I was wondering why it didn't take off? Did it have shortcomings?

So to answer the questions:

- Is there additional features or capabilities that you thinking about?
No, Usb4java seems very complete. At least for what I want to do (just bulk transfers). It's just cross-platform support that I'd like to achieve.

- And then how is a pure Java USB library going to be faster than the underlying C libusb natives?

I don't think it would be faster. I did not meant to say I want a pure Java USB library. On platforms where libusb is available, the spec-in-question could be implemented as a wrapper around it. Just like Usb4java is now. (So Usb4java could be a candidate. But the ultimate goal would be to have support for the spec-in-question directly inside the JVMs. Then, no native libraries would have to be shipped with your application, and your application would run everywhere where the JVM runs.)

With kind regards,

Jurrie

[Dennis Sheirer]

Jurrie, there's a link on the usb4java website that links back to work on the original JSR-80 specification: https://javax-usb.sourceforge.net/

It's dated ~2006 and looks like some of the content may have been lost over the years.