Здравствуйте, lpc, Вы писали:
lpc> Похоже в Оракл совсем из ума выжили. lpc> http://blog.dripstat.com/removal-of-sun-misc-unsafe-a-disaster-in-the-making/ lpc> Кроме перечисленного по ссылке, джава 9 превратится в тыкву для low latency систем в финансах.
Ух.. А что там незаменимого осталось? С появлением nio, concurrent и прочего — unsafe вроде используется реже и реже.
Здравствуйте, lpc, Вы писали:
lpc> ·>Ух.. А что там незаменимого осталось? С появлением nio, concurrent и прочего — unsafe вроде используется реже и реже.
lpc> Вот видимо и в Оракл так думают, а в реальности — длинный список библиотек, без которых джава была бы (и вероятно теперь будет) ущербной.
Если библиотеки не дохлые — обновят, дохлые — проще выкинуть.
Притом, как я понимаю, править можно было начать года два назад и ещё как минимум год времени на это.
warning компилятора о том, что нельзя использовать этот класс был с рождения.
Все будет хорошо, ведь из приведенного списка больше всего пострадают библиотеки, которые использовали Unsafe для создания объектов без вызова конструкторов, а не те:
а) что выделяли память вне хипа через Unsafe, когда можно было взять DirectBuffer и никто бы не заметил (сюдя можно отнести Netty, которая находится во главе списка).
б) что обновляли поля объектов в thread safe manner, используя getFieldOffset и putXXXVolatile/Ordered.
Для а) уже давно есть nio с DirectByteBuffer-ами, которая уже упоминалась в этом треде, а б) заменят на VarHandles.
Здравствуйте, ·, Вы писали:
·>Если библиотеки не дохлые — обновят, дохлые — проще выкинуть. ·>Притом, как я понимаю, править можно было начать года два назад и ещё как минимум год времени на это.
Вопрос в том, будет ли техническая возможность обновить.
·>warning компилятора о том, что нельзя использовать этот класс был с рождения.
То есть не надо было писать эти библиотеки, нада было ждать пока в оракл дойдет сделать public api?
Здравствуйте, Joie de vivre, Вы писали:
JDV>Все будет хорошо, ведь из приведенного списка больше всего пострадают библиотеки, которые использовали Unsafe для создания объектов без вызова конструкторов, а не те: JDV> а) что выделяли память вне хипа через Unsafe, когда можно было взять DirectBuffer и никто бы не заметил (сюдя можно отнести Netty, которая находится во главе списка). JDV> б) что обновляли поля объектов в thread safe manner, используя getFieldOffset и putXXXVolatile/Ordered.
JDV>Для а) уже давно есть nio с DirectByteBuffer-ами, которая уже упоминалась в этом треде, а б) заменят на VarHandles.
К сожалению DirectByteBuffer не является полноценной заменой того что давал unsafe. Как минимум, оно делает boundary checks, которые многим нафиг не сдались и которые просаживают performance в критических местах. В этих случаях лучше быть unsafe чем переписывать все на С++ (jni тоже не всегда подходит из-за оверхеда).
Про VarHandles не знал, спасибо, есть значит маленькая надежда. Маленькая потому что судя по всему в Оракл не до конца понимают как и главное зачем люди используют Unsafe. В моей индустрии (low latency java) это то что позволяет таки писать на java, а не на С++.
Я слышал, что в 9 совсем убирать не будут, через какой-то флаг можно будет достучаться, чтобы кому надо — пока могли пользовать. И будут вводить весь нужный функционал другими способами, чтобы люди мигрировали с Unsafe.
Здравствуйте, lpc, Вы писали:
lpc> ·>Если библиотеки не дохлые — обновят, дохлые — проще выкинуть. lpc> ·>Притом, как я понимаю, править можно было начать года два назад и ещё как минимум год времени на это. lpc> Вопрос в том, будет ли техническая возможность обновить.
Для опен-сорс библиотек — конечно будет. Почему может быть нет?
lpc> ·>warning компилятора о том, что нельзя использовать этот класс был с рождения. lpc> То есть не надо было писать эти библиотеки, нада было ждать пока в оракл дойдет сделать public api?
Нет, конечно, когда выбора нет — все средства хороши. Но вполне было очевидно, что когда-то это кончится, рано или поздно. Недокументированные приватные api меняются или ломаются.
Здравствуйте, lpc, Вы писали:
lpc>Про VarHandles не знал, спасибо, есть значит маленькая надежда. Маленькая потому что судя по всему в Оракл не до конца понимают как и главное зачем люди используют Unsafe.
да все там прекрасно понимают, не понимают скорее разработчики некоторых популярных фреймворков кто на это закладывался, а раз так у них бомбануло то попутно не понимают еще и различие между private/public api.
