我有兴趣使用Java 7 SDK中的一些NIO2功能(特别是文件系统观察者),但是我不想为Java 7编译我的类并排除Java 6运行时.主要是因为我希望保持与Mac OS X的兼容性,还因为我不想强迫我的用户升级.
这可能吗？最好的方法是什么？任何链接或示例？
以下是我可以想象的一些方法:使用不同的编译器编译类文件并根据Java版本动态加载它？或者也许使用反射？或者也许只有Java 7的编译器设置来生成Java 6兼容的类？
我正在寻找一个不会变成丑陋混乱的解决方案:),所以理想情况下我可以编写两个接口实现,一个使用新功能,一个不使用,然后动态选择一个而不必进行反射调用到处都是.
我在一个应用程序中遇到一个经常出现的问题,该应用程序基于Java 7 WatchService API跟踪目录中文件的内容.当底层文件系统触发文件的修改事件时,我想立即计算其SHA-256.
但是经常发生另一个进程打开文件(即Word),从而扣留了一个独占锁并阻止我的应用程序进行任何读/写操作.如果针对打开的文件创建了任何Stream/Channel,则会抛出一个类似于以下消息的FileNotFoundException或者用于nio API的FileSystemException:
该进程无法访问该文件,因为该文件正由另一个进程使用
当文件实际上不存在于fs上时,我无法提供能够检测到这种情况而不屏蔽"真正的"FileNotFoundException的解决方案.
我想出了通过File.exists检查存在的想法,然后如果在打开流时抛出FileNotFoundException,我将能够推断该文件已被锁定.我愿意接受任何意见!
谢谢!
我一直在寻找内存中的nio2 FileSystem实现,这将使我能够更轻松地测试我的IO相关代码.
看起来本质上,Java只提供(在我的JDK中)a Win32FileSystem和a ZipFileSystem.
似乎ShrinkWrap有类似的东西,但似乎主要处理ZIP文件系统或任何东西.
我想现在,有些人已经在你自己的项目中加入了新的nio FileSystem IO,可以帮助我吗？
谢谢
我正在编写一个程序,需要确定上次修改时间的文件/目录.我想使用Joda Time处理这次,我正在使用Java 7 NIO.2类Files来获取文件的最后修改时间.它的getLastModifiedTime()方法返回一个FileTime类的实例,它有方便的方法toMillis(),其结果我传递给Joda Time DateTime类构造函数:
new DateTime(Files.getLastModifiedTime(path).toMillis());
但是,我觉得我做错了,因为DateTime(long)构造函数明确提到DateTime将使用默认时区创建实例.FileTime但是,docs在任何地方都没有提到它的时区.我查看了FileTime代码; 它似乎非常简单,它的toString()方法表明它使用UTC时区(它Calendar在UTC时区创建一个并直接设置其毫秒).
那么,确实FileTime使用UTC或当地时间吗？什么是转换正确的方式FileTime来DateTime？
我正在使用的项目一直在使用Java 6和jpathwatch(.95),现在正在升级到Java 7.目前在Windows 7和2008 Server上.我正在重构代码区域以使用新的Java 7 NIO并且相对简单 - 甚至使用NIO.2来替换jpathwatch.但是,我们代码的文件监视区域开始无法进行单元测试.似乎Java 7 NIO不会获取UNC路径到其他机器的变化 -
\\otherMach\path\to\watch.
为了测试,我实现了Java NIO教程站点http://docs.oracle.com/javase/tutorial/essential/io/fileio.html中的代码,然后在jpathwwatch导入而不是Java NIO中创建了一个重复的类交换.进口.jpathwatch适用于UNC路径,但Java NIO不适用.它似乎注册甚至返回该位置的初始事件键:(示例输出)
INFO: Watching: \\otherMach\path\to\watch
DEBUG: Added: \\otherMach\path\to\watch
INFO: Got event key: sun.nio.fs.WindowsWatchService$WindowsWatchKey@1f26ecd2
INFO: event key for: \\otherMach\path\to\watch
但后来从未发现任何进一步的变化.
jpathwatch注册并报告目录和文件事件(尽管它在注册后不会立即报告初始事件).
INFO: Watching: \\otherMach\path\to\watch
DEBUG: Added: \\otherMach\path\to\watch
INFO: Got event key: name.pachler.nio.file.impl.WindowsPathWatchService$WatchRecord@79a7bd3b
INFO: event key for: \\otherMach\path\to\watch
INFO: EVENT RECEIVED: ENTRY_CREATE file/dir created - \\otherMach\path\to\watch\New folder
INFO: Got event key: name.pachler.nio.file.impl.WindowsPathWatchService$WatchRecord@79a7bd3b
INFO: event key for: \\otherMach\path\to\watch
INFO: EVENT RECEIVED: ENTRY_CREATE file/dir created - \\otherMach\path\to\watch\New …我的服务器使用a AsynchronousServerSocketChannel来侦听客户端连接CompletionHandler.当接受客户端连接时,将AsynchronousSocketChannel再次使用a CompletionHandler来读取,以便在没有超时的情况下接收数据.
到目前为止,我的客户端连接,写入服务器读取的数据,它能够响应通过同一个套接字将数据发送回客户端.
当我的客户端终止时,它会调用AsynchronousSocketChannel.close(),以关闭套接字.进行此调用时,服务器正在等待从套接字读取数据.
我曾期望AsynchronousSocketChannel.close()客户端上的调用转换为服务器上CompletionHandler.completed读取长度为的回调-1,表明套接字已关闭,但回调是CompletionHandler.failed以下异常:
java.io.IOException: The specified network name is no longer available.
at sun.nio.ch.Iocp.translateErrorToIOException(Iocp.java:309)
at sun.nio.ch.Iocp.access$700(Iocp.java:46)
at sun.nio.ch.Iocp$EventHandlerTask.run(Iocp.java:399)
at sun.nio.ch.AsynchronousChannelGroupImpl$1.run(AsynchronousChannelGroupImpl.java:112)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:744)
客户端应如何关闭套接字,以免在服务器上看到错误？
似乎Files.newBufferedReader()对UTF-8比对天真的替代品更严格.
如果我创建一个单字节128的文件---所以,不是一个有效的UTF-8字符---如果我在结果上构造一个BufferedReaderon ,但是抛出异常会很高兴.InputStreamReaderFiles.newInputStream()Files.newBufferedReader()
这段代码
try (
InputStream in = Files.newInputStream(path);
Reader isReader = new InputStreamReader(in, "UTF-8");
Reader reader = new BufferedReader(isReader);
) {
System.out.println((char) reader.read());
}
try (
Reader reader = Files.newBufferedReader(path);
) {
System.out.println((char) reader.read());
}
有这个结果:
?
Exception in thread "main" java.nio.charset.MalformedInputException: Input length = 1
at java.nio.charset.CoderResult.throwException(CoderResult.java:281)
at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:339)
at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:178)
at java.io.InputStreamReader.read(InputStreamReader.java:184)
at java.io.BufferedReader.fill(BufferedReader.java:161)
at java.io.BufferedReader.read(BufferedReader.java:182)
at TestUtf8.main(TestUtf8.java:28)
这记录了吗？是否有可能获得宽松的行为Files.newBufferedReader()？
在对溢出文件规定:
OVERFLOW - 表示事件可能已丢失或丢弃.
它没有说在什么情况下我应该期望事件丢失或丢弃？起初我以为这是将很多文件写入文件夹的结果.我创建了几千个零大小的文件,并将它们移动到受监控的目录.没有溢出.
我错过了什么？
虽然可能是不明智的,但是通过使用URI方案来读取基本上重命名的.zip文件(.ear,.war,.jar等)的存档格式是可能的.jar:
例如,当uri变量求值为单个顶级归档时,以下代码可以正常工作,例如当uri等于时jar:file:///Users/justingarrick/Desktop/test/my_war.war!/
private FileSystem createZipFileSystem(Path path) throws IOException {
URI uri = URI.create("jar:" + path.toUri().toString());
FileSystem fs;
try {
fs = FileSystems.getFileSystem(uri);
} catch (FileSystemNotFoundException e) {
fs = FileSystems.newFileSystem(uri, new HashMap<>());
}
return fs;
}
然而,getFileSystem和newFileSystem调用失败的IllegalArgumentException时候URI包含嵌套压缩文件,例如,当uri平等jar:jar:file:///Users/justingarrick/Desktop/test/my_war.war!/some_jar.jar!/(一的.jar一个内部的.war).
java.net.URI嵌套存档文件是否有有效的方案？
SSL握手完成后如何获取解码数据？
目前它似乎只解密了一些数据.
重现步骤
？GET ......#$？+ {??? u7Y ???