Есть ли простой, единственный NIO2 способ преобразования URL-адреса в путь

    URL url = new URL("file:/C:/projektoj/ĝeneralaj");
    Path path = Paths.get(url.toURI());

C:\projektoj\ĝeneralaj

Если URL-адрес указывает на jar/zip ("jar:file:/... .zip!.../..."), то можно использовать путь в файловой системе zip, см.: java: изменить имя ZipEntry

Я искал что-то вроде:

JarURLConnection connection = (JarURLConnection) sourceUrl
     .openConnection();

Paths.get(connection.getJarFileURL().toURI());

Взгляните на:
http://docs.oracle.com/javase/tutorial/essential/io/pathClass.html

Примечание версии. Если у вас есть код до JDK7, использующий java.io.File, вы все равно можете воспользоваться преимуществами функциональных возможностей класса Path, используя метод File.toPath. Дополнительную информацию см. в разделе Устаревший код файлового ввода-вывода.

Отредактировано: я думаю, что метод File.toPath() должен быть тем, что вы хотите, он возвращает Path, в этом случае Paths.get(URI) не нужен.

Отредактируйте еще раз: вы можете воспользоваться Paths.get(URL.toURI()), если начнете с URL-адреса, но вам нужно обработать URISyntaxException, выброшенный из URL.toURI().

Как упоминал @Stephen C, Path — это функция nio2.

На самом деле NIO.2 — это просто удобное обозначение новых функций NIO, добавленных в обновлении Java 7. То есть... если только вы не придаете этому термину какое-то другое значение.

Если вам нужно решение, которое не включает ничего, кроме NIO.2, то (строго говоря) это невозможно. Любое решение будет включать использование String, а String предшествует NIO.2. Следовательно, это «не NIO.2».

Если в качестве альтернативы вы собираетесь разрешить использование классов, которые есть в NIO.2, но не в NIO, то File не является ни NIO.2, ни NIO. Он предшествует им обоим.

Можно ли изменить "jar:file:/D:/../some.jar!/folder", чтобы получить только файловую систему NIO2?

Если вы спрашиваете, возможно ли создать поставщика FileSystem, который мог бы справиться с этим, то теоретически ответ «Да», и, вероятно, это уже было сделано ... ограничения по модулю на то, что вы можете делать с файлом JAR. (Обновление на месте через Path / FileSystem было бы очень сложно реализовать и дорого с точки зрения ресурсов времени выполнения.)

Если вы ограничиваете вышеуказанную проблему, говоря, что для реализации провайдера и/или его использования следует использовать только API-интерфейсы NIO.2, то ответ, вероятно, будет «Нет». (Но это зависит от того, что вы действительно подразумеваете под «только NIO.2 "... и это зависит от того, чего вы на самом деле пытаетесь достичь...)