Develop Reference

how to choose java nio vs io?

As we had known, If we want to use traditional IO to construct server, it must block somewhere, so we had to use loop or one thread one socket mode, So nio seem it is better choice. So I want know if the nio is better choice forever?

IMHO, Blocking IO is generally the simplest to use, and unless you have a specific requirement which demands more from your system, you should stick with simplest option.
The next simplest option is blocking NIO, which I often prefer if I want something more efficiency or control than IO. It is still relatively simple but allows you to use ByteBuffers. e.g. ByteBuffers support little endian.
A common option is to use non-blocking NIO with Selectors. Much of the complexity this introduces can be handled by frameworks such as Netty or Mina. I suggest you use such a library if you need non-blocking IO e.g. because you have thousands of concurrent connections per server. IMHO You have thousands of connections, you should consider having more servers unless what each connection does is pretty trivial. AFAIK google go for more servers rather thousands of users per server.
The more extreme option is to use NIO2. This is even more complex and lengthy it write than non-blocking NIO. I don't know of any frameworks which support this well. i.e. it is actually faster when you do. AFAIK It appears this is worth using if you have Infiniband (which is what it was designed to support) but perhaps not worth using if you have Ethernet.

If you want non-blocking IO, NIO is not the better choice—it's the only choice in Java. Keep in mind that people still use the old IO regularly because it is way simpler to code against. NIO API is quite raw and is more of an enabling low-level technology than a client-side API. I suggest using NIO through an API that provides a simpler interface to the problems you want to solve using non-blocking IO.

A little late, but personally, I use NIO even for the regular "everyday" file handling. So, I use things like:
1. if(Files.notExists(path)) { }
2. Files.createDirectory(path);
3. Files.newInputStream(path) targetPath.resolve("somefile.txt");
4. Files.newBufferedWriter(path, charset);
5. DirectoryStream<Path> directoryStream = Files.newDirectoryStream(path);
and it works fine for me. I prefer Path instead of the old File because of methods like relativize or resolveSibling.
Doesn't strike me as more complicated than IO.

You would only use NIO if you can justify the inevitable complexity that it introduces. If you do not have any guidance in terms of the expected load, and also in terms of whether your product / project has the resources to maintain the relevant code, then your should err on the side of caution and use IO.
To give my answer some weight, I have just spent three months maintaining and bug fixing an integration layer where raw Java NIO (i.e. no overarching framework was used) was used. The design was based, in essence, on client threads adding messages to a queue and a small number of worker threads performing their NIO magic and then passing replies back to client threads in an event-based manner. In retrospect, I cannot justify the original decision to use NIO, since it became a distraction that ate significant amounts of time that should have been spent on higher level business logic.

You can use any of this, unless you are going to create "super fast" server.
Of course a good approach here is to use nio, since it's new and modern way to write multi-client servers for high throughput tasks.

Some advantages of the NIO.2 API over the legacy java.io.File class for working with files:
Supports file system–dependent attributes.
Allows you to traverse a directory tree directly.
Supports symbolic links.
For specific use cases and more details, you can see this article

Traditional IO is easy and simplified code, NIO is more complicated but more flexible.
In my case i prefer use IO for small streaming and NIO for large streaming but nio is really more complex
with NIO i have to create an entire package to manage it instead io package that i directly use snippet

HTTP Client with NIO2

Have someone familiar with HTTP Client that based on JDK7 and NIO2,
Implementation that use: AsynchronousSocketChannel
I am looking for implementation that based on NIO2 and can scale out unlimited, thousands of HTTP requests concurrently.
NOTES:
please do not suggest me an implementation that based on NIO1 like Apache::AsyncHTTPClient and JBOSS::Netty framework
Please do not suggest me a solution that based on distribute solution, I am looking for one client that can handle all the HTTP requests efficiently.
THANKS!

I would recommend checking out AsyncHttpClient. It was written by the guy that wrote Grizzy for Sun and now works for Sonatype.

I believe you are mistaken in your assumption that you must use NIO2 to scale up. Please listen!
NIO2 is the non-blocking version of Java's IO. This means it's easier to write high performance io in NIO2 because you need not start and manage threads, because most of your threads are just going to be waiting on IO. Multi-threaded programming is tricky, so anything to make it easier is a feature, hence NIO2.
However, as a library user how hard the library was to write isn't your concern. Modern JVMs can handle a lot of threads and the old io API should be powerful when used by skilled programmers. Since you are a user of the library, I suggest that you just find the fastest library.
HTTPClient from Apache is a very popular library. I suggest you get in contact with the experts on that and ask them your performance questions. I'm not an expert in this area, so I'm not telling you HTTPClient is the best, I'm just saying not to count it out yet and that talking to the HTTPClient people would be a good place to start.
Good Luck

What is about NIO problems in Scala / Java

While searching the web for concurrency in jvm I found questions about searching Non-blocking IO library for Scala / Java.
What is the problem about? If I want to send something to file / socket I can launch separate thread which make the job.
I know there could be problem using event based threads - because whole system could be blocked. But does it reference to JVM/ Scala?
ADDED:
Please correct me if I'm wrong:
I think that when you need to call some IO function in asynchronous way it need to go into separate process or system (heavy) thread. Am I right?
So - all the questions about solving this kind of thing in common languages goes into creating and managing separate process or threads. So the only facilitate from the language is to create some pool of threads which will be assigned to IO operations in async.
So my hypotheses is.
Sentence: Language X is better then Y because calling async IO operation dosen't block the virtual machine is false because in every language that support system threads there is possibility to manage NIO, the only difference is that language X has better support for this through builtin libraries / language features.
Is this hypothese Truth?
Can some language achieve NIO without os system support? (through processes / threads)

Scala has a bunch of tools for concurrency, and NIO has a few tools for non-blocking IO. So, it should come as no surprise that there are a lot of great libraries that help connect the dots:
Finagle
... a library for building
asynchronous RPC servers and clients
in Java, Scala, or any JVM language.
Built atop Netty, Finagle provides a
rich set of tools that are protocol
independent.
Akka is a pretty nice, featureful actors/concurrency/services package which also uses Netty for their built-in remoting functionality
Naggati2 is another one from Twitter, also built on Netty, not sure if it's being superseded by Finagle though.

Here is an interesting recent blog post that may help you: http://jim-mcbeath.blogspot.com/2011/03/java-nio-and-scala-continuations.html

java.nio.channels.*

What is up with nio channels ? There were some nice talks when it was added to java but I still don't see people using it in their applications.
Is there something wrong with it, or am I just not encountering people who use it?
Any nice examples as to why I should bother using it at all ?
Thanks

You're asking about channels, but channels only make sense within the general framework of using the (relatively) new nio capabilities as a whole.
My guess is that of the many, many Java applications out in the world, not many need the capabilities of nio. The usual "business" process read streams and/or files... nothing special.
That said, the Apache folks have recently rewritten their core Java libraries ( http://hc.apache.org/ ) to use nio, and claim some impressive performance benefits in some cases.
nio also lets you do stuff like memory-mapping files, and this can allow an application to do very fast random access to the file. Again, only some special applications need this, and that's probably why you don't see a lot of it used.

Apache Mina is a great networking library and uses NIO.
Apache MINA is a network application framework which helps users develop high performance and high scalability network applications easily. It provides an abstract · event-driven · asynchronous API over various transports such as TCP/IP and UDP/IP via Java NIO.

Net4J, a signaling platform/framework, makes heavy use of NIO channels. (One part of Net4J basically provides a convenience API to NIO channels.)

Asynchronous IO in Java?

What options for async io (socket-based) are there in java other then java.nio? Also does java.nio use threads in the backround (as I think .NET's async-socket-library does, maybe it's been changed) or is it "true" async io using a proper select call?

Java's NIO package (as of Java6), provides support for non-blocking I/O only, via Selectors. Java7 is hopefully going to ship with NIO.2, which includes asynchronous I/O support. Today, your best bet is to make use of a framework. ARMistice mentioned Mina. Here are some others.
Grizzly. This is the I/O core for Sun's GlassFish server. Grizzly provides a facility for doing asynchronous reads/writes (via a queue model). It supports TCP and UDP alike. I've used Grizzly in a couple of projects. There are things I like and dislike about the framework, but to detail this is really another topic. I will say that it's quite easy to get something up and running and Grizzly does a lot of the heavy lifting for you.
Netty. This project comes from one of the original authors of the Mina project. I haven't used this one so I don't know about its support for asynchronous I/O. You should take a look.
Now, with regard to your question about threads, NIO Selectors do not use threads for non-blocking I/O. In JDK6 they use select() under Windows and the epoll facility on newer Linux kernels. For asynchronous I/O, threading details depend on the framework.

JAVA 7 arrived so new answer is NIO.2 with Future class. Example :
On server side:
final AsynchronousServerSocketChannel serverSocket=
AsynchronousServerSocketChannel.open().bind(new InetSocketAddress("127.0.0.1", 2587)); // Listening on port 2587 for client connection
Future<AsynchronousSocketChannel> future= serverSocket.accept();
final AsynchronousSocketChannel clientSocket= future.get(); // now it's blocking, useful: future.isDone() and .isCancelled()
//Do whatever you want ..
InputStream stream = Channels.newInputStream(clientSocket) (...)
On client side:
AsynchronousSocketChannel clientChannel = AsynchronousSocketChannel.open();
Future connected = localSocket.connect(ourServerSocketAddress);
// later: if(future.isDone())
connected.get();
//Send something
OutputStream os = Channels.newOutputStream(clientChannel );
os.write (...)
Update:
If you can use actor model then AKKA TCP IO would be even better.

Another suggestion in regards to libs would be Naga (http://naga.googlecode.com). It is a bit less like a framework and more like a library. It tries to look more like the ordinary java sockets, if that is your cup of tea. It's minimalistic compared to Grizzly, Mina and Netty.

java.nio is just a package - a collection of "dumb" classes - by itself it does not employ any use of threads. When used properly, such as in the Reactor design pattern, you can achieve proper, fully-scalable, asynchronous I/O.

If you are interested in using it for Network Stuff. A really good choice is:
http://mina.apache.org/
Have a look there its easy to use and very powerfull.

To the original question, the implementation only consumes a thread per I/O operation in one case, AsynchronousFileChannel on Unix/Linux systems.