In this post we’ll look at some alternative solutions to the traditional loop. The great thing about the new functional features in Java 8, is that it allows us to say what we want to be done instead of saying how to do it. This is where loops fall short. Sure loops are flexible, but this flexibility doesn’t come without a price. A return, break or continue dramatically changes how the loop will act, forcing us not only to understand what the code is trying to achieve, but also understand how the loop works.

Let the coding begin!

This time we’re going to work with articles. An article has a title, an author and several tags.

 private class Article {  
   private final String title;  
   private final String author;  
   private final List<String> tags;  
   private Article(String title, String author, List<String> tags) {  
     this.title = title;  
     this.author = author;  
     this.tags = tags;  
   }  
   public String getTitle() {  
     return title;  
   }  
   public String getAuthor() {  
     return author;  
   }  
   public List<String> getTags() {  
     return tags;  
   }  
 }  

Each of the examples will contain a traditional loop solution, and a solution using the new features in Java 8.
In the first example we want to find the first article in the collection that has the tag “Java”.

Let’s look at a solution using a for-loop.
 public Article getFirstJavaArticle() {  
   for (Article article : articles) {  
     if (article.getTags().contains("Java")) {  
       return article;  
     }  
   }  
   return null;  
 }  

Now let’s solve the problem using operations from the stream API.
 public Optional<Article> getFirstJavaArticle() {   
   return articles.stream()  
     .filter(article -> article.getTags().contains("Java"))  
     .findFirst();  
   }  

Pretty cool right? We first use the filter operation to find all articles that have the Java tag, then used the findFirst() operation to get the first occurrence. Since streams are lazy and filter returns a stream, this approach only processes elements until it finds the first match.

Now, lets get all the elements that match instead of just the first.
First, the solution using a for-loop.
 public List<Article> getAllJavaArticles() {  
   List<Article> result = new ArrayList<>();  
   for (Article article : articles) {  
     if (article.getTags().contains("Java")) {  
       result.add(article);  
     }  
   }  
   return result;  
 }  

Solution using stream operations.
 public List<Article> getAllJavaArticles() {   
   return articles.stream()  
     .filter(article -> article.getTags().contains("Java"))  
     .collect(Collectors.toList());  
   }  

In this example we used the collect operation to perform a reduction on the result stream instead of declaring a collection ourselves and explicitly add the articles if they match.

So far so good. Time to create a few examples that really make the stream API shine! Let's group all the articles based on the author. As usual, we start with the solution using a loop.

 public Map<String, List<Article>> groupByAuthor() {  
   Map<String, List<Article>> result = new HashMap<>();  
   for (Article article : articles) {  
     if (result.containsKey(article.getAuthor())) {  
       result.get(article.getAuthor()).add(article);  
     } else {  
       ArrayList<Article> articles = new ArrayList<>();  
       articles.add(article);  
       result.put(article.getAuthor(), articles);  
     }  
   }  
   return result;  
 }  

Can we find a clean solution for this problem using the stream operation?

 public Map<String, List<Article>> groupByAuthor() {   
   return articles.stream()  
     .collect(Collectors.groupingBy(Article::getAuthor));  
 }    

Great! Using the groupingBy operation and a method reference to getAuthor we got some clean and readable code.

Now, let's find all the different tags used in the collection. We start with the loop example.

 public Set<String> getDistinctTags() {  
   Set<String> result = new HashSet<>();  
   for (Article article : articles) {  
     result.addAll(article.getTags());  
   }  
   return result;  
 }  

Ok, let's see how we can solve this with the stream operations.

 public Set<String> getDistinctTags() {   
   return articles.stream()  
     .flatMap(article -> article.getTags().stream())  
     .collect(Collectors.toSet());  
 }  

Nice! flatmap helpes us flatten the tag lists into one result stream, then we use collect to create a set to return.

Endless possibilities

That was 4 examples of how you can replace the loops with more readable code. Make sure to take a closer look at the stream API, because this post has barely scratched the surface.

Spring Data MongoDB 1.2.0 silently introduced new feature: support for basic auditing. In this post I will show what benefits does it bring, how to configure Spring for auditing and how to annotate your documents to make them auditable.
Auditing let you declaratively tell Spring to store:

Configuration

First of all add Maven dependencies to latest Spring Data MongoDB and Spring Data Commons. Additionally in order to use date-related audit annotations we need to add joda-time to class-path.

 <dependency>  
   <groupId>org.springframework.data</groupId>  
   <artifactId>spring-data-mongodb</artifactId>  
   <version>1.2.1.RELEASE</version>  
 </dependency>  
 <dependency>  
   <groupId>org.springframework.data</groupId>  
   <artifactId>spring-data-commons</artifactId>  
   <version>1.5.1.RELEASE</version>  
 </dependency>  
 <dependency>  
   <groupId>joda-time</groupId>  
   <artifactId>joda-time</artifactId>  
   <version>2.2</version>  
 </dependency>  

In order to enable auditing we need to add <mongo:auditing/> to Spring configuration. Currently there is no way to configure it through Java Config.

 <mongo:auditing />  
 <mongo:mongo id="mongo" />  
 <bean class="org.springframework.data.mongodb.core.MongoTemplate">  
   <constructor-arg name="mongo" ref="mongo" />  
   <constructor-arg name="databaseName" value="blog-tests" />  
 </bean>  

Usage

Configuration above provides us way for auditing that includes versioning and time stamps. Example document will look like:

 @Document  
 public class Item {  
   @Id  
   private String id;  
   ...  
   @Version  
   private Long version;  
   @CreatedDate  
   private DateTime createdAt;  
   @LastModifiedDate  
   private DateTime lastModified;  
   ...  
 }  

Now you can save document using MongoTemplate or your repository and all annotated fields are auto magically set.

As you have probably noticed I did not use here user related annotations @CreatedBy and @LastModifiedBy. In order to use them we need to tell Spring who is a current user.

First add user related fields to your audited class:

 @CreatedBy  
 private String createdBy;  
 @LastModifiedBy  
 private String lastModifiedBy;  

Then create your implementation of AuditorAware that will obtain current user (probably from session or Spring Security context – depends on your application):

 public class MyAppAuditor implements AuditorAware<String> {  
   @Override  
   public String getCurrentAuditor() {  
     // get your user name here  
     return "John Doe";  
   }  
 }  

Last thing is to tell Spring Data MongoDB about this auditor aware class by little modification in Mongo configuration:

 <mongo:auditing auditor-aware-ref="auditor" />  
 <bean id="auditor" class="pl.maciejwalkowiak.blog.MyAppAuditor"/>  
Today, I want to show you debugging method, more specifically one for measuring execution times: Say hello to console.time().

Measuring Execution Times the Classic Way

Here's a small JavaScript snippet which concatenates the first one million natural numbers:
 var i, output = "";    
 for (i = 1; i <= 1e6; i++)  
   output += i;  

If you're wondering what 1e6 means, it's just a short way to write ten to the sixth power, which equals one million. It means exactly the same as the number literal 1000000.

The script is very simple, yet takes a couple dozen milliseconds (about 150ms on my machine) to execute. How did I measure this time? I could've done something like this:
 var i, output = "";  
 // Remember when we started  
 var start = new Date().getTime();  
 for (i = 1; i <= 1e6; i++)  
   output += i;  
 // Remember when we finished  
 var end = new Date().getTime();  
 // Now calculate and output the difference    
 console.log(end - start);  

This approach is very straightforward. It also has the advantage that it runs pretty much everywhere. If you're using a modern browser though, there's a shorthand method for measuring durations and logging them to the console. Let's inspect console.time()now.

Measuring Execution Times Using console.time()
Making use of console.time(), the code from before can be rewritten as this:

 var i, output = "";  
 // Start timing now  
 console.time("concatenation");  
 for (i = 1; i <= 1e6; i++)  
   output += i;  
 // ... and stop.  
 console.timeEnd("concatenation");  

We've now managed to make the code more expressive and slightly shorter than before: The call to console.time() starts a timer with the name concatenation, which is later stopped by console.timeEnd(). The timer names passed to both function calls have to match in order for the measuring to work.
Note that console.time() and console.timeEnd() are only supported by modern browsers, starting with Chrome 2, Firefox 10, Safari 4, and Internet Explorer 11.

Displaying the Measured Duration in the Console

Chrome 31 has written the following output to the console:

Here is what Firefox 25 gives us (notice the concatenation: timer started information):

A Closing Word on High-Precision Timing

If you need to measure time precisely, neither Date.getTime() nor console.time()will get you far. Check out John Resig's blog post about the accuracy of JavaScript time to learn why.
There's a different API for that purpose, though: the Performance interface, which is implemented by most modern browsers. For more information, I recommend you go read Matthew Johnson's blog post JavaScript precision timing.
Next Post Newer Posts Previous Post Older Posts Home