ну вдруг там все накрылось медным тазом...

кто тут кроме вас лучше поймет. я и так и так делаю по случаю

если нужны фишки от гуавы - берите ее. если нет, юзайте хэшмап с шедулером

Ну вопрос в том что есть еще? Я выбираю среди двух вариантов и решил спросить у народа может есть еше вариант

Когда живешь без SpringBoot, XML, как по мне, наиболее читаемый формат. Правда я в них года 3 или 4 подряд смотрел. ?

Тоже в них хз сколько лет смотрел, больше нет желания

Я про кэш спрашиваю

Caffeine весьма хорош для кэширования

Долбаный гугл. Пытаюсь google-java-format завести на андроиде. А там блин java 8. Долбаный гугл

А в андроиде какая версия? 7 до сих пор?

В Андроиде есть поддержка восьмой, но не все методы доступны на низких версиях апи

В Андроиде есть поддержка восьмой, но не все методы доступны на низких версиях апи

24+

Или нет. Короче выше шестого

ого. Тяжко вам.

Или нет. Короче выше шестого

@android_ru

24+

не совсем верно. некоторые фичи восьмой (те же лямбды) и на 15 можно использовать

Я пишу IDEA под андроид..) Приложение использует встроенный линукс, подключается с помощью proot. Уже поставил и jdk8 для arm hf.. Я юзаю google-java-format через этот же jdk но просто каряво это очень.

@android_ru

Да да просто бомбит

Да да просто бомбит

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

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

Ага.. Я так много либ понадобавлял модулями

В апи яндекса (авторизация через яндекс) помню чет не работало как нам надо было

Его тоже пришлось вскрыть

У меня есть Executor внутри которого я запускаю Callable, мне нужно заблокировать методом wait конкретный Callable, а точнее его поток, но блокиреутся вся группа потоков почему-то, в таком случае я решил сделать Thread.currentThread().wait(), что меня удовлетворяло, но теперь нельзя оживить поток при необходимости методом notifyAll() Как это исправить?

У меня есть Executor внутри которого я запускаю Callable, мне нужно заблокировать методом wait конкретный Callable, а точнее его поток, но блокиреутся вся группа потоков почему-то, в таком случае я решил сделать Thread.currentThread().wait(), что меня удовлетворяло, но теперь нельзя оживить поток при необходимости методом notifyAll() Как это исправить?

кем оживляется поток?

просто notifyAll()

не как, а кем, то есть из какого потока/источника

Из другого потока в том же Executor

то есть ссылки на эти callable где-то хранятся/передаются между callable?

то есть ссылки на эти callable где-то хранятся/передаются между callable?

Нет

Нет

так как тогда один callable уведомит другой, не имея на него ссылки?

Сейчас попробую передавать и вызывать notify конкретного callable

У меня есть Executor внутри которого я запускаю Callable, мне нужно заблокировать методом wait конкретный Callable, а точнее его поток, но блокиреутся вся группа потоков почему-то, в таком случае я решил сделать Thread.currentThread().wait(), что меня удовлетворяло, но теперь нельзя оживить поток при необходимости методом notifyAll() Как это исправить?

Может, лучше использовать более высокоуровневые примитивы синхронизации? Кроме того, если в Executor 1 поток, "другой поток" его уже никак не разбудит. Это какое-то неправильное использование Executor, если имеет значение, в каком потоке выполняется Callable.

так как тогда один callable уведомит другой, не имея на него ссылки?

Кстати, вопрос немножко не по теме, но зачем усыплять и пробуждать потоки через ключ типо: synchronized(lock){ lock.wait() }

Кстати, вопрос немножко не по теме, но зачем усыплять и пробуждать потоки через ключ типо: synchronized(lock){ lock.wait() }

через какой ключ?

Может, лучше использовать более высокоуровневые примитивы синхронизации? Кроме того, если в Executor 1 поток, "другой поток" его уже никак не разбудит. Это какое-то неправильное использование Executor, если имеет значение, в каком потоке выполняется Callable.

Ты прав

через какой ключ?

Через объект который внутри synchronized

Кстати, вопрос немножко не по теме, но зачем усыплять и пробуждать потоки через ключ типо: synchronized(lock){ lock.wait() }

потому что это единственный низкоуровневый способ усыпить поток

Через объект который внутри synchronized

в блоке синхронизации?

все блокировки в итоге сводятся к нему

в блоке синхронизации?

Да

Почему нельзя написать просто wait()

Тот же самый callable.notifyAll() сделать после

Почему нельзя написать просто wait()

потому что wait не работает вне блока синхронизации

выдаст ошибку

Почему нельзя написать просто wait()

ну, wait всегда вызывается в многопоточной среде и после проверки определенного условия. Отсутствие синхронизации может привести к возникновению check-then-act race condition, когда поток войдет в состояние ожидания в том случае, когда условие, приводящее к ожиданию, ложно. А это может привести к неприятным последствиям. Пример: Продьюсер-консьюмер, очередь длиной 1. 1. Потребитель вызывает poll() и видит, что очередь пустая, переходит в состояние ожидания. 2. Перед вызовом wait() продюсер добавляет элемент в очередь и вызывает notify. 3. Потребитель уходит в ожидание после уведомления, хотя элемент в очереди существует. 4. Производитель добавляет элемент в очередь, но поскольку она заполнена, он блокируется. результат - оба треда заблокированы без возможности разблокировки.

выдаст ошибку

Не выдаёт

ну, wait всегда вызывается в многопоточной среде и после проверки определенного условия. Отсутствие синхронизации может привести к возникновению check-then-act race condition, когда поток войдет в состояние ожидания в том случае, когда условие, приводящее к ожиданию, ложно. А это может привести к неприятным последствиям. Пример: Продьюсер-консьюмер, очередь длиной 1. 1. Потребитель вызывает poll() и видит, что очередь пустая, переходит в состояние ожидания. 2. Перед вызовом wait() продюсер добавляет элемент в очередь и вызывает notify. 3. Потребитель уходит в ожидание после уведомления, хотя элемент в очереди существует. 4. Производитель добавляет элемент в очередь, но поскольку она заполнена, он блокируется. результат - оба треда заблокированы без возможности разблокировки.

Спасибо огромное за подробный ответ

Не выдаёт

ошибку компиляции не выдаёт, а вот на рантаймке грохнется

ошибку компиляции не выдаёт, а вот на рантаймке грохнется

И этого не происходит, wait() работает стабильно, впринципе я считаю ответ Владимира праильным и достаточно доходчивым

public void insertMessage(Message message){ String uuid = message.addressId; if (getNicknameById(uuid) == null) new ServerPostman().postRequest(new AddressRequest(uuid)); Future future = service.submit(() -> { while (getNicknameById(uuid) == null) synchronized (lock){ lock.wait(); } MessageDao messageDao = App.getInstance().getDatabase().messageDao(); messageDao.insert(message); return null; }); try { future.get(); App.getInstance().getResponseListeners().getContactUpgradeBus().onUpdateLastMessage(message.addressId, message.text); } catch (InterruptedException | ExecutionException e) { e.printStackTrace(); } } public void insertAddressee(Addressee addressee) { Future<Object> future = service.submit(() -> { AddresseeDao addresseeDao = App.getInstance().getDatabase().addresseeDao(); addresseeDao.insert(addressee); synchronized (lock){ lock.notifyAll(); } return null; }); try { future.get(); App.getInstance().getResponseListeners().getContactUpgradeBus().onLoadContacts(); } catch (InterruptedException | ExecutionException e) { e.printStackTrace(); } }

Он не пробуждает

И этого не происходит, wait() работает стабильно, впринципе я считаю ответ Владимира праильным и достаточно доходчивым

значит, это внутри synchronized

Когда я делаю без ExecutorService всё работает так как нужно, никаких проблем, но с Executor никак

Когда я делаю без ExecutorService всё работает так как нужно, никаких проблем, но с Executor никак

пример кода с ExecutorService дайте

пример кода с ExecutorService дайте

Я его и дал

service - это объект типа ExecutorService

service - это объект типа ExecutorService

инициализацию покажите

protected static ExecutorService service = Executors.newFixedThreadPool(2);

protected static ExecutorService service = Executors.newFixedThreadPool(2);

хорошо, вы также можете попробовать использовать https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/locks/Condition.html

хорошо, вы также можете попробовать использовать https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/locks/Condition.html

Это к сожалению совсем не то что нужно

товарищи! Вопрос! Csv файл проще на фронте сгенерить или на беке?

Vitaly по каким условиям одни потоки должны будить другие?

Он не пробуждает

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

(либо вообще не происходит)

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

Уведомление происходит после ожидания, это я сразу провери

ERROR: S client not available

значит, после уведомления условие getNicknameById(uuid) == null снова истинно

Это к сожалению совсем не то что нужно

Ок. Вам виднее. А не может быть такого, что из-за маленького размера пула у вас все залочилось?

и поток снова входит в ожидание

Vitaly по каким условиям одни потоки должны будить другие?

Код имеет следующую логику: Если в БД нет пользователя, то отправляй запрос на получение пользователя и блокируй поток для отправки сообщения, приходит (уже в другой поток) сообщение с пользователем, он заносится в БД, после вызывается пробуждение потоков и по сути он должен быть уже не null

Кстати, сейчас проверю, заносится ли в БД пользователь

а зачем блокировать поток для отправки? он какой-то долгоживущий?

а зачем блокировать поток для отправки? он какой-то долгоживущий?

Потому что дальше планируется отобразить сообщение

А для него необходим адресант

Чёрт, почему-то не происходит добавление в БД, поэтому и поток не просыпается

товарищи! Вопрос! Csv файл проще на фронте сгенерить или на беке?

а у тебя на фронте есть все данные?

Проблема видимо совсем в другом, а я с этим парюсь

да

бывает

@guga4ka с бека прилетает дто и рисуется на фронте

сейчас стоит вопрос - где проще сгенерить эту csv

да

тогда можешь на фронте сгенерить, но учти, лично я тебя прокляну

подумай о мобильных пользователях

пф, я не фронтенд разработчик)

а что с ними?

короче, в любом случае, лучше дернуть эндпоинт и получить cvs в лицо

так так же по сути и делается

даже если у тебя на фронте есть все данные, это операция займет сколько-то памяти и процессорного времени

просто надо перевеси html страницу в csv форму

ну дела)

Проблема видимо совсем в другом, а я с этим парюсь

У вас задача, которая кладет в бд отрабатывает?

ты уверен, что потребителями твоего апи будет только этот конкретный js код?

да

в любом, случае, я за бэкенд, а ты как хочешь

эх. придеться страдать

Я за бек. Если данных станет много, на фронте будут проблемы