In reality, NIO.2 is really just a convenient label for new NIO features added in the Java 7 overhaul. That is ... unless you are placing some other meaning on the term.
If you want a solution that doesn't involve anything that is not NIO.2, then (strictly speaking) that is not possible. Any solution will involve using String
, and String
predates NIO.2. It is therefore "not NIO.2"
If alternatively, you are going to allow use of classes that are in NIO.2 but not NIO, then File
is neither NIO.2 or NIO. It predates both of them.
Is it possible to modify "jar:file:/D:/../some.jar!/folder"
to get a FileSystem NIO2 only?
If you are asking if it is possible to create a FileSystem
provider that could handle that, the answer is Yes in theory, and it has probably already been done ... modulo restrictions on what you can do to a JAR file. (In-place update via the Path / FileSystem would be really difficult to implement, and expensive in terms of runtime resources.)
If you are constraining the above problem by saying that only NIO.2 APIs should be used to implement the provider and/or use it, then the answer is probably No. (But it depends on what you really mean by "only NIO.2" ... and that depends on what you are really trying to achieve ...)