ну так то я предполагаю что категорий будет небольшоеколичество

я наоборот делаю явную всегда если нет ОЧЕНЬ веских причин так не делать, чтобы не прятать элементы реализации, и не ловить потом проблемы с переделкой этого места + всех наложившихся за время зависимостей

ооо, кстати, я это не проверял, спасиб, потом посмотрю)

@Override
   public boolean equals(Object o) {
       if (this == o) return true;
       if (!(o instanceof Article)) return false;
       Article article = (Article) o;
       return Objects.equals(title, article.title) &&
               Objects.equals(content, article.content);
   }

   @Override
   public int hashCode() {
       return Objects.hash(title, content);
   }
ломбок я убрал, у меня он чот глючил с последней идеей, в принципе работало все, но ошибки в стек сыпались

не помню почему я сет временно поменял на лист , да так и оставил :)
UPD. у меня кастомный контроллер есть который описывает общие для разных сущностей вещи, такие как getAll:

   public List<D> findAll() {
       return repository.findAll()
               .stream()
               .map(e -> mapper.toDto(e))
               .collect(Collectors.toList());
   }

Странно, переставил на set тип данных коллекции категорий в статьях тоже все работает, ну хз тогда зачем я это делал :)

Какой переделкой?
Как раз добавить сущность никогда не поздно, а так это просто мусор

Как сессия работает в курсе? Хибера

далеко не до конца
к чему ты ведёшь?

Внутри хэшмапа, которая будет дергать equals, поэтому надо убирать из него все лэзи

Что будет если этого не сделать думаю догадаешься

я знаю что equals  и hashcode ломбока по дефолту дёргают все связи, в тч LAZY, но не знаю в какой момент сессия вызывает их, как правило я стараюсь вообще не переопределять equals от греха подальше чтобы он по дефолту сравнивал по ссылкам (просто я не помню что конкретно стояло в модели в тот раз)

я не знаю все кейсы которые нужно обработать при переопределении equals и hashcode)

Икволс и хешкод для Entity почти всегда надо переопределять.

жаль но я не осилил как это делать правильно, а значит не буду этого делать до явной необходимости, чтобы когда понимание таки придёт не иметь дело с кучей написанных ранее методов разной степени работоспособности а ошибка из-за которой я мне придётся этим заняться не будет осложнена моей кастомной логикой)
в конце твоей статьи даже есть небольшой холиварчик где автор отвечает автору другой статьи, в которой среди всего прочего предлагается не переопределять equals и hashcode, и беда в том что я не знаю кто из них прав )

Прочитал этот пост Влада, и пост Марка, на который Влад отвечает. Как-то слишком поверхностно. Марк пишет, что если переопределить equals/hashCode, то будут проблемы с merge/getReference, а Влад отвечает, что не будет. Но, блин, какие именно проблемы?) Как вообще можно отвечать, что проблем не будет, если Марк не написал, какие именно проблемы он имеет ввиду..

Влад отвечает:

> As for getReference(), there’s a check for that as well. It’s all on GitHub.

Открываю ссылку на гитхаб. Там всего лишь проверка того факта, что в сете находится объект, полученный через getReference() (вызванный в другой сессии), т.е. проверка на то, что equals работает.

Но, возможно, Марк имел ввиду совсем другую проблему. На сколько я помню, в Хибернейт (по крайней мере раньше так было, давно с ним не работал) довольно плохо работал getReference(). Он загружал (может и до сих пор загружает) весь объект, т.е. генерировал SELECT... Т.е. работал как find. Не знаю, связано ли это как-то с equals/hashCode, как-то раньше не задумывался (у меня они обычно переопределены примерно так, как у Влада - и это дефолтный способ в AbstractPersistable от spring-data-jpa).

Возможно, это никак и не связано с equals/hashCode, а связано с AccessType у ID. У Хибера еще одна проблема есть (или была): если ставить аннотации над полями сущности (как чаще всего делают), то user.getRole().getId() триггерит загрузку Role, даже если она LAZY (имеется ввиду связь User-Role many-to-one). Если же у ID сделать @Access(AccessType.PROPERTY), то не триггерит (что хорошо, ведь у нас уже есть role_id в памяти - это FK в таблице User. В Keycloak используют этот "хак" - https://github.com/keycloak/keycloak/blob/master/model/jpa/src/main/java/org/keycloak/models/jpa/entities/UserEntity.java#L70). Возможно, это и на getReference() как-то влияет. Хотя вряд ли.

В любом случае, попытка Влада опровергать такое нечеткое утверждение ("Even Vlad’s advanced version does have holes. E.g. if you use em.getReference() or em.merge()." - Mark) выглядит как-то странно. Сначала нужно понять, в чем именно Марк видит проблему.

Подскажите пожалуйста, сертификация от Oracle по java, стоит ли получать их? Дает какое то  преимущество?

Нет

Подскажите пожалуйста, есть приложение на spring boot. В пропертях есть значение, которое нужно взять из env.
В линуксе в /etc/environment добавил нужное мне значение. В итоге если jar запускать из консоли в ручную, то спринг читает значение корректно. Если же тот же jar запускать как service, то спринг уже не видит переменную окружения.
Что я упускаю, помогите пожалуйста.

Потому что systemd сервисы (если под "service" вы имеете ввиду именно это) не читают  /etc/environment

Вот тут не плохо описано, что такое /etc/environment и в каких случаях он вообще используется https://superuser.com/a/664236