|
Java 8 - уже не совсем Java?
|
|||
---|---|---|---|
#18+
mayton, толи ещё будет https://habrahabr.ru/post/280188/ ... |
|||
:
Нравится:
Не нравится:
|
|||
28.03.2016, 16:33 |
|
Java 8 - уже не совсем Java?
|
|||
---|---|---|---|
#18+
Usmanвадя, var (справочник по C#) но для написания в ide лучше четко определить - ide будет проще конторолировать. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.03.2016, 16:41 |
|
Java 8 - уже не совсем Java?
|
|||
---|---|---|---|
#18+
Почитал. ПОЛНОСТЬЮ плюсуюсь. Человек верно пишет. Все так и есть ((( ... |
|||
:
Нравится:
Не нравится:
|
|||
28.03.2016, 16:46 |
|
Java 8 - уже не совсем Java?
|
|||
---|---|---|---|
#18+
http://izm.izvm.net/zhaba/java-a.htm 17) Одно из замечательных изобретений Вирта - перечислимый тип. Жаль, что он от него отказался в Обероне. В каком-то виде этот тип пробрался даже в С. В Жабе его нет, и это очень неудобно. Вместо него - просто целые "константы", которые вовсе и не константы. Никакой проверки типов (которая была бы естественна для "надежного" языка). Иные удальцы применяют классы для этого - то есть передают указатели там, где нужно целое значение, и используют функции там, где нужно число, закодированное этим значением. В итоге программа становится совершенно нечитаемой, и к тому же на пустом месте теряется эффективность. Я не знаю (еще раз) какой датой датируется эта статья. Возможно автор апеллирует к спекам 1.4. Кроме того он часто упоминает Microsoft Visual J++. Проект который уже давно мёртв. Но ключевое слово enum работает начиная с Java 1.5 (5) и позволяет спокойно описывать перечислимые типы и даже набор методов над ними. Код: java 1. 2. 3.
... |
|||
:
Нравится:
Не нравится:
|
|||
28.03.2016, 17:41 |
|
Java 8 - уже не совсем Java?
|
|||
---|---|---|---|
#18+
27) Сама библиотека оставляет желать лучшего. Почему, например, для узнавания текущей даты я должен выделять в памяти объект? А вот еще задачка, достойная пера. Напечатать текущую дату в формате дд.мм.гггг чч:мм:чч.МММ (МММ - миллисекунды). Ну все сделано, чтобы только сделать это невозможным! Вообще, опыт практического использования библиотеки заставляет подумать, что она была сделана левой ногой пьяного матроса. Необходимо пересмотреть с учотом Java8 (java.time.*) Код: java 1. 2.
Возможно аллоцирование форматтеров перенесено в пулы и т.п. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.03.2016, 17:48 |
|
Java 8 - уже не совсем Java?
|
|||
---|---|---|---|
#18+
Только сейчас получил: java.lang.Error: Unresolved compilation problem: Б...! Этот язык компилирующий или что? Какая нафиг compilation problem в момент выполнения? ... |
|||
:
Нравится:
Не нравится:
|
|||
28.03.2016, 17:49 |
|
Java 8 - уже не совсем Java?
|
|||
---|---|---|---|
#18+
mayton Код: java 1. 2.
Возможно аллоцирование форматтеров перенесено в пулы и т.п. Если следовать логике автора, то immutable объекты это совсем за гранью. Там ведь не просто объект аллоцируется! Он на каждую операцию аллоцируется! А то что производительность GC от количества мусора почти не зависит, это ведь ещё знать надо. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.03.2016, 17:54 |
|
Java 8 - уже не совсем Java?
|
|||
---|---|---|---|
#18+
29) При написании на С много внимания уделяется всяким случаям вроде "А что если функция malloc вернула NULL?" Так вот, в Жабе считается, что память всегда есть. В общем-то никаких оснований для этого нет. А когда память кончится, будет брошена эксепция вроде OutOfMemoryException, которая есть объект и должна быть выделена в куче... В данном тезисе автор лихо играет софизмами и парадоксами (почеркнуто) тоесть не по сути. Аллокация new действительно всегда работает OK и память всегда есть. Ситуация когда ее нет - не перехватываемая ошибка и с точки зрения приложения - это авария и на ее решение вобщем-то нет рецепта нигде. Возможно behaviour систем версии 1.4 был действительно иной. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.03.2016, 17:54 |
|
Java 8 - уже не совсем Java?
|
|||
---|---|---|---|
#18+
Blazkowiczmayton Код: java 1. 2.
Возможно аллоцирование форматтеров перенесено в пулы и т.п. Если следовать логике автора, то immutable объекты это совсем за гранью. Там ведь не просто объект аллоцируется! Он на каждую операцию аллоцируется! А то что производительность GC от количества мусора почти не зависит, это ведь ещё знать надо. Станно но введение immutable объектов повысило производительность Card-Raytracer. Можно найти даже конкретный коммит где я оптимизирую Vector добавляя в него final и переписываю логику таким образом что координаты x,y,z внутри вектора отдельно не мутируют. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.03.2016, 17:57 |
|
Java 8 - уже не совсем Java?
|
|||
---|---|---|---|
#18+
BlazkowiczЕсли следовать логике автора, то immutable объекты это совсем за гранью. Там ведь не просто объект аллоцируется! Он на каждую операцию аллоцируется! А то что производительность GC от количества мусора почти не зависит, это ведь ещё знать надо. А оно не так? А производительность GC от количества мусора и размера кучи зависит очень сильно. По крайне мере в 1.6. Очень бы хотелось понять, что за GC алгоритм такой чудесный, что "почти не зависит". Да и сама по себе инструкция new - конечно очень быстрая (если сравнивать с другими языками), но не мгновенная. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.03.2016, 18:00 |
|
Java 8 - уже не совсем Java?
|
|||
---|---|---|---|
#18+
Код: sql 1.
Я наблюдал эволюцию компиллятора. И сегодня мы можем больше использовать оператор + (к примеру при перегрузке toString()) и не париться о том что конкатенация будет собрана через StringBuffer StringBuilder. Опять-же тезисы автора касались весьма древних компилляторов. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.03.2016, 18:02 |
|
Java 8 - уже не совсем Java?
|
|||
---|---|---|---|
#18+
Leonid KudryavtsevА оно не так? А производительность GC от количества мусора и размера кучи зависит очень сильно. По крайне мере в 1.6. Очень бы хотелось понять, что за GC алгоритм такой чудесный, что "почти не зависит". Да и сама по себе инструкция new - конечно очень быстрая (если сравнивать с другими языками), но не мгновенная. GC сканирует и перемещает живые объекты. Мусор при этом целиком и полностью отмирает как единое целое. Хоть его мегабайт был, хоть сто. Не важно. А вот сканирование живых объектов занимает время. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.03.2016, 18:06 |
|
Java 8 - уже не совсем Java?
|
|||
---|---|---|---|
#18+
Leonid KudryavtsevДа и сама по себе инструкция new - конечно очень быстрая (если сравнивать с другими языками), но не мгновенная. Тут надо ставить на обе чаши весов очень много аргументов. new в С++ может быть в заведомо неблагоприятных условиях. Работать по фрагментированной куче где free вроде-бы есть но целым экстентом выделить невозможно на данный момент без каких-то дополнительных действий по уплотнению. В Java - аллокация идет как на стеке без поисковых операций поэтому накладые могут быть меньше. Вобщем это уравнение со многими неизвестными. И сравнение стоимостей new/free надо делать в бенчмарках с возможностью многократного повторяемого воспроизведения условий. Я такие бенчмарки не смог создать. Хотя и обещал в части своих тяпничных блогов. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.03.2016, 18:09 |
|
Java 8 - уже не совсем Java?
|
|||
---|---|---|---|
#18+
Кто нибудь знает этого африканца? Киньте ему ссылочку сюда если можете. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.03.2016, 18:11 |
|
Java 8 - уже не совсем Java?
|
|||
---|---|---|---|
#18+
BlazkowiczLeonid KudryavtsevА оно не так? А производительность GC от количества мусора и размера кучи зависит очень сильно. По крайне мере в 1.6. Очень бы хотелось понять, что за GC алгоритм такой чудесный, что "почти не зависит". Да и сама по себе инструкция new - конечно очень быстрая (если сравнивать с другими языками), но не мгновенная. GC сканирует и перемещает живые объекты. Мусор при этом целиком и полностью отмирает как единое целое. Хоть его мегабайт был, хоть сто. Не важно. А вот сканирование живых объектов занимает время. Дьявол кроется в мелочах: 1. Eden область: Copy GC 2. Old область: Mark Sweep GC Выделение объектов ---> больше потребление памяти --> чаще вызов GC. Т.к. copy gc крайне быстро работает, то пофиг Массивное выделение объектов + частый вызов minor GC + несколько потоков - есть риск, что temporary объекты из Eden области попадуть в old область heap. А вот это уже очень плохо ((( Т.к. мусор в old области в heap - распухание heap и значительно замедление и без того медленного Mark Sweep. AFAIK note: в терминах могу ошибаться, но смысл думаю ясен Blazkowicz...Мусор при этом целиком и полностью отмирает как единое целое. Хоть его мегабайт был, хоть сто... В реальной жизни ситуации когда из Eden мусор проникает в Old - как грязи, как Eden не выкручивай. Хотя, на прошлой работе добились того, что при многозадачной работе Oracle Customer Care & Billing mark sweep GC запускался всего 1-2 раза за целый рабочий день предприятия ))) До настройки памяти (default значения) было раз в 1.5 - 2 сек + периодические out of memory. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.03.2016, 18:24 |
|
Java 8 - уже не совсем Java?
|
|||
---|---|---|---|
#18+
Leonid KudryavtsevВ реальной жизни ситуации когда из Eden мусор проникает в Old - как грязи, как Eden не выкручивай. Вот уж не знаю. Мы через ratio сводили это к минимуму. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.03.2016, 18:26 |
|
Java 8 - уже не совсем Java?
|
|||
---|---|---|---|
#18+
BlazkowiczВот уж не знаю. Мы через ratio сводили это к минимуму. А просто Eden задирал до максимуму (1/2 памяти). Остальные параметры читал, но если памяти под Eden достаточно - то и бог с ними, если мало - как мертвому припарка. Тот же Oracle Customer Care & Billing. ОДИН И ТОТ ЖЕ код выставления счета, запускаемый из Web-морды (over 300-400 Mb всякого GUI барахла в Heap) и из Batch processing (отдельная VM, в Heap мусора нет) - во втором случае работал в разы (2-3 раза) быстрее. Но у них при каждом выставлении одного счета по 200-300 Mb temporary объектов (Copy Book) создается. В общем, память гадят знатно ... |
|||
:
Нравится:
Не нравится:
|
|||
28.03.2016, 18:39 |
|
Java 8 - уже не совсем Java?
|
|||
---|---|---|---|
#18+
p.s. При этом одним временем на GC не объяснимо. Т.к. на GC уходит пусть и больше времени, но не намного. Возможно какие-то скрытые эффекты, типа фрагментации кучи и лучшего использования кэша процессора. Загадочно, но факт. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.03.2016, 18:50 |
|
Java 8 - уже не совсем Java?
|
|||
---|---|---|---|
#18+
Только мне кажется, что оптимальный код генерации счетов даст в разы бОльший эффект, чем возня с оптимизацией сборки мусора? ... |
|||
:
Нравится:
Не нравится:
|
|||
28.03.2016, 19:00 |
|
Java 8 - уже не совсем Java?
|
|||
---|---|---|---|
#18+
Basil A. SidorovТолько мне кажется, что оптимальный код генерации счетов даст в разы бОльший эффект, чем возня с оптимизацией сборки мусора? Всё зависит от трудоёмкости оптимизации этого кода. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.03.2016, 19:01 |
|
Java 8 - уже не совсем Java?
|
|||
---|---|---|---|
#18+
Это понятно. Непонятно другое. Есть проблема. Есть известный путь решения с некими затратами. Гарантированное решение с, более-менее, гарантированными затратами. Но есть ещё "эффективный менеджмент", который сразу заявляет: "Это дорого". И начинает неопределённое время сношать мозг и заказчику и самому себе. Вот чего я не могу понять. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.03.2016, 19:21 |
|
Java 8 - уже не совсем Java?
|
|||
---|---|---|---|
#18+
И сама возможность оптимизации. Код покупной. Гей-архитектор где-то на западном побережье. Код пишут пара сотен манильцев. Кому оптимизировать ? ))) Там и так, все в лучших традициях ООП - патерн на патерне и патерном погоняет. Самая крутой патерн - Copy book. Дает работу огромному кол-ву манильцев. Без него, кол-во бедных в маниле было бы намного больше ))) ... |
|||
:
Нравится:
Не нравится:
|
|||
28.03.2016, 19:23 |
|
Java 8 - уже не совсем Java?
|
|||
---|---|---|---|
#18+
Basil A. Sidorov...Есть проблема.... Да нет там проблемы. 1 .Решение масштабируемое - купите еще N серверов, считать будет в N раз быстрее. 2. Выставляется счет через интерфейс за 1 сек или за 3 сек - пользователю в целом пофиг. 3. При ситуациях "когда ночной batch процесс не успевает за ночь закончится" ( C ) см. п. 1 Или сервер можно перевезти в Варкуту. Там зимой ночи длиннее ))) ... |
|||
:
Нравится:
Не нравится:
|
|||
28.03.2016, 19:26 |
|
Java 8 - уже не совсем Java?
|
|||
---|---|---|---|
#18+
maytonКто нибудь знает этого африканца? Киньте ему ссылочку сюда если можете. зачем? Выбери, чего ты чего на самом деле хочешь: - узнать, как изменилось его мнение с тех пор - спросить - почему не оправдались его прогнозы о недолгой жизни обсуждаемого им сабжа - хочешь, поспорив с ним по каким-то конкретным деталям, опровергнуть его взгляд в целом ? Последнее, имхо, бессмысленно. Прими в расчет следующее: - тот сайт литературный , и предложенные тобой заметки, по сути, являются литературным произведением для программистов. - На том сайте последнее сообщение размещено в 2008 году, а обсуждаемые заметки я склонен отнести по косвенным признакам к 2000-му году, т.е. ко времени jdk 1.3 - (имхо) в целом, сам по себе текст Африканца в техническом плане весьма приличного качества. Но, писался в , как мне кажется, несколько второпях, преследуя больше литературные цели, чем цель последовательного "опровержения" языка. Его литературная задача мне понятна - заявить, что вместе с явой в мир программирования громко и напористо приходит агрессивный непрофессионализм, активно порождающий собственный мир не просто заявляющий право на существование, а претендующий на абсолютное заполнение всего пространства программирования. (Это умом объять невозможно - говорят, что в мире уже 19 миллионов java-программистов, а скоро станет 25. Т.е. уже больше 2.5 java-программистов на каждую 1000 душ населения Земли. Для сравнения: в 1904 году в городах Западной Европы в среднем было 4 извозчика на 1000 городских душ. В России, правда, заметно больше - от 3.38 в Лодзи с пригородами (это ровно как если бы уже сейчас было 25 миллионов java-программистов в расчете на 1000 ныне живущего на Земле населения) до 18.8 в Москве. ) По технике его замечания касаются синтаксиса, быстродействия, пригодности к созданию "больших проектов". По части синтаксиса - это больше "вопросы вкуса", даже там, где это касается простоты или сложности или "наивности" предполагаемого компилятора. По части всего остального - общий ответ примерно такой - java никогда (до сих пор) не позиционировалась как средство создания критичных по производительности систем или систем реального времени. Уж как минимум - не позиционировалась так создателями языка. Для задачи доставки компактных аплетов в браузер клиента в ней с самого начала всего достаточно. И вряд ли стоит упрекать создателей в том, что у языка фактическая жизнь оказалась и дольше, чем можно было бы ожидать, и, в конце концов, совсем другого назначения. Решения сорта жить или умирать принимаются не ими. Даже если это кому-нибудь обидно (например - Вирту). PS Все сказанное выше исключительно "по моему скромному мнению". Кто такой Африканец я не знаю. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.03.2016, 23:44 |
|
|
start [/forum/topic.php?fid=59&msg=39202427&tid=2120495]: |
0ms |
get settings: |
10ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
32ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
62ms |
get tp. blocked users: |
1ms |
others: | 276ms |
total: | 415ms |
0 / 0 |