AsynchrronousByteChannel vs AsynchronousFileChannelandAsynchronousTransmitter

[Alexander Libman]

Hi Alan,
  
> Given that the usage differs a bit from the intended usage then this 
> seems more appropriate for a utility library or method. You might not 
> need to define a class name but instead have a static method that 
> returns an adapter, maybe:
> 
> static AsynchronousByteChannel newChannel(AsynchronousFileChannel ch) { 
> ... }

Agree as the implementation does not have any public methods 
except AsynchronousByteChannel methods.

> >   
> I don't have a strong opinion on this except to say that different 
> global positions for reading and writing is likely to be a surprise to 
> many developers.

There is an "intermediate" solution:
  static AsynchronousByteChannel newChannel(AsynchronousFileChannel ch,
                                            boolean twoOrOnePositions) 

So the developer can choose the behavior he wants.

 
> 
> > :
> > For this pure Java solution we do not have to specify thread pool.
> > After initiation of the first read, Transmitter initiates next 
> operations
> > from the completion handler for the previous operation.
> > So it works in both thread pools: for source and destination.
> >   
> It it possible that the source and target channel are associated with 
> different group and hence there would be problems with thread identity 
> if you don't specify who will call the completion handler. It's an 
> interesting question to think about.

I see you point, you want to specify the executor for the user completion
handler. I was more concentrated on internal implementation details and
was thinking that any thread pool (for source or destination) will be OK.
OK, here again solution that will satisfy any goal:

AsynchronousTransmitter {

  private AsynchrnousTransmitter (....);
  public static <A>
      Future<AsynchronousTransmitter>
           transmit(AsynchronousChannel inChannel,
                    AsynchronousChannel outChannel,
  		        A attachment,
 	              CompletionHandler<...>  handler,
                    Executor executor) 
  }

If the executor is null, it means that handler can be invoked
in any inChannel or outChannel thread pool (depends which  
internal completion comes last).
Otherwise, the developer can specify any Executor/ExecutorService.
If executor had been accessible for AsynchronousChannel,
then user could make a choice of three executors:
inChannel's, outChannel's or third-party executor.

BTW, it is one more argument to support getExecutor()  method for 
AsynchronousChannel and AsynchronousGroup.
I expect more coming asynchronous engines based on similar to AsynchronousTransmitter or
AsynchronousFilter ideas.

I rememeber that the problem is in default AsynchronousGroup, which
should not be closed by user. 
Is it possible to throw SecurityExeption or introduce other exception, if  the user made attempt
to shutdown default group?

Alex