Is TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 a safe cipher suite to use?

TLS ciphersuite names are structured in such a way that you can tell what algorithms and key sizes are used for each part of the handshake and encrypted session. Let's break this one down and see if there are any improvements we can make:

• TLS - This doesn't signify anything in itself, but does allow me to mention that TLS 1.2 is the latest version of TLS and does not have any known vulnerabilities.
• ECDHE - Elliptic Curve Diffie-Hellman with Ephemeral keys. This is the key exchange method. Diffie-Hellman key exchanges which use ephemeral (generated per session) keys provide forward secrecy, meaning that the session cannot be decrypted after the fact, even if the server's private key is known. Elliptic curve cryptography provides equivalent strength to traditional public-key cryptography while requiring smaller key sizes, which can improve performance. Additionally, they serve as a hedge bet against a break in RSA.
• RSA - The server's certificate must contain a RSA public key, and the corresponding private key must be used to sign the ECDHE parameters. This is what provides server authentication. The alternative would be ECDSA, another elliptic-curve algorithm, but you may be restricted by the types of certificates your CA will sign.
• AES_128 - The symmetric encryption cipher is AES with 128-bit keys. This is reasonably fast and not broken (unless you think NSA has backdoored AES, a topic for another time). Other than AES_256 (which may be too costly performance-wise), it's the best choice of the symmetric ciphers defined in RFC 5246, the others being RC4 (which has some known weaknesses and may be broken relatively soon) and 3DES_EDE (which only has a practical bit strength of 108 to 112, depending on your source).
• CBC - Cipher Block Chaining mode. Here's where you can probably improve your choice. CBC mode is a way of employing a block cipher to encrypt a variable-length piece of data, and it has been the source of TLS woes in the past: BEAST, Lucky-Thirteen, and POODLE were all attacks on CBC-mode TLS. A better choice for performance and security is AES_128_GCM, which is one of the new AEAD ciphers introduced in TLS 1.2 and has good performance and security characteristics.
• SHA256 - This is the hash function that underlies the Message Authentication Code (MAC) feature of the TLS ciphersuite. This is what guarantees that each message has not been tampered with in transit. SHA256 is a great choice, and is the default hash algorithm for various parts of TLS 1.2. I'm pretty sure that using SHA-1 would be OK here, since the window for exploitation is so much smaller than, e.g. the certificate signature. AEAD ciphersuites are authenticated to begin with, so this additional MAC step is not needed or implemented.

Essentially, you have chosen a good ciphersuite that doesn't have any practical problems for now, but you may wish to switch to an AEAD ciphersuite (AES-GCM or Google's ChaCha20-Poly1305) for improved performance and protection against future CBC-related vulnerabilities.

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 is as "safe" as any cipher suite can be: there is no known protocol weakness related to TLS 1.2 with that cipher suite. Any particular implementation can, of course, botch things and introduce weaknesses on its own accord. You can also trample your own security to the ground by, for instance, failing to properly protect the storage of your server RSA key; or using weak key pair generation for that RSA key; or deactivating certificate validation in the client; or any other of a zillion stupid actions that are doable if you do not take care.

There was a recent update on all CBC ciphers that might render them unsafe in most situations. So you should probably reassess your server security by running a check. (More info from SSLLabs)

As for what to use, cfieber commented correctly, and your best (and only) bets for Java 8 now are TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 and TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 depending on the cert type. (Taken from here)