La clase que fue concebida para esta labor evidentemente es la clase File, a continuación te dejo la documentación correspondiente: http://docs.oracle.com/javase/7/docs/api/java/io/File.html

Y un recordatorio: tratar los filepaths como URIs, las razones de esto las explican bien en Java Puzzlers

Saludos

la clase File?, no lo creo, sino para que exiten clases como el FileReader, BufferedReader, etc, para manipular archivos.

aparentemente el paquete java.nio.* es de las mas potentes( inclusive que la clase RandomAccessFile ).

qué tan cierto es esto??gracias.salu2

Lo que pasa es que estás confundiendo algunas cosas, cada clase que mencionas es muy diferente a la otra, y sirven para cosas y propósitos igualmente diferente. Vamos a ver:

java.io.File
Esta es la abstracción de un Archivo (File) y de los pathnames (Rutas y nombres). Así entonces podemos encontrar funcionalidades como isDirectory(), isFile(), mkdir(), renameTo(), que nos permitirán realizar acciones sobre archivos y directorios como: crear, mover, obtener información de tamaños, nombres, rutas, testear si son directorios, archivos, ejecutables, si están escondidos, etc.

java.io.FileReader
Esta clase hereda de java.io.InputStreamReader y esta diseñada para leer archivos como streams de caracteres, lo que lo hace ideal para leer archivos en texto plano por ejemplo. lo que quiere decir en definitiva que lee caracteres y no bytes. En ella encontrarás métodos como read() o getEncoding()

java.io.BufferedReader
Esta clase al igual que la anterior lee a través de streams de caracteres, la gran diferencia con la anterior es que lo hace a través de buffers, lo que le da eficiencia. Un objeto de esta clase solo puede ser construido especificando un Reader. lo que quiere decir que por ejemplo se puede usar con un FileReader.

Ahora la manzana de la discordia tal vez si pueda ser un poco esta:

java.nio.*
Lo primero que hay que entender de java.nio.* es que no fue creada para reemplazar a java.io.*, fue creada para complementarla. Es por esta razón vamos a encontrar funcionalidades ampliadas, no así las mismas funcionalidades que ofrece java.io.*

java.nio.* fue concebida para ofrecer operaciones de bajo nivel en la manipulación de acciones I/O. Y tal vez su ventaja más grande y destacada es que estas operaciones son realizadas de forma asincrona (Asynchronous I/O) o No-bloqueante (Non-Blocking I/O) lo que quiere decir que mientras se hacen se realizan procesos de I/O el flujo del programa no se detiene (no se hacen llamadas bloqueantes: Blocking-calls). esto se logra de diferentes maneras y técnicas, si quieres saber más al respecto aquí encontrarás mucha más información. Y para más información acerca de java.nio aquí encontrarás más información, ya que en este aspecto la información es muy amplia (uso de Channels, Buffers, Charsets, etc)

Espero haya quedado un poco más claro (aunque veo veo las explicaciones un poco toscas, igual en todas partes encontrarás links a la documentación oficial de Java SE 7 para ampliar y aclarar la info).

Saludos

Bueno, todo depende de las funcionalidades que necesites. Del proposito que tengas. Pero en general  las dos no son mutuamente incluyentes (excluyentes tampoco), si una clase te ofrece una funcionalidad que la otra no tiene pues la importas y la usas.

java.nio también puede trabajar con Sockets, de hecho por su naturaleza asíncrona es ideal para escribir servidores por ejemplo, también es bastante util para reducir el uso y creación de Threads.

Y si, básicamente la clase URL es muy vieja y tiene algunos problemas de compatibilidades con pathnames locales y de comparación en la resolución de nombres. Por eso puede terminar en comportamientos extremadamente dificiles de depurar y corregir.

Saludos

De nada, espero haya sido de ayuda

Saludos