А вы о маппере говорите

Да, Дмитрий верно написал

А Дима нет

Проблема же была в том, что этот класс используется для проведения запросов в базу

Ну если ты эту сущность в jpa провайдер скрамливаешь, тогда да, опшинал не вырулит

А с обычными запросами, можешь замапить как удобно.

Я бы вообще сделал это трифтовой моделью

Там все это есть из коробки

Я бы вообще сделал это трифтовой моделью

киви привет передавай

Зачем костыли писать

А Дима нет

что я не так написал?

Проблема в том что ДТО не отображает информацию о том - отсутствует ли значение либо присутствует null

Я бы вообще сделал это трифтовой моделью

Ну началось, а от клиента что принимал бы?

задача апдейта - тривиальная и обсосона тысячу раз была

Для ДТО и то и то null

Ну началось, а от клиента что принимал бы?

сериализованный трифтовый объект

сериализованный трифтовый объект

А если клиент не может в трифт

Тогда надо что-то другое придумывать

А если клиент не может в трифт

Поменяй клиента, чо ты

Поменяй клиента, чо ты

Вот так браузер взял и начал слать трифт

Вот так браузер взял и начал слать трифт

Лол, а что мешает?

Трифт может стать в жсоне

Или поставить сервис перед сервисом который перегоняет реквесты.

Вот так браузер взял и начал слать трифт

Го обратно к нам, тебя не хватает

Будешь просто немного другую структуру принимать

в общем, типичная задача: как привести объекты {} , { "someFlag": null} , { "someFlag": false } и { "someFlag": true } к public class Type { private boolean someFlag; } ?

Boolean

в общем, типичная задача: как привести объекты {} , { "someFlag": null} , { "someFlag": false } и { "someFlag": true } к public class Type { private boolean someFlag; } ?

Boolean имеет 3 состояния

Чего ещё надо?

Boolean имеет 3 состояния

с Optional<Boolean> - 4 состояния )))

И тебе правда нужны 4 состояния?

нет, просто использую приём доведения до абсурда

Бери тогда булеан и норм :)

с Optional<Boolean> - 4 состояния )))

почему 4?

почему 4?

null, empty, false, true

Boolean имеет 3 состояния

А?! Я не сварщик, а маску на стройке нашёл, но расскажите больше, мне интересно

там 5 на самом деле

еще опшионал нулл

может быть

становится потно

Бери тогда булеан и норм :)

это не мне надо, я использую нормальные источники данных (до такого маразма в реальных ситуациях не доходил)

А?! Я не сварщик, а маску на стройке нашёл, но расскажите больше, мне интересно

Я без троллинга, честно интересно

еще опшионал нулл

если внутри опшионала нулл, то это эмпти

если внутри опшионала нулл, то это эмпти

А если сам опшионал - нулл?

А если сам опшионал - нулл?

вот и 4 состояние

А если сам опшионал - нулл?

это я уже перечислил

Я без троллинга, честно интересно

У Boolean 3 состояния, т.к. оно может быть непроинициализированно, то есть быть nullом, ну и два состояния bool

вот и 4 состояние

Вот и я думаю :)

У Boolean 3 состояния, т.к. оно может быть непроинициализированно, то есть быть nullом, ну и два состояния bool

тебе псн отрубили?

У Boolean 3 состояния, т.к. оно может быть непроинициализированно, то есть быть nullом, ну и два состояния bool

Жевануться

У Boolean 3 состояния, т.к. оно может быть непроинициализированно, то есть быть nullом, ну и два состояния bool

т.е. 4 в итоге?

т.е. 4 в итоге?

4 с опшионалом

т.е. 4 в итоге?

С опшионалом?

Да

4 с опшионалом

Кто больше?

Опшионал даёт эмпти

воооот, пришли к консенсусу

5 с опшионалом епта

там +2

5 с опшионалом епта

как

ты

это

ERROR: S client not available

5 с опшионалом епта

Где пятый

сам опшионал нулл

посчитал

5 с опшионалом епта

+1, нуль и так был

ето другой нулл

в классе LinkedBlockingQueue: private final AtomicInteger count = new AtomicInteger(); в методе put() final AtomicInteger count = this.count; и далее обращаются к объекту по локальной ссылке count вопрос - зачем?

Налл, емпти, тру, фолс

У тебя других вариантов нет

скажем так можно написать 5 юнит тестов которые свалятся в разных местах

Ничего ты не напишешь

опшионал = нулл емпти Булеан = тру фолс нулл

в классе LinkedBlockingQueue: private final AtomicInteger count = new AtomicInteger(); в методе put() final AtomicInteger count = this.count; и далее обращаются к объекту по локальной ссылке count вопрос - зачем?

для ускорения, получили ссылку и юзаем ссылку на объект из стека, не бегая в кучу

в классе LinkedBlockingQueue: private final AtomicInteger count = new AtomicInteger(); в методе put() final AtomicInteger count = this.count; и далее обращаются к объекту по локальной ссылке count вопрос - зачем?

А тебя в целом не смущает как там написан код

это пять (5) состояний

для ускорения, получили ссылку и юзаем ссылку на объект из стека, не бегая в кучу

Што?

опшионал = нулл емпти Булеан = тру фолс нулл

У тебя булиан не может быть наллом, так как любой нал превращается в empty

А тебя в целом не смущает как там написан код

нормально там написан код, не придирайся

У тебя булиан не может быть наллом, так как любой нал превращается в empty

действительно

Што?

доступ в стек быстрее, чем доступ к полю в this

Ну если мы ссылку локальную для ускоренич делаем то ок, нормально там все

доступ в стек быстрее, чем доступ к полю в this

Ясно понятно

1. Optional<Boolean> b = null; 2. Optional<Boolean> b = Optional.ofNullable(null); 3. Optional<Boolean> b = Optional.of(Boolean.FALSE); 4. Optional<Boolean> b = Optional.of(Boolean.TRUE);

1337

допиши пятый

1. Optional<Boolean> b = null; 2. Optional<Boolean> b = Optional.ofNullable(null); 3. Optional<Boolean> b = Optional.of(Boolean.FALSE); 4. Optional<Boolean> b = Optional.of(Boolean.TRUE);

Верно

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

допиши пятый

я уже капитулировал пару сообщений назад

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

Нет

Какие же полезные вы тут вопросы задаете