mscharhag, Programming and Stuff;

A blog about programming and software development topics, mostly focused on Java technologies including Java EE, Spring and Grails.

  • Sunday, 5 March, 2017

    Be aware that bcrypt has a maximum password length

    bcrypt is a popular password hashing function these days. Other than standard hash functions (like SHA-515), bcrypt is designed to be slow and therefore very resistant to brute force attacks.

    However, when using bcrypt you should be aware that it limits your maximum password length to 50-72 bytes. The exact length depends on the bcrypt implementation you are using (see this stackexchange answer).

    Passwords that exceed the maximum length will be truncated.

    The following piece of code shows the password truncation using Spring Securities BCryptPasswordEncoder:

    BCryptPasswordEncoder passwordEncoder = new BCryptPasswordEncoder();
    // 72 characters
    String password1 = "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa";
    // 73 characters
    String password2 = "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaab";
    String encodedPassword1 = passwordEncoder.encode(password1);
    boolean matches = passwordEncoder.matches(password2, encodedPassword1);
    System.out.println("encodedPassword1: " + encodedPassword1);
    System.out.println("matches: " + matches);

    When running this example, the output might look like this:

    encodedPassword1: $2a$10$A5OpVKgjEZzmy6UNsqzkjuG2xGET1wp3b/9ET5dz/tHQ3eRvyXSSO
    matches: true

    According to BCryptPasswordEncoder both passwords match (= are identical) even if they have a different length.

  • Wednesday, 27 April, 2016

    Java EE 8 MVC: Global exception handling

    In the previous previous posts we learned about various ways to access request information (e.g. query or path parameters) in Java EE MVC. This post shows how to apply global exception handling to an MVC application.

    Assume we have a controller method that might throw an IllegalArgumentException:

    public class ExceptionController {
      public String doWork() {
        // code that might throw an IllegalArgumentException

    We could now add a try/catch block to doWork() and wrap the piece of code that might throw the exception. However, this approach becomes tedious if it needs to be applied to multiple methods.

    In such a case we can register a global exception mapper. To do this, we habe to create a class that implements the generic ExceptionMapper interface.

    A simple ExceptionMapper for IllegalArgumentExceptions looks like this:

    public class IllegalArgumentExceptionMapper implements ExceptionMapper<IllegalArgumentException> {
      private Models models;
      public Response toResponse(IllegalArgumentException exception) {
        models.put("message", exception.getMessage());
        return Response.status(Response.Status.BAD_REQUEST)

    Now, whenever an IllegalArgumentException is thrown from controller methods, IllegalArgumentExceptionMapper will be used to convert the exception to an appropriate response. Here a simple error view (error.jsp) is rendered.

    If you want a generic ExceptionMapper that handles all types of exceptions, you simply have to implement ExceptionMapper<Exception>. If you have multiple ExceptionMapper implementations that are suitable to handle a thrown exception, the most specific ExceptionMapper is used.

    Quick Summary

    Adding global exception handling to an Java EE MVC application is quite simple. We only have to create a class that implements the ExceptionMapper interface with the exception type that should be handled.

    The full example code can be found on GitHub.

  • Sunday, 3 April, 2016

    Simplifying nested loops with Java 8 Lambdas

    This is just a quick tip for everyone who often has to work with multi dimensional arrays in Java 8 (or newer).

    In this case you might often end with code similar to this:

    float[][] values = ...
    for (int i = 0; i < values.length; i++) {
      for (int k = 0; k < values[i].length; k++) {
        float value = values[i][k];
        // do something with i, k and value

    If you are lucky you can replace the loops with for-each loops. However, often the indices are required for computations inside the loop.

    In such a case you can come up with a simple utility method that looks like this:

    private void loop(float[][] values, BiConsumer<Integer, Integer> consumer) {
      for (int i = 0; i < values.length; i++) {
        for (int k = 0; k < values[i].length; k++) {
          consumer.accept(i, k);

    We can now loop over array indices like this:

    float[][] values = ...
    loop(values, (i, k) -> {
      float value = values[i][k];
      // do something with i, k and value

    This way you can keep the looping code out of your main logic.

    Of course you should change the shown loop() method so it fits your personal needs.


  • Wednesday, 30 March, 2016

    Retry handling with Spring-Retry

    Whenever software components communicate with each other, there is a chance for temporary self-correcting faults. Such faults include the temporary unavailability of a service, momentary loss of network connectivity, or timeouts that arise when a service is busy. In such situations a proper retry handling can reduce the problems these faults might cause.

    In this post we will see how Spring Retry can be used to add robust retry logic to Spring applications. Spring Retry is probably not that well know because it is not listed on the Spring documentation overview. However, you can find it on the Spring Initializr page.


    To use Spring Retry we need to add the following dependency to our project:


    Spring Retry makes use of AOP, so make sure Spring AOP is available:


    If you are using Spring Boot, you can use spring-boot-starter-aop instead:


    To enable Spring Retry we simply have to add @EnableRetry to our application configuration class:

    @SpringBootApplication // or @Configuration if you are not using Spring Boot
    public class RetryExampleApplication {
      // ...

    Adding retry handling with Annotations

    We are now ready to add retry handling to methods. To do so, we simply have to annotate the appropriate methods with @Retryable:

    public class MyService {
      public void simpleRetry() {
        // perform operation that is likely to fail

    Methods annotated with @Retryable can be called like any other methods. However, whenever the execution of a retryable method fails with an exception, Spring will automatically retry to call the method up to three times. By default Spring uses a 1 second delay between method calls. Please note that the calling thread blocks during retry handling.

    The retry behavior can be customized in various ways. For example:

    public class MyService {
      @Retryable(value = {FooException.class, BarException.class}, maxAttempts = 5)
      public void retryWithException() {
        // perform operation that is likely to fail
      public void recover(FooException exception) {
        // recover from FooException

    Here we tell Spring to apply retry handling only if a Exception of type FooException or BarException is thrown. Other exceptions will not cause a retry. maxAttempts = 5 tells Spring to retry the method up to 5 times if it fails.

    With @Recover we define a separate recovery method for FooException. This allows us to run special recovery code when a retryable method fails with FooException.

    Adding retry handling with RetryTemplate

    Besides annotations Spring Retry offers a RetryTemplate that can be used to define retry handling in Java code. Like any other bean, a RetryTemplate can simply be configured in our configuration class:

    @SpringBootApplication // or @Configuration if you are not using Spring Boot
    public class RetryExampleApplication {
      public RetryTemplate retryTemplate() {
        SimpleRetryPolicy retryPolicy = new SimpleRetryPolicy();
        FixedBackOffPolicy backOffPolicy = new FixedBackOffPolicy();
        backOffPolicy.setBackOffPeriod(1500); // 1.5 seconds
        RetryTemplate template = new RetryTemplate();
        return template;
      // ...

    A RetryPolicy determines when an operation should be retried. SimpleRetryPolicy is a RetryPolicy implementation that retries a fixed number of times.

    A BackOffPolicy is a strategy interface to control back off between retry attempts. A FixedBackOffPolicy pauses for a fixed period of time before continuing. Some other default BackOffPolicy implementations are ExponentialBackOffPolicy (increases the back off period for each retry) or NoBackOffPolicy (no delay between retries).

    We can now inject the RetryTemplate to our service. To run code with retry handling we simply have to call RetryTemplate.execute():

    public class RetryService {
      private RetryTemplate retryTemplate;
      public void withTemplate() {
        retryTemplate.execute(context -> {
          // perform operation that is likely to fail
      // ...

    RetryTemplate.exeucte() takes a RetryCallback<T, E> as parameter. RetryCallback is a functional interface so it can be implemented using a Java 8 Lambda expression (as shown above).


    Spring retry provides an easy way to add retry handling to spring applications. Retry handling can be added using either annotations (@Retryable and @Recover) or by passing a RetryCallback to a RetryTemplate.

    You can find the full example source code on GitHub.

  • Tuesday, 15 March, 2016

    Java EE 8 MVC: Working with bean parameters

    In the last posts we saw how to access query, path and form parameters in MVC Controllers. This post shows how multiple parameters can be mapped to an object using the @BeanParam annotation.

    Let's reuse the simple HTML form from the post about form parameters:

    <form action="submit" method="post">
      <input type="text" name="id" />
      <input type="text" name="name" />
      <select name="role">
    	<option value="admin">Admin</option>
    	<option value="reporter">Reporter</option>
    	<option value="accountant">Accountant</option>
      <input type="submit"/>

    This defines a simple form containing two text input fields and a select menu with three options.

    In the previous post about form parameters, we learned that we can access these parameters by annotating controller parameters with @FormParam.

    However, this approach is cumbersome if the form has more than a few parameters. In these situations we typically want to map form parameters to a separate object. @BeanParams helps us with doing exactly this.

    With @BeanParam we can write:

    public String submit(@BeanParam User user) {
      // use user ..

    The User class looks like this:

    public class User {
      private long id;
      private String name;
      private Role role;
      // getters and setters

    When the controller method is called a new instance of User will automatically be created. The fields of the created object will be filled with the passed form parameters.

    @BeanParam and other parameter annotations

    Classes used with @BeanParam are not limited to form parameters. All parameter annotations shown in previous blog posts (@QueryParam, @PathParam, etc.) can be used inside bean parameters.

    For example:

    public String get(@BeanParam RequestData data) {
    public class RequestData {
      private int year;
      private int month;
      private String name;
      // getters and setters

    If we now send a HTTP GET request to


    the values 2016, 2 and john will be injected to the fields year, month and name of RequestData.

    Quick Summary

    With @BeanParam you can inject request parameters into beans. This is especially useful if you have more than a few parameters. Inside bean parameters all other parameter annotations can be used.

    You can find the example source code on GitHub.