Summary
We have JSE (J2SE) java.net/java.io, JME (J2ME) connectors and java.nio. It would be great if Dolphin could consolidate things.
Advertisement
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.
A close look at even just the .io package shows some fundamental design mistakes, such as the InputStream and OutputStream interfaces being .. um .. classes. This ends up two levels down (with DataInput/DataOutput in the middle) totally uglifying the ObjectInput and ObjectOutput interfaces, which forcibly include the OIS/OOS methods .. not to mention the impossibility of extending DataInputStream/DataOutputStream, which adds its own ugliness.
Previous Topic
