Summary
We have JSE (J2SE) java.net/java.io, JME (J2ME) connectors and java.nio. It would be great if Dolphin could consolidate things.

In dolphin, the NIO jsr is supposed to finally happen. Some of the things that will happen, reportedly, is that we'll finally have Selector access to files (important in unix where not just files are files). One of the things that continues to bother me is how TCP/IP specific the original Selector implementation is. I'm also bothered by the fact that InputStream and OutputStream didn't become the "channel" of the Selector mechanism.

Instead, we have Selectors that just know about SocketChannels, ServerSocketChannels and the like. Thus to create a new SelectorProvider that might, perhaps provide access to RS232, USB, Bluetooth, or X25 communications paths, you can't really actually use the current Selector implementation because Selector doesn't have much real support for such "device" type protocols.

The JME connector architecture, for me, is much better designed for arbitrary streams. It's more focused on the I/O and less focused on the protocol/transport details. I'm starting to wonder if we shouldn't press the dolphin powers that be to go after a new I/O API for JSE that brings together the connector architure from JME together with a new Selector API thats more focused on generic I/O sources and less focused on the specific sources of I/O.

Talk Back!

Have an opinion? Readers have already posted 2 comments about this weblog entry. Why not add yours?

RSS Feed

If you'd like to be notified whenever Gregg Wonderly adds a new entry to his weblog, subscribe to his RSS feed.

Digg | del.icio.us | Reddit

About the Blogger

Gregg Wonderly graduated from Oklahoma State University in 1988 with an MS in COMSCI. His areas of concentration include Operating Systems and Languages. His first job was at the AT&T Bell Labs facilities in Naperville IL working on software retrofit for the 5ESS switch. He designed a procedure control language in the era of the development of Java with similar motivations that the Oak and then Java language development was driven by. Language design is still at the top of his list, but his focus tends to be on application languges layered on top of programming languages such as Java. Some just consider this API design, but there really is more to it! Gregg now works for Cyte Technologies Inc., where he does software engineering and design related to distributed systems in highly available environments.