ни одной

игра будет может быть на обезьяне

сколько игорей было написано на жабафх?

писать игры на UI-фреймворке?)

а то что её будет скачивать

ставить и прочее на fx

На сорсфорже видел эмулятор марсианской колонии

это извращение, но идея интересна, да и на чём ещё кодить?

Никогда не понимал, зачем такое делать Разве что если фронтендеров найти не смогли

Это же с жпоинта последнего, можешь глянуть чтобы понять зачем

а может идею переписали на жабафх что она такая стала

не на qt же кодить ui

а может идею переписали на жабафх что она такая стала

какая? Идея на свинге до сих пор, я думаю

а может идею переписали на жабафх что она такая стала

У них же свинг со своими компонентами

А жавафх нормальная штука

бек на жабафх?

не увидел )

бек? бэкенд?

ват

имел ввиду что на бекенде в играх джаву юзают

это мы уже выяснили

Это же с жпоинта последнего, можешь глянуть чтобы понять зачем

Да про это вроде и статья на хабре была, но я как-то не проникся этой идеей

я видел как на спринге игровой сервер писали

как вы кстати относитель к функциональщине?

одни говорят это ад

другие рай

я что-то думаю что и там и там ад

"Builder-style использование методов" что это значит?

дай контекст

"Builder-style использование методов" что это значит?

вангую что про шаблон проектирования "builder"

fun arrayOfMinusOnes(size: Int): IntArray { return IntArray(size).apply { fill(-1) } }

вроде понятно

но непонятно что это значит

Вопрос - насколько корректно утверждение, что синхронизация решает проблему видимости?

опять в памяти не отложится и забуду как юзать

но непонятно что это значит

возвращается объект, который пришел на вход.

Вопрос - насколько корректно утверждение, что синхронизация решает проблему видимости?

ну решает

и ты дальше можешь вызывать еще один метод

Во всех случаях?

О_О

круто

Во всех случаях?

нет, только если используется правильно)

fun arrayOfMinusOnes(size: Int): IntArray { return IntArray(size).apply { fill(-1) } }

это котлин штоле ?

Во всех случаях?

А все случаи это какие ?

котлин да

убого выглядит. простите если кого обидел

я его изучаю

в целом это функционально

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

в целом это функционально

а?

ну это одна из фич такого синтаксиса

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

что?

смотри

public static final Vobla getGoldVobla(params ...)

и тебе нужно

резко

заменить возвращаемый тип c Vobla на GoldVobla

Под всеми случаями я подразумеваю утверждение: проблема видимости может быть всегда разрешена средствами синхронизации Естественно, речь не идет о том, что кто-то неправильно написал синхронизированный код, не решающий вопрос

пока ты туда курсор поставишь

и так тысячи раз

особенно когда баг ищешь

а тут он в конце

оп Ctrl + стрекла вправо

или влево если с нижней строки

и ты у цели

и тип сразу видно

Под всеми случаями я подразумеваю утверждение: проблема видимости может быть всегда разрешена средствами синхронизации Естественно, речь не идет о том, что кто-то неправильно написал синхронизированный код, не решающий вопрос

В такой постановке - всегда. Но утверждение не несёт смысла, по крайней мере для меня

убого выглядит. простите если кого обидел

ещё можно вим освоить тогда проблема подстановки типа уйдёт может быть

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

в общем немного бесит

в итоге это всё равно долго

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

и править сидеть чтобы выглядело огонь

и там минус если где-то забыл

Точнее: я бы даже сказал - не понимаю, что ты проверяешь. Но да, после выхода из synchronize все записи в переменные будут видны в других потоках, которые прошли тот же synchronize(на том же блоке взаимного исключения)

Т.е для синхронизированного блока существуют гарантии на чтение и запись, подобно тем, которые есть для volatile переменных? Изменения переменных в синхронизированном блоке обязательно записываются в память, а чтение в синхронизированном блоке осуществляется напрямую из RAM, или что-то в этом роде?

Т.е для синхронизированного блока существуют гарантии на чтение и запись, подобно тем, которые есть для volatile переменных? Изменения переменных в синхронизированном блоке обязательно записываются в память, а чтение в синхронизированном блоке осуществляется напрямую из RAM, или что-то в этом роде?

1 вопрос - да. 2) Изменения всегда записываются в основную память, но, запись в блоке - инвалидирует кеш, поэтому следующее чтение в том же блоке, увидит инвалидированный кешлайн и пойдёт в память за новым значением.

Т.е для синхронизированного блока существуют гарантии на чтение и запись, подобно тем, которые есть для volatile переменных? Изменения переменных в синхронизированном блоке обязательно записываются в память, а чтение в синхронизированном блоке осуществляется напрямую из RAM, или что-то в этом роде?

Про запись в память и "напрямую из RAM" JMM ничего не говорит. Но запись переменной в synchronized-блоке видна при её чтении в другом потоке в этом synchronized-блоке

А как это может достигаться, если не через RAM? Если я изменил переменную в кеше на одном ЦП, но не записал в память, как тред на другом ЦП увидит изменения?

(При следующем чтении)

А как это может достигаться, если не через RAM? Если я изменил переменную в кеше на одном ЦП, но не записал в память, как тред на другом ЦП увидит изменения?

Он сказал, что в спеке не сказано. А как это реализовано в конкретной jvm хз, но предполагаю что через RAM

А как это может достигаться, если не через RAM? Если я изменил переменную в кеше на одном ЦП, но не записал в память, как тред на другом ЦП увидит изменения?

об этом за вас уже подумали. https://ru.wikipedia.org/wiki/%D0%9A%D0%BE%D0%B3%D0%B5%D1%80%D0%B5%D0%BD%D1%82%D0%BD%D0%BE%D1%81%D1%82%D1%8C_%D0%BA%D1%8D%D1%88%D0%B0

для интеловых cpu точно гарантируется. для ARM - хз, думаю тож

А как это может достигаться, если не через RAM? Если я изменил переменную в кеше на одном ЦП, но не записал в память, как тред на другом ЦП увидит изменения?

Ну по факту только так. Но лучше не полагаться на это. А если например JVM точно знает, что оба потока выполняются на том же ядре? Тогда третий поток (на другом ядре/ЦП) может ничего и не увидеть, если будет полагаться на то, что "ну там же synchronized, зачит, в RAM есть".

Вроде ж jvm только про happens before говорит а все остальное это уже нюансы реализации

Не?

Понятно! Т.е, по сути, volatile может в подавляющем большинстве случаев быть заменено приемами синхронизации. А зачем тогда его использовать вообще? Ради выигрыша в производительности в отдельных случаях?

Да

Понятно! Т.е, по сути, volatile может в подавляющем большинстве случаев быть заменено приемами синхронизации. А зачем тогда его использовать вообще? Ради выигрыша в производительности в отдельных случаях?

Ну например https://www.javaworld.com/article/2074979/java-concurrency/double-checked-locking--clever--but-broken.html

Понятно! Т.е, по сути, volatile может в подавляющем большинстве случаев быть заменено приемами синхронизации. А зачем тогда его использовать вообще? Ради выигрыша в производительности в отдельных случаях?

Volatile не гарантируют атомарности

Понятно! Т.е, по сути, volatile может в подавляющем большинстве случаев быть заменено приемами синхронизации. А зачем тогда его использовать вообще? Ради выигрыша в производительности в отдельных случаях?

Но вообще да, если все операции над общими данными выполнять в synchronized, то всё будет ок. Но так можно быстро познакомиться с дедлоками. Да и различие в производительности может быть существенным.

Volatile не гарантируют атомарности

Ну точнее как. Если есть несколько действий на переменными volatile факапит

Тут приходит на помощь synchronize

Ну точнее как. Если есть несколько действий на переменными volatile факапит

Запись и чтения - конечно атомарны

Ну точнее как. Если есть несколько действий на переменными volatile факапит

Например, volatile int++?

Ну точнее как. Если есть несколько действий на переменными volatile факапит

CAS в помощь

Да, так как оно раскладывается в три инструкции

CAS в помощь

Это понятно