[← Validation](05-validation.md) · [Index](../README.md) · [IDE metadata →](07-ide-metadata.md)

# 6. When `@Value` is still the right answer

Binding wins most of the time, and this project is largely an argument for it. The exceptions
are real though, and pretending otherwise makes the advice easy to dismiss.

## SpEL

`@Value` evaluates SpEL; the binder does not. If the value has to be *computed*, this is the
only one of the two that can do it:

```java
@Value("#{T(java.lang.Runtime).getRuntime().availableProcessors() * 2}")
private int computedThreads;
```

There is no `@ConfigurationProperties` equivalent. The binder maps a value; it does not derive
one. (You can always compute in a compact constructor instead, which is usually clearer.)

## A single value in a class that is not about configuration

A `@Component` that needs one feature flag does not benefit from a properties type. The type
would exist to hold one field and would be injected in one place.

The line is roughly: if you would name the type after the group of settings and the name would
be meaningful, use binding. If you would have to invent a name, use `@Value`.

## Reading someone else's property

`@Value("${server.port}")` reads a property owned by Spring Boot. Declaring your own type for
it would imply you own it.

## What is *not* a good reason

- **"It's less code."** For one property, marginally. For four, the properties type is
  shorter and it is also checked.
- **"I need a default."** Both support defaults.
- **"@Value is faster."** Neither is measurable next to a database call, and both happen once
  at startup.
- **"Relaxed binding doesn't work with @Value."** Inside Spring Boot, it does —
  [chapter 2](02-relaxed-binding.md).