tisdag 3 januari 2012

Changing channel

Picking up my networking work. I created a VMNetChannel which holds all socket/net-related operations and altering VMChannel to only contain file I/O. Looking at where VMChannel is used, I can only find the entries listed in the screenshot.





Hopefully it is only a matter of:
1. Removing all net-related methods in VMChannel
2. Replacing VMChannel with VMNetChannel in net-classes
3. Recompile, ship and release! ;) Well... sort of.



Looking closer at the screenshot reveals that VMChannel is used in the VMChannelOwner interface. This interface makes sure that Channel implementations (i.e. any *ChannelImpl-class) can return a VMChannel... so I'm assuming this would also have to be replicated with a VMNetChannelOwner interface, which consequently must be implemented by any net/socket-related ChannelImpl-classes (i.e. *SocketChannelImpl). This will most likely lead to even more dependencies since each class using these implementations rely on VMChannel methods. Another solution would be to change the VMChannel class to an interface implemented by two new classes, VMFileChannel and VMNetChannel. They would throw exceptions for any un-implemented methods. That way, the classpath would still compile without to much change, but could/would(/should?) fail in runtime. One perk of the second solution would be that changes would only (looking quickly at the search result) be made in the reference-classes (the last three entries in the vm/reference/-drawer), which is good from a maintainability point-of-view. (Any VM-specific stuff should go in the vm-drawer, so any VM can use the non-VM-specific stuff [not in /vm/reference/]. If I were to make changes in other classes, these classes would have to be moved to the vm-drawer and affect more parts of the GNU Classpath.)


Don't know how much time I will have for Jamiga the next few months though... Hopefully some, but probably not much.