How to remove unnecessary trailing zeros from the string representation of a number

Recently I have had an issue where I needed to display some numbers that was sent to an application as strings. A lot of these numbers had some unnecessary trailing zeros at the end. I needed to remove these zeros, but keep the precision of the numbers.

The BigDecimal class came to my help. I converted my strings to BigDecimal instances and I was able to remove the unnecessary zeros and get back a string again the following way:

new BigDecimal("123.45600").stripTrailingZeros().toPlainString()

The result of this is another string, but without the trailing zeros.


This works with any other number, it won’t loose precision, just removes unnecessary zeros.

Codec not found for requested operation: [date <-> java.util.Date] exception in Cassandra

I was trying to create an Accessor interface in a Java application communicating with cassandra. The interface looked something like this:

import java.util.Date;

import com.datastax.driver.mapping.Result;
import com.datastax.driver.mapping.annotations.Accessor;
import com.datastax.driver.mapping.annotations.Query;
import com.custom.package.Order;

public interface OrderAccessor {

    @Query("SELECT * FROM orders WHERE checkout_date = ?")
    Result<Order> findAllOrdersByCheckoutDate(Date checkoutDate);


When I was trying to run the query, I got the following exception:

Codec not found for requested operation: [date <-> java.util.Date]

It turned out that for the Cassandra date type, the correct Java type to use is com.datastax.driver.core.LocalDate

Changing my java.util.Date to this resolved the issue.

IntelliJ reports that there is more than one bean of a repository, although app starts up fine

I’ve come across an issue recently in a project where I was using Spring Data JPA. I had a repository defined like this:

public interface QuestionCategoryRepository extends JpaRepository<QuestionCategory, Long> {


I also had a service class where I injected this repository:

private QuestionCategoryRepository questionCategoryRepository;

I noticed, that IntelliJ reported the following error: “There is more than one bean of QuestionCategoryRepository type”. It seemed wierd to me, so I went ahead and started my application. The context was built successfully and there were no problems with the startup at all.

It turned out that IntelliJ really had provided me a useful hint, because I noticed that I have an

@ComponentScan(basePackages = "...")

annotation on my class that is used for persistence related configuration. The scope of this annotation was involving the package where I had my repositories defined.

This is why IntelliJ believed, that there are two definitions.

Actually, there were three.

I also noticed that I have

@EnableJpaRepositories(basePackages = "...")

on my configuration class, pointing to the packes where my repositories reside.

It turned out that I can remove both the @Repository annotation and the @ComponentScan as well, becauses the @EnableJpaRepositories was enough to detect my repositories. Of course, @ComponentScan might need to be kept if it is for scanning some other classes.

Keep form field values and errors after redirection in Spring MVC controller

Ways for processing form submit

When you are processing a form submit using Spring MVC, if there are validation errors, you can:

  1. Return the errors in the response to the form submit request (POST request usually).
  2. Redirect the user to the form and return the result from this new request.

The first option has a drawback that if the user refreshes the page after we return with the response, the form will be resubmitted the same way as before (also he’ll see the confirmation popup asking if it is okay to do that). On one hand, most of the users won’t even understand the situation, on the other hand if the user decides to resubmit the form, sometimes unwanted situations might happen.

Also, another case to consider, if the user just wants to refresh the page to get an empty form, he’ll not succeed because he’ll still see the errors and filled values from the previous submission.

Because of these reasons the second option might be preferred, let’s see how to do that

Retaining filled values and errors upon redirect

First let’s see the whole code of a controller that implements the solution:

package com.devsphinx.web.controller.user;

import com.devsphinx.web.controller.BaseController;
import com.devsphinx.web.model.user.CreateAccountModel;
import org.springframework.stereotype.Controller;
import org.springframework.ui.Model;
import org.springframework.validation.BindingResult;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RequestMethod;

import javax.validation.Valid;

public class CreateAccountController extends BaseController {

    @RequestMapping(value = "/create-account", method = RequestMethod.GET)
    public String getCreateAccount(Model model) {

        if (!model.containsAttribute("createAccountModel")) {
            model.addAttribute("createAccountModel", new CreateAccountModel());

        return "create-account/create-account";

    @RequestMapping(value = "/create-account", method = RequestMethod.POST)
    public String postCreateAccount(
            @Valid CreateAccountModel createAccountModel,
            BindingResult result, RedirectAttributes redirectAttributes) {

        if (result.hasErrors()) {
            redirectAttributes.addFlashAttribute("org.springframework.validation.BindingResult.createAccountModel", result);
            redirectAttributes.addFlashAttribute("createAccountModel", createAccountModel);
            return "redirect:/create-account";
        // Success case omitted...

You can see that we have here a standard spring controller with two methods. The first method serves the GET request for the account creation page and the second one serves the POST request.

What we wanted to achieve is if the POST request is performed and there are validation errors, then the request is redirected to the GET handler with the errors and form field values still populated.

In the POST handler method

if (result.hasErrors()) {
    redirectAttributes.addFlashAttribute("org.springframework.validation.BindingResult.createAccountModel", result);
    redirectAttributes.addFlashAttribute("createAccountModel", createAccountModel);
    return "redirect:/create-account";

In this, we have to populate these to the RedirectAttributes instance.

  • For the BindingResult you have to specify the class with the full package name and contatenate the model’s name to the end.
  • The model must be added with the same name as you were using in this method.

In the GET handler method

@RequestMapping(value = "/create-account", method = RequestMethod.GET)
public String getCreateAccount(Model model) {

  if (!model.containsAttribute("createAccountModel")) {
    model.addAttribute("createAccountModel", new CreateAccountModel());

  return "create-account/create-account";

If we redirect from the POST handler, because we added the flash attributes, the model in the GET handler will be automatically populated with these.

However, if we reach the GET handler with just a regular page request, without anything added as flash attributes, we need to manually add the our form backing object (createAccountModel) to the model.

How to monitor your local Java web application through JMX

Java Management Extensions (JMX) is a Java technology that supplies tools for monitoring applications. Monitoring a locally running Java web application is really straightforward.

You do not need any extra configuration to set up, you only need a tool called JConsole, and it’ll be able to see all your locally running JVMs and monitor them.

JConsole can be found in the bin directory inside your JDK’s installation directory. For me it is: C:\Program Files\Java\jdk1.8.0_91\bin 

Start jconsole.exe and you should see your local processes:

On this example screenshot, the first process is a Java web application which I started in a standalone tomcat. The second one is the process of JConsole itself.

Even you are running your application using the Maven tomcat plugin and not in a standalone tomcat, it’ll still work.

Select one of the processes and double click on it. You should see the management interface open up with a slew of useful statistics and information:


If you do not see any processes in the “Local Processes” list, please check out this post for a possible solution.