Usage of new Java5 method - inheritedChannel()
Posted on December 28th, 2007 by Rajs
Posted in blog city on September 3rd 2004
I am struggling to understand how to use the new method inheritedChannel() in java.lang.System.
Any example code on the usage? The method returns an instance of Channel interface which has only two methods close() and isOpen(). So, unless one knows the exact class that is returned by this method (SocketChannel, DatagramChannel, ServerSocketChannel etc), there is nothing much that can be done with inheritedChannel method.
So, are developers expected to somehow “detect” (instanceof?) the exact class that is being returned and use this method? If that is indeed the intention, not sure what is the purpose of returning an interface that is useless.
Comments
|
#1
|
‘‘ posted this on Sat 4 Sep 2004, 12:37 am
What would be the point of giving it a less specific return type? It gives the programmer a good idea about what is going on. Most types do not specialise Channel.The idea, I believe, is that a program would be written to expect the inherited channel to be something specific. Obviously giving a nice error message in the case of that expectation not being reached is a good idea. So a logind style program may start up a Java program as a particular user inheritting a SocketChannel. Listening to ports less than 1024 is not allowed for user programs under UNIX, therefore a web server may inherit a ServerSocketChannel bound to port 80. It’s tough if you want two channels, for instance to support both HTTP and HTTPS.
|
|
#2
|
‘Rajs‘ posted this on Thu 9 Sep 2004, 4:06 pm
To me looks like this is violating some fundamental principles of OO. The API is kind of forcing it’s users to always check for the return type. With out this one cannot do anything. It is kind of same as returning java.lang.Object.Ideally it would have better if there is some other interface or base class from which all these different channels are derived OR there should have been more methods that Channel interface must be enforcing. To me, it looks like a design issue. |
|
#4
|
‘Rajs‘ posted this on Mon 4 Oct 2004, 2:50 am
Anon,I am aware of the SelectorProvider api when I wrote this blog. That’s exactly the problem I was talking about. One has to do an “instance of” kind of operation to figure out which among the ServerSocketChannel, SocketChannel and DatagramChannel is returned. There is no other way to figure out.Rajs |
Filed under: Java, Technology

What would be the point of giving it a less specific return type? It gives the programmer a good idea about what is going on. Most types do not specialise Channel.The idea, I believe, is that a program would be written to expect the inherited channel to be something specific. Obviously giving a nice error message in the case of that expectation not being reached is a good idea. So a logind style program may start up a Java program as a particular user inheritting a SocketChannel. Listening to ports less than 1024 is not allowed for user programs under UNIX, therefore a web server may inherit a ServerSocketChannel bound to port 80. It’s tough if you want two channels, for instance to support both HTTP and HTTPS.


This is a great feature! Now I can write my inetd daemons in java. Cool!
Oh, sorry, forgot to include sample code.
import java.io.PrintStream;
import java.net.Socket;
import java.nio.channels.SocketChannel;
public class jInetdApp
{
public static void main(String[] args)
throws Exception
{
SocketChannel client = (SocketChannel)System.inheritedChannel();
PrintStream ps = new PrintStream(client.socket().getOutputStream());
ps.println(”Hello world”);
} // public static void main(String[] args)
} // public class jInetdApp
I will assume the reader knows how to program UNIX inetd daemons in c.
cj