Skip to main content

Let's See Action

Posted by editor on July 6, 2006 at 10:25 AM EDT

Seriously, why not implement JSR-80 in core?

Yesterday, I talked about trying to file a feature request to put an implementation of JSR-80, the Java USB API, in core Java, and how that would be a big step towards using Java to knock down barriers, such as device interoperability.

Part of my thinking here comes from my reaction to a forum thread quoted by Jeff Friesen in today's feature article on USB in Java. He wraps up his article by asking whether we should even have a USB API in Java. One line of thinking, in the thread USB support (especially for Windows) argues that this is "similar to having direct access to the physical layer on network cards or directly accessing the SCSI bus," and is thus the responsibility of the operating system.

Maybe that's the nice, clean, separation-of-concerns answer, but for Java-as-a-platform, it leads to a pretty non-functional dead-end. First off, let's stop thinking of USB only in terms of storage devices: of course, those are already abstracted away by the OS as filesystems. Fine. Now let's think about webcams, game controllers, card stripe readers, copy-protection dongles, etc., that use USB. Each of these is profoundly different, and in most cases, they aren't abstracted away by the OS: there's no core Java class that corresponds to the game controller as an input device, and the web cam, card stripe reader, and the dongle really don't have any corresponding representations.

Generally, the assumption has been that we need to use a JNI approach: create a Java representation, then back that up with a native representation for each platform we care about. But the problem with this approach is the spottiness of the platform coverage: for each set of devices we're interested in, we need developers who are proficient in Java and native ([Obj-]C[++|#]) code, and have an interest in these devices... and somehow with all those skills, don't have something better to do. Is it any wonder that important projects go wanting for a lack of qualified developers, especially when native code for multiple platforms is needed?

Now what if we had a broadly-capable Java USB library that was always part of the JDK or JRE distribution? Well, for all of these cases, we could eliminate the need to use native code: write a Java representation of some class of devices, then deliver implementations in Java, by making Java calls to the USB library. This would radically increase the number of developers capable of writing code to work with these devices, as developers who only know Java would be able to produce driver code... and would be able to do it for multiple platforms. In fact, this would even be good news for device manufacturers -- being in the hardware business, they don't necessarily care that much about software, and with a Java version, they could deliver end-user software for all platforms with one code drop.

Write once, plug anywhere. Why is this not already happening?

Returning our attention to today's realities, Jeff Friesen takes a clear-eyed view of the state of USB support in Java in today's Feature Article. In Java and USB, he takes a look at JSR-80 and the state of its reference implementations. He also looks at a rival API, jUSB. Finally, he shows how to roll your own USB library, with a native Windows 95/98/Me/2000 implementation of his own JavaUSB. He also looks at the broad question of whether USB is something that should be exposed to Java application developers, and proposes a novel idea: a high-level serial IO API that would cover USB, FireWire, and Bluetooth.

In today's Forums, nickminutello seeks some guidance for Mixing custom/manual marshalling with JAXB: "Basically, what I need to know is if/how I can use a mix of jaxb marshalling and my own custom marshalling to to marshal/unmarshal an object graph. Stated another way: I want to use jaxb to marshal and unmarshal my object graph but there are objects within this graph that I need to marshal/unmarshal manually (I have to use data that is only available at runtime to do it). I think I can work out the unmarshalling bit - by using an XMLFilter. But at the moment, its not clear to me how I can hook into the marshalling. Is there not some standard mechanism for plugging in custom/manual marshalling for some object types?"

Kleopatra reveals some SwingX internals (and their consequences) in [FYI] JXTreeTable - family secrets discovered: "...probably nothing new to the experts but I had to dig in core code to come up with a shattering fact: JXTreeTable actually _is_ a tree disguised as a table, it's not much more than an empty hull regarding its "tableness", the rendering tree rules near to everything: the content is driven by a TreeModel, the selection is driven by a TreeSelectionModel, and sorting/filtering is not supported because the tree doesn't support it."

In Java Today, Martin Odersky argues In Defense of Pattern Matching in a recent Artima blog: "When I propose pattern matching [to object-oriented programming advocates], I get violent outbursts of rejection. The arguments against are usually a permutation of: 1. Pattern matching is unnecessary, just use the visitor design pattern, 2. Pattern matching is not extensible, 3. Pattern matching breaks encapsulation. I disagree, obviously."

The Semantic Annotations for Web Services Description Language (SAWSDL) Working Group has released the First Public Working Draft of Semantic Annotations for WSDL. The attributes defined in this draft are references from elements within Web Services Description Language (WSDL) or XML Schema documents to concepts in ontologies outside the documents.

Tom Baeyens writes About BPM miracles and what you can expect in real life: "BPM vendors suggest the miracle that drawing a graphical process in their BPM tool will unify analysis, requirements and implementation. I guess it makes sense when you put it like this. But regrettably, many BPM vendors have a poor story on the bigger picture. This post will address the two main problems i have with current thinking around BPM and workflow: BPM vendors often overpromise by hinting that BPM tools can unify analysis with implementation, [and the] lack of integration between processes and plain general purpose programming language"

Jacob Hookom is concerned about the direction of webapp action frameworks in SAF2 and Shale: Missing the Buck, featured in today's Weblogs. "InfoQ.com just announced that Struts and Shale (JSF) are finally parting ways. Integration is one thing, collaboration is something wholly different."

Cay Horstmann wonders about Railroad diagrams: "Does anyone still use railroad diagrams (AKA syntax diagrams)? If so, how do you produce them?"

In Using relationships in the Java Persistence Query Language, Michael Bouschen writes: "The Java Persistence Query Language supports using relationships as defined in the object model in the query. The syntax of a relationship access expression is the same as in Java: a navigational expression using a dot as in o.customer."

In today's java.net News Headlines :

Registered users can submit news items for the java.net News Page using our news submission form. All submissions go through an editorial review before being posted to the site. You can also subscribe to the java.net News RSS feed.

Current and upcoming Java Events :

Registered users can submit event listings for the java.net Events Page using our events submission form. All submissions go through an editorial review before being posted to the site.

Archives and Subscriptions: This blog is delivered weekdays as the Java Today RSS feed. Also, once this page is no longer featured as the front page of java.net it will be archived along with other past issues in the java.net Archive.



Seriously, why not implement JSR-80 in core?
Blog Links >>