Introduction

Generating a random integer between 1 and 10 in Java is simple once you remember the range rules. The main source of bugs is off-by-one thinking, because Java APIs usually define random integer ranges as inclusive of the lower bound and exclusive of the upper bound.

Use ThreadLocalRandom for Most Modern Code

For everyday Java code, ThreadLocalRandom is the clearest answer.

1import java.util.concurrent.ThreadLocalRandom;
2
3public class Main {
4    public static void main(String[] args) {
5        int value = ThreadLocalRandom.current().nextInt(1, 11);
6        System.out.println(value);
7    }
8}

This returns a value from 1 through 10 because the upper bound 11 is exclusive.

That exclusive upper-bound rule is the detail people most often miss.

Use Random if You Already Have One

java.util.Random also works fine.

1import java.util.Random;
2
3public class Main {
4    public static void main(String[] args) {
5        Random random = new Random();
6        int value = random.nextInt(10) + 1;
7        System.out.println(value);
8    }
9}

Here is the logic:

• 'nextInt(10) gives 0 through 9'
• adding 1 shifts the range to 1 through 10

This is still a correct and common approach.

Math.random() Also Works

If you want a one-liner and do not need a reusable random generator object, Math.random() is acceptable.

1public class Main {
2    public static void main(String[] args) {
3        int value = (int) (Math.random() * 10) + 1;
4        System.out.println(value);
5    }
6}

The same range logic applies:

• 'Math.random() gives a double in [0.0, 1.0)'
• multiplying by 10 gives [0.0, 10.0)
• casting to int truncates to 0 through 9
• adding 1 gives 1 through 10

This works, but many developers prefer ThreadLocalRandom or Random because the intent is clearer.

Know When You Need Secure Randomness

If the number is for a game, simulation, or basic app logic, the normal random APIs are fine. If the number affects security, token generation, or secrets, use SecureRandom instead.

1import java.security.SecureRandom;
2
3public class Main {
4    public static void main(String[] args) {
5        SecureRandom random = new SecureRandom();
6        int value = random.nextInt(10) + 1;
7        System.out.println(value);
8    }
9}

This is slower but appropriate for security-sensitive randomness.

Test the Range, Not Just One Run

Random code often looks correct even when the bounds are wrong. A quick loop makes mistakes obvious.

1import java.util.concurrent.ThreadLocalRandom;
2
3public class Main {
4    public static void main(String[] args) {
5        for (int i = 0; i < 20; i++) {
6            int value = ThreadLocalRandom.current().nextInt(1, 11);
7            System.out.println(value);
8        }
9    }
10}

If you ever see 0 or 11, the bounds are wrong.

Reproducibility for Tests

If you are writing tests or examples and want repeatable output, use a seeded Random instance instead of relying on a fresh generator each run. That gives deterministic sequences for debugging while preserving the same range logic.

1import java.util.Random;
2
3Random random = new Random(12345L);
4int value = random.nextInt(10) + 1;
5System.out.println(value);

This is helpful for unit tests, but not appropriate when the point is real unpredictability.

Common Pitfalls

• Forgetting that many Java random methods use an exclusive upper bound leads to off-by-one errors.
• Writing nextInt(1, 10) when you really want 1 through 10 excludes 10 because the upper bound is not included.
• Using Math.random() without understanding the cast-and-shift logic can accidentally produce the wrong range.
• Reaching for SecureRandom for ordinary non-security cases adds overhead without benefit.
• Assuming one printed result proves the bounds are correct can hide mistakes that only show up across repeated runs.

Summary

• The easiest modern answer is ThreadLocalRandom.current().nextInt(1, 11).
• With Random, use nextInt(10) + 1.
• With Math.random(), use (int)(Math.random() * 10) + 1.
• Remember that Java random upper bounds are usually exclusive.
• Use SecureRandom only when the randomness is security-sensitive.