+1. Намного гибче в итоге будет.

А если все таки хочется именно определять активность какого-то профайла, то можно же просто через тот же @Value заинжектить значение ${spring.profiles.active}, без SPEL. И сделать геттер, в котором будет тот же код, но в виде кода, а не в виде строки:

@Value("${spring.profiles.active}")
private String activeProfile;

boolean isProxyProfileActive() {
    return activeProfile.contains("proxy"); // или equals, или что угодно
}

То, что спринг поддерживает SPEL, вовсе не значит, что его нужно обязательно применять там, где можно обойтись нормальным кодом.

@Value("${spring.profiles.active}")
private String activeProfile;

boolean isProxyProfileActive() {
    return activeProfile.contains("proxy"); // или equals, или что угодно
}

зачем мне каждый раз его вычислять? проще один раз вычислить значение и использовать его.

Ну сделайте сеттер, а не геттер. Но вообще, едвали стоит на спичках экономить. Разве что если вызов этого метода действительно будет осуществляться миллион раз в секунду )

+- столько раз и будет.

private boolean proxyProfileActive;

@Value("${spring.profiles.active}")
void setProxyProfileActive(String activeProfile) {
  this.proxyProfileActive = activeProfile.contains("proxy");
}

Либо еще можно использовать все тот же getter + мемоизацию, раз к производительности критичный участок кода.

Боже. Зачем так все усложнять? Там простое boolean поле. Один раз вычислить и забыть про это. Зачем создавать себе гемор с геттерами и меморизацией? Что бы что? Я в упор не могу этого понять. Как альтернативное решение - да.

а вообще профили не совсем для таких штук нужны, с их помощью круто переопределять разные конфигурационные параметры приложения, а не раскидывать по коду прямые зависимости на название профиля.

тебе тонко намекают, что то, чем ты занимаешься - code smell

Да ну? По мне так лучше один раз вычислить, чем городить огород ради простого булеан поля.

а может стоит вынести булеан поле в конфигурацию по нормальному, а не городить проверки на contains?

И куча кода рад чего? Хз. Придумали SpEL и что им нельзя пользоваться теперь? Бред какой-то

Коим образом? Мне нужно проверять существует ли профиль нужный. Может я чет не знаю. Просветите

Усложнение - это когда ты вместо кода на Java пишешь тоже код, но в кавычках, внутри аннотации. Какие у этого подхода недостатки? Да много их. Корректность кода можно проверить только в рантайме. До запуска не понятно даже, компилируется ли он. SPEL не каждый разработчик хорошо знает (вообще не уверен, что есть такие), соответственно хуже в поддержке.

В общем, не понимаю, почему вы это "усложнением" называете. Больше строк кода != сложнее.

это вопрос поддерживаемости кода. SpEL - неподдерживаемый. обычный Джава код - поддерживаемый

ты проверяешь профиль с какой то целью? так вот вынеси эту цель в конфиг.

Эм. Не могу

Так SPEL не для того придумали. Его придумали во времена XML-конфигураций, когда нужно было чуть-чуть покодить внутри XML.

ну, действительно, лучше нагородить говнокода, чем подумать как сделать по нормальному.

Ну, действительно, лучше осудить человека, не зная деталей, чем узнать что да как если реально интересно

Спорить не буду. Возможно это и так.