Главная Java-конференция в России — Joker 2017

Проводите конференции в интернете, не ? И лететь никому не надо и оплачивать ничего не надо. И по затратам ноль;)

Проводите конференции в интернете, не ? И лететь никому не надо и оплачивать ничего не надо. И по затратам ноль;)

https://www.youtube.com/watch?v=XMtKi9PJZr4

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

Чем больше различий в областях применения, чем меньше шансов, что подход «one size fits all» сработает. К.О.

эльбрус - говно. чего жалеть?

просто

http://slovarick.ru/868/

-----

Для тех, кто в теме - зачетный троллинг программистами «народных умельцев», пишущих _простой_ софт «на коленке» -

https://habrahabr.ru/post/153225/

просто - значит просто.

тебе, видимо, это понятие неведомо.

Не-а, неведомо.

http://chtooznachaet.ru/smysl-poslovicy-prostota-xuzhe-vorovstva.html

Мне ваши пословицы нафиг не нужны.

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

Мне ваши пословицы нафиг не нужны.

Как и в реальном программировании не нужны «специалисты» незнающие Spring, Hibernate, GWT и подобные технологии.

и подобные

Ничего общего в этих базвордах нет ни по смыслу ни по содержанию. так что не знаю что подразумевается под «подобные»


Ну и с трудозанятостью проблем не имею, не зная GWT ни Hibernate ни всего убогого многообразия Spring. Ибо есть более нужные умения и навыки, чем иметь в кэше мозга наборы этих (и любых других) API. Видал я этих «специалистов по технологиям». Потом исправлять за ними же нужно, залезая в кишки этих «технологий», о которых специалисты даже не подозревают.

Ради Б-га, продолжайте...

обязательно

Спасибо.

https://www.youtube.com/watch?v=VqFHdRpMeGk

В каждой первой конференции по java.

Повод же есть: Red Hat сейчас ваяет новый GC "Shenandoah", а Oracle на днях объявил о том, что они сейчас заняты ZGC

Это когда они делают побитовую операцию, а потом так озаряются на коллег с прищуренным взглядом и тихо так себе под нос... шёпотом, «я сука хакер, я апасный» =)

еще расскажи про write once, run anywhere. джава одна - на сервере. десктопная джава (идея и эклипс) будет довольствоваться тем, что есть на серверах. «архитекторы бекенда» могут сколько угодно рассуждать о том, что «когда как», но потом садятся в кружок и дружно наяривают на: короткие паузы, параллельный гц, минимальный STW, работа из коробки. То, что сборщиков дохера, говорит только о том, что работа движется и эволюция на месте не стоит, а не о том, что гц просто много на вкус и цвет.

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

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

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

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

взять например софт который Google (а не какая-то школота) сделали в качестве инструментария к разработке Андроида — ды подобного ДЕРЬМИЩА нужно ещё и поискать :-) — эти программы даже не стесняются перезаписывать промежуточные файлы внутрь чужих символьных ссылок, созданных злоумышленником по предсказуемому пути в общедоступном для записи каталоге..

.. нужно быть полным профаном-делетантом чтобы допускать такое. но по какой-то нелепой СЕКТАНСКОЙ причине Java-разработчики хотят думать будто JVM сама якобы решает все проблемы коректного поведения Java-программы в разных ОС, без необходимости знания программистом тонкостей конкретной ОС.

ды будь ты хоть трижды специалистом в кишках своего любимого компилятора\интерпрератора, но если ты не умеешь писать софт под Linux, то твои Linux-программы будут соответствующего говнокачества! :-)

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

То, что кто-то на Си налабал херотень допускающее такое, заместо изоляции приложений друг от друга, не делает прикладника «профаном-делетантом». Кто-то из прикладников, например, может впечатлиться секурностью линуха и подумать, что такие банальные вещи там уж не прокатят. А по сути Си-лошары создали дыру на дыре, а виноват конечно прикладник... И это лишь говорит об уровни чмошности разработчиков такой архитектуры, допускающие такие вещи - «нужно быть полным профаном-делетантом чтобы допускать такое» (с)

А по сути Си-лошары создали дыру на дыре, а виноват конечно прикладник... И это лишь говорит об уровни чмошности разработчиков такой архитектуры, допускающие такие вещи

тонны man-страниц написали же, разжовывающие как пользоваться системными вызовами и glibc..

с чего бы не прочитать их?

есть и открытые исходники, в которых можно посмотреть интересующие нюансы, если сомниваешься по какому-то вопросу.

ды куча информации — читай-не-хачу!

но нет — Java-разраб будет лучше сидеть и читать про свои чёртовы сборщики мусора, и всякие блоггерские статьи об очередном никчёмном фреймворке и депенденси-инъекциях через аннотации (и прочии «крутые» способы написания кода, которые как правило только приумножает проблем, делая Java-код более крассивым но зато более глупым)

о нет — Java-разраб будет лучше сидеть и читать про свои чёртовы >сборщики мусора, и всякие блоггерские статьи об очередном >никчёмном фреймворке и депенденси-инъекциях через аннотации (и >прочии «крутые» способы написания кода, которые как правило ?>только приумножает проблем, делая Java-код более крассивым но ?>зато более глупым)

Конечно, мы все должны поверить «знатоку Java». И конечно вы приведете примеры кода показывающий все эти нюансы, а еще свободно приведете примеры эквивалентного не глупого кода на С выполняющего тоже самое.

нет, это когда ты пишешь многопоточный код с учётом lock contension.

Десктопные программы с heap на 200MiB вряд ли рождают такие проблемы как класс.

взять например софт который Google (а не какая-то школота) сделали в качестве инструментария к разработке Андроида — ды подобного ДЕРЬМИЩА нужно ещё и поискать :-) — эти программы даже не стесняются перезаписывать промежуточные файлы внутрь чужих символьных ссылок, созданных злоумышленником по предсказуемому пути в общедоступном для записи каталоге..

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

а есть ли на жабе способ не резолвать ссылки при открытии дескрипторов файлов - хз.

нет, это когда ты пишешь многопоточный код с учётом lock contension.

А contention предугадывается или выясняется профилировщиком?

Это процесс творческий. Особенно если библиотеку пишешь и не знаешь наверняка в каких условиях она может использоваться.

Инструментальная поддержка нужна в том числе.

Ну и *contension -> contention

это когда ты пишешь многопоточный код с учётом lock contension.

А contention предугадывается или выясняется профилировщиком?

то процесс творческий. Особенно если библиотеку пишешь и не знаешь наверняка в каких условиях она может использоваться.

Тогда «не с учетом lock contention», а с «учетом своих предположений о lock contention». И получается почти по Кнуту.

Ну как сказать. Классический уже пример - сравни java.util.Collections.synchronizedMap() и java.util.ConcurrentHashMap.

Бенчмарки в этом деле нужны в любом случае. Гаданием сложно что-то проверять.

Ну как сказать.

Ну, например, так: «при проектировании библиотеки одним из критериев является минимизация lock contention с учетом предвидимых сценариев использования» (и возможны доработки по результатам реальной эксплуатации).

Классический уже пример - сравни java.util.Collections.synchronizedMap() и java.util.ConcurrentHashMap.

Не понял, что именно это должно показывать. Разные сценарии использования ведут к разным решениям.

synchronizedMap() использует один мьютекс на любые чтение и запись.
ConcurrentHashMap использует несколько мьютексов одновременно для увеличения параллелизма и при чтении использует мьютексы только при несинхронизированных кэшах.

Оба используются для многопоточного кода.

говно у тебя в черепной коробке, а эльбрус интересный и доклад был шикарен особенно последний.
Надеюсь может на какой нибудь конференции по джаваскрипту так-же доклад сделают про «V8 на Эльбрусе».

взять например софт который Google (а не какая-то школота) сделали в качестве инструментария к разработке Андроида

Мое личное мнение: АНДРОИД НИКАКОГО ОТНОШЕНИЯ К JAVA НЕ ИМЕЕТ

(можно на ЛОРе это как-то вставить в подпись под постом, чтобы было как в письмах у Столлмана - «не Линукс, а GNU/Linux»?)

По крайней мере, не имел до выхода Android N, на который, по слухам, таки портировали OpenJDK.

Java - это то, что проходит тесты совместимости с платформой Java. Андроид ни на Дальвике, ни на ART, их не проходит по понятной причине - потому что Андроид - не Java.

Причем Дальвик настолько убог, что они раньше на всех конференциях упрашивали пользователей не злоупотреблять ООП, а то если сильно много классов отнаследовать - оно начинает люто тормозить

Поэтому всю свою ненависть к Дальвику можешь выслать маркетологам Гугла, которые годами пытаются всех обмануть что их поделия имеют отношение к Java

У меня на прошлой работе было приложение, которое со старта выжирало терабайт памяти. Было приложение, обрабатывающее десятки тыяч транзакций в секунду. Java - средство решения проблем с производительностью, именно поэтому жабисты читают и про GC, и про тонкие детали реализации систем, и по алгоритмы, итп.

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

Если же кто-то скрипт из трех строчек пишет на Java, а не на Python или Golang, скопипастив его со StackOverflow и ни в чем не разобравшись, и потом ругается на непонятно куда девшуюся память, ему остается только посочувствовать и отрубить руки

Нет, в черепной коробке у меня эльбруса нет. У меня там мозг.

А эльбрусу место на помойке.

Не лопни от важности, то сборщик мусора захлебнется.

Этот товарищ чужой

«этот товарищ» объективно оценивает рыночную конкурентоспособность этой процессорной архитектуры и конечной продукции - т.е. процессоров, сделанных по ней.

Будет продаваться эльбрус за $10 за младшую модель - можно будет о чём-то говорить.

А вы там надувайте щёки и дальше.

Счастливчик, моей идее и с 4 гигабайтами плохо.

-Xms256m -Xmx1024m

eclipse з проектом на 50 модулей.

Понимаю и завидую. Я просто пишу на скале и у нас еще и монорепа с примерно таким же количеством модулей. Недавно пришлось пописать на ванильной джаве, я просто обалдел от того, насколько шустрее все

Это да. Билды кода на скала + play на Turion X2 1.8GHz + 1.8GiB RAM занимали по 20 минут.

интересно другое, спич о том, что люди по миру используют уже больше 5 лет.

можно с уверенностью утверждать, что там, в кулуарах, рождается будущее.

у стиви как обычно своё, особое, будущее.

Java - средство решения проблем с производительностью

именно поэтому жабисты читают и про GC

Хотел было написать тебе, но передумал. Ты и сам всё знаешь, маркетолог.

У меня вопрос к хардкорным сеньорам: где можно почитать как jvm верифицирует байт-код?

Пилю VM, и никак не могу сделать статичную проверку типов агрументов функций. В JVM это должны были решить давным-давно.

jvm specification просканируй. Ну или сорцы openjdk. Там-то уж точно найдёшь всё что нужно.

Логичный, но грустный ответ :(

стартовую точку легко ж найти - реализацию ClassLoader#loadClass в исходниках. Грепом за 30 минут точно получится.

Оба используются для многопоточного кода.

Они используются по-разному. У тех, кто их делал, было неплохое представление «в каких условиях она может использоваться».

жабисты читают и про GC, и про тонкие детали реализации систем, и по алгоритмы, итп.

...а почитав, идут в евангелисты. Наверное, есть в прочитанном что-то религиозное.

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

Разница в использовании - ConcurrentHashMap завязан на том, что там не может быть ключей и значений null. Обычный HashMap + synchronizedMap() обёртка может содержать значения null (ключи не может тоже).