Using register()

This API allows us to register an implementation of java.nio.file.WatchService interface which will listen for events like directory creation, modification, and deletion. And it intimates the listeners by means of a java.nio.file.WatchKey. I would like to dedicate a different article for this API because it involves another new feature which was introduced in Java 7.

Using resolve()

This method deals with two Path instances. One instance on this the resolve() method is called and the other instance which is passed as an argument. The argument can be either a Path instance or a String representing the path.

This method resolves the other path against this path. The resolution is done as follows:

1. If the other path is an absolute path, then it returns the other path. Because the other path can be reached by using the absolute path.
2. If the other path is a relative path then the other path is appended to this path. For example:

   Path path = Paths.get("src", "main", "resources");
   Path other = Paths.get("blogsamples");
   
   assertThat(path.resolve(other)).isEqualTo(
           Paths.get("src", "main", "resources", "blogsamples"));

The different scenarios in which this method can be invoked is given in the test below:

@Test
public void testResolved() throws IOException {
    Path path = Paths.get("src", "main", "resources");
    Path other = Paths.get("blogsamples");

    assertThat(path.resolve(other)).isEqualTo(
            Paths.get("src", "main", "resources", "blogsamples"));

    other = Paths.get("/Users");
    assertThat(path.resolve(other)).isEqualTo(Paths.get("/Users"));

    path = Paths.get("/src", "main", "resource");
    assertThat(path.resolve("/Users")).isEqualTo(Paths.get("/Users"));
}

Using resolveSibling()

This method is similar to resolve() except that it considers this path’s parent to resolve the other path. Again there are different possibilities which I have captured in the test below:

@Test
public void testResolveSibling(){
    Path path = Paths.get("src", "main", "resources", "test1");
    Path other = Paths.get("test2");

    //both paths are not absolute
    assertThat(path.resolveSibling(other)).isEqualTo(
            Paths.get("src", "main", "resources", "test2"));

    //other path is absolute
    assertThat(path.resolveSibling("/test2")).isEqualTo(
        Paths.get("/test2"));

    //this path has no parent
    path = Paths.get("/");
    assertThat(path.resolveSibling("/test2")).isEqualTo(
        Paths.get("/test2"));

    //the other path is empty and this path has no parent
    assertThat(path.resolveSibling("")).isEqualTo(Paths.get(""));

    //the other path is empty and this path has parent
    path = Paths.get("src", "main", "resources", "test1");
    assertThat(path.resolveSibling("")).isEqualTo(
            Paths.get("src", "main", "resources"));
}

Using relativize()

This method returns a relative path that when resolved against this path returns the other path (i.e the path which is passed as a parameter).

I have tried to illustrate in the tests below the different possibilities while trying to create a relative path between two paths.

Path path = Paths.get("src", "main", "resources", "test1");
Path other = Paths.get("test2");

assertThat(path.relativize(other).toString())
    .isEqualTo("..\\..\\..\\..\\test2");

In the above case, both the paths are relative. It requires 4 hops backward from the src/main/resources/test1 to reach /test2. The same is obtained by applying the relativize method.

If one of the paths is absolute and the other is relative, then invoking relativize results in an IllegalArgumentException as shown below:

@Test(expected = IllegalArgumentException.class)
public void testRelativize_WithRelativeAndAbsolutePath(){
    Path path = Paths.get("/src", "main", "resources", "test1");
    Path other = Paths.get("src", "main", "resources");
    path.relativize(other);
}

If both the paths are absolute, then the output of relativize() is implementation dependent. The below test is written against JDK 8 on Windows platform:

@Test
public void testRelativize_WithAbsolutePaths(){
    Path path = Paths.get("/src", "main", "resources", "test1");
    Path other = Paths.get("/src", "main", "resources", "test1", "test2");
    assertThat(path.relativize(other).toString())
        .isEqualTo("test2");
}

Using startsWith()

This method checks if the path on which the startsWith() method has the same name elements in the beginning as that of the path passed as the argument. And the path passed as the argument has no extra name elements that are not present in this path.

For example: /a/b/c starts with /a/b , a/b/c/d starts with a/b/c

Let us look at the different possible cases while invoking the method:

@Test
public void testStartsWith(){
    //both paths are absolute
    Path path = Paths.get("/src", "main", "resources", "test1");
    Path other = Paths.get("/src", "main", "resources");
    assertThat(path.startsWith(other)).isTrue();

    /*
    both paths are absolute, where as the other 
    path has more name elements 
    */
    path = Paths.get("/src", "main", "resources", "test1");
    other = Paths.get("/src", "main", "resources", 
        "test1", "test2");
    assertThat(path.startsWith(other)).isFalse();

    //both paths are same
    path = Paths.get("/src", "main", "resources", "test1");
    other = Paths.get("/src", "main", "resources", "test1");
    assertThat(path.startsWith(other)).isTrue();

    //either of them is relative
    path = Paths.get("src", "main", "resources", "test1");
    other = Paths.get("/src", "main", "resources", "test1");
    assertThat(path.startsWith(other)).isFalse();

    //both of them are relative
    path = Paths.get("src", "main", "resources", "test1");
    other = Paths.get("src", "main", "resources");
    assertThat(path.startsWith(other)).isTrue();

}

The last few released of Java namely Java 7, Java 8 and the upcoming Java 9 have quite a lot of features which makes the life of Java developers easier. (I know Java 9 will make it tougher, but only while you adopt the new paradigm. After that it’s going to be much better).

One of the features or API was the enhancements of the File API introduced in Java 7. One of the new classes of that feature set is java.nio.file.Path and its factory java.nio.file.Paths.

Maven Dependencies

We will be using JUnit and AssertJ to write our tests to demonstrate the API.

<dependency>
    <groupId>junit</groupId>
    <artifactId>junit</artifactId>
    <version>4.12</version>
</dependency>
<dependency>
    <groupId>org.assertj</groupId>
    <artifactId>assertj-core</artifactId>
    <!-- use 2.8.0 for Java 7 projects -->
    <version>3.8.0</version>
    <scope>test</scope>
</dependency>

Creating an instance of java.nio.file.Path

As I mentioned before java.nio.file.Paths is the creator for java.nio.file.Path that is it provides two factory methods:

• static Path get(String first, String … more)
• static Path get(URI uri)

that can be used to get an instance of java.nio.file.Path. Let us look at the two ways to obtain the instance:

@Test
public void testPathCreation(){
    Path path = Paths.get("src", "main", "resources");
    assertThat(path.isAbsolute()).isFalse();
    assertThat(path.toString()).isEqualTo("src\\main\\resources");

    Path uriPath = Paths.get(URI.create("file:///Users/Mohamed/git"));
    assertThat(uriPath.isAbsolute()).isFalse();
    assertThat(uriPath.toAbsolutePath().toString())
            .isEqualTo("C:\\Users\\Mohamed\\git");
}

Exploring the APIs

Using endsWith()

This method is used to check if a given Path object ends with another Path object or a path represented as a String object.

@Test
public void testEndsWith(){
    Path path = Paths.get("src", "main", "resources");
    assertThat(path.endsWith(Paths.get("main","resources"))).isTrue();
    assertThat(path.endsWith("resources")).isTrue();
}

Using getFileName()

This method returns the name of the directory or the file present at the terminal or end of the path.

@Test
public void testGetFileName(){
    Path path = Paths.get("src", "main", "resources");
    assertThat(path.getFileName().toString()).isEqualTo("resources");
    path = Paths.get("src", "test", "java", "info", 
        "sanaulla","PathDemoTest.java");
    assertThat(path.getFileName().toString())
        .isEqualTo("PathDemoTest.java");
}

Using getFileSystem()

This method returns an instance of java.nio.file.FileSystem representing the underlying file system. We will look at this in detail in a future post.

@Test
public void testGetFileSystem(){
    Path path = Paths.get("src", "main", "resources");
    assertThat(path.getFileSystem()).isNotNull();
    assertThat(path.getFileSystem().getSeparator()).isEqualTo("\\");
    path.getFileSystem().getRootDirectories().forEach(System.out::println);
}

Using getName() and getNameCount()

The getNameCount() returns number of name components present in the path where each name component is seperated by a file seperator. And the method getName() takes an index and returns the name component at the index.

For example  a given path: /var/log/myapp/spring.log has 4 name components and the component position is 0 based. So the name component at index 1 is log.

@Test
public void testGetName(){
    Path path = Paths.get("src", "main", "resources");
    assertThat(path.getName(0)).isEqualTo(Paths.get("src"));

    assertThat(path.getName(path.getNameCount() - 1))
            .isEqualTo(Paths.get("resources"));
}

Using getParent()

This API returns the path from the root of a path until the terminal directory or file (i.e excluding it). For example: invoking getParent() on a Path instance representing /var/log/myapp/spring.log returns a Path instance representing /var/log/myapp

It returns null if the given path has no parent or if it is the root directory.

@Test
public void testGetParent(){
    Path path = Paths.get("src", "main", "resources");
    assertThat(path.getParent()).isEqualTo(Paths.get("src", "main"));
    assertThat(Paths.get("/").getParent()).isNull();
}

Using getRoot()

This API returns a Path instance of the root if it exists or null for a given instance of Path.

@Test
public void testGetRoot(){
    Path path = Paths.get("src", "main", "resources");
    assertThat(path.getRoot()).isNull();

    path = Paths.get("/users", "Mohamed", "git", "blogsamples");
    assertThat(path.getRoot()).isEqualTo(Paths.get("/"));
}

Using normalize()

This API is a bit tricky. It removes redundant elements in your path. Redundant elements are those whose removal will eventually result in a similar Path. For example: if we have a path src\..\src\main\java is equivalent to src\main\java. The normalize() API helps in achieving the latter from the former.

@Test
public void testNormalize(){
    Path path = Paths.get("src","..", "src", "main", "resources", ".");
    assertThat(path.toString())
            .isEqualTo("src\\..\\src\\main\\resources\\.");
    assertThat(path.normalize().toString())
            .isEqualTo("src\\main\\resources");
}

Using subpath()

This method returns a sub path identified by the lower bound and upper bound which are passed as parameters to the method. The upper bound is excluded while computing the sub path.

@Test
public void testSubpath(){
    Path path = Paths.get("Mohamed", "git", 
            "blogsamples", "src", "main", "resources");
    assertThat(path.subpath(2, 3).toString()).isEqualTo("blogsamples");
    assertThat(path.subpath(0, path.getNameCount()).toString())
            .isEqualTo("Mohamed\\git\\blogsamples\\src\\main\\resources");
}

Using toAbsolutePath()

This method returns the absolute path for the given path. An absolute path originates from the root of the file system.

@Test
public void testToAbsolutePath(){
    Path path = Paths.get("src", "main", "resources");
    assertThat(path.toAbsolutePath().toString())
       .isEqualTo("C:\\Users\\Mohamed\\git\\blogsamples\\src\\main\\resources");
}

Using toFile()

This is a very handy way to create an instance of java.io.File. We can leverage the use of creating a Path object with multiple folder levels and then use toFile() to get an instance of File.

@Test
public void testToFile(){
    Path path = Paths.get("src", "main", "resources");
    File file = path.toFile();
    assertThat(file).isNotNull();
    assertThat(file.isDirectory()).isTrue();
    assertThat(file.exists()).isTrue();
}

Using toRealPath()

This method can be used to resolve a symbolic link to its real location. To test this API we create a symbolic link:

On windows you would use:

mklink /D "C:\blogsample" "C:\Users\Mohamed\git\blogsamples"

On Linux, you would use

ln -s /var/log/sample.log sample

The method takes an option of type LinkOption. As of now, this enum has one element i.e NOFOLLOW_LINKS. If this option is passed then the symbolic link is not resolved to its real path.

@Test
public void testToRealPath() throws IOException {
    Path path = Paths.get( "/blogsample");
    assertThat(path.toRealPath().toString())
            .isEqualTo("C:\\Users\\Mohamed\\git\\blogsamples");
    assertThat(path.toRealPath(LinkOption.NOFOLLOW_LINKS).toString())
            .isEqualTo("C:\\blogsample");
}

Using toUri()

This method returns a URI representation of a given path. Generally, on Windows, you would see something of the form: file:///C:/. But this is system dependent

@Test
public void testToUri(){
    Path path = Paths.get("src", "main", "resources");
    assertThat(path.toUri()).isEqualTo(
      URI.create("file:///C:/Users/Mohamed/git/blogsamples/src/main/resources/"));
}

Note: It’s important to note that the return type of most of the APIs is an instance of java.nio.file.Path. This helps us in chaining multiple methods and invoke them on a single java.nio.file.Path instance.

In the next article, we will look at the remaining few APIs in java.nio.file.Path.

I went through few of those topics and blogged about them and I thought it is best to aggregate them here for the benefit of the readers.

Fork-Join Framework:

In Java 5 java.util.concurrent package was added with lot of new classes for developing concurrent applications- Executor, ExecutorService, Callable, Futures among others. Fork-Join framework was added in Java 7 which builds on top of ExecutorService and adds task stealing algorithm in which the tasks queued in one thread can be picked by ideal threads and this facilitates creating multiple tasks and not worrying about tasks not getting executed.

• A brief overview of Fork-Join framework can be found here.
• Implementing mergesort algorithm using ForkJoin framework can be found here.

Enhancements to the File API:

A new package java.nio.file was added with support for representing file path, a static Files utility for reading, writing to a file and other file related tasks, working with symbolic links, api for implementing watch service and others.

• Implementing WacthServie API in Java 7 to monitor directory changes.
• A peek into the Files utility which is part of java.nio package in Java 7.
• Creating, Writing, Reading files using Java Files API of Java 7.

There was another utility added to java.util package- Objects class with static utility methods for operating on object references. This is kind of unknown addition but has been used extensively in the Java 8 APIs. And I came across this while reading through the Java 8 code.

One other important feature added to the JVM- invokedynamic has been missed out here. And I think its quite important to explore this feature for there are languages like Groovy 2.0, JRuby making use of this feature.

• Each of the sessions were filled with technical content and lot of things to be learnt. I got an early peak into the Lambda expressions to be introduced in Java 8 and whole lot of other features to accompany that release. Also there was a quick walk through of Java 7 features.
• The concurrency in Java session showed as to why the current concurrency model in Java is aptly called as synchronize and suffer model. We were shown how the Software Transactional Memory model of  Clojure could be made use of in Java as well.
• We as Java developers dont spend much time writing  JavaScript and more so people working with component frameworks like JSF, ADF would spend even less time. During the session about JavaScript, there was a face-off between Java and JavaScript and how they are familiar and different.
• There was a really good session on Scala by Venkat Subramaniam which stretched beyond the allotted 45 minutes into about 90 minutes. He covered concepts such as Tail Recursion, Traits, Val-Var, Classes and so on. I really appreciate the effort he put in and the dedication he showed in conveying and covering the concepts he intended to during the session which involved stretching out of the allotted time.
• I by chance happened to sit in a session on creating RESTful WebService using JAX-RS and the new features in JAX-RS 2.0, though there was lot discussed, my eyes were paining seeing at the amount of code one had to write to create and consume the RESTful webservice. But for people of JavaEE stack that shouldn’t be much of concern.
• Interesting to see lot of Goldman Sachs employees turning up at the GIDS 2012 and being present in their Expo booths. Also go to know about a Collection library developed by Goldman Sachs for their internal use which now they have open sourced. I have a copy of their source-code, binaries and some material which I would go through in the coming days and see if I can share some of my findings here. So looks like they are trying to build and sustain a good technical expertise inhouse.

So stuffs to try out:

• Goldman Sachs Collections API
• JavaScript and BackBone.js framework
• Lambda expressions in Java 8
• HTML 5 features

]]> /2012/04/19/overview-of-the-java-sessions-at-the-great-indian-dev-summit-2012-2/feed/ 1 Sanaulla /2011/07/10/java-7-project-coin-try-with-resources-explained-with-examples-2/ /2011/07/10/java-7-project-coin-try-with-resources-explained-with-examples-2/#comments Sun, 10 Jul 2011 17:21:03 +0000 http://blog.sanaulla.info/?p=954 Prior to “try-with-resources” (before Java 7) while dealing with SQL Statement or ResultSet or Connection objects or other IO objects one had to explicitly close the resource. So one would write something like-

[java]
try{
//Create a resource- R
}catch(SomeException e){
//Hanlde the exception
}finally{
//if resource R is not null then
try{
//close the resource
}
catch(SomeOtherException ex){
}
}
[/java]

We have explicity close the resource and thereby few more lines of code. There are few cases where the developer will forget to close the resource. So to overcome these and other issues- try-with-resources is introduced in Java 7.

Lets look at an example of how we would use try..catch…finally in pre java 7-
Let me create 2 custom exceptions- ExceptionA and ExceptionB. These will be used throught out the examples.

[java]
public class ExceptionA extends Exception{
public ExceptionA(String message){
super(message);
}
}
[/java]

[java]
public class ExceptionB extends Exception{
public ExceptionB(String message){
super(message);
}
}
[/java]

Lets create some resource- say OldResource which has two methods- doSomeWork(): which does some work and close(): which does the closing [Note that this depicts the use of a generic resource- do some work and then close the resource]. Now each of these operations- doSomeWork, close- throw an exception each.

[java]
public class OldResource{
public void doSomeWork(String work) throws ExceptionA{
System.out.println("Doing: "+work);
throw new ExceptionA("Exception occured while doing work");
}
public void close() throws ExceptionB{
System.out.println("Closing the resource");
throw new ExceptionB("Exception occured while closing");
}
}
[/java]

Lets use this resource in a sample program:

[java]
public class OldTry {
public static void main(String[] args) {
OldResource res = null;
try {
res = new OldResource();
res.doSomeWork("Writing an article");

} catch (Exception e) {
System.out.println("Exception Message: "+e.getMessage()+" Exception Type: "+e.getClass().getName());
}finally{
try {
res.close();
} catch (Exception e) {
System.out.println("Exception Message: "+e.getMessage()+" Exception Type: "+e.getClass().getName());
}
}
}
}
[/java]

The output:

[shell]
Doing: Writing an article
Exception Message: Exception occured while doing work Exception Type: javaapplication4.ExceptionA
Closing the resource
Exception Message: Exception occured while closing Exception Type: javaapplication4.ExceptionB
[/shell]

The program is straight forward: create a new resource, use it, and then try to close it. One can look at the number of extra lines of code there. Now lets implement the same program using Java 7’s try-with-resource construct. For this we would need a new resource- NewResource. In Java 7 a new interface has been introduced- java.lang.AutoCloseable. Those resources which need to be closed implement this interface. All the older io APIs, socket APIs imlement Closeable interface- which means these resources can be closed. With Java 7- java.io.Closeable implements AutoCloseable. So everything works without breaking any existing code:)

The NewResource code below:

[java]
public class NewResource implements AutoCloseable{
String closingMessage;

public NewResource(String closingMessage) {
this.closingMessage = closingMessage;
}

public void doSomeWork(String work) throws ExceptionA{
System.out.println(work);
throw new ExceptionA("Exception thrown while doing some work");
}
public void close() throws ExceptionB{
System.out.println(closingMessage);
throw new ExceptionB("Exception thrown while closing");
}

public void doSomeWork(NewResource res) throws ExceptionA{
res.doSomeWork("Wow res getting res to do work");
}
}
[/java]

Now lets use the NewResource in a sample Program using try-with-resource:

[java]
public class TryWithRes {
public static void main(String[] args) {
try(NewResource res = new NewResource("Res1 closing")){
res.doSomeWork("Listening to podcast");
}catch(Exception e){
System.out.println("Exception: "+e.getMessage()+" Thrown by: "+e.getClass().getSimpleName());

}
}
}
[/java]

The output:

[shell]
Listening to podcast
Res1 closing
Exception: Exception thrown while doing some work Thrown by: ExceptionA
[/shell]

One thing to note above is that the Exception thrown by the close is being supressed by the Exception being thrown by the worker method.

So you can right away notice the difference between the two implementations- one using try…catch…finally and the other using try-with-resource. In the example above only one resource is declared as used. One can declare and use multiple resources within the try block, also nest these try-with-resources blocks. Along with this few new methods and constructor were added to the java.lang.Throwable class- all related to suppressing the exceptions thrown along with other exception. Best example for this would be- ExceptionA being thrown by the try block will get suppressed by the ExceptionB being thrown by the finally (while closing the resource) and this was the behavior pre Java 7, but with Java 7, the thrown exception keeps track of the exceptions it suppressed on its way to being caught/handled. So the earlier said example can be restated as follows- The ExceptionB being thrown by the close method gets added to the List of suppressed exception of the ExceptionA which is being thrown by the try block. Let me explain you- Nested try-with-resources and Supressed exceptions with the examples:

Nested try-with-resources

[java]
public class TryWithRes {
public static void main(String[] args) {
try(NewResource res = new NewResource("Res1 closing");
NewResource res2 = new NewResource("Res2 closing")){
try(NewResource nestedRes = new NewResource("Nestedres closing")){
nestedRes.doSomeWork(res2);
}
}catch(Exception e){
System.out.println("Exception: "+e.getMessage()+" Thrown by: "+e.getClass().getSimpleName());
}

}
}
[/java]

The output for the above would be:

[shell]
Wow res getting res to do work
Nestedres closing
Res2 closing
Res1 closing
Exception: Exception thrown while doing some work Thrown by: ExceptionA
[/shell]

Note the order of closing the resources- latest first. Also note the exception being thrown by each of these close() operations is supressed.
Lets see how we can retrieve the supressed exceptions:
Suppressed Exceptions

[java]
public class TryWithRes {
public static void main(String[] args) {
try(NewResource res = new NewResource("Res1 closing");
NewResource res2 = new NewResource("Res2 closing")){
try(NewResource nestedRes = new NewResource("Nestedres closing")){
nestedRes.doSomeWork(res2);
}
}catch(Exception e){
System.out.println("Exception: "+e.getMessage()+" Thrown by: "+e.getClass().getSimpleName());
if(e.getSuppressed() != null){
for(Throwable t : e.getSuppressed()){
System.out.println(t.getMessage()+" Class: "+t.getClass().getSimpleName());
}
}
}

}
}
[/java]

The output for the above code:

[shell]
Wow res getting res to do work
Nestedres closing
Res2 closing
Res1 closing
Exception: Exception thrown while doing some work Thrown by: ExceptionA
Exception thrown while closing Class: ExceptionB
Exception thrown while closing Class: ExceptionB
Exception thrown while closing Class: ExceptionB
[/shell]

The getSuppressed() method is used to retrieve the exceptions supressed by the thrown exception. Also new constructor has been added to Throwable class which can be used to enable or disable the supression of exceptions- If disabled none of the suppressed exceptions are tracked.