One of many daily activities that every programmer needs to do in order to do their work is to control logging output from their application. Logging, when done properly and correctly, provides great insight into the inner workings of the application and may be a great resource for analyzing and optimizing your codes behavior. Whether it is during development or maintenance/support phase of the product life-cycle, this task is often considered to be unpleasant for many programmers. But since log analysis is so important and often required there usually isn’t simple way around. In this article I will present an elegant solution to reviewing logs in development stage of the application within IDE.
When writing tests, programmers often need to provide some test files for their code to work. This is typically done by uploading them to their version control systems or exposing them over the network to be downloaded at runtime. However the reasons for a particular test file being used may differ greatly. Usually there are these main reasons to include test files in your automated testing process:
- Data transfer
- Test data
One of the biggest problems with pre-NIO.2 libraries was inefficient work with metadata of files and directories. Authors of NIO.2 library introduce concept of file attribute views to address this problem and also to solve couple of other issues that are dependent on this one. These problems included inability to create files with file attributes initialized at the creation time, inability to copy files with file attributes as well as problematic and inefficient way of handling file attributes. This concept was also adapted on file stores so the work with file system with regard to attributes and metadata feels seamless and consistent.
In order to work with file system one must first be able to point to files and directories. The first thing that needs to be understood is the role of
java.nio.file.Path class, the way instances are created and its functionality. As mentioned in previous articles,
Path is just an abstraction of the file system location. This allows for the situations when directory does not even have to exist. NIO.2 presents more elegant solutions for getting the object representing file system location. This shields programmer from platform specific problems.
Path instances allow two types of operations:
- syntactic operations
- any operations related to the Path representation itself – hierarchy traversal, conversion, comparison and so on
- file operations
- operations that modify location, state or contents of a file represented by a path instance
Java platform long needed tools to work with file systems that are not so limited as those of prior releases to Java 7. Programmers require consistent behavior throughout many different platforms and efficiency in gathering file attributes and other data (or metadata). When it comes to platform specific capabilities of certain file systems, Java should benefit from them and provide the means to harness their power. Last but not least, programmer should always receive concrete description of exceptional situations during execution of their code.