Tag Archives: Java

Gotcha: Migrating from Spring Security 3.2.x to Spring Security 4.x

Here is a simple gotcha to keep in mind while migrating to newer Spring Security version 4.x from Spring Security 3.2.x

What’s the problem?

The Spring security configuration expressions hasRole('role_name') and hasAuthority('role_name') are no longer the same.

The catch is: hasAuthority checks for any role name passed to the expression without prepending ‘ROLE_’ (which is the default role prefix), where as hasRole checks for any role name passed to the expression by prepending ‘ROLE_’ to the role name.

Below is the snapshot of the class definition for SecurityExpressionRoot for both the versions of Spring Security which defines the methods hasRole and hasAuthority.

springsec-gotcha

In Spring Security 3.2.x hasAuthority and hasRole are checking for the presence of given role name in getAuthoritySet() [The getAuthoritySet() retrieves the GrantedAuthority list for the user]

In Spring Security 4.x hasAuthority is invoking the API hasAnyAuthorityName passing the prefix as null whereas hasRole is invoking the API hasAnyAuthorityName passing the default prefix which is ‘ROLE_’ (the same has been highlighted in the image above)

There is another interesting API in Spring Security 4.x (again highlighted in the image above) called getRoleWithDefaultPrefix() as shown in image below:

springsec4-2.png

Interesting to see above how the role name is being prefixed with the role prefix.

What is the fix?

  1. Either you append all your roles with ‘ROLE_’ prefix. OR
  2. Use hasAuthority as the replacement for hasRole expression without the need for changing the role names OR
  3. Override the defaultRolePrefix with null or empty string so that the same expression hasRole works with the same role names. [I need to figure out how to do this. It should be possible because the setter for the property is public]
Advertisements

Deep dive into Optional class API in Java 8

We all as Java programmers been through the situation where in we invoke a method to get some value and then instead of directly invoking some methods on the return value, we first have to check that the return value is not null and then invoke the methods on the return value. This has been a pain point which external APIs like Guava have tried to solve. Also alternate JVM languages like Scala, Ceylon and others have this features baked right into the core APIs. In my previous post I wrote about support in one such JVM language namely Scala.

The newer version of Java i.e Java 8 introduces a new class called Optional. The Javadoc for Optional class says:

A container object which may or may not contain a non-null value. If a value is present, isPresent() will return true and get() will return the value.

In this post lets go through each of the methods present in Optional class and explain the same with an example or two.

of

Returns an Optional with the specified present non-null value.

This method is a factory method for creating instances of Optional class. Something to take note of here is that the value being passed to created the instance has to be non-null. If the value passed is null then a NullPointerException is thrown.

//Creating an instance of Optional using the factory method.
Optional<String> name = Optional.of("Sanaulla");
//This fails with a NullPointerException.
Optional<String> someNull = Optional.of(null);

ofNullable

Returns an Optional describing the specified value, if non-null, otherwise returns an empty Optional.

Similar to the of method, the only difference is that this method handles null values as well. An example:

//This represents an instance of Optional containing no value
//i.e the value is 'null'
Optional empty = Optional.ofNullable(null);

isPresent

Very simple to understand:

Return true if there is a value present, otherwise false.

Something like:

//isPresent method is used to check if there is any 
//value embedded within the Optional instance.
if (name.isPresent()) {
  //Invoking get method returns the value present
  //within the Optaional instance.
  System.out.println(name.get());//prints Sanaulla
}

get

If a value is present in this Optional, returns the value, otherwise throws NoSuchElementException.

This method is used to retrieve the value present in the Optional instance. We saw one such example above. Lets look at an example where a NoSuchElementException is thrown:

//The below code prints: No value present 
try {
  //Invoking get method on an empty Optaional instance 
  //throws NoSuchElementException.
  System.out.println(empty.get());
} catch (NoSuchElementException ex) {
  System.out.println(ex.getMessage());
}

ifPresent

If a value is present, invoke the specified consumer with the value, otherwise do nothing.

To understand this method you would have to understand about the Consumer class. In short Consumer is a class with single abstract method to consumer some value and perform some operation on it without returning any value. In Java 8 one can pass a lambda expression to the method expecting an implementation of Consumer interface.
The above method accepts an block of code/lambda expression to perform some operation if the value is present in the Optional instance. Something like:

//ifPresent method takes a lambda expression as a parameter.
//The lambda expression can then consume the value if it is present
//and perform some operation with it.
name.ifPresent((value) -> {
  System.out.println("The length of the value is: " + value.length());
});

orElse

Return the value if present, otherwise return other.

This method either returns the value present in the Optional instance and if not it returns the value passed as a parameter to the orElse method. Lets look at an example:

//orElse method either returns the value present in the Optional instance
//or returns the message passed to the method in case the value is null.
//prints: There is no value present!
System.out.println(empty.orElse("There is no value present!"));
//prints: Sanaulla
System.out.println(name.orElse("There is some value!"));

orElseGet

This method is similar to the above method. The difference is in how the default value is obtained. In the orElse method we pass a fixed string as the default value, but in orElseGet method we pass an implementation of Supplier interface which has a method which is used to generate the default value. Lets look at an example:

//orElseGet is similar to orElse with a difference that instead of passing 
//a default value, we pass in a lambda expression which generates the default 
//value for us.
//prints: Default Value
System.out.println(empty.orElseGet(() -> "Default Value"));
//prints: Sanaulla
System.out.println(name.orElseGet(() -> "Default Value"));

orElseThrow

Return the contained value, if present, otherwise throw an exception to be created by the provided supplier.

Just like in the method orElseGet we pass a Supplier interface, but in orElseThrow method we pass a lambda expression/method reference to throw an exception when the value is not found. An example for this:


try {
  //orElseThrow similar to orElse method, instead of returning a default
  //value, this method throws an exception which is generated from 
  //the lambda expression/method reference passed as a param to the method.
  empty.orElseThrow(ValueAbsentException::new);
} catch (Throwable ex) {
  //prints: No value present in the Optional instance
  System.out.println(ex.getMessage());
}

And the definition for ValueAbsentException is:

class ValueAbsentException extends Throwable {

  public ValueAbsentException() {
    super();
  }

  public ValueAbsentException(String msg) {
    super(msg);
  }

  @Override
  public String getMessage() {
    return "No value present in the Optional instance";
  }
}

map

From the documentation for map method:

If a value is present, apply the provided mapping function to it, and if the result is non-null, return an Optional describing the result. Otherwise return an empty Optional.

This method is used to apply a set of operations on the value present in the Optional instance. The set of operations are passed in the form of a lambda expression representing an implementation of the Function interface. If you are not familiar with the Function interface, then please spend some time reading my earlier blog post on the same topic here. Lets look at an example for the map method:

//map method modifies the value present within the Optional instance
//by applying the lambda expression passed as a parameter. 
//The return value of the lambda expression is then wrapped into another
//Optional instance.
Optional<String> upperName = name.map((value) -> value.toUpperCase());
System.out.println(upperName.orElse("No value found"));

flatMap

From the documentation for the flatMap method:

If a value is present, apply the provided Optional-bearing mapping function to it, return that result, otherwise return an empty Optional. This method is similar to map(Function), but the provided mapper is one whose result is already an Optional, and if invoked, flatMap does not wrap it with an additional Optional.

This method is very similar to map method and differs from it in the return type of the mapping function passed to it. In the case of map method the mapping function return value can be of any type T, where as in case of flatMap method the return value of the mapping function can only be of type Optional.

Lets look at the above example for map method being re-written for flatMap method:

//flatMap is exactly similar to map function, the differece being in the
//return type of the lambda expression passed to the method.
//In the map method, the return type of the lambda expression can be anything
//but the value is wrapped within an instance of Optional class before it 
//is returned from the map method, but in the flatMap method the return 
//type of lambda expression's is always an instance of Optional.
upperName = name.flatMap((value) -> Optional.of(value.toUpperCase()));
System.out.println(upperName.orElse("No value found"));//prints SANAULLA

filter

This method is used to restrict the value within an Optional instance by passing the condition to be applied on the value to the filter method. The documentation says:

If a value is present, and the value matches the given predicate, return an Optional describing the value, otherwise return an empty Optional.

By now you must have got an idea of how to pass some block of code to the method. Yes, it is a lambda expression. In the case of this method we have to pass a lambda expression which would be an implementation of the Predicate interface. If you are not familiar with the Predicate interface, then please take some time to read this post.

Now lets look at different usages of filter method i.e both examples of condition being satisfied and condition not being satisfied.

//filter method is used to check if the given optional value satifies
//some condtion. If it satifies the condition then the same Optional instance
//is returned, otherwise an empty Optional instance is returned.
Optional<String> longName = name.filter((value) -> value.length() > 6);
System.out.println(longName.orElse("The name is less than 6 characters"));//prints Sanaulla

//Another example where the value fails the condition passed to the 
//filter method.
Optional<String> anotherName = Optional.of("Sana");
Optional<String> shortName = anotherName.filter((value) -> value.length() > 6);
//prints: The name is less than 6 characters
System.out.println(shortName.orElse("The name is less than 6 characters"));

With this I have introduced you to the various methods present in the Optional class. Let me aggregate all the above examples into one single example shown below:

public class OptionalDemo {

  public static void main(String[] args) {
    //Creating an instance of Optional
    //This value can also be returned from some method. 
    Optional<String> name = Optional.of("Sanaulla");

    //This represents an instance of Optional containing no value
    //i.e the value is 'null'
    Optional empty = Optional.ofNullable(null);

    //isPresent method is used to check if there is any 
    //value embedded within the Optional instance.
    if (name.isPresent()) {
      //Invoking get method returns the value present
      //within the Optaional instance.
      System.out.println(name.get());

    }

    try {
      //Invoking get method on an empty Optaional instance 
      //throws NoSuchElementException.
      System.out.println(empty.get());
    } catch (NoSuchElementException ex) {
      System.out.println(ex.getMessage());
    }

    //ifPresent method takes a lambda expression as a parameter.
    //The lambda expression can then consume the value if it is present
    //and perform some operation with it.
    name.ifPresent((value) -> {
      System.out.println("The length of the value is: " + value.length());
    });

    //orElse method either returns the value present in the Optional instance
    //or returns the message passed to the method in case the value is null.
    System.out.println(empty.orElse("There is no value present!"));
    System.out.println(name.orElse("There is some value!"));

    //orElseGet is similar to orElse with a difference that instead of passing 
    //a default value, we pass in a lambda expression which generates the default 
    //value for us.
    System.out.println(empty.orElseGet(() -> "Default Value"));
    System.out.println(name.orElseGet(() -> "Default Value"));

    try {
      //orElseThrow similar to orElse method, instead of returning a default
      //value, this method throws an exception which is genereated from 
      //the lambda expression/method reference passed as a param to the method.
      empty.orElseThrow(ValueAbsentException::new);
    } catch (Throwable ex) {
      System.out.println(ex.getMessage());
    }
    
    //map method modifies the value present within the Optional instance
    //by applying the lambda expression passed as a parameter. 
    //The return value of the lambda expression is then wrapped into another
    //Optional instance.
    Optional<String> upperName = name.map((value) -> value.toUpperCase());
    System.out.println(upperName.orElse("No value found"));
    
    //flatMap is exactly similar to map function, the differece being in the
    //return type of the lambda expression passed to the method.
    //In the map method, the return type of the lambda expression can be anything
    //but the value is wrapped within an instance of Optional class before it 
    //is returned from the map method, but in the flatMap method the return 
    //type of lambda expression's is always an instance of Optional.
    upperName = name.flatMap((value) -> Optional.of(value.toUpperCase()));
    System.out.println(upperName.orElse("No value found"));
    
    //filter method is used to check if the given optional value satifies
    //some condtion. If it satifies the condition then the same Optional instance
    //is returned, otherwise an empty Optional instance is returned.
    Optional<String> longName = name.filter((value) -> value.length() > 6);
    System.out.println(longName.orElse("The name is less than 6 characters"));
    
    //Another example where the value fails the condition passed to the 
    //filter method.
    Optional<String> anotherName = Optional.of("Sana");
    Optional<String> shortName = anotherName.filter((value) -> value.length() > 6);
    System.out.println(shortName.orElse("The name is less than 6 characters"));

  }

}

And the output of the above code:

Sanaulla
No value present
The length of the value is: 8
There is no value present!
Sanaulla
Default Value
Sanaulla
No value present in the Optional instance
SANAULLA
SANAULLA
Sanaulla
The name is less than 6 characters

Book review: Core Java, Volume II–Advanc​ed Features (9th Edition)

http://www.flipkart.com/affiliate/displayWidget?affrid=WRID-136978840229968837
I always liked the approach Cay S. Horstmann takes in the examples in his Core Java books. He tries to follow good practices in all his examples which includes better naming convention, documentation and comments, identifying right classes. This book, Core Java Volume-2, is no different. You find examples which are in themselves mini applications. You dont find toy programs which illustrate the feature and do some printing on the console. Instead the examples themselves include different concepts across Java.

There are very interesting topics covered in this book like: Streams and Files, XML processing, JDBC, Network Programming, Scripting and Annotations, Security, JNI, Advanced Swing and AWT. I see that few chapters which were originally in Volume-2 have been moved to volume-1 namely multi-threading and collections. I see a very exhaustive coverage on Swing and AWT, what I feel missing is the coverage of JavaFX features for which I think a chapter would suffice. Not to forget this book covers the Java 7 features as well. http://rcm.amazon.com/e/cm?lt1=_blank&bc1=FFFFFF&IS2=1&bg1=FFFFFF&fc1=000000&lc1=0000FF&t=experieunlimi-20&o=1&p=8&l=as1&m=amazon&f=ifr&ref=qf_sp_asin_til&asins=013708160X

Otherwise this book covers lot of stuff and I would recommend to use it as a reference to pick chapters as and when you want to explore those features. Reading end-to-end may not be necessary because most likely we would not be using all of those features in one place together. Reading end-to-end might be an overkill as well owing to the number of pages.

Bottom line: Highly recommend book in your bookshelf of Java references.

Note: this book was review on behalf of Coderanch.

Whats in store for Project Lambda in Java 8?

There are lot of things happening in the Project Lambda branch of JDK 8 and these are quite significant for Java programmers. I know lot of Anti-Java people would criticize these changes claiming them to be too late. But for loads of the Java developers out there its a welcome change. At this point of time the specs for Project Lambda part of JSR 335 are evolving, but I think lot of basic ground work done is kind of frozen. For those who want to try out the Project Lambda you should download the binaries from here.

The important concepts as part of Project Lambda are:

  • Virtual Extension Methods
  • Functional Interfaces
  • Lambda Expressions
  • API Enhancements to Collections library
  • Method and Constructor references

I have tried my hand at some of these concepts and barely managed to scratch the surface. I have blogged about few of the concepts with examples:

Virtual Extension Methods

We all know how limiting the interfaces can be, without being able to have method implementations in interfaces we at times tend to copy over the common implementations across different classes or create a adapter class with the common implementations. This is one side of it, but the other side is that it gives no scope for API enhancements without breaking the existing code. You cannot get away with adding a new method in the Interface without breaking millions of lines of code using your API. A similar kind of issue was being faced by the collections library which started to show their age. So a new feature in the language without the existing APIs being able to support them is hardly of any value. With an idea to enhance the existing collections API the concept of Virtual Extension Methods was introduced. In the early draft version 2 these have been referred to as default methods.

The blog posts which I wrote for this were:

Functional Interfaces

The Single Abstract Method (SAM) classes are now being referred to as Functional Interfaces. And these functional Interfaces can be replaced by lambda expression. The compiler then identifies the context in which this lambda expression is being used and then correspondingly converts the lambda expression into the SAM class. There’s another concept associated with this which is: “Functional Descriptor”. A functional descriptor of the Functional interface is the method type of the single abstract method of the interface.

Blog post related to this:

Lambda expressions

This is the main feature of this JSR. The idea of this is to support closures in Java. All those Anonymous Inner classes can be replaced by the Lambda expressions. The Collections API has also been enhanced with new APIs which accepts these lambda expressions.

The blog posts which I wrote for this are:

With the above blog posts I have barely scratched the surface. There’s lot to be learnt in this and a sound knowledge in Generics can help to a really great extent. Lot of them would say that the specs are in Draft and things can change, but I believe its always good to know what was there before and what changed and the reason for change. And its always good to keep yourself one step ahead of others so that when it is released you are in quite a good shape to welcome the changes!

Please feel free to correct me if I have made any mistakes in my understanding of the various features. There’s always an opportunity to learn from mistakes.

Developing a sample Todo desktop application using JavaFX and MongoDB

I wanted to explore learning to use MongoDB with Java and the best way to do this was to develop a toy application. And to add to this, I thought of using JavaFX and building a desktop application instead. I am building the application as I am writing this. I will upload the code onto Github once I am done with the application.

I am writing a 2 or 3 part series of posts on how to go about building the application. So do check out the detailed posts here. Just to clarify, I have started to write a few technical how-tos or my tryst with technologies on JavaBeat. So if you find this blog not being updated more often, you can find me at the other place. I would continue to update this blog with my experiences (so apt the title of the blog is ;))

Here’s an update on the TodoFX application:

Using JDeodorant to refactor java code

I got to know about JDeodorant– a tool for identifying bad smells in code and helping it to refactor. I got curious and downloaded its Eclipse plugin, I then picked the first bad smell code which Martin Fowler explains in his book: “Refactoring: Improving the design of existing code”. I tried my hand at refactoring a long method by Extract Method refactor move. Here’s the long method:
Continue reading

Play Framework Cookbook review

In a previous post I had mentioned that I would be soon reviewing the Play Framework Cookbook. So here it is-

Chapter-1 Basics of Play Framework

  • Concise coverage of basic features of the Play Framework. Though you must be using the Play Framework documentation for a more detailed information. The last few sections which explain- Extensions, Suspendable requests need a bit more explanation.
  • Good to have, as one can refresh the basic concepts.